SCRUM i nie tylko. Teoria i praktyka w metodach Agile. Fragment książki

– W tym szaleństwie jest metoda – powiedział William Shakespeare. Autor książki, Krystian Kaczor, uważa podobnie i w publikacji stara się pokazać teoretyczne i praktyczne rozwiązania związane z wdrożeniem metodyki Agile. Poniżej prezentujemy fragment jego pracy.

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.

(Mała dygresja – od razu przypomina mi się dowcip zasłyszany przy kolacji w Sankt Petersburgu. Nasz gospodarz zapytał mojego managera:

– Czy wiesz, skąd pochodzi słowo wegetarianin?

– Nie. Powiedz mi.

– W języku Indian to znaczy kiepski myśliwy.)

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(4). 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ź”.

W tym szaleństwie jest metoda

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.

Do przemyślenia

1. Jakie zadania, które wykonujesz w ciągu dnia, można uznać za pracę twórczą?

2. Jakie umiejętności stają się najważniejsze w obecnych czasach?

3. Poprawa których Twoich umiejętności zapewniłaby Ci większy sukces zawodowy?

–

– 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.

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.

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(5):

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.

Do przemyślenia

1. Czy model kaskadowy może działać dobrze?

2. Do jakich projektów można stosować model kaskadowy?

3. Czy model waterfall nadaje się do projektu, nad którym pracujesz? Dlaczego?

–

Przypisy:

(4) Chodzi tutaj o linię czasu, będącą częścią Programowania Neuro-Lingwistycznego (NLP). Linię czasu wykorzystuje się do planowania celów i usuwania traum będących skutkiem wydarzeń w przeszłości.

(5) Źródło: Standish Report 2003.

–