Krystian Kaczor

SCRUM i nie tylko
Teoria i praktyka w metodach AGILE

DILBERT © 2005 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

DILBERT © 2007 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

DSDM and Atern are registered trademarks of Dynamic Systems Development Method Limited. The author has been granted permission to use the DSDM copyright material reproduced in this book.

Projekt okładki

Grzegorz Laskowski

Zdjęcie na okładce

Liviu Ionut Pantelimon/Shutterstock

Wydawca

Łukasz Łopuszański

Redaktor

Bianka Piwowarczyk-Kowalewska

eBook został przygotowany
na podstawie wydania papierowego z 2014 r.
(wyd. I)

Warsawa 2014

Copyright © by Wydawnictwo Naukowe PWN SA

Warszawa 2014

ISBN 978-83-01-17951-9 (ePub)

ISBN 978-83-01-17952-6 (Mobi)

Wydawnictwo Naukowe PWN SA

02-460 Warszawa, ul. G. Daimlera 2

tel. 22 69 54 321, faks 22 69 54 288

infolinia 801 33 33 88

e-mail: pwn@pwn.com.pl

www.pwn.pl

Skład komputerowy: Bogusław Górecki

Skład wersji elektronicznej:

Virtualo Sp. z o.o.

Książkę dedykuję mojej wspaniałej żonie Agnieszce,
od której nauczyłem się wielu rzeczy od nowa.

Ciągle żartuję, że kiedy wracam z pracy i wchodzę do domu,
najpierw otwieram laptopa, potem całuję żonę.

Przez ostatni rok to nie był żart, ale ponura rzeczywistość.

Dziękuję Ci za wsparcie, motywację i przestrzeń
dla mojego rozwoju.

Jesteś dla mnie wszystkim.

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 Sprinters

WSTĘ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[1]. 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 krystian@kaczor.info. 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!

[1] Nawiązanie do czterech poziomów uczenia się w NLP.

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.[1]

[1] Określenia „interesariusze” użyłem do zdefiniowania grupy osób zainteresowanych projektem. Na początku chciałem posłużyć się słowem „udziałowcy”, ale ponieważ to pierwsze przyjęło się już w środowisku IT, zmieniłem zdanie. Nie oznacza to jednak, że treść książki odnosi się do kontekstu projektowego.

ROZDZIAŁ 1 W TYM SZALEŃSTWIE
JEST METODA

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[1]. 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ący 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[2]. 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.

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?

[1] 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.

[2] 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.

ROZDZIAŁ 2 WATERFALL

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ło 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).

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

Czy to 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ą zaspokojone,

□ 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[1]:

■ 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?

[1] Źródło: Standish Report 2003.

ROZDZIAŁ 3 AGILE

Zmiana nie jest konieczna. Przetrwanie nie jest obowiązkowe.

W. Edwards Deming

Pomimo popularności metody kaskadowej i tworzenia kolejnych metod, które próbowały usystematyzować wszystkie czynności, role i artefakty projektu (jak chociażby RUP[1]), znalazła się grupa ludzi, która podczas konferencji dzieliła się doświadczeniami z wykorzystywania zupełnie innego podejścia. Wypracowane, autorskie metody osiągały większą skuteczność niż tradycyjne sposoby wytwarzania oprogramowania.

3.1. Manifest Agile

W 2001 roku w ośrodku narciarskim Snowbird w Stanach Zjednoczonych zebrało się siedemnaście osób promujących nieco różne metody i podejścia do budowania systemów informatycznych, ale zgadzających się odnośnie do podstawowych założeń. Najważniejsze wartości stojące za sposobem budowania oprogramowania w inny, lepszy sposób zostały spisane w postaci czterech punktów tworzących Manifest Agile[2] (ang. Agile Manifesto).

Pod manifestem podpisało się siedemnastu oryginalnych sygnatariuszy, z których cześć stworzyła własne metody Agile: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.

Poprzez wytwarzanie oprogramowania oraz pomaganie innym w tym zakresie odkrywamy lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń zaczęliśmy przedkładać:

Ludzi i ich interakcje nad procedury i narzędzia.

Działające oprogramowanie nad wyczerpującą dokumentację.

Współpracę z klientem nad negocjację umów.

Reagowanie na zmiany nad realizowanie planu.

Chociaż doceniamy elementy wymienione po prawej stronie, to jednak bardziej cenimy pozycje po lewej.

Ramka 2. Manifest Agile

Manifest Agile jest podstawą oceny, czy konkretna metoda jest metodą zwinna i często stanowi też kryterium oceny praktyk w zespole lub całej organizacji. Niestety, szczególnie w niedoświadczonych organizacjach deklaracja bywa wypaczana poprzez czytanie jej jako czarno-białej listy (rób rzeczy po lewej stronie a tych po prawej unikaj). W ostatnim zdaniu autorzy zadeklarowali, że nadal cenią wartości stojące po prawej stronie. Stosowanie Manifestu Agile nie oznacza, że w projektach prowadzonych metodami zwinnymi na przykład nie ma dokumentacji, nie obowiązują jasne standardy albo nie trzeba zawierać umów. Takie błędy w interpretacji manifestu prowadzą do niebezpiecznych mutacji praktyk, które mogą spowodować porażkę całego projektu. Oczywiście winą obarcza się wtedy Agile. Co tak naprawdę zostało przekazane w tym dokumencie?

1. „(…) Ludzi i ich interakcje nad procedury i narzędzia”

Pierwszy punkt jasno określa, co odgrywa największą rolę w pracy przy projekcie i kto wie, jak najlepiej wykonać pracę. Najważniejsi są ludzie i komunikacja między nimi. Problemy są rozwiązywane, a rozwiązania projektowane przez ludzi, nie przez narzędzia i kolejne procedury. W tradycyjnym podejściu do zarządzania projektem i wytwarzania produktów pracujący w projekcie ludzie są redukowani do zasobu (ang. resource), czyli znajdują się w tej samej kategorii, co drukarka, krzesło, serwer czy licencja na Windows. Im więcej procedur i narzędzi wprowadzimy, tym bardziej będziemy skupiać się na dostosowaniu do nich pracy, a nawet sposobu myślenia, zabijając przy tym kreatywność. Rozmowa w cztery oczy i krótkie spotkanie wyjaśniające nieścisłości w wymaganiach będzie dużo bardziej efektywne niż prowadzenie dyskusji w narzędziu do zarządzania wymaganiami, które jest źródłem kolejnych nieporozumień. Narzędzia i procedury są potrzebne, żeby wspomóc i przyspieszyć pracę. Dlatego wszelkie próby różnej maści konsultantów sprzedających super modele uniwersalnie rozwiązujące wszystkie problemy są całkowitym zaprzeczeniem idei Agile. Procesy powinny być wypracowane na podstawie relacji wypracowanych w zespołach oraz wokół jednostek je budujących.

2. „(…) Działające oprogramowanie nad wyczerpującą dokumentację”

Wystarczy się przez chwilę zastanowić się, dlaczego klient ma nam zapłacić. Klient zamawia i płaci za oprogramowanie, które ma spełniać określone funkcje i przede wszystkim działać. Dokumentacja architektury, plany testów, dokładne opisy modułów nie stanowią dla klienta wartości, podobnie jak niezliczone raporty w MS Excel i prezentacje PowerPoint. Liczy się efekt pracy, a nie jej opis. Jaki zatem sens ma przedstawianie dokumentacji projektu jako efektu osiągnięcia kamienia milowego? Czy klient powinien za nią zapłacić i przekazać do archiwizacji? Podstawową miarą postępu prac jest dostarczanie działającego oprogramowania spełniającego potrzeby lub rozwiązującego problemy klienta, poprawnie zbudowago i wysokiej jakości. Oczywiście pewne rzeczy muszą zostać udokumentowane. Dobrze jest opisać decyzje dotyczące architektury i budowy systemu. Jeżeli potrzebne będą pliki pomocy lub przewodnik użytkowania systemu, to dokumentacja taka powinna powstawać przyrostowo wraz z przyrastającą funkcjonalnością oprogramowania. Dokładny opis tego, co rozumiane jest przez gotowy kawałek systemu, powinien znaleźć się w umowie między zespołem a klientem. W Scrumie taka umowa nazywana jest Definicją Ukończenia (ang. Definition of Done), ale o tym w rozdziale 5.

3. „(…) Współpracę z klientem nad negocjację umów”

Czy we współpracy z klientem chodzi o to, żeby zawsze mieć rację, nawet jego kosztem? Przecież nawet przy budowaniu prostej firmowej strony WWW trudno jest z góry ustalić, jak ma ona wyglądać. Myślimy, że wszystko jest jasne, siadamy do pracy, pokazujemy ukończony produkt, a klient mówi, że chodziło mu o coś całkowicie innego. Osiągnęliśmy tak zwany sukces techniczny – wszystko zgadza się z umową i wymaganiami, a pod względem jakości wykonania i użytej technologii nie ma się do czego przyczepić. Czy klient w tej sytuacji będzie zadowolony?

Rozważmy inną, równie często spotykaną sytuację. Co się stanie, gdy klient będzie chciał zmienić priorytety realizowanego już projektu, a nawet zupełnie zmienić jego kierunek? Powiedzmy, że klient ma lepszy pomysł na produkt lub musi zareagować na zmiany zachodzące na rynku. W takim momencie firma zazwyczaj macha klientowi przed nosem klauzulami zawartymi w umowie, wskazując ustalony zakres prac i datę zakończenia projektu.

Dużo lepszym podejściem jest zawarcie bardziej elastycznej umowy i ciągła współpraca z klientem. Zamiast znanej z modelu waterfall długiej fazy analizy budujemy produkt przyrostowo, dostarczając kolejne małe kawałki tworzone na podstawie informacji zwrotnej od klienta. Doświadczenie wielokrotnie potwierdziło, że klient dużo lepiej określa, czego potrzebuje, kiedy ma przed sobą namacalną, działającą wersję systemu. Zleceniodawca, widząc, że tworzony produkt jest zgodny z jego oczekiwaniami a dostarczane Przyrosty produktu (ang. Increment) to w pełni działające oprogramowanie, bardziej zaufa zespołowi. Dodatkowo za każdym razem możemy przedyskutować z klientem wymagania odnoszące się do kolejnej iteracji i listę rzeczy do zrobienia, pokazując zawsze aktualny stan pracy. Jeśli z biznesowego punktu widzenia produkt przedstawia już wystarczającą wartość, można wypuścić go na rynek przed zakończeniem projektu i rozwijać na podstawie informacji zwrotnej od grup użytkowników.

4. „(…) Reagowanie na zmiany nad realizowanie planu”

W tradycyjnym podejściu rozwieszone na ścianach, niezwykle długie wykresy Gantta już po kilku tygodniach przestają odpowiadać rzeczywistości. Oczywiście planowanie jest potrzebne – jeśli nie potrafimy zaplanować pracy, to planujemy porażkę. Przygotowanie planu dostarcza wielu informacji, musimy wtedy przemyśleć wiele spraw i odkryć nowe aspekty pracy do wykonania. Jak zamierzam osiągnąć cel? Co muszę zrobić? Jakie problemy mogę napotkać na swojej drodze? Jak je rozwiążę?

Jednak, jak powiedział marszałek Helmuth von Moltke, „Żaden plan nie przetrwa kontaktu z wrogiem”. Rzeczywistość potrafi zaskakiwać i psuć nawet najlepsze plany, szczególnie gdy pracujemy z ludźmi. Dlatego zawsze należy pamiętać, po co stworzyliśmy plan. Nie jest on niezmiennym artefaktem wyrytym w kamieniu jak kalendarz Azteków. To zestaw kroków na drodze do celu, biorący pod uwagę to, co do tej pory wiemy o drodze. Jeżeli sytuacja się zmieni, będzie nam potrzebny nowy plan.

3.2. 12 Zasad Agile

Wiele osób zdaje się zapominać, że oprócz czterech deklaracji Manifestu Agile, zostało również spisane 12 zasad stojących za nim[3] (ang. Principles behind the Agile Manifesto).

1. Naszym najwyższym priorytetem jest zadowolenie klienta osiągane przez wczesne i ciągłe dostarczanie wartościowego oprogramowania.

2. Zmiany w wymaganiach są mile widziane nawet na późnych etapach projektu. Proces Agile wykorzystuje zmianę do osiągnięcia przewagi we współzawodnictwie na korzyść klienta.

3. Dostarczaj oprogramowanie często, w odstępach czasu od kilku tygodni do kilku miesięcy, preferując mniejsze odstępy czasowe.

4. Ludzie biznesu i deweloperzy muszą pracować razem codziennie przez cały czas trwania projektu.

5. Projekty powierzaj zmotywowanym jednostkom. Daj im środowisko i wsparcie, którego potrzebują i zaufaj im, że praca zostanie wykonana.

6. Najskuteczniejszą i najwydajniejszą metodą przekazywania informacji w zespole deweloperów jest rozmowa w cztery oczy.

7. Działające oprogramowanie jest podstawową miarą postępu.

8. Procesy Agile promują zrównoważony rozwój [oprogramowania]. Sponsorzy, deweloperzy i użytkownicy powinni być w stanie utrzymać stałe tempo.

9. Ciągła koncentracja na technicznej doskonałości i dobrym projekcie (ang. design) poprawia zwinność (ang. agility).

10. Prostota – sztuka zwiększania ilości pracy niewykonanej – jest niezbędna.

11. Najlepsze architektury, wymagania i projekty wyłaniają się z samoorganizujących się zespołów.

12. W regularnych odstępach czasu zespół zastanawia się, jak zwiększyć wydajność, a następnie odpowiednio dopasowuje swoje zachowanie.

Ramka 3. 12 Zasad Agile

1. „Naszym najwyższym priorytetem jest zadowolenie klienta osiągane przez wczesne i ciągłe dostarczanie wartościowego oprogramowania”

Zwróć uwagę, ile wskazówek zawiera to jedno zdanie. Celem pracy nie jest zadowolenie biura projektu ani spełnienie wszystkich wymaganych standardów zapewnienia jakości. Na pierwszym miejscu zapisano, że najważniejsze jest zadowolenie klienta.

Oprogramowanie będziemy dostarczać najszybciej, jak będzie to możliwe, i w sposób ciągły. Klient będzie mógł obejrzeć wyniki naszej pracy i sprawdzić kierunek działania na prostych i podstawowych rozwiązaniach, zanim zostanie w nie włożone dużo pracy, która może okazać się niepotrzebna.

Dostarczamy oprogramowanie, które przedstawia wartość dla klienta. Będzie ona rosła wraz z kolejnymi elementami tworzonymi przez zespół do osiągnięcia celu, którego oczekuje klient.

2. „Zmiany w wymaganiach są mile widziane, nawet na późnych etapach projektu. Proces Agile wykorzystuje zmianę do osiągnięcia przewagi we współzawodnictwie na korzyść klienta”

Duża część sukcesu metod zwinnych jest skutkiem zmiany wymagań. Zakładamy, że lista rzeczy do zrobienia jest płynna i można dodawać do niej nowe wymagania, modyfikować istniejące, usuwać zbędne. Nie potrzebujemy do tego procesów zarządzania zmianą znanych z metod zarządzania projektami. Zawsze będziemy zajmowali się wymaganiami o najwyższym priorytecie, przeznaczając zasoby projektu na działania najbardziej pewne i najlepiej zdefiniowane.

W trakcie trwania iteracji nie dopuszcza się dużych zmian, ponieważ cały plan pracy przestaje mieć sens i lepiej jest zacząć od nowa.

Zmiany mają swoje konsekwencje. Korzystanie z metod zwinnych nie daje klientowi możliwości całkowitej zmiany kierunku projektu bez ich poniesienia. Jeżeli umówiliśmy się na zbudowanie samochodu i mamy gotowe podwozie, to nie można teraz zrobić jachtu. Zwinność ma swoje granice. Jeżeli jednak klient kategorycznie stwierdzi, że już nie potrzebuje samochodu, lecz jachtu i jest gotowy poświęcić zużyte do tej pory środki, to ma prawo do takiej decyzji. Ustalanie priorytetów zostało dokładniej omówione w rozdziale 12.

3. „Dostarczaj oprogramowanie często, w odstępach czasu od kilku tygodni do kilku miesięcy, preferując mniejsze odstępy czasowe”

Ten punkt narzuca zespołom pracę w iteracjach, których maksymalna długość będzie czasem narzucona przez używaną metodę. Na przykład w Scrum jest to najwyżej jeden miesiąc. Gotowe oprogramowanie, które dostarczamy klientowi, nie trafia oczywiście automatycznie na rynek – o tym decyduje klient.

4. „Ludzie biznesu i deweloperzy muszą pracować razem codziennie przez cały czas trwania projektu”

Razem? Codziennie? To już nie możemy trzymać testerów w piwnicy?[4] Nie możemy wysyłać maili Cc do wszystkich? Nie możemy przeskoczyć szczebla na drabinie hierarchii służbowej? Nie.

Metody zwinne działają dzięki krótkiej pętli informacji zwrotnej. Iteracje są częste i szkoda czasu na zajęcia bezproduktywne, jak komunikacja inna niż w cztery oczy. Jeśli programista utknie na jakimś etapie pracy, bo podczas implementacji pojawił się nowy, nieomawiany wcześniej szczegół, kto może błyskawicznie odpowiedzieć na jego pytanie? Oczywiście ktoś z biznesu. Kiedy tester znajdzie problem i nie jest pewien, czy jest to błąd, czy zaplanowana funkcja, kto rozwieje jego wątpliwości? Znowu odpowiedź jest jedna – osoba z biznesu. Dlatego tak ważne jest, aby w miarę możliwości zespół deweloperów i przedstawiciele biznesu siedzieli w jednym pomieszczeniu. Jeżeli niemożliwe jest (co zdarza się bardzo rzadko), aby osoba znająca realia biznesowe była zawsze obecna, należy zapewnić stały kontakt z przedstawicielem biznesu, który od tej pory będzie odpowiednikiem serwera proxy. Oczywiście wywoła to także pewne opóźnienie i przekłamania na linii. Z własnego doświadczenia wiem, że odległość pokój – dziesięć metrów korytarza – maszyna do kawy – dziesięć metrów korytarza – drugi pokój wywiera bardzo negatywny wpływ na komunikację. Nawet tak niewielki dystans sprawia, że ludzie zamiast podejść i porozmawiać, wolą poczekać, aż spotkają właściwą osobę przy automacie z kawą lub na kolejnym zebraniu.

Główną przyczyną nieporozumień podczas pracy nad projektem jest przepaść komunikacyjna pomiędzy sferą biznesu a zespołami deweloperskimi. Jednym ze sposobów na zmniejszenie tej różnicy jest zbliżenie tych dwóch posługujących się swoimi językami światów przez ich połączenie na co dzień. Przedstawiciele świata biznesu dowiedzą się więcej na temat rozwiązań informatycznych, ich ceny i konsekwencji utrzymania. Pracownicy IT będą z kolei uczyć się podstaw myślenia biznesowego, co pomoże im zrozumieć potrzeby i zaproponować najlepsze rozwiązania zamiast takich, które biznesowi wydają się oczywiste.

Pozwól proszę, że przytoczę przykład z mojego doświadczenia. Przy automacie z kawą spotkałem kiedyś dwóch handlowców, którzy rozmawiali o negocjacjach z nowym klientem dotyczących rozwiązania tworzonego przez mój zespół.

Podpisanie umowy zależało od możliwości udostępnienia API do naszej aplikacji webowej. Spytałem, po co im API, skoro oprócz interfejsu webowego mamy także rozbudowane funkcje wyszukiwania i eksportu danych. Klient chciał zintegrować wyszukiwanie danych przez własną aplikację i automatycznie przekazywać pasujące rekordy do dalszej obróbki.

Odpowiedziałem, że przecież może to zrobić przez bramkę XML, która od ponad roku jest dostępna na serwerze. Zdziwieni handlowcy nie wiedzieli, o czym mówię i w czym ma to pomóc, ale zgodzili się zorganizować konferencję z programistami klienta. W ciągu godziny programista z mojego zespołu pomógł dopisać potrzebną część skryptów w automacie klienta i umowa mogła zostać podpisana. Jedna godzina pracy programisty rozwiązała problem, który potrzebowałby dodatkowego projektu wycenionego na kilka tysięcy Euro.

Bramka XML trafiła do spisu funkcjonalności zawartego w ofercie handlowej i została wykorzystana jeszcze kilka razy.

W dalszej części książki opiszę kolejne metody i techniki pomagające zmniejszyć przepaść komunikacyjną.

5. „Projekty powierzaj zmotywowanym jednostkom. Daj im środowisko i wsparcie, którego potrzebują i zaufaj im, że praca zostanie wykonana”

Kto najlepiej wie, jak wykonać pracę, jak ją zorganizować i ile czasu na nią poświęcić? Oczywiście osoba, która ją faktycznie wykonuje. Wykonano wiele badań porównujących produktywność zespołów zarządzanych i pracujących według określonych procedur i samoorganizujących się zespołów profesjonalistów. Produktywność mierzona w punktach funkcyjnych[5] jest zazwyczaj dziesięć razy większa w zespołach samoorganizujących się. Głównymi czynnikami blokującymi zwinność projektów są kontrola i brak zaufania ze strony kierownictwa.

W zespołach pracujących zgodnie z metodyką Agile wszystkie decyzje dotyczące pracy są podejmowane codziennie przez zespół, więc, jak to określił Mike Cohn, mamy do czynienia z „mikromanagementem w Zespole”. Rola kierownictwa jest ograniczona do wspierania zespołu, zapewniania wszystkich elementów niezbędnych do wykonania pracy i usuwania przeszkód.

6. „Najskuteczniejszą i najwydajniejszą metodą przekazywania informacji w zespole deweloperów jest rozmowa w cztery oczy”

Zasada ta została już częściowo opisana w poprzednich punktach. W tym miejscu można jedynie zwięźle wytłumaczyć działanie procesu komunikacji.

Komunikacja to proces przekazywania informacji od nadawcy do odbiorcy. Jest ona efektywna, jeśli odbiorca potwierdzi, że otrzymał taki komunikat, jaki wysyłał nadawca. Najlepszym przykładem skutecznej komunikacji jest rozmowa pilota samolotu z wieżą kontroli lotów.

Z psychologicznego punktu widzenia rozróżniamy trzy rodzaje sygnałów komunikacji, które można uszeregować w następującym porządku pod względem znaczenia komunikatu: mowa ciała, brzmienie głosu i słowa. Wszystkie trzy elementy obecne są w komunikacji w cztery oczy lub podczas wideokonferencji. Podczas rozmowy telefonicznej tracimy element mowy ciała, a w komunikacji pisemnej – również brzmienie głosu. Dużo łatwiej pojawiają się więc błędy w komunikacji i wynikające z nich nieporozumienia. Ponadto wiadomości e-mail i dokumentacja to komunikacja asynchroniczna – nie wymagają natychmiastowej odpowiedzi, można ją odłożyć na później.

7. „Działające oprogramowanie jest podstawową miarą postępu”

Do śledzenia postępu projektu menedżerowie uwielbiają arkusze kalkulacyjne i prezentacje Power Point, które dają im złudne poczucie kontroli. Z ich tworzeniem związane jest zdefiniowanie mierzalnych wskaźników, które mają odzwierciedlać postęp projektu. Niestety, skutkuje to próbami osiągnięcia przez zespoły wskaźników, a nie stojącego za nimi celu.

W metodach zwinnych najwazniejszym wskaźnikiem jest działające oprogramowanie. Nieważne ile punktów z listy wykonał zespół, ile linii kodu napisał, ile błędów wykrył, jaki jest poziom złożoności cyklomatycznej (ang. cyclomatic complexity) itd. Najpierw sprawdzamy binarnie, czy oprogramowanie działa. Tak czy nie? Nie ma miejsca na odpowiedź „prawie gotowe”. Jeśli zespół nie dostarczył działającego oprogramowania, to poniósł porażkę. Od teraz czynnik ten powinien stać się dla zespołu najważniejszy.

8. „Procesy Agile promują zrównoważony rozwój [oprogramowania]. Sponsorzy, deweloperzy i użytkownicy powinni być w stanie utrzymać stałe tempo”

Jak pokazuje praktyka, członkowie zespołów pracujących w nadgodzinach popełniają więcej błędów wskutek przemęczenia, a ich zdrowie psychiczne zaczyna się pogarszać. Braku czasu na wypoczynek i odreagowanie stresu skutkuje napięciem i nerwową atmosferą w pracy, co negatywnie odbije się na pracy zespołowej. Duży stres wpływa też negatywnie na zdolność rozwiązywania problemów i kreatywność. Taka sytuacja często prowadzi do odejścia członków zespołu z pracy, co zmusza nas do znalezienia i wdrożenia nowych członków i jest procesem długim i kosztownym. Ponadto przy wprowadzaniu nowej osoby do zespołu produktywność nie spadnie o jeden, ale prawie o dwa FTE[6], ponieważ osoba odpowiedzialna za wyszkolenie nowego pracownika nie będzie pracowała równie efektywnie, jak wcześniej.

Na moich szkoleniach prowadzę ćwiczenie z piłkami, które doskonale ilustruje to zjawisko[7]. Każdy zespół wypracowuje optymalne tempo, w którym jest w stanie wykonać zadanie polegające na dostarczeniu wysokiej jakości produktów pracy. Jeśli jest to zauważalne w pracy polegającej na podawaniu piłek, to będzie tym bardziej istotne podczas skomplikowanej pracy nad projektem.

Istotne jest wypracowanie stałego tempa i utrzymywanie go przez cały czas trwania projektu. Na tempo zespołu wpływa oczywiście jego skład. Każda jego zmiana zmusza nas do ponownego rozpoczęcia cyklu Tuckmana.

Jeśli potrzebujesz nadgodzin, to nie pracujesz zgodnie z zasadami Agile. Kent Beck, twórca Programowania Ekstremalnego stwierdził nawet, że czterdziestogodzinny tydzień pracy jest jedną z podstaw jego metodyki.

9. „Ciągła koncentracja na technicznej doskonałości i dobrym projekcie (ang. design) poprawia zwinność (ang. agility)”

Kod napisany w pośpiechu i bez przemyślenia sprawia wiele problemów, zarówno w utrzymaniu, jak i podczas rozwijania systemu. Na początku liczymy na to, że na dalszych etapach będziemy dostarczać funkcjonalności szybciej, ale wraz ze wzrostem złożoności systemu nasz plan odwraca się o sto osiemdziesiąt stopni i działa przeciwko nam. Pojawiają się wtedy nowe problemy, począwszy od brakującej dokumentacji, przez zduplikowany kod, na modułach posiadających zbyt wiele funkcji skończywszy[8]. Czasem bardziej opłaca się napisać system od nowa niż próbować rozszerzyć istniejącą bazę. Widziałem na własne oczy, jak dwóch doświadczonych deweloperów zbudowało od nowa system tworzony przez dziewięć miesięcy przez sześciu zewnętrznych podwykonawców.

Ostatnio popularne stało się pojęcie Total Cost of Ownership (TCO), czyli całkowity koszt posiadania. Bierze on pod uwagę nie tylko koszt wyprodukowania sytemu w analizowanym momencie, ale także koszt utrzymania go w przyszłości. Biznes powinien być świadom tego problemu i brać go pod uwagę przy podejmowaniu decyzji odnośnie do budowy systemu. IT powinno wspomagać biznes, informując go o dokładnych konsekwencjach wyboru architektury systemu i podejścia.

Dużo bardziej efektywne, a w gruncie rzeczy opłacalne, jest budowanie elastycznego systemu z wykorzystaniem najlepszych praktyk programistycznych i optymalizacją kodu, kiedy jest to potrzebne. Rozszerzanie, skalowanie czy późniejsze utrzymanie systemu nie powinny wtedy stanowić dużego obciążenia, a sam projekt będzie bardziej opłacalny. Dokładne wskazówki, jak to zrobić, znajdują się w książkach dotyczących Clean Code. Oczywiście wymaga to posiadania w zespole doświadczonych specjalistów, prawdziwych mistrzów w swoim fachu.

Warto wspomnieć, że refactoring, czyli optymalizacja kodu, jest jedną z obowiązkowych praktyk Programowania Ekstremalnego.

10. „Prostota – sztuka zwiększania ilości pracy niewykonanej – jest niezbędna”

Projektant wie, że osiągnął doskonałość, nie wtedy,
kiedy nie można nic dodać, ale wtedy, kiedy nie można nic ująć.

Antoine De Saint-Exupery

Ponad sześćdziesiąt procent funkcjonalności oprogramowania używane jest rzadko lub wcale[9]. Nie wierzysz? Zajrzyj do instrukcji swojego telefonu komórkowego, a będziesz zaskoczony, o ilu funkcjach do tej pory nie wiedziałeś. No tak, ale gdzie leży instrukcja? Nigdy jej nie czytałeś, prawda? Tymczasem zbudowanie każdej funkcji jest kosztem biznesowym.

Kolejnym problemem rozwiązywanym przez prostotę jest podatność na błędy i zwiększone ryzyko produktowe.

Należy zatem budować system, dostarczając najpierw najprostsze rozwiązania problemów i podstawowe wersje funkcjonalności. Ich rozwijanie w sposób przyrostowy, kiedy jest to potrzebne, jest nie tylko łatwiejsze, ale i tańsze.