Agile Software Development with

Sacrum. Ken Schwaber, Mike Beedle

Agile Project Management with Scum. Ken Schwaber

The Enterprise and Scam. Ken Schwaber

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

Sacrum.

Scam.

Ile jest Scruma w Scrumie?

bnd 1.00.00

Scum. Tomasz Włodarek

Scrum jest obecny w Polsce. Firmy różnej skali, branż, pochodzeniu kapitału. Offshoring, nearshoring, rodzime. Od kilku lat. Wszędzie. Najbardziej popularna ze wszystkich zwinnych metod: 58% Scrum, 17% hybryda Scruma z programowaniem ekstremalnym (XP), pozostałe łącznie 25% (w tym własne odmiany 5%).

State of Agile Survey. 5th annual State of Agile Software Development Survey.

VersionOne Inc., 2010

Skąd się wziął? Jest głównie promowany oddolnie przez zespoły projektowe 70%, coraz częściej postrzegany jest jako wymóg branży 33%, rzadziej wdrażany decyzją kierownictwa 26% czy jako wymóg klienta 15%. To interesujący fakt. Warto o tym pamiętać.

Scrum w Polsce. Raport z badań. red. dr M.Ćwiklicki

UEK, 2009

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

agile (Agile Software Development)

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

Zwinność (ang. agility) oznacza potencjał – w sferze umiejętności i możliwości – do szybkiego i sprawnego dostosowywania się do zachodzących zmian.

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

…natychmiast pojawiają się wykręty – ScrumButs. ScrumButs to „powody”, dla których nie można w pełni wykorzystać Scruma, by rozwiązać problemy i uzyskać spodziewanych korzyści.

ScreamM

aster podczas wdrażania Scruma…

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

(Wykręt)(Powód)(Alternatywa)

Scrumujemy, ale (nasz Product Owner nie ma czasu)(bo jest bardzo zajęty swoimi sprawami)(więc Product Backlog jest przygotowywany przez Scrum Mastera) Scrumujemy, ale (Product Backlog jest zamrożony)(bo nasz PM wymaga od nas deklaracji co do zakresu i czasu)(więc nie robimy testów, żeby wyrobić się na koniec Sprintów) Scrumujemy, ale (właściwie granice sprintów są umowne)(bo i tak ciągle wchodzi coś nowego)(więc po prostu lecimy z robotą)

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

(Wykręt)(Powód)(Alternatywa)

Scrumujemy, ale (nie oddajemy Product Ownerowi pracy co sprint)(bo nie mamy testerów w zespole, a zresztą i tak trzeba by się integrować z innymi)(więc zespół QA robi dla nas testy na koniec projektu) Scrumujemy, ale (nie robimy Sprint Review)(bo i tak nikt tego nie rozumie)(więc pokazujemy coś Product Ownerowi średnio raz na pół roku) Scrumujemy, ale (retrospektywy to strata czasu)(bo i tak się nic nie zmienia)(więc po prostu ich nie robimy)

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

Fasada. Scrum but. WAGILE*. Quasi–agile. Flaccid Scrum. Kanban? *waterfall agile (sic!)

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

ScrumButs to przejaw postaw kulturowych, tradycyjnie stosowanych praktyk i przyzwyczajeń.

Pierwotny strach przed nieznanym

– Ale przecież działamy, jakoś to idzie. Oczywiście mamy problemy, ale kto ich nie ma!? Po co to zmieniać? §  Scrum wymaga zmiany kultury organizacyjnej. Wprowadza rytm i przyspiesza realizację

projektów. Organizacja „wyszczupla się” i staje się bardziej efektywna.

§  Otwartość i przejrzystość wymagane przez Scruma to nowy sposób robienia biznesu. Ceniona jest aktywność, kreatywność i innowacyjność, punktuje się marnotrawstwo, politykierstwo i arogancję. Decyzyjność przesuwana jest w dół hierarchii. Czasem wymagana jest zmiana struktury organizacyjnej. Czasem wymagane jest nabycie nowych kompetencji. Zdarza się, że ktoś odchodzi z tego powodu.

§  Taka zmiana wywołuje strach i opór (od pasywnego do aktywnego) i wymaga odpowiedniego podejścia (otwartości i konsekwencji). Jest ceną, którą płaci się za zwiększoną efektywność organizacji.

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

Strach przed rozmyciem terminów (zupełnie jakbyśmy teraz je kontrolowali)

– W Scrumie nie mogę wyznaczać kamieni milowych. Nie da się wyznaczyć i monitorować ścieżki krytycznej. Nie wiem jaki jest status projektu. To nie dopuszczalne! §  Nieporozumienie. W Scrumie nie planuje się sekwencji czynności, nie tworzy się diagramu

Gantta (finish-or-perish!), nie wyznacza się ścieżki krytycznej. Plan zorientowany jest na produkt (wykonane zakresy funkcjonalności, podnoszące wartość produktu), a nie czynności (zadania) prowadzące do ich wytworzenia.

§  Kamienie milowe wynikają z ograniczeń czasowych (time–boxes) i obowiązują zarówno na poziomie Sprintu i spotkań w jego trakcie, jak i na poziomie wydań.

§  Można je określić mianem nieprzekraczalnych są bowiem stałym elementem procesu. Pozwala to lepiej kontrolować ryzyko, zwiększa dyscyplinę i motywację.

§  Dodatkowo na podstawie danych historycznych (empirycznych) można wyznaczyć kiedy zostanie osiągnięty określony zakres funkcjonalny, jaki zakres prac zostanie wykonany w określonym czasie etc.

§  Ocena kondycji projektu dokonywana jest na podstawie „twardego” dowodu – działającego (lub nie) oprogramowania o określonej wartości, a nie mętnych miar.

§  Szybko widać, że są problemy. Scrum to narzędzie zarządzania ryzykiem.

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

Strach przed pełzającym zakresem

– Jak możemy się zdeklarować do czegokolwiek bez spisania kontraktu na zakres / bez książki wymagań / bez solidnej dokumentacji analitycznej / bez kompleksowego projektu architekury systemu?

§  Pełzanie zakresu jest podstawowym problemem w klasycznych projektach, kontraktowanych na zakres i czas, realizowanych kaskadowo.

§  Ocenia się, że mimo ogromnych nakładów na etap wstępnego planowania średnio 35% wymagań ulega zmianie w trakcie prac, a około 60% dostarczonej funkcjonalności jest używane rzadko lub wcale. Sprawę pogarsza dyskusyjna kwestia zgłaszanych w ramach gwarancji „usterek” („w dokumentacji po uzgodnieniach nie było co prawda mowy, że ma być, ale nie było też mowy, że ma nie być”)

§  Scrum rozwiązuje tę kwestię poprzez ideę etapowego osiągania celów biznesowych, dynamicznego planowania i zaprzęgnięcie zachodzących zmian do wytworzenia przełomowego produktu.

§  Scrum dopuszcza zmianę zakresu (wyjątkiem jest okres realizacji Sprintu), przy czym ograniczenie czasowe na wydanie (zakontraktowana liczba Sprintów) lub Sprint (stała liczba dni) wymusza dokonywanie racjonalnych wyborów odnośnie realizacji poszczególnych funkcjonalności. Dotyczy to zarówno ich liczby jak i „bogactwa”.

§  Dobór zakresu pracy do kolejnego Sprintu (czy wydania) jest dokonywany przez zestawienie potrzeb biznesowych Product Ownera z realnymi możliwościami produkcyjnymi Zespołu.

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

Strach przed utratą kontroli nad budżetem

– Ile to będzie kosztować? – Ale co dokładnie mamy zrobić? – Nie wiem, to wy jesteście specjalistami, powinniście to wiedzieć!

§  Klasyczne metody przyzwyczaiły nas do planowania budżetu na podstawie ustalonego zakresu prac. Tyle, że zwykle nie bardzo wiadomo czego dokładnie oczekujemy, jakie niespodzianki czekają nas po drodze i jak nasze wymagania będą się zmieniać w czasie.

§  Większość klasycznie realizowanych projektów IT przekracza budżet o 150% do 1000%, przechodząc przez czasochłonny i stresujący dla obu stron proces zarządzania zmianą.

§  W Scrumie ryzyko pozornie jest większe ze względu na możliwość zmiany zakresu, ale:

§  koszty są namacalne i policzalne (każdy Sprint kosztuje w przybliżeniu tyle samo i daje efekt w postaci gotowego oprogramowania)

§  co Sprint uzyskujemy informację zwrotną

§  na tej podstawie zarządzamy ryzykiem np. dostosowując zakres prac do realiów i rzeczywistych potrzeb

§  Jest spora szansa, że osiągniemy oprogramowanie spełniające nasze potrzeby (faktyczne, nie wydumane) zanim wydamy cały przeznaczony na projekt budżet.

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

Strach przed spowolnieniem tempa prac

– Mamy 42 projekty w toku, do każdego z nich przypisane są zasoby. Nie możemy tych ludzi nagle przekonfigurować w zespoły scrumowe i pozwolić im skupić się na pojedynczych funkcjonalnościach. Cała organizacja zwolni.

§  Klasyczne projekty realizowane są przez wyznaczone do tego osoby i zarządzane przez kierowników projektów. Po zakończeniu prac osoby te przypisywane są do nowych projektów, niekonieczne w tym samym składzie, niekoniecznie w tym samym obszarze systemu. Ogranicza to ich poczucie odpowiedzialności za jakość wykonanej pracy. Cierpi na tym także współpraca zespołowa. Te grupy pracownicze w istocie nie są zespołami i muszą być zarządzane.

§  Ponieważ projekty się spóźniają i zawierają błędy pojawiają się trudności w zarządzaniu zasobami, często te same osoby jednocześnie uczestniczą w realizacji wielu projektów, co pozornie zwiększa ilość pracy wykonywanej. W rzeczywistości zostaje wykonana mniejsza ilość pracy, a wykonanie każdej części pracy jest wielokrotnie droższe. Zaczyna się polityka, pojawiają się naciski i rywalizacja o (kluczowe) zasoby. Praca wykonywana jest gorzej i mniej kreatywnie. To kula śniegowa.

§  Podstawą wysokiej (hiper) produktywności zespołów scrumowych jest stabilność ich składu i samoorganizacja wokół celów wyznaczanych przez jednego Product Ownera.

§  Zespół z czasem wypracowuje stabilne tempo pracy, właściwe dla składu danej grupy i środowiska projektowego. Nie wszystkim to tempo będzie odpowiadać. Niektórzy żyją w świecie marzeń. Zamiast frustrować się, że rzeczywistość nie spełnia naszych oczekiwań, lepiej jest poznać co mamy do dyspozycji i przemyśleć jak najlepiej to wykorzystać.

§  Zapewne mniej pracy będzie wykonywane jednocześnie, ale dzięki temu będzie ona kończona szybciej. Poprawiona zostanie przewidywalność i jakość.

§  Scrum dopuszcza możliwość realizowania przez jeden zespół scrumowy wielu projektów jednocześnie (np. dla różnych klientów) w obrębie jednego produktu (wspólnej bazy).

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

paralelioza

Niebezpieczna choroba wywołująca błędne przekonanie, że więcej pracy zostanie zrobione jeśli więcej będzie wykonywane jednocześnie.

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

Strach przed utratą kontroli (oddaniem odpowiedzialności)

– Oni mają decydować?! Przecież będą tak robić żeby się nie narobić! Na ludziach można cokolwiek wymóc tylko z pozycji siły!

§  Klasyczny kierownik ponosi pełną odpowiedzialność (za projekt, za produkt, za zespół). Podejmuje decyzje i wydaje dyspozycje – często pod presją czasu, w oparciu o nikłą znajomość tematu i opinie osób trzecich. W razie kłopotów staje się kozłem ofiarnym i sprawa jest jasna. Czyżby?

§  Ponieważ (zwykle) mamy do czynienia ze złożonymi przedsięwzięciami, nikt nie jest w stanie podejmować racjonalnych decyzji jednoosobowo.

§  Mimo to oddając decyzyjność w dół hierarchii obawiamy się rozmycia odpowiedzialności i nieracjonalnego zachowania ludzi, którym powierzamy obowiązki. Brak zaufania?

§  Scrum w klarowny sposób rozdziela odpowiedzialność pomiędzy Product Ownera (biznes), Zespół (propozycje rozwiązań technicznych) i Scrum Mastera (proces i wsparcie organizacyjne).

§  Kontrola jest częsta (co dzień, co Sprint, co wydanie), jest przeprowadzana na różnych poziomach przez kwalifikowane do tego osoby i jest elementem procesu (jest nieuchronna). Wszystko to zwiększa zaangażowanie i motywację do przejawiania odpowiedzialnych zachowań.

§  Decyzje podejmowane są periodycznie (co Sprint) na podstawie empirycznie stwierdzonych faktów (przyrost lub jego brak) w sposób przejrzysty (jawny). Z faktami nie da się dyskutować. Przejrzystość usuwa politykę. Nie wszystkim to odpowiada.

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

samoorganizacja

Szybka reakcja na dynamikę otoczenia. Skrócenie czasu podejmowania decyzji. Lepsze rozpoznanie potrzeb, lepsze dopasowanie nakładów do potrzeb. Wzrost motywacji. Odpowiedzialność.

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

samoorganizacja?

Osłabienie zewnętrznej kontroli, ograniczenie ingerencji kierownictwa. Większa swoboda działania w zamian za obietnicę zwiększonego zaangażowania.

Autonomia. Czy może anarchia?

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

brak czasu a zatem i przyzwolenia na

popełnianie błędów

fundamentalna potrzeba pewności i gwarancji

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

kontrola, kontrola, kontrola Phone Driven Development (PDD)

Ograniczanie dostępu do informacji. Brak bezpośredniego kontaktu z klientem lub osobami, które go reprezentują. Brak wglądu w długofalowe plany. (wkrada się kaskadowość) Ograniczanie decyzyjności. Długa i zawiła ścieżka decyzyjna. (wkrada się kaskadowość) Ograniczanie interdyscyplinarności. Osoby o różnych kompetencjach zaangażowane w przedsięwzięcie pracują w izolacji od siebie. Potrzebni pośrednicy i koordynatorzy. Planowanie zasobów. (wkrada się kaskadowość) Ograniczanie autonomii. Rozdzielanie zadań. Wymuszanie zobowiązania. (wkrada się kaskadowość) Ograniczenie zaufania. Zwiększone nakłady na zewnętrzną kontrolę. Zmniejszone poczucie odpowiedzialności.

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

§  Odwołanie do procesu/planu. Zabijamy kreatywność. W najlepszym przypadku otrzymujemy perfekcyjnie wykonaną przeciętność.

§  Przyzwyczajenie. Zawsze tak robiliśmy. Postępuję tak jak moi przełożeni. Taką mamy kulturę pracy.

§  Pułapka odpowiedzialności. Jestem za to odpowiedzialny, powierzono mi te obowiązki. Muszę się upewnić, że wszystko będzie wykonane prawidłowo.

§  Po prostu powiem im kto/kiedy/jak ma to zrobić. Mikro-zarządzanie (być może zarządzanie w ogólności) wydaje się być łatwiejsze niż przywództwo. W istocie jest bardziej angażujące i daje znacznie gorsze rezultaty długofalowe.

§  Powiem im też, że mają to zrobić bezbłędnie, bo jak nie… Tak, to bez wątpienia pomaga. Podobnie jak komenda “pracuj szybciej”.

§  Arogancja i/lub ignorancja. Kiedy brakuje zaufania i wzajemnego szacunku pozostają jedynie rozwiązania siłowe. Tymi przypadkami nie chcę się nawet zajmować.

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

będzie pan zadowolony

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

§  Założeniem Scruma jest fakt, że przedmiotem podlegającym częstej kontroli jest coś zrozumiałego dla wszystkich zainteresowanych, coś podlegającego wszechstronnej ocenie.

§  Nie abstrakt (dokument, formularz, projekt, prezentacja, kolor raportu, procent zaawansowania). Konkret. Dowód.

§  Zintegrowany, przetestowany, działający software.

§  Na całe szczęście to potrafimy robić, prawda?

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

Prawie, właściwie, praktycznie, teoretycznie, zasadniczo, jakby, generalnie, ogólnie rzecz biorąc, z grubsza… w 90% skończone.

Strach przed przejęciem kontroli (podjęciem odpowiedzialności)

– Scrum jest kolejną sztuczką managementu, żeby nas jeszcze bardziej przycisnąć. To teraz mamy jeszcze robić ich robotę?!

§  Nieporozumienie. W Scrumie odpowiedzialność jest przesuwana w dół hierarchii wraz z decyzyjnością. To Zespół proponuje rozwiązania, Zespół z Product Ownerem ustala realny poziom oczekiwań i Zespół deklaruje ile pracy może zostać wykonane w Sprincie.

§  Scrum bazuje na wysokiej motywacji do wykonania dobrej pracy. Motywacja wynika z głębokiego poczucia sensu wykonywanej pracy i poczucia wpływu na bieg wydarzeń. Potrzebna jest przejrzysta i bogata informacja kontekstowa.

§  Niewiele osób jest przyzwyczajonych do takiego stylu pracy. Niektóre osoby w ogóle się do tego nie nadają. Niektórzy po prostu potrzebują kierownika. Takie osoby nie zagrzeją miejsca w zespole scrumowym.

§  Jeśli produktywność Zespołu nie jest zgodna z oczekiwaną, Zespół poszukuje sposobów jej zwiększenia. Proponuje rozwiązania i oczekuje wsparcia kierownictwa w tym zakresie.

§  Wypracowanie takiego podejścia wymaga czasu. Najmniejszy przejaw braku przejrzystości, łamania ustaleń czy braku konsekwencji będzie powodować szybki i gwałtowny regres. To jedno z najczęstszych miejsc załamania.

§  Niemniej – jeśli mimo tych wszystkich wysiłków – przedsięwzięcie nie spełnia podstawowych założeń biznesowych, zamyka się je a Zespół jest rozwiązywany lub zmienia się jego skład. Nikt nie powinien być zaskoczony takim obrotem spraw.

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

Strach przed zaangażowaniem (lub obnażeniem braku kompetencji)

– Mam teraz co dwa tygodnie pokazywać jak to działa komuś z biznesu, szkoda czasu, to techniczne sprawy i tak nie skapują! –Przecież dewelopment nie operuje podstawowymi pojęciami i nie zna założeń biznesowych! Nie mam czasu na takie pierdoły.

§  Końcowi odbiorcy i reprezentujący ich przedstawiciele biznesu (marketing, Product Management, etc.) nie są przyzwyczajeni do współuczestniczenia w procesie produkcji oprogramowania. Rezultaty są opłakane (przepaść komunikacyjna, produkty nie spełniające oczekiwań, przerzucanie się winą).

§  Ponieważ software jest zazwyczaj częścią większej całości, Scrum angażuje obie strony w proces wytwórczy. Obie strony muszą pokonać opór przed wejściem na obszar leżący poza ich podstawowymi kompetencjami. Dialog prowadzony z równorzędnych pozycji – obie strony są od siebie wzajemnie zależne – jest kluczem.

§  Jest to możliwe tylko przy założeniu, że proces planowania będzie przejrzysty (informacja kontekstowa – nie tylko co, ale również po co), a swoboda realizacyjna będzie prowadzić do wytworzenia zrozumiałego dla wszystkich i kompletnego (ukończonego) przyrostu. Przejrzystość usuwa politykę. Nie wszystkim to odpowiada. Niektórzy zrobią wszystko by zapobiec przejrzystości.

§  Użycie Scruma często prowadzi do odkrycia, że niechęć do współpracy ma swoje źródło w fakcie, że dewelopment ma poważne braki na poziomie inżynierii oprogramowania i/lub biznes niedomaga pod względem wizji produktu, planowania strategicznego czy komunikacji.

§  Scrum szybko daje namacalne wyniki w postaci konkretnych obserwacji. To fakty na których można budować. Jeśli będą one prowadzić do zmian, stopniowo zwiększy się zaangażowanie po obu stronach.

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

Framework within which people can address complex problems and productively and creatively develop products of the highest possible value.

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

”

“

–Ken Schwaber

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

”

“

–?!

Process can address complex problems and develop products for the lowest possible cost.

which

Scrum umożliwia tranzycję

Scrum: (1) narzędzie wykorzystywane do osiągnięcia zwinności (2) ramy metodyczne (framework), w obrębie których ludzie mogą rozwiązywać złożone problemy, tworząc w ten sposób, kreatywnie i produktywnie, produkty o najwyższej możliwej wartości. §  proste reguły i ograniczenia czasowe (time-boxed containers) pozwalają

zapanować nad chaosem

§  oparcie dla szeregu lekkich (lean) praktyk

Scrum jest modelem koncepcyjnym, narzędziem, które pomaga ustalić co jest przeszkodą w produkowaniu oprogramowania o wyższej jakości, lepiej, szybciej. Redukuje zlożoność i pozwala lepiej kontrolować ryzyko. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

wybita szyba

Członkowie zespołu samoorganizującego się asymilują się z otoczeniem

poprzez obserwację, naśladownictwo i wzmocnienie. W ten sposób (powoli) tworzy się kodeks zachowań, którym posługuje się grupa.

Daj przykład, a efekt przyjdzie sam. Cierpliwości. Niepożądane

zachowania (zwykle wygodniejsze) są zazwyczaj przejmowane szybciej niż poprawne.

Brak jednoznacznej, stanowczej i konsekwentnej korekty niepożądanych

zjawisk (czy zachowań) zawsze prowadzi do ich eskalacji.

Jeśli komuś na czymś nie zależy jest spora szansa, że za chwilę nikomu na niczym nie będzie zależało.

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

Wszyscy docenią Scruma, bowiem opisuje on dokładnie to, co robimy, gdy zostaniemy przyparci do muru.

–Jim Coplien (The Scrum Guide, Ken Schwaber, Jeff Sutherland)

Paradoksalnie, dopiero kiedy jest naprawdę tragicznie zaczynamy postępować właściwie – zbieramy zespół i odwołując się do nadrzędnego celu, prosimy o pomoc i zaangażowanie, deklarując pełne wsparcie i dając wolną rękę. Byle nie było za późno.

ScreamM

aster

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

to musi wejść w krew

Nie da się robić agile’a – trzeba być agile. Poszczególne elementy, techniki i sztuczki nie wystarczą. Liczy się koncept (przesłanie) i umiejętność wykorzystania całego modelu w praktyce.

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

Nawet kulawy Scrum pomaga. Krótszy czas wprowadzenia produktu na rynek 63%*, lepsza zdolność do absorbowania zmian 86%*, wzrost produktywności 86%*, wzrost jakości produktu 71%*, poprawa komunikacji 93%*, wzrost morale 78%*, spadek ryzyka niepowodzenia projektu 63%*, neutralny wpływ na koszty realizacji projektu. 41%* wskazuje na pełny sukces realizowanych projektów. Jakby to wyglądało gdybyśmy wykorzystali go w pełni?

Scrum w Polsce. Raport z badań. red. dr M.Ćwiklicki UEK, 2009

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

dziękuję!

© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

Tomasz Włodarek Projekty szkoleniowo-doradcze realizowane m.in. dla: ABG S.A., Anixe Polska, Apriso Polska, Asseco Business Solutions S.A., ATSI S.A., BLStream, CCA Europe, CD Projekt RED, Copi S.A., GE Money Bank S.A., Getin Bank S.A., Hurra Communications, Logintrans, Nokaut.pl, Quantum Software S.A., Grupa Allegro, RST, Sterkom, Spot.pl, Travelplanet.pl, TRW Polska, TVN, Volantis Systems, VSoft S.A., Young Digital Planet S.A.

tomek@poddrzewem.pl http://www.poddrzewem.pl

http://www.linkedin.com/in/wlodarek On our loss of wisdom, Barry Schwartz, TED talk http://www.ted.com/talks/barry_schwartz_on_our_loss_of_wisdom.html

The child–driven education, Sugata Mitra, TED talk http://www.ted.com/talks/sugata_mitra_the_child_driven_education.html

Scrum Guide. K.Schwaber, J.Sutherland Scrum w Polsce. Raport z badań. red. dr M.Ćwiklicki, UEK, 2009

Metodyka Scrum w Polsce w świetle badań. M.Ćwiklicki, T.Włodarek, kwartalnik Nauka i gospodarka, 2010

State of Agile Survey. 5th annual State of Agile Software Development Survey, VersionOne Inc., 2010

Agile Software Development with Scrum. K.Schwaber, M.Beedle

Agile Project Management with Scrum. K.Schwaber

The Enterprise and Scrum. K.Schwaber