SCRUM i nie tylko. Teoria i praktyka w metodach Agile. Wydanie poszerzone - ebook

PRZEDMOWA

Pomimo rosnącej popularności metod Agile w Polsce wciąż nie ma dostatecznego wyboru literatury na ten temat w języku polskim. Poza trzema książkami elektronicznymi (e-book) nie było do tej pory właściwie literatury godnej polecenia. Książka „Nie tylko Scrum – Teoria i praktyka metod Agile” z pewnością pomaga ten stan rzeczy zmienić. Jest ona cenna zarówno ze względu na konwersacyjny, przystępny styl, jak i szeroki zakres podejmowanych tematów. W książce znaleźć można nie tylko omówienie najważniejszych metod Agile, ale także większości powszechnie stosowanych praktyk nierozerwalnie z nimi związanych.

Chociaż autor dużo miejsca poświęcił Scrumowi, na uwagę zasługuje obszerne omówienie zarządzania wymaganiami w Agile, gdzie Czytelnik znajdzie także opis praktycznych metod pracy z historyjkami użytkownika (User Stories) oraz wiele innych pożytecznych rad i przykładów z praktyki. Dużo uwagi poświęcono istotnej kwestii, jaką jest wizja produktu. Bez dobrej wizji produktu, dobrze przekazanej zespołowi trudno spodziewać się z jego strony zaangażowania w pracę. Bez tego zaangażowania, bez profesjonalnego podejścia wszystkich uczestników metody Agile nie dadzą tak dużych efektów, jak można by tego oczekiwać.

Pozostaje mieć nadzieję, że dzięki m.in. tej książce poprawi się nie tylko poziom wiedzy na temat metod Agile w Polsce, ale przede wszystkim poziom ich praktykowania w zespołach.

Andy Brandt, PST

Code SprintersWSTĘP

Tak, piszę wstęp, chociaż zwykle, biorąc do ręki kolejną książkę z półki albo spod stolika w salonie, bo w biurze już się nie mieszczą, opuszczam wstęp.

Dziękuję, że kupiłeś tę książkę lub masz zamiar zrobić to już za chwilę. Inwestycja w siebie to najlepsze, co możesz zrobić. Jesteś jedyną osobą, która może Ci dać błyskawiczny awans lub podwojenie dochodów. Nie wiem, na ile praca w IT była Twoją świadomą decyzją, ale chyba już wiesz, że oznacza ona ciągły rozwój. Świat wydaje się nie mieć ograniczeń. Rozwiązania informatyczne są potrzebne na każdym kroku i coraz częściej mówi się, że nie ma czegoś takiego jak biznes i IT – IT to biznes. Aby korzystać z tego bezkresu możliwości, musi być jednak spełniony jeden warunek. Albo postanowisz nadążać za technologią, albo utkniesz w tej samej pracy na kilka lat, a później będzie już za późno, żeby nadgonić zaległości. Pierwsza droga wymaga odrobinę samodyscypliny i zainwestowania jedynej rzeczy, jakiej nie można kupić – czasu.

Czy wiesz, co wyróżnia ludzi osiągających sukces? Odpowiedź może być zaskakująca. Okazuje się, że bardzo dużo zależy od perspektywy czasu. Innymi słowy, istotne jest myślenie o tym, jak to, co robisz teraz lub masz zamiar zrobić za chwilę, wpłynie na Twoje życie w dłuższej perspektywie. Możesz kupić kilka kaw w popularnej kawiarni i pójść na imprezę albo kupić i przeczytać książkę.

Książka, którą trzymasz przed sobą, jest efektem siedmiu lat zbierania doświadczeń i materiałów. Zawarłem tutaj wiedzę, którą kursanci zdobywają podczas kilkudziesięciu dni szkoleń, praktyczne rady udzielane przeze mnie jako trenera odpowiedzialnego za setki godzin szkoleniowych i odpowiedzi na dziesiątki pytań zadawanych przez uczestników warsztatów. Równie dużo materiału zostało zgromadzone dzięki analizie dziesiątek przygotowywanych i oglądanych przeze mnie prezentacji. Można powiedzieć, że książka powstawała w częściach już od kilku lat. Zajmuję się Agile od 2006 roku i można powiedzieć, że podążałem ścieżką Shu-Ha-Ri. Czy jestem na etapie Ri? Chyba tylko inne osoby mogą to ocenić.

Od kilku lat, co jakiś czas słyszę to samo pytanie zadawane w różnych językach. Jeśli jesteś taki dobry, to dlaczego nie napiszesz książki? Nie wierzę w przypadki i zbiegi okoliczności, dlatego staram się podążać za sygnałami, które zwracają moją uwagę. Wszystko ma swój czas i swoje miejsce. Każdy musi przejść swoją drogę, każdy musi przejść kolejne fazy i pokonać swoje demony, które szepczą do ucha, że nie jesteś wystarczająco dobry i możesz ponieść porażkę. Dzisiaj nadszedł moment, kiedy mogę oddać tę książkę w Twoje ręce. Uwierz mi, że do jej napisania wykorzystałem całą swoją wiedzę dotyczącą rozwoju osobistego, coachingu i Agile. Motywowałem się, zarządzałem czasem, wyznaczałem cele, zmieniałem swoje przekonania, uczestniczyłem w sesjach coachingowych i przesuwałem do kolejnego etapu zadania spisane na samoprzylepnych karteczkach.

Czy dzięki tej publikacji nauczysz się Agile? Agile to przede wszystkim stan umysłu i sposób myślenia, więc mogę Ci jedynie obiecać to, że wejdziesz na poziom świadomej kompetencji. Reszta to praktyka, refleksja i niemal nieskończona pętla – Sprawdź i Dostosuj.

Wiesz, dlaczego na półkach księgarń jest tyle różnych poradników? To proste, książki działają tylko wtedy, kiedy wykonuje się ćwiczenia i podąża za tym, co jest w nich zawarte. Jeżeli przeczytasz tę książkę i nie zmienisz niczego w pracy Zespołów w swojej organizacji, to również niewiele zmieni się w Twoim życiu.

Teoria – zasady, wartości i pryncypia, odpowiedź na pytanie, dlaczego robimy to, co robimy. Opisując teorię, sięgałem do źródeł, czyli do publikacji Kena Schwabera i Jeffa Sutherlanda. Tam, gdzie nie ma jasnej odpowiedzi, proponuję swoją opinię popartą argumentacją. Oczywiście nie musisz jej ufać, to tylko sugestia. Najważniejsze to wybrać drogę, trzymać się jej i umieć wytłumaczyć swoją decyzję innym osobom.

Praktyka – czyli jak to robimy. Czasem dotyczy to jednego pomysłu, czasem kilku. Nie wierz mi na słowo, sprawdź sam/sama. Jedyną miarą skuteczności praktyki jest jej rezultat. Jeśli korzystając z opisanych tutaj pomysłów, osiągasz zamierzone efekty, to świetnie. Jeśli jest inaczej, sprawdź, czy robisz wszystko tak, jak zostało to zaproponowane i albo popraw wadliwy element lub etap, albo spróbuj innego podejścia.

Jeżeli czymś się zajmuję, lubię sięgać do źródeł, żeby zrozumieć prawdziwe podstawy techniki. Szukam tego, co w języku angielskim jest określane słowem principle, które na język polski chyba najlepiej przetłumaczyć jako pryncypia. Można powiedzieć, że interesuje mnie odpowiedź na pytanie „dlaczego warto to robić?”, a nie „co robić?”. Jeśli korzystam z narzędzia zaprezentowanego przez trenera, tak długo szukam osoby, która go tego nauczyła, lub badań, w wyniku których odkryto zasadę, aż dotrę do oryginalnego źródła, i jestem w stanie wytłumaczyć działanie narzędzia od początku do końca. Jeżeli mówimy o technice używanej w projekcie, szukam jej pierwszego zastosowania i sposobu myślenia, które doprowadziło do jej powstania.

Dlaczego tak wiele firm nadal zmaga się z wdrożeniem Agile? Ponieważ Agile to nie techniki i narzędzia, to zmiana sposobu myślenia i podejścia do swojej pracy. Tutaj nie da się posiedzieć od 9 do 17, zrobić swoje i pójść do domu. Firmy często wprowadzają Agile, bo obiecują sobie, że to wszystko zmieni. Nie wychodziło tradycyjnymi metodami? Zmieńmy metodę! Niestety Agile, a w szczególności Scrum, niczego nie rozwiązują. Zmieni się jedynie to, że te same problemy organizacyjne, które wcześniej uniemożliwiały skuteczne wytwarzanie produktów, będą teraz bardziej widoczne i dokuczliwe. Znajdą się na dużych kolorowych kartkach papieru powieszonych na ścianie, będą codziennie wytykane i rozsyłane w podsumowaniach spotkań. Od Ciebie zależy, czy wykorzystasz szansę, jaką daje Agile i rozwiążesz stare problemy, czy też zrobisz wszystko, aby nie opuścić strefy komfortu. Mam nadzieję, że kiedy podejmiesz właściwą decyzję, będziesz używać tej książki jako przewodnika.

Czy ta książka jest doskonała? Na pewno nie. Z oczywistych powodów nie mogłem napisać o wszystkim. Przez lata rozwoju metod i narzędzi powstało wiele ciekawych pomysłów i praktyk. Każdemu rozdziałowi tej książki można by więc poświęcić osobną książkę. Jeżeli zainteresuje Cię coś konkretnego i będziesz chciał dowiedzieć się więcej na ten temat, sprawdź w bibliografii, czy podałem odnoszące się do tego zagadnienia źródła, albo spytaj wujka Google. Jeśli zaplanowane zostaną kolejne wydania, na pewno uzupełnię zakres książki. Chciałbym jednak wiedzieć, co Cię najbardziej zainteresowało, a Twoja opinia jest dla mnie bardzo ważna, więc napisz do mnie [email protected]. Każda opinia jest ważna. Zawsze liczę na konstruktywny feedback, choć dużo łatwiej jest krytykować pracę innych i poprawiać cudze produkty niż tworzyć własne. Jeśli nie jesteś pewny/pewna, czy chcesz wysłać do mnie wiadomość, tym bardziej ją wyślij. W najgorszym wypadku będę musiał przeczytać ją dwa razy.

Chciałbym podzielić się z Tobą starą historią. Dawno temu w Chinach żył pewien człowiek imieniem Ajnoł, który postawił sobie za cel posiąść wiedzę od wszystkich mistrzów, jakich spotka na swojej drodze. Szedł do takiego mistrza na nauki i pilnie studiował, dopóki nie uznał, że wie już wszystko. Kiedy nastąpił ten moment i w jego mniemaniu mistrz nie miał mu już nic do zaoferowania, szukał kolejnego. W końcu dowiedział się o niezwykle sędziwym starcu, który słynął ze swojej wiedzy w całym kraju i nie było mistrza, który wiedziałby więcej od niego. Nasz bohater wyprawił się do klasztoru, w którym mieszkał ów mistrz. Pokonał trudny górski szlak, na którym namiastką schodów było tylko kilka łańcuchów i desek zawieszonych na skalnych ścianach. Dotarł do bram klasztoru, ale przez wiele dni nikt mu nie otwierał. W końcu jeden z mnichów wyszedł na zewnątrz i spytał wędrowca, czego chce. Ajnoł oznajmił, że chce widzieć się z mistrzem i pobierać od niego nauki. Po kilku dniach oczekiwania został zaproszony na audiencję. Mistrz powiedział, że oczywiście wie, kim jego gość jest i czym się zajmuje, ale zaproponował, żeby o swoich dokonaniach opowiedział mu dokładniej podczas picia herbaty. Ajnoł zaczął szczegółowo opowiadać czego dowiedział się od kolejnych mistrzów i jak bardzo ich teraz przewyższa. Mędrzec w tym czasie zaparzył herbatę i zaczął nalewać ją do czarki gościa. Naczynie szybko napełniło się gorącym płynem, ale mistrz lał dalej. W końcu herbata wypłynęła poza krawędź tacy i zaczęła płynąć po spodniach gościa. Ajnoł podskoczył oparzony i krzyknął do mistrza „Co robisz, nie widzisz, że czarka jest już pełna i więcej się nie zmieści?”. Mistrz ze spokojem odparł „No właśnie. Twoja czarka jest już pełna. Nie mogę więcej nalać. Przyjdź do mnie, kiedy będzie pusta.”

Zawsze przypominam sobie tę historię przed każdym szkoleniem, prezentacją i książką, którą czytam, i dzięki temu za każdym razem znajduję coś nowego i porządkuję dotychczasową wiedzę.

Miłej lektury!PODZIĘKOWANIA

Twoje przeznaczenie kształtuje się w momentach podejmowania decyzji.

Tony Robbins

Dziękuję Tony’emu Robbinsowi za inspirację, motywację i narzędzia, które pomagają wielu ludziom na świecie diametralnie zmienić ich życie. Wykorzystywanie tej wiedzy w praktyce pomogło mi wyznaczyć ważne dla mnie cele i przyciągnąć zasoby potrzebne do ich osiągnięcia.

Większość ludzi jest szybka w powstrzymaniu Cię, zanim zaczniesz,
ale zawaha się stanąć Ci na drodze, jeśli już jesteś w ruchu.

Tim Ferris

Dziękuję Timowi Ferrisowi za pokazanie sposobów, w jakie różne rzeczy można robić szybciej i łatwiej, jak osiągać więcej w ciągu doby i nadal mieć wolny czas. Jestem również wdzięczny za Evernote, w którym od lat gromadzę wszystkie swoje notatki i pomysły.

Jeśli widzę dalej, to tylko dlatego, że stoję na ramionach olbrzymów.

Isaac Newton

Większość wiedzy zawartej w tej książce nie pochodzi ode mnie. Ja ją tylko spisałem.

Dziękuję sygnatariuszom Agile za pójście pod prąd i stworzenie nowego, dużo lepszego sposobu wytwarzania systemów informatycznych.

Dziękuję Jeffowi Sutherlandowi i Kenowi Schwaberowi za Scrum, który otwiera oczy wielu organizacjom i pozwala na bardziej motywującą i satysfakcjonującą pracę w wielu Zespołach.

Dziękuje Zespołom i organizacjom, które mi zaufały, pokazały najbardziej skrywane sekrety i pozwoliły zmienić to, do czego tak bardzo się przyzwyczaiły. Nasza współpraca była dla mnie wyzwaniem i zawsze dużo mnie uczyła.

Dziękuję uczestnikom szkoleń za tysiące dociekliwych pytań, które popychały mnie do zgłębiania zakamarków Agile, testowania oprogramowania, zarządzania i wielu innych dziedzin.

Na szczególne podziękowania za dzielenie się materiałami i wiedzą potrzebnymi do napisania tej książki zasługują Ken Schwaber, Jeff Sutherland, Ron Jeffries, Mike Cohn i Mike Griffiths.

Jeden z trenerów stwierdził, że w życiu spotykamy dwie kategorie ludzi – przyjaciół i nauczycieli. Dziękuję wszystkim anty-guru, których spotkałem na swojej drodze – dzięki wam dowiedziałem się, kim nie chcę być i czego nie chcę robić. W ten sposób szybciej poznałem, co jest dla mnie naprawdę ważne.JAK CZYTAĆ TĘ KSIĄŻKĘ?

W fazie planowania wydawało mi się, że wiedzę warto wyraźnie podzielić na dwie części – teorię i praktykę. Jednak po głębszym zastanowieniu i opisaniu części materiału bardziej naturalne wydało się połączenie ich w płynną, logiczną całość.

Książka jest skonstruowana w taki sposób, że może być czytana jako całość, od początku do końca, lub wykorzystywana jako podręczne źródło wiedzy dla osób, które chcą sobie odświeżyć konkretny temat.

Z uwagi na dziwolągi językowe, które powstają przy tłumaczeniu pojęć technicznych na język polski oraz powszechne w Polsce stosowanie terminologii angielskiej i słowotwórstwo, postanowiłem trzymać się nazw oryginalnych lub przynajmniej podawać angielskie odpowiedniki w nawiasach. W ten sposób treść książki jest łatwiej przyswajalna i ułatwia korzystanie z innych źródeł. Czasem nadal musiałem uciekać się do słowotwórstwa, jak w przypadku Modelu Kano. Ważne pojęcia pisałem dużą literą, żeby się wyróżniały, choć nie zawsze są to nazwy własne.

Niektóre pojęcia i zasady zostały powtórzone kilkukrotnie, żeby je utrwalić i pokazać ich znaczenie w wielu aspektach.

Książka może stanowić dobre przygotowanie do egzaminu na certyfikat i PSPO I, ale znacznie wykracza poza obszar wiedzy sprawdzanej podczas tego testu.W tym szaleństwie jest metoda.

William Shakespeare

1.1. (R)ewolucje

Patrząc na sposób tworzenia oprogramowania, często na myśl przychodzi mi stwierdzenie z mitologii greckiej – na początku był chaos. Jednak zanim uporządkujemy wszystko krok po kroku, spójrzmy, jak ewoluowała nasza cywilizacja.

Zacznijmy w momencie, kiedy podobnie jak nieliczne obecnie plemiona Indian amazońskich, które nie znają chipsów i blachy falistej, byliśmy zbieraczami albo myśliwymi. Ci, którzy dobrze biegali i sprawnie posługiwali się bronią, byli myśliwymi. Ci którym szło nieco gorzej, zbierali grzyby i jagody. Ktoś wpadł na pomysł, że zamiast biegać za zwierzętami i szukać jagód w lasach pełnych żmij i tygrysów szablastozębnych, można zamknąć zwierzęta w zagrodzie, a krzaki jagód zasadzić obok domu. Tak dokonała się rewolucja rolnicza.

Niektórzy wykazywali się talentem w wytwarzaniu narzędzi, naczyń, ubrań i mogli przehandlować je za produkty rolników. Powstawały coraz bardziej skomplikowane narzędzia wspomagające codzienną pracę i zwiększające jej wydajność. Z czasem narzędzia zyskały nawet własny napęd i zostały nazwane maszynami. Wytwarzanie produktów stało się nową, bardzo dochodową czynnością. Ale jak można wytwarzać więcej produktów w tym samym czasie? Jak sprawić, aby nie-rzemieślnicy wytwarzali takie same produkty podobnej jakości? Spróbujmy rozłożyć produkcję na czynniki pierwsze, a proces produkcji na kroki, które może zrozumieć każdy. „Wbij po jednym gwoździu w oznaczone miejsca”. „Połącz elementy gumowym wężem”. Każda osoba wykona małą część pracy, a półprodukt zostanie przekazany kolejnemu pracownikowi.

Zbudowano fabryki, w których zamykano tysiące robotników wykonujących proste czynności. Pojawił się jednak kolejny problem – jak ich zorganizować wokół całego procesu? Może potrzeba do tego jakiegoś medium? Na przykład pasa transmisyjnego przesuwającego się z lewej do prawej co określony czas? Tak w świecie zachodnim zrodziło się poczucie czasu i konieczność posiadania budzika, ale to już temat na książkę z zupełnie innej branży. Ważniejsze jest to, że ludzie zaczęli przenosić się do miast, gdzie było więcej pracy niż w rolnictwie.

W ten sposób weszliśmy w erę przemysłową. Ten właśnie moment ma znaczenie z punktu widzenia wytwarzania produktów i zarządzania projektami, czyli tematów poruszanych w książce, którą trzymasz. Właśnie wtedy powstały takie narzędzia, jak wykresy Gantta, Work Breakdown Structure (WBS) i inne używane w tradycyjnym podejściu do zarządzania projektami. Jako pochodna wyłonił się także kaskadowy model wytwarzania oprogramowania (ang. Waterfall) będący próbą ustandaryzowania procesów i ogarnięcia chaosu w całkiem nowej dziedzinie przemysłu. Podejście używane wtedy do organizacji projektów i zarządzania jest określane mianem podejścia predykcyjnego. Jego rdzeniem jest zbudowanie dobrego planu i konsekwentne jego wykorzystanie. Musimy więc wiedzieć nie tylko, co chcemy zbudować, ale też jak będziemy wykonywać tę pracę. Patrząc na wykres Gantta, będziemy wiedzieć, czym będzie się zajmował nasz pracownik za trzy tygodnie. Predykcja, czyli przewidywanie przebiegu całego procesu, od planowania do wypuszczenia produktu na rynek, jest metodą, która dobrze zadziała tylko w przypadku wytwarzania prostych produktów w stabilnym środowisku i przy użyciu znanych metod.

Ale czy nasza ewolucja zatrzymała się w tym momencie? Oczywiście, że nie. Najnowszy etap w rozwoju cywilizacji dzieje się na naszych oczach. W ciągu kolejnych dekad zawody wymagające większego przygotowania i większej wiedzy stały się bardziej doceniane. Naukowcy, inżynierowie, prawnicy, lekarze stali się elitą pracowników. Część z nich pracuje jako niezależni eksperci, tak zwani freelancerzy. Tak dokonuje się rewolucja informacyjna. Posiadanie wiedzy i umiejętność jej wykorzystania jest obecnie ceniona najbardziej. Nie chodzi już o pracę odtwórczą, ale twórczą, wymagającą kreatywności. Zupełnie nowe produkty tworzone są często w warunkach niepełnej lub zmieniającej się specyfikacji – budujemy coś, czego nikt wcześniej nie zrobił, i do końca nie wiemy, jak to będzie wyglądać.

Czy pracę twórczą da się usystematyzować? Spójrzmy na dwa przykłady.

Kiedyś zapytano rzeźbiarza, jak wyrzeźbił z marmuru niedźwiedzia. „To bardzo proste” – odpowiedział – „bierzesz kawałek marmuru, dłuto i odcinasz to, co nie wygląda jak niedźwiedź”.

Moja teściowa poprosiła pewną kobietę, aby ta nauczyła ją ozdabiać torty kremem. Kiedy obie stanęły nad tortem, nauczycielka powiedziała jej: „Trzeba zrobić tutkę z papieru, odciąć koniec, a potem robisz wzorki. O, tak albo tak…”.

Choć będziemy w stanie szczegółowo opisać i dokładnie zaplanować wyrzeźbienie niedźwiedzia lub ozdobienie tortu w ten sam sposób, to stracimy dużo czasu na analizę procesu. Nadal jednak nie będziemy mieli sposobu na wyrzeźbienie na przykład kaczki, podczas gdy rzeźbiarz wykona to bez problemu.

Sposób wykonywania produktu będzie ewoluował w trakcie produkcji. Model predykcyjny, oparty na planowaniu z góry, zupełnie tutaj nie zadziała. Potrzebujemy czegoś innego. Organizacja wyznacza pracownikom cele, pracownicy wykorzystują swoją wiedzę oraz doświadczenie, żeby zaplanować osiągnięcie pierwszego z nich i w miarę postępu prac dostosowują swoją strategię, reagując na zmiany. Projekt składa się z małych odcinków nazywanych iteracjami, a po zakończeniu każdego z nich dostarczamy działającą wersję systemu. Efekt pracy jest następnie omawiany z klientem, a wyciągnięte wnioski wpływają zarówno na wymagania realizowane w dalszej części projektu, jak i na sam proces. Sposób wytworzenia produktu powstaje w trakcie wykonywania pracy na podstawie doświadczenia nabytego po drodze. Dlatego nazywamy go procesem empirycznym. Działające w ten sposób organizacje i zespoły projektowe określane są jako Złożone Systemy Adaptacyjne (ang. Complex Adaptive Systems). Złożone, ponieważ ze względu na zmienne środowisko trudno jest przewidzieć ostateczny kształt produktu. Systemy adaptacyjne po prostu reagują na zmiany i dostosowują się do sytuacji. Ponieważ praca przy projekcie informatycznym dużo częściej przypomina warunki Złożonego Systemu Adaptacyjnego niż przewidywalnego procesu wytwórczego w fabryce, metody wytwarzania oprogramowania mające za podstawę proces empiryczny i reagujące na zachodzące zmiany zostały nazwane metodami zwinnymi (ang. Agile methods), potocznie Agile. Wbrew powszechnemu przekonaniu panującemu w środowisku IT Agile to nie tylko Scrum. Istnieje bowiem cała gama mniej lub bardziej restrykcyjnych metod – od Kanban i Crystal, przez Feature-Driven Development (FDD) i Programowanie Ekstremalne (XP) do Scrum i Dynamic Systems Development Method (DSDM).

Przyjrzyjmy się bliżej dwóm, jakże różnym podejściom – Waterfall i Agile.Zasadniczo wszystkie modele są błędne, ale niektóre są użyteczne.

George Edward Pelham Box

2.1. Omówienie metody Waterfall

Model Waterfall, inaczej model kaskadowy, swoją nazwę zawdzięcza schematowi przedstawiającemu pięć wyraźnych i następujących po sobie faz. Praca przy projekcie, niczym woda płynąca po skalnych stopniach wodospadu, przesuwa się w dół do kolejnych faz procesu. Pomysł na takie podejście do procesu wytwarzania oprogramowania został zaczerpnięty z organizacji pracy w fabrykach i przy projektach budowlanych. Działanie zawsze zaczynamy od zebrania wymagań, eksperci planują wytworzenie produktu lub zbudowanie domu, a potem robotnicy wykonują pracę w kolejnych etapach. Czasami etapy to kolejne stacje taśmy produkcyjnej, a kiedy indziej – przekazanie budowy kolejnej ekipie specjalistów i formalny odbiór. Każdy etap musi zostać zakończony, żeby mógł się rozpocząć kolejny. Zawsze następuje oficjalne przekazanie projektu do kolejnej fazy.

Rysunek 1. Model Waterfall

Model kaskadowy został po raz pierwszy przedstawiony przez Herberta D. Beningtona na konferencji Symposium on Advanced Programming Methods for Digital Computers w 1956 roku. Za pierwszy formalny opis metody uważany jest artykuł „Managing the Development of Large Software Systems”, który opublikował w 1970 roku dr Winston W. Royce.

Chociaż obecnie w opisie tego podejścia używa się jedynie pięciu kroków, to oryginalny model dostarczenia dużego programu komputerowego dla zewnętrznego klienta zawierał ich siedem:

■ wymagania systemu (ang. System Requirements);

■ wymagania oprogramowania (ang. Software Requirements);

■ analiza (ang. Analysis);

■ projekt programu (ang. Program Design);

■ kodowanie (ang. Coding);

■ testowanie (ang. Testing);

■ użytkowanie (ang. Operations).

Ciekawostką jest, że takie podejście do wytwarzania oprogramowania zostało przez samego autora uznane za podatne na błędy ze względu na umieszczenie fazy testowania na końcu oraz kosztowne wprowadzanie poprawek w momencie, gdy założona implementacja okazuje się błędna lub niemożliwa do wykonania. Jedynym wyjściem w takich sytuacjach jest powrót do wyższych faz procesu i ponowne przejście całej sekwencji.

Wierzę w ten koncept, ale implementacja opisana powyżej
jest ryzykowana i naraża się na porażkę.

Dr. Winstone W. Royce, Preceedings, IEE WESCON, sierpień 1970

Ramka 1. Opinia „ojca chrzestnego” modelu Waterfall o ryzyku związanym z jego stosowaniem

Autor zaznaczył, że iteracja między fazami minimalizuje ryzyko porażki i redukuje zmiany do poziomu łatwego do zarządzania. To oznacza, że po przejściu do kolejnej fazy może nastąpić powrót. Żeby zminimalizować większość ryzyka, autor zaleca pięć praktyk:

1. Wprowadzenie kroku Wstępnego Projektu Programu przed Analizą Wymagań.

2. Udokumentowanie projektu.

3. Przygotowanie symulacji, zbudowanie wersji pilotażowej.

4. Planowanie, kontrola i monitorowanie testowania.

5. Zaangażowanie klienta.

Przyjrzyjmy się bliżej kolejnym fazom modelu. Na początku pracy bardzo ważne jest ustalenie z klientem wymagań odnośnie do zamawianego oprogramowania i podpisanie kontraktu, który nie będzie negocjowany do czasu ukończenia projektu. Ewentualne zmiany będą uwzględnianie jedynie w postaci udokumentowanych, często dodatkowo płatnych zgłoszeń zmiany (ang. change request). Jak łatwo się domyśleć, takie założenie nie działa na korzyść klienta. Kiedy określone zostaną przynajmniej najważniejsze ustalenia, zespół ekspertów rozpoczyna fazę zbierania i opracowywania wymagań. Na ogół w tym momencie nad projektem pracują analitycy biznesowi, którzy rozumieją zarówno domenę biznesu klienta, jak i rozwiązania technologiczne. Następnie możliwie najdokładniej definiowany jest efekt końcowy.

Po fazie Analizy wymagań (ang. Requirements analysis) następuje faza Projektowania (ang. Design), podczas której architekci projektują rozwiązanie na podstawie ustalonych wymagań. Nadal jesteśmy w obszarze pracy wykonywanej przez ekspertów, ale już tutaj mogą powstać pierwsze błędy w interpretacji wymagań. Dopiero teraz może nastąpić Implementacja (ang. Implementation), podczas której nawet kilka zespołów programistów, specjalistów od baz danych, grafików itp. dostanie swoje zadania i będzie pracować nad częścią systemu, za którą będą odpowiedzialni. Dziesiątki programistów będą tworzyć swój moduł albo pojedynczą funkcję, nie rozumiejąc, jaki wpływ na cały system ma ich praca. Każdy dostaje specyfikację z opisem interfejsu do innych części systemu i dodaje swój kawałek kodu. Pamiętasz Neo z Matrixa? On był takim programistą. Kiedy ten etap będzie blisko planowanego końca, zacznie się integracja wszystkich małych kawałków przygotowanych przez różne zespoły. Menedżer projektu będzie trzymał kciuki i zaklinał rzeczywistość, żeby wszystko zadziałało. Niestety, ten etap projektu często bardziej przypomina odpalanie starego, wyciągniętego z bagna czołgu niż składanie nowego modelu Nissana GTR na linii montażowej. Wymagania nie zostały dobrze zrozumiane, kod jest nieczytelny, osoba odpowiedzialna za określony moduł jest na urlopie, czasami nawet system został źle zaprojektowany. Trzeba zgłosić problem, który zostanie przekazany w górę strumienia, do odpowiedniej grupy specjalistów. Po dyskusji i podjęciu decyzji powstaną nowe wymagania, które muszą zostać zaimplementowane i mogą spowodować zmiany w architekturze. Zegar tyka, termin ukończenia projektu się zbliża, a efekt nie może być przetestowany, bo nie można skompilować kodu. Kiedy w końcu można uruchomić system, okazuje się, że projekt jest spóźniony i na fazę Testowania (ang. Verification) zostały nie, jak pierwotnie założono, trzy miesiące, ale trzy tygodnie. Testerzy czytają wymagania, piszą procedury, uruchamiają testy i znajdują błędy. Czasami, choć rzadko, jest to błąd w kodzie, częściej jest to błąd związany z wymaganiami. W takim wypadku trzeba je zweryfikować, czyli udać się w górę wodospadu, doprecyzować lub zmienić wymagania, sprawdzić ich wpływ na architekturę, zaimplementować poprawkę i upewnić się, że błąd został usunięty. Tak wyglądają działania na projekcie do momentu osiągnięcia ostatecznego terminu, kiedy projekt należy wypuścić na rynek albo wdrożyć u klienta i przejść do fazy Utrzymania/Pielęgnacji (ang. Maintenance).

Czy nie przypomina Ci to trochę zabawy w głuchy telefon? Na szczęście charakterystyczną cechą modelu kaskadowego jest dobra dokumentacja przekazywania systemu z jednej fazy do drugiej. Pałeczka jest przekazywana niemal jak w biegu sztafetowym.

Rysunek 2. Widoczność postępu prac w tradycyjnym projekcie. DILBERT C 2007 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

Podsumujmy zatem charakterystyczne cechy modelu Waterfall:

■ proces fazowy, sekwencyjny;

■ ¼ czasu spędzona na planowaniu;

■ na początku nad projektem pracują eksperci, a następnie szeregowi deweloperzy;

■ z góry przewidziany rezultat końcowy;

■ projekt odnosi sukces, gdy:

☐ wszystkie wymagania zostaną spełnione,

☐ zakończy się w przewidzianym terminie,

☐ budżet nie zostanie przekroczony,

☐ otrzymany zostanie produkt o ustalonej wcześniej jakości.

Czy to naprawdę są kryteria sukcesu? Z punktu widzenia metody i menedżera projektu na pewno jest to sukces. Niekoniecznie jednak stanowi on wartość dla biznesu klienta.

Stosowanie sekwencyjnego procesu Waterfall, w którym nie wykonamy dodatkowych iteracji między fazami, stwarza ryzyko wystąpienia szeregu problemów, takich jak:

☐ niejasne wymagania;

☐ rosnący koszt wprowadzania zmian;

☐ zawiedzione oczekiwania klientów;

☐ brak czasu na testowanie;

☐ postęp pracy trudny do określenia w danym momencie;

☐ brak możliwości ciągłego zapewnienia jakości;

☐ późna integracja modułów oznaczająca późne pojawianie się błędów.

Oczywiście można powiedzieć, że ryzyko potencjalnych problemów nie równa się faktycznym kłopotom spowodowanym korzystaniem z metody. Sięgnijmy zatem po garść danych statystycznych dotyczących projektów prowadzonych metodą Waterfall:

■ 52% wymagań zostało zaimplementowanych;

■ 64% powstałych funkcjonalności jest używane rzadko;

■ 34% projektów zakończone sukcesem.

Czy w takim razie model kaskadowy można stosować z powodzeniem? Oczywiście, że tak. Muszą być jednak spełnione pewne warunki:

■ zakres projektu i wymagania się nie zmieniają;

■ zespół doskonale zna technologię;

■ zespół dobrze rozumie wymagania;

■ zespół dobrze oszacował zakres prac do wykonania;

■ nic nie wpłynie na zmianę planu.