Przyczyna źródłowa

Pisząc o koncepcji Jidoka napisałem tak “[pracownik ma obowiązek] znaleźć przyczynę takowego niepożądanego stanu rzeczy, wyeliminować ją i dopiero potem [podjąć z powrotem pracę]”. Po zastanowieniu dochodzę do wniosku, że to jest świetny materiał na rozważania o tym, co powinno być elementem sesji retrospekcji i co leży w obowiązku kierownika projektu, zwłaszcza realizowanego metodami agile. Chodzi o to znajdowanie i eliminowanie przyczyn źródłowych problemów.

Jak się popatrzy na obecne środowisko pracy w wielu organizacjach to jedyną reakcją na problemy stosowaną przez wyższe kierownictwo jest coraz większy nacisk na to, aby problemów nie było. Jeżeli projekt przekracza deadline’y to kierownictwo wyznacza większe bonusy za dotrzymanie deadline’ów. Jeżeli jest za dużo błędów to grozi się obcięciem pensji za ponowne wypuszczenie błędnej wersji oprogramowania. Problem w tym, że takie podejście tak naprawdę konserwuje to, co jest. Bo zakłada, że wszystko robiliśmy dobrze, tylko się nie staraliśmy wystarczająco dobrze. Więc jeżeli następnym razem się postaramy bardziej to będzie dużo lepiej. Hmm, bardzo odważne założenie. W rzeczywistości będzie zapewne tak, że jak teraz przy tych metodach które mamy trochę nam nie wyszło to jak je zastosujemy jeszcze bardziej dokładnie to jeszcze bardziej nam nie wyjdzie.

Tak naprawdę rzadko kto podejmuje się zadania proponowanego przez Japończyków (choć nie tylko ich) czyli znalezienia przyczyny źródłowej takiego a nie innego stanu rzeczy. Wysiłek ten podejmowany jest rzadko, bo nie jest to zadanie proste. Przyczyna źródłowa oznacza zadawanie pytania “dlaczego” tak długo aż dojdziemy do odpowiedzi, której już dalej nie da się podzielić. Co więcej bardzo często znajdowanie przyczyny źródłowej polega na odkrywaniu i kwestionowaniu podstawowych założeń, na których oparta jest nasza organizacja i jej sposób działania.

Jeżeli popatrzyć na metodyki agile to najodpowiedniejszym miejscem do znajdowania przyczyn źródłowych problemów wydaje się być retrospekcja. Wówczas poza zastanowieniem się co się stało warto by też zastanowić się nad przyczynami źródłowymi problemów. Ponieważ nie jest to łatwe ani proste nie można się zastanawiać nad wieloma przyczynami źródłowymi jednocześnie. Raczej spośród wielu problemów nękających projekt należałoby wybrać jeden, który najbardziej boli i skupić się na jego rozwiązaniu. Czyli najpierw znaleźć jego przyczynę źródłową a dopiero potem wdrożyć rozwiązanie.

Aha i tutaj jedna uwaga. Przyczyny źródłowe problemów w projektach mają to do siebie, że często są tzw. przyczynami systemowymi. Czyli wynikają wprost z tego jak skonstruowany jest system, w tym wypadku system zarządzania w danej organizacji. Jeżeli przyczyna jest przyczyną systemową to aby permanentnie ją wyeliminować należy zmienić system. A to niestety często jest poza zasięgiem kompetencyjnym osób pracujących w projektach. Jedyne logiczne rozwiązanie w takiej sytuacji to rzeczony przypadek udokumentować oraz przedstawić odpowiednio wysokim menedżerom w firmie. A następnie mieć nadzieję, że zależy im na tym, aby ich system zarządzania działał sprawnie.

Dwa narzędzia, które mogą pomóc w znajdywaniu przyczyn źródłowych to na przykład A3 Problem Solving Method (bazująca na rozwiązaniach Toyoty) oraz Current Reality Tree (bazująca na narzędziach myślowych teorii ograniczeń).

Dług technologiczny

Koncepcja długu technologicznego jest stara jak agile a ostatnio natknąłem się na nią przy okazji robienia czegoś zupełnie innego. Co to jest dług technologiczny? Oto jak kiedyś mi to wytłumaczono: cokolwiek co czyni Twój produkt trudnym do zmiany w przyszłości jest długiem technologicznym - możesz albo zapłacić pełną cenę technologiczną teraz (zrobić od razu rozwiązanie elastyczne) albo zaciągnąć dług i spłacić go później (zrobić rozwiązanie szybkie ale nieelastyczne a przy pierwszej konieczności zmiany mieć trudność z brakiem elastyczności). Dług ma to do siebie, że generuje odsetki. To znaczy, że jeżeli dzisiaj nie poświęcimy dwóch dni na uczynienie naszego produktu elastycznym, to w przyszłości jeżeli będziemy chcieli przeprowadzić zmiany nie będzie kosztowało to dwa dni, tylko dwa dni plus odsetki. Odsetki te niestety przyrastają zdecydowanie szybciej niż w popularnych bankach. Efektem skrajnym jest kiedy produkt staje się tak niepodatny na zmiany, że prościej jest takowy produkt zrobić od nowa niż zmienić stary (sam byłem w takiej sytuacji).

W szczególności dług technologiczny dotyczy kodu oprogramowania. Tam jest bardzo łatwo zrobić rozwiązanie, które jest mało elastyczne ale bardzo szybkie we wdrożeniu (np. użycie nieudokumentowanych funkcji - kto z nas tego nie robił ;-)). Zdecydowanie trudniej jest napisać kod, który jest elastyczny. Co więcej często wprowadzenie zmiany sprawia, że kod staje się mniej elastyczny. Wówczas, aby nie zaciągać długu należy przeprowadzić refaktoryzację i zmienić kod tak, aby elastycznym był. Pominięcie refaktoryzacji spowoduje pogłębianie się długu, produkt będzie coraz trudniejszy do zmian. Prędzej czy później trzeba będzie za to zapłacić. Z tego punktu widzenia czas poświęcony na refaktoryzację to nie jest koszt. Jest to raczej inwestycja. Dzisiaj inwestujemy dwa dni pracy po to, aby w przyszłości nie musieć inwestować 5 dni w przeprowadzenie prostej zmiany.

Agile w sposób naturalny wspiera eliminację długu technologicznego. Poprzez iteracyjność oraz fakt, że nikt w zasadzie nie wie nad jakim kawałkiem produktu będzie pracował w przyszłej iteracji wspiera się aktywnie tworzenie rozwiązania bardzo elastycznego. W zespołach bardzo często tworzenie rozwiązań elastycznych jest przyjmowane jako jedna z głównych zasad pracy. Niestety nawet w przypadku takim jak ten, kiedy metodyka wspiera takie działania można cały ten efekt zepsuć. Najprościej dzięki mało kompetentnym kierownikom projektów, którzy nie pozwalają własnym zespołom na pracę dobrą a wymagają tylko pracy szybkiej. Jeżeli jesteście w takiej sytuacji to wytłumaczcie proszę zarządzającym koncepcję długu technologicznego i odsetek od niego. Moje ostatnie doświadczenia wskazują, że takie podejście skutkuje.

User Acceptance Tests

Ostatnio prowadziłem szkolenie z agile, podczas którego padło bardzo logiczne pytanie: „a co z User Acceptance Tests (UAT – testy akceptacyjne)? kiedy je się wykonuje i jak zapewnia się, że podczas ich trwania ma się dostęp do grupy wykonawczej, aby ewentualnie naprawić zgłoszone przez użytkowników błędy?”. Pytanie jak najbardziej logiczne, dobre i odpowiedź powinna gdzieś być do znalezienia. Niestety po przeszukaniu dostępnej w mojej biblioteczce literatury okazało się, że odpowiedzi na to pytanie nie ma w posiadanej przeze mnie literaturze agile. Dlatego napiszę co ja na ten temat sądzę i jak ta sprawa była rozwiązywana w firmach, w których widziałem duże wdrożenia metod zwinnych. I przy okazji: jak ktoś gdzieś ma opis w literaturze takiego lub podobnego rozwiązania to bardzo proszę o podanie mi źródła.

„Problem” z User Acceptance Tests wynika z faktu, że według procesów agile grupa wykonawcza, pracująca nad projektem powinna cały czas w ramach iteracji dostarczać kolejne działające inkarnacje produktu. Tymczasem w tzw. świecie realnym, w którymś momencie przychodzi moment, kiedy taki działający produkt należy pokazać klientowi, który to klient powinien się zdecydować czy produkt spełnia jego wymagania czy nie. Ta właśnie procedura nazywa się testami akceptacyjnymi (UAT) i zwykle trwa jakiś czas- na pewno nie jeden czy nawet dwa dni. Co więcej z punktu widzenia firmy produkującej oprogramowanie jest to czas, który jest krytyczny. W trakcie testów akceptacyjnych musi być stały dostęp do zespołu, który wytworzył dany produkt aby bardzo szybko reagować na ewentualne błędy (pamiętajmy, że testuje to już klient – użytkownik ostateczny). Jak to więc zrobić, aby mieć dostęp do grupy wykonawczej w środowisku agile?

Ano bardzo prosto. Tylko trzeba się wznieść na „poziom wyżej”. Tak jak już kiedyś pisałem poziom iteracji i poziom wersji rządzi się trochę innymi prawami jeżeli chodzi o planowanie. Przypomnę tylko, że w ramach jednej wersji może być kilka iteracji. Wersja natomiast oznacza wersję produkcyjną, która zostaje zainstalowana u klienta ostatecznego w jego środowisku produkcyjnym. W ramach danej wersji następujące po sobie iteracje stanowią pewną całość i odbywają się jedna po drugiej, bez przerw. Nikt jednak nie powiedział, że tak samo musi być z wersjami. Często jest to w ten sposób rysowane w różnej literaturze (prace nad kolejną wersją rozpoczynają sie natychmiast po zakończeniu prac nad poprzednią), ale praktyka często weryfikuje takie podejście. W praktyce jest tak, że po zakończeniu pracy nad jedną wersja produkcyjną danego produktu następuje jej wypuszczenie i wdrożenie (deployment) w środowisku klienta. Natomiast prace nad kolejną wersją tego samego produktu zaczynają się zwykle z pewnym opóźnieniem (na przykład 2-4 tygodnie). W trakcie tego „opóźnienia” odbywają się dwie rzeczy. Po pierwsze klient przeprowadza UAT wersji, którą dostał. Jako, że w tym czasie nie ma prac rozwojowych nad wersją kolejną to w przypadku jakiejkolwiek awarii zespół wykonawczy jest w stanie bardzo szybko zareagować na ewentualne problemy. Jednak zespół wykonawczy nie przeznacza tego czasu tylko na bycie w gotowości. Oprócz tego, ten czas przeznaczany jest na przygotowanie do rozpoczęcia prac nad kolejną wersją. Zwykle oznacza to w praktyce przejrzenie z kierownikami produktu wszystkich funkcjonalności mających wejść w skład następnej wersji, nadanie im priorytetów oraz przeprowadzenie wstępnej estymacji. I nie jest to wbrew zasadom agile – wręcz przeciwnie, powtórzę po raz kolejny, że agile to nie chaos i kierownicy produktu powinni na początku prac nad wersją wiedzieć co chcą w jej ramach dostać. Zwłaszcza jeżeli chodzi o funkcjonalności o wysokich priorytetach, które wejdą do produkcji w pierwszych iteracjach pracy nad nową wersją.

Na koniec podsumowując w jednym zdaniu: praktyka wskazuje, że User Acceptance Tests w projektach agile przeprowadza się w „przerwie” pomiędzy pracą nad kolejnymi wersjami produktu.

Metoda Uwe K.

Jakiś czas temu pracowałem dla naszych sąsiadów zza Odry i Nysy Łużyckiej a moim szefem był niejaki Uwe K. Miał on bardzo ciekawą metodę zarządzania zadaniami. Otóż dzwonił codziennie o godzinie 16.15 do mnie, jako do swojego pracownika i przekazywał ustnie zadania do wykonania. Następnego dnia często dzwonił o godzinie 8.00 z pytaniem gdzie może obejrzeć rezultaty mojej pracy. Najwięcej zadań oczywiście było przekazywane w piątek o 16.15, tylko po to, aby oczekiwać, że będą zrealizowane do poniedziałku do 8.00. Bardzo ciekawa metoda zarządzania to była. Szczególnie w kontekście tego, że życie nie składa sie jedynie z pracy. Jak się zapewne domyślacie dość szybko zacząłem aktywnie działać w kierunku zwolnienia Uwe K. z funkcji mojego szefa...

Historia powyższa przypomniała mi się gdy rozmawiałem w zeszłym tygodniu z pewną osobą, której nie udało się wdrożenie zwinnych metod zarządzania w średniej wielkości polskiej firmie informatycznej. Teoretycznie firma była idealna do wdrożenia. Produkty cechujące się dużą niepewnością funkcjonalności, bardzo duża możliwość testowania niepełnego produktu przez klientów ostatecznych, projekty na tyle małe, że można je robić jednym zespołem, więc odpadają wszelkie typowe problemy ze skalowaniem metod zwinnych. Niestety wdrożenie zostało wyłożone. Co się stało? Zacznijmy od tego, że wdrożenie agile project management zostało umotywowany tym, że "firma zbyt wolno reaguje na potrzeby klienta". Celem było więc stworzenie systemu, który pozwoli szybko reagować na zgłaszaną przez klienta informację zwrotną o produktach firmy. O ile osoby zajmujące się programowaniem dość szybko zrozumiały o co chodzi w nowym systemie pracy, to zrozumienie metod zwinnych po stronie osób zarządzających produktem (product managerów) było cokolwiek powierzchowne. Doprowadzono do sytuacji, w której dano product managerom pełną dowolność zmian funkcjonalności produktu bez liczenia się z opinią kierowników projektów realizacyjnych. Bardzo szybko spowodowało to pojawienie się syndromu opisanego powyżej. Objawiało się to wpisywaniem przez menedżerów produktu na listę funkcjonalności niezdefiniowanych rzeczy podczas spotkań planujących iterację. Realizatorzy prosili o uszczegółowienie takich wymagań, co następowało zwykle na trzy dni przed końcem iteracji. Na innym poziomie było wrzucanie do ostatniej iteracji przed wypuszczeniem wersji zmian fundamentalnych, wymagających zmian w architekturze - oczywiście tłumaczone nagłą potrzebą klienta. A także inne kwiatki, których nie mogę opublikować. Jak się domyślacie oczekiwanie było, że na koniec każdej iteracji będzie dostępny działający produkt. A już wersja to koniecznie musiała być, bo przecież obiecana klientowi. Jakiekolwiek tłumaczenie od strony realizatorów, że taka praca jest nieoptymalna menedżerowie produktów kwitowali krótko: "no jak to, czy to znaczy, że nie jesteście wystarczająco agile?". Dość szybko ludzie z zespołów realizacyjnych zaczęli myśleć dokładnie to, co ja myślałem o moim szefie.

Nauka z tego taka, że zwinność zwinnością, ale i tak zawsze trzeba pamiętać, że istnieje gdzieś niepisana cienka linia, której przekroczenie spowoduje zabicie metody. Najpierw na poziomie elementarnego poziomu i trzymania się zasad. Chwilę potem na poziomie ludzkich relacji i chęci dalszej współpracy. Napiszę jeszcze raz to, co już tu wielokrotnie wprowadzałem: agile to wprowadzanie porządku w chaos. Agile to nie jest zarządzanie bez reguł.

I na koniec taka refleksja. Nie wiem dlaczego, ale zaczyna u mnie dominować przekonanie, że wdrożenia metod agile są najbardziej zagrożone nie od strony realizacji, ale od strony zarządzania produktem. Właśnie ze względu na błędne zrozumienie, że agile oznacza "wszystko nam wolno". A co ciekawe firmy praktycznie nigdy nie chcą aby im szkolić menedżerów produktów...

Dokumentacja wdrożeniowa i administracyjna

Ostatnio pojawiło się bardzo dużo, bardzo ciekawej pracy. Stąd przerwy w pisaniu na blogu. Będę próbował się poprawiać :-)

Wracając do tematu, spotkałem się z bardzo ciekawym człowiekiem, który pisze pracę magisterską z dziedziny agile. Konkretne na temat dokumentacji w projektach realizowanych metodami zwinnymi. Ja już kiedyś swoje zdanie na ten temat wyraziłem (tutaj). W trakcie rozmowy wyniknął jednak jeden ciekawy problem.

Kto bowiem w zespole pracującym zgodnie z metodami zwinnymi jest odpowiedzialny za pisanie dokumentacji wdrożeniowej i administracyjnej? Na początek ustalmy pojęcia. Dokumentacja wdrożeniowa obejmuje opis procesu, który trzeba zastosować, aby system został uruchomiony w środowisku klienta i poprawnie funkcjonował z innymi systemami wcześniej tam obecnymi. Dokumentacja administracyjna obejmuje opis procedur, które muszą być stosowane przez osoby obsługujące systemy (bardzo często są to pracownicy naszego klienta) aby zapewnić utrzymanie systemu. Często dokumentacja administracyjna obejmuje też instrukcję radzenia sobie z najczęstszymi problemami.

W przypadku dokumentacji technicznej oraz dokumentacji użytkownika sprawa jest dość prosta. Odpowiadają za nią członkowie zespołu, którzy jednocześnie piszą kod bądź testują oprogramowanie. Z dokumentacją wdrożeniową, a już zwłaszcza administracyjną, jest jednak inaczej. Otóż w najczęściej spotykanych przypadkach jest tak, że osoby zajmujące się wdrożeniami systemu (czy też integracją systemów) nie są bezpośrednio członkami zespołów agilowych. Wynika to z faktu, że w większość znanych mi firm (nie mówię tu o sytuacji super-idealnej wziętej z książki któregoś z guru) osoby zajmujące się rozwojem produktu oraz osoby zajmujące się jego wdrożeniem i później ewentualnie administracją pracują w różnych działach, często nie mających ze sobą nic wspólnego. Dlatego w znanych mi zespołach nie było osób z kwalifikacjami potrzebnymi do napisania tego typu dokumentacji.

Jak więc sobie z tym poradzić? Długo się zastanawiałem i wymyśliłem dwa sposoby. Pierwszy jest „ortodoksyjny”. To znaczy zespół agilowy jest odpowiedzialny za stworzenie i tej dokumentacji. Przy czym oznacza to wprowadzenie do zespołu osoby, która się na tym zna. Oznacza to, niestety, że zespół się rozrośnie, bo tak jak to wspomniałem wcześniej rzadko zdarza się, żeby osoby pracujące nad rozwojem produktu miały wiedzę i umiejętności potrzebne do napisania takiej właśnie dokumentacji. Drugim rozwiązaniem, bardziej praktycznym, jest… odpuszczenie sobie tej dokumentacji na poziomie prac wykonywanych w poszczególnych iteracjach. Dokumentacja wdrożeniowa i administracyjna powinna pojawiać się wówczas jako element wypuszczanej wersji a nie produkt iteracji (o różnicach w planowaniu wersji i iteracji pisałem tutaj). Wówczas będzie działać to tak, że zanim wersja zostanie uznana za gotową do wypuszczenia do klientów jako warunek konieczny pojawi się „dostępna dokumentacja wdrożeniowa i administracyjna”. Pracę tą można wykonać na przykład podczas iteracji synchronizującej (tutaj). Ma to też sens patrząc się ze strony działów wdrożeń, których pracownicy będą się musieli uczyć zmian w systemie raz na wersję a nie raz na iterację. Z ich punktu widzenia to akurat bardzo duże ułatwienie.

Dzielenie funkcjonalności raz jeszcze

Prawie dokładnie dwa lata temu napisałem post nt. wielkości funkcjonalności. Post był krótki i treściwy, ale po dwóch latach w sposób równie krótki i równie treściwy muszę dokonać pewnej modyfikacji tego, co w nim napisałem.

Otóż jak najbardziej prawdą jest, że w ramach iteracji powinniśmy realizować funkcjonalności, których wielkość jest nie większa niż jedna iteracja. Doświadczenie dwóch lat nauczyło mnie jednak, że nie jest optymalne mówienie, iż każda z tych funkcjonalności musi dostarczać wartość dodaną dla klienta. Powinno się mówić o tym, że każda z funkcjonalności (w tym takie po podziale) powinny dostarczać wartość dodaną dla właściciela produktu (Product Managera). Czy to robi różnicę? Subtelną, ale jednak robi. Różnica ta polega na tym, że właściciel produktu nie koniecznie jest klientem (aczkolwiek może nim być). Zdarzyło mi się w mojej praktyce spotkać się z przypadkami, kiedy klient końcowy jako wartość dodaną dla siebie widział tylko i wyłącznie coś, co jest efektem końcowym całego projektu. Po prostu z punktu widzenia klienta końcowego żaden z elementów pośrednich, będących efektami poszczególnych iteracji nie powoduje, że biznes klienta zacznie lepiej działać i przynosić lepsze efekty. Dlatego czasami trudno tu jest mówić o wartości dodanej poszczególnych iteracji. Z punktu widzenia klienta takowych po prostu nie ma.

Natomiast wartość dodana z punktu widzenia właściciela produktu może być trochę inną wartością dodaną niż z punktu widzenia klienta. Na przykład posiadanie części rozwiązania może być dla właściciela produktu wartością, bo wie, że jest bliżej całości rozwiązania. Natomiast z punktu widzenia klienta to nie ma żadnego znaczenia, bo jemu wartość przynosi tylko i wyłącznie rozwiązanie w całości.

Nauka z tego taka, że w planowaniu zwinnym jeżeli istnieje ktoś taki jak właściciel produktu to planowanie odbywa się z oparciu o jego definicję wartości i on odpowiada za definiowanie funkcjonalności. I to właściciel produktu odpowiedzialny jest za to, aby koniec końców produkt dostarczał wartość dla klienta ostatecznego.

Uwaga!!! Klient i właściciel produktu w niektórych przypadkach to może być jedna i ta sama osoba, wtedy oczywiście cały ten post i tłumaczenie ma mały sens.

I na koniec jeszcze jedno spostrzeżenie. Gdyby nie praktyczna próba zastosowania agile nigdy nie spotkałbym się z taką sytuacją i nigdy nie przypuszczałbym, że wartość dodana dla klienta może w pewnych wypadkach być tak trudna do zastosowania. Ale od czego jesteśmy zwinni (agile). W sposób agilowy dostosowaliśmy się do panujących warunków. Zastanawiam się tylko jak by się w takiej sytuacji zachowali reprezentanci nurtu "agile ortodoksyjny"?

Wieloprojektowość

Wyobraźcie sobie szpital, w którym operuje się chorych. Teraz kierownictwo tego szpitala, jako że chce skutecznie i szybko leczyć swoich pacjentów nakazuje aby natychmiast jak tylko pojawi się pacjent kierować go na potrzebną mu operację. Pomyślcie co się zaczyna dziać na salach operacyjnych. Jak jest jeden czy dwóch pacjentów to jest jeszcze dobrze, potem zaczyna być ich coraz więcej (kierowani są na operacje od razu jak tylko się pojawią). W końcu jest ich więcej niż zespołów lekarzy chirurgów i sal operacyjnych. Co w tym momencie robi kierownictwo szpitala? Nakazuje, żeby jeden zespół lekarzy wykorzystujący jedną salę operacyjną jednocześnie robił kilka operacji. Przecież Ci lekarze to świetni specjaliści, na pewno jakoś dadzą radę. Tak więc zaczyna się dzielenie czasu. Nad jednym pacjentem godzina, potem godzina dla drugiego. W miarę jak rośnie ich liczba zaczyna się problem z dostępnością sal operacyjnych. Anestezjologów zresztą też brakuje. W związku z tym tworzymy listy dostępności sali wraz ze ścisłym harmonogramem, który chirurg kiedy operuje którego pacjenta a który anestezjolog gdzie asystuje. Sale są dokładnie na godziny, więc nie można się spóźniać. Problem w tym co chirurdzy mają robić w czasie, gdy nie mogą operować swojego pacjenta, bo sala jest zajęta. Najchętniej by poczekali, ale szefostwo szpitala nie chce marnować drogocennego czasu chirurgów. Przecież to są świetni specjaliści i nie mogą w pracy spędzać "nieproduktywnych" godzin. W związku z tym szefostwo nakazuje chirurgom robić obchody w czasie jak ich (już "rozpoczęty") pacjent czeka na wolną salę. Skutek jest taki, że przestają zdążać na swój czas w harmonogramie dostępności sali, bo nie mogą się oderwać od obchodów. A jak już przyjdą i zaczną operować to jak tylko się dobrze "wdrożą" w danego pacjenta okazuje się, ze muszą go zostawić, bo w harmonogramie skończył się czas dostępności dla nich sali operacyjnej. Anestezjolodzy mają podobny problem.

Jesteście oburzeni takim podejściem? Kto by się chciał tam leczyć?

Teraz proszę podstawicie sobie w powyższym przykładzie zamiast "pacjent" to "projekt", zamiast "chirurg" to "programista" a zamiast "sala operacyjna" to "serwerownia" (czy dowolny inny zasób, który jest wystarczający rzadki w Waszym środowisku). Brzmi znajomo? Nikt nie zadaje pytania "kto by kupił projekt od takiej organizacji"?

Ciekawe jest, że branża medyczna, jakkolwiek niedoskonała, już od dawna potrafi sobie radzić z taką sytuacją. W prosty sposób: dedykowane zespoły, priorytetyzacja wykorzystania kluczowych zasobów (najpierw ten co ma życie zagrożone a potem ten co operacja plastyczna), kolejkowanie pacjentów zamiast współbieżności. Śmiem twierdzić, że nawet w Polsce statystyki sukcesów są dużo lepsze dla operacji medycznych niż dla projektów, w tym zwłaszcza projektów innowacyjnych. Znaczy, że takie rozwiązania działają. Teraz wypadałoby podpatrzyć czy u nas nei da się tak samo. I tutaj niespodzianka. Zarządzanie zwinne bardzo podobnie podchodzi do portfolio projektów jak szpital do operacji. To znaczy: zespół jest dedykowany do jednego projektu (nie wolno pożyczać ludzi), projekty robi się jeden po drugim a nie współbieżnie, a priorytety zapewnia właściciel produktu. Czyli podobnie. Ciekawe, dlaczego skoro w branży medycznej te zasady uznajemy za taką oczywistość w projektach już nie.

Kontrakty na projekty zwinne

Ostatnie kilka tygodni spędziłem bardzo pracowicie spotykając się z wieloma bardzo interesującymi ludźmi. Stąd dłuższy brak postów na blogu. Z drugiej strony spotkania te były niezwykle interesujące i dostarczyły bardzo ciekawych spostrzeżeń.

Przykład, który mnie najbardziej zadziwił to omawiany już tu kiedyś (tutaj) „problem” kontraktów na projekty zwinne. Generalnie podczas każdej prezentacji, szkolenia czy nawet rozmowy na temat zwinnych metod zarządzania projektami prędzej czy później któryś z obecnych kierowników projektów podnosi „problem” kontraktów. Najczęściej przybiera to formę pytania „a co ja mam powiedzieć mojemu klientowi jak on zapyta ile będzie kosztował cały system”. Zwykle w takich przypadkach tłumaczę, że kontrakty na projekty realizowane zwinnie powinny być płacone inkrementalnie za wykonaną pracę, tak jak jest dostarczana funkcjonalność. Odpowiedź kierowników jest zwykle jedna: „moi klienci się na to nigdy nie zgodzą, oni chcą wiedzieć ile będzie kosztowała całość”. Dyskusja trwa długo.

Otóż tak się składa, że rozmawiałem ostatnio z kilkoma osobami, na co dzień kupującymi oprogramowanie, w tym oprogramowanie tworzone na zamówienie. Jako, że metody zwinne moim konikiem są, prędzej czy później schodziło na tą tematykę. Z wielkim zdziwieniem stwierdzałem, że idea zwinnego rozwoju oprogramowania, w tym płacenia inkrementalnego... bardzo im się (wszystkim) podobała. Jako, że byli to ludzie odpowiedzialni za pieniądze natychmiast (wszyscy) reagowali tak samo: to jest idealny sposób ograniczania ryzyka. Jeden z nich wprost od razu zapytał gdzie może znaleźć firmę, która zgodzi się na rozwój oprogramowania w taki właśnie sposób: płacenia za krótkie, ściśle zdefiniowane iteracje. Czy przeszkadza im to, że nie wiedzą ile będzie kosztowała całość? W zasadzie nie. Ewentualne kontrowersje natychmiast znikały gdy dowiadywali się, że będą mogli zmieniać definicję „całości” w dowolnym momencie, ze skutkiem z końcem kolejnej iteracji. To jest racjonalne, bo przecież zwykle oprogramowanie kupuje się nie po to, aby było „całością”, tylko po to, aby realizowało potrzeby biznesowe. Co ciekawe ludzie, którzy zlecają tworzenie oprogramowania rewelacyjnie to rozumieją. Dla nich rachunek jest prosty: kwota jaką zapłaciłem za oprogramowanie musi być (zdecydowanie) mniejsza niż korzyść wyrażona finansowo, którą ono (szybko) wygeneruje. Dlatego możliwość dynamicznego dostosowywania się do zmieniających się potrzeb i w ten sposób możliwość szybszego generowania większej korzyści jest bardzo, ale to bardzo dużą realną wartością. Więc ja się pytam o jakim „problemie” kontraktów na projekty zwinne mówią kierownicy projektów? Zadanie domowe dla nich: przy następnej rozmowie z klientem zapytajcie się czy nie zgodziliby się na kontrakt oparty o metody zwinne zarządzania projektami.

Na koniec jedna uwaga: klienci z którymi rozmawiałem są osobami wydającymi pieniądze, że które ponoszą pełną odpowiedzialność (w części są to ich własne pieniądze). Podkreślam to, bo w korporacjach, gdzie wydaje się pieniądze „budżetowe” sprawa może wyglądać zdecydowanie inaczej.

Co to jest to Agile Project Management?

Jak w największym skrócie wytłumaczyć czym jest zwinne zarządzanie projektami (Agile Project Management)? Odpowiedź w szczegółach będzie inna w zależności od tego do kogo ma być skierowana. W jednym zdaniu powiedziałbym tak:

Dla organizacji, działających w warunkach, w których istnieje niepewność dotycząca technologii bądź wymagań klienta, Agile Project Management jest klasą metod zarządzania projektami pozwalającą,w odróżnieniu od innych, na natychmiastowe rozpoczęcie, uporządkowane poprowadzenie i zakończenie z sukcesem projektów kierując sie cały czas przepływem wartości dodanej dla odbiorcy produktów projektu.*

Miejscem, gdzie metody zwinne znajdują najlepsze zastosowanie są te środowiska, w których występuje niepewność. Na przykład wszelkiego typu projekty innowacyjne lub projekty dla bardzo szybko zmieniających się rynków (internet, „nowe media”). W takich wypadkach nie ma możliwości dokładnego zaplanowania całości projektu w sensownym czasie. Mamy więc klasyczny dylemat: albo planujemy dokładnie (bo tak jest bezpiecznej) i odkładamy start projektu w nieskończoność albo zaczynamy działać szybko (bo tak wymaga rynek) w oparciu o niepełne plany. Metody zwinne rozwiązują ten potencjalny konflikt dając zestaw narzędzi pozwalający na rozpoczęcie projektów w nie będąc pewnym całego planu osiągnięcia celów projektu. Co więcej dają możliwość usystematyzowania prac nad takim projektem w sposób, który gwarantuje, że zespół mimo braku posiadania pełnego planu pozostanie na właściwej drodze i będzie wykonywał właściwe zadania.

Metody zwinnego zarządzania projektami są tak skonstruowane, że mimo braku pewności co do dróg osiągnięcia celów projektu jeden parametr jest cały czas w punkcie skupienia zarówno kierownictwa projektu jak i każdego członka zespołu. Tym parametrem jest przepływ dodanej wartości biznesowej dla odbiorcy produktów projektu (klienta). Ta jedna cecha stanowi, że w połączeniu z elastycznością tego rozwiązania projekty realizowane metodami zwinnymi mają zdecydowanie większe szanse zakończyć się sukcesem. Klient jest zaangażowany w cały proces decyzyjny w projekcie zwinnym. Zespół projektowy realizując projekt ściśle odpowiada na potrzeby klienta dostarczając mu dokładnie te elementy, które stanowią realną wartość dodaną dla klienta. Takie podejście powoduje, że z jednej strony zespół projektowy uczy się co ma a co nie ma wartości w danym projekcie, z drugiej odbiorca produktu (klient) doskonale wie, że będzie dostawał dokładnie to, co dla niego jest wartościowe a nie to co wartościowe jest dla zespołu projektowego.

Na koniec rzecz wcale nie najmniej ważna, którą zawsze lubię podkreślać. Zarządzanie zwinne projektami, poprawnie zaimplementowane, oprócz opisanych wcześniej realnych zalet biznesowych ma jedną niepowtarzalną zaletę ludzką: zespoły projektowe po prostu lubią pracować tą metodą. Jakie są tego powody tłumaczyłem tutaj. A możliwe implikacje biznesowe przedstawiałem nie swoimi słowami tutaj.

*Dodatkowy warunek konieczny: produkty projektu można dostarczać w postaci inkrementacyjnej. To oznacza, że funkcjonalność, którą spodziewamy się dostać w ramach całego projektu powinna być możliwa do podzielenia na tak małe części, aby każdą z nich dało się wykonać w ramach jednej, dość krótkiej (2-6 tygodni), iteracji.

Iteracje synchronizujące

Kiedyś pisałem o tym, że nie każda iteracja musi być „zwykłą” iteracją. Wtedy podawałem przykład tzw. iteracji 0, których cechą jest dostarczanie wartości dodanej dla zespołu projektowego nie dla klienta. Osobom wyznającym „agile ortodoksyjny” na pewno się to nie spodoba, ale ja dopuszczam poza iteracją 0 także inne „specjalne” iteracje. Ważne tylko jest, aby każda z tych iteracji dostarczała realną wartość dodaną dla klienta. Nie dopuszczam sytuacji, kiedy iteracja inna niż 0 nie wytwarza rzeczywistej wartości dodanej.

Szczególnym przykładem takiej specjalnej iteracji jest coś, co popularnie nazywa się iteracjami synchronizującymi. Takie iteracje występują w sytuacji, kiedy na jeden produkt składa się więcej niż jeden element wytwarzany metodami zwinnymi w jednym czasie. Wówczas w którymś momencie musi nastąpić połączenie poszczególnych elementów w jeden produkt, czyli integracja komponentów. „Agile ortodoksyjne” zakłada, że takie komponenty są integrowane cały czas wykorzystując mechanizmy ciągłej integracji. W praktyce często zdarza się jednak, że z różnych powodów nie jest możliwe przeprowadzanie ciągłej integracji. Wówczas dość często stosuje się tak zwane iteracje synchronizujące. Polega to na tym, że dana wersja produktu jest rozwijana w ramach poszczególnych komponentów (czyli normalnie). Ostatnia iteracja w rozwoju danej wersji przeznaczona jest na poskładanie w całość wszystkich komponentów. Z punktu widzenia przepływu wartość dla klienta wygląda to tak, że do przedostatnie iteracji klient dostaje komponenty o zwiększonej funkcjonalności, natomiast zwiększoną wartością ostatniej iteracji jest działanie systemu (zamiast sumy komponentów). Takie działania integracyjne w ramach ściśle określonej iteracji dają w większości przypadków bardzo pozytywne efekty. Należy jedynie pamiętać, aby tą akurat iterację zaplanować od strony czasowej bardzo konserwatywnie. Powód jest bardzo prosty. Bez włączonych mechanizmów ciągłej integracji okazuje się, że sama integracja wykazuje wiele błędów w poszczególnych komponentach. Dlatego dodatkowy czas musi być przeznaczony na ewentualne poprawki znalezionych błędów. Cóż: coś za coś – brak „problemów” ciągłej integracji skutkuje zwiększonymi kosztami poprawiania błędów.

Na koniec dwie uwagi do powyższego tematu. Po pierwsze mimo braku zaimplementowanych mechanizmów ciągłej integracji pod żadnym pozorem nie wolno doprowadzić do rozjechania się interfejsów poszczególnych komponentów. Zadanie zsynchronizowania poszczególnych części jest w takiej konfiguracji szczególnie ważne i powinno zostać powierzone osobie odpowiedzialnej za całość przedsięwzięcia (uwaga, to też nie jest zgodne z „agile ortodoksyjnym”).

Druga uwaga, to dość oczywisty, ale często zapominany fakt, że problemy z integracją komponentów w największym stopniu można ograniczyć poprzez inteligentny i przemyślany podział na całości systemu na części. Do takich przemyśleń można wykorzystać na przykład czas iteracji 0. Jak konkretnie to zrobić to byłby już temat na osobny post.

Metody zwinne w organizacji "stabilnej" cz. 3

Dzisiaj kolejny powód, dla którego organizacje stabilne wdrażają zwinne metody zarządzania projektami. Powodem tym jest przejrzystość prac, którą zapewniają metody zwinne.

Przejrzystość prac jest widoczna na dwóch ogólnych poziomach. Po pierwsze przejrzyste jest to co kto robi i jaki jest stopień zaawansowania prac. Podczas codziennych spotkań zespołu uczestnicy projektu opowiadają nad czym pracowali wczoraj i co będą robić dzisiaj, co skutkuje bardzo szybkim rozpowszechnianiem się informacji. Prowadzi to do jasnej sytuacji na temat tego, jakie jest aktualne zajęcie wszystkich członków zespołu. Innym, jeszcze ciekawszym narzędziem są wszelkiego typu „radiatory informacji” wykorzystywane przez zespoły do graficznej prezentacji zaawansowania prac. To temat na osobny post, ale w skrócie narzędzia te są „analogowe” (np. tablica z żółtymi karteczkami) a nie elektroniczne i mogą zawierać najważniejsze informacje zarządcze dotyczące projektu: co zostało zrobione, co jest robione, co będzie robione, a także informacje o tym jak aktualny status ma się do planu. Wszystko to jest przedstawione wizualnie. To narzędzie jest genialne w swojej prostocie a jednocześnie przekazuje zadziwiająco dużo informacji.

Drugim poziomem przejrzystości jest przejrzystość w stosunku do klienta. W tradycyjnych metodach zarządzania projektami często jest tak, że klient nie ma najmniejszej wiedzy, co się dzieje w projekcie, za który przecież płaci, aż do dnia ostatecznego odbioru produktu. Techniki zwinne zakładają inne podejście. Po pierwsze klient musi być zaangażowany cały czas. W każdej chwili zespół pracujący nad projektem ma prawo zapytać się klienta o uszczegółowienie wymagań lub potwierdzić, że wymagania zostały zaimplementowane poprawnie. Takie zaangażowanie samo w sobie daje klientowi wgląd w to, nad czym aktualnie pracuje zespół projektowy i wystarcza, aby klient nie miał pretensji, co do stopnia informowania go o stanie projektu. Jednak techniki zwinne mają jeszcze jedno potężne narzędzie: krótkie iteracje zakańczane działającą wersją produktu. Po każdej z iteracji klient może wypróbować nowe funkcjonalność stworzone podczas tej iteracji. W związku z tym klient ma cały czas poczucie, że wie, za co płaci. Wie też, kiedy pojawią się kolejne funkcjonalności do przetestowania (na koniec aktualnej iteracji). To z punktu widzenia klienta zapewnia pełną przejrzystość i pozwala na utrzymanie bardzo dobrych relacji z dostawcą. Uwaga!!! Trzeba być jednak świadomym, że taka sytuacja nie powstanie od razu i jej wypracowanie będzie wymagało włożenia odpowiednio dużej ilości czasu w ustalanie zasad współpracy z klientem.

Inną stroną przejrzystości prac jest to, o czym wspomniał jakiś czas temu w komentarzach Marcin (tutaj). Przejrzystość może być bowiem bardzo niewygodna dla tych, którzy mówiąc delikatnie „nie lubią” pracować. Częste sprawdzanie postępu prac i konieczność wyraźnego informowania o tym co się zrobiło powoduje, że nie ma mowy o ukrywaniu się przez kilka dni nic nie robiąc. Poza ewidentnym pokazaniem szefom, że taki pracownik jest zbędny w środowiskach pracujących według metod zwinnych pojawia się bardzo silna presja ze strony grupy. Podczas wspomnianych codziennych spotkań wszyscy współpracownicy słyszą i widzą kto pracuje mało. Doświadczenie wskazuje też, że da się wyczuć kto po prostu się obija a kto rzeczywiście tworzy mało bo ma jakieś problemy. Osoby ewidentnie się obijające są pod bardzo dużą presją grupy aby zabrać się do pracy.

I w ten sposób ujawnia się jeszcze jedna duża zaleta metod zwinnych: znacząco wzrasta wydajność zespołów pracujących przy użyciu tych metod w porównaniu do zespołów stosujących metody tradycyjne. Rzecz nie do przecenienia w biznesowym świecie nastawionym na efektywność prac. Co więcej wzrost tej efektywności nie ma żadnego negatywnego wpływu na atmosferę prac. Wręcz przeciwnie ma wpływ pozytywny.

Metody zwinne w organizacji "stabilnej" cz. 2

Wracamy do tematu wdrażania metod zwinnych w organizacji stabilnej. Jak już pisałem wcześniej (tutaj) jest to obecnie pewna moda, ale są też realne powody dla których taka decyzja może być podjęta. Dzisiaj o aspekcie biznesowo-technicznym a mianowicie o uzyskiwaniu informacji zwrotnej od klienta.

Metody zwinne prowadzenia projektów zakładają podejście iteracyjne do tworzenia produktu. Każda z krótkich iteracji zakończona jest przedstawieniem klientowi działającej wersji produktu, która jest wzbogacona o konkretną wartość biznesową w porównaniu z wersją dostępną na początku iteracji. Klient uczestniczy w prezentacji funkcjonalności stworzonej podczas iteracji i/lub dostaje niewykończony produkt do testów. To, że klient widzi działający produkt powoduje natychmiastową reakcję klienta i dostarczenie zespołowi informacji zwrotnej (feedback) na temat produktu. Najważniejsze w tym opisie jest to, że w odróżnieniu od innych metod zarządzania w metodach zwinnych obowiązkowo informacje zwrotną klient przekazuje po każdej iteracji, czyli bardzo często. Dla każdej organizacji nastawionej na dostarczanie wartości dodanej dla klienta częsta informacja zwrotna jest kluczowym czynnikiem sukcesu. Pozwala ona bardzo często dokonywać sprawdzenia, czy rozwijany produkt faktycznie spełnia oczekiwania klienta, będzie mu przydatny i ogólnie czy będzie sukcesem (z punktu widzenia stopnia zadowolenia klienta). Dla tych graczy na rynku, którzy faktycznie żywią się sukcesem swoich klientów jest to zaleta nie do przecenienia.

Dla tych samych graczy kluczowy jest także drugi aspekt zbierania informacji zwrotnej od klientów w projektach zarządzanych zwinnie. Otóż informacja ta jest w 100% zbierana na podstawie stworzonej i działającej wersji produktu ostatecznego. W innych metodach bardzo często zdarza się, że informacja zwrotna zbierana jest na podstawie analizy dokumentów. Problem w tym jest taki, że każdy dokument ma pewien stopień swobody interpretacyjnej. Co więcej im mniej jest tej swobody tym dokument droższy do stworzenia. Zwykle następuje więc kompromis pomiędzy stopniem swobody a kosztami wytworzenia dokumentacji. Efekt jest taki, że choć obie strony przeczytają dokument i według nich będzie on dobry, obie zrozumieją go inaczej i klient dostanie nie to, co sobie zinterpretował z dokumentu. Porażka i negocjacje dotyczące trybu wprowadzenia poprawek są w takiej sytuacji gwarantowane. Metody zwinne pozwalają zbierać informację zwrotną już na podstawie stworzonego produktu. Klient namacalnie może stwierdzić, czy to jest zgodne z jego oczekiwaniami. Nie ma tu już możliwości interpretacji, bo ogląda działający produkt. W ten sposób przekazywana informacja zwrotna jest nie tylko częsta i szybka, ale także dokładna. Dla firm „upolitycznionych” żyjących z tego jak dobrych mają prawników może to być duża wada, ale dla większości firm, które dostają faktury za spełnienie oczekiwań swoich klientów może być to kluczowa element budowania dobrej marki.

Warto wspomnieć o dwóch biznesowych skutkach częstego zbierania dokładnej informacji zwrotnej. Po pierwsze dramatycznie zmniejszają się koszty poprawek. Choć na początku projektu klient może zgłaszać ich dużo to po praktyka wskazuje, że po pewnym okresie (kilka iteracji) jest ich już znacząco mniej, bo zespół uczy się na czym zależy klientowi. Taka sytuacja powoduje, że jest możliwe wprowadzenie kluczowych poprawek w momencie, kiedy produkt jest jeszcze stosunkowo mały (1-3 iteracja). Jest to zdecydowanie tańsze niż wprowadzanie tej samej poprawki w momencie, kiedy produkt już się rozrósł. Po drugie zbieranie szybkiej informacji zwrotnej od klienta pozwala bardzo szybko zlikwidować nieudane projekty. W każdej organizacji zdarza się tak, że czasami któryś projekt nie jest udany i nie ma szans na sukces. Problem, który się zwykle pojawia, to że okazuje się to kiedy organizacja zainwestowała już w projekt bardzo dużo środków. Wówczas podjęcie decyzji o zamknięciu takiego projektu jest bardzo trudne, bo ciężko jest się przyznać do tak dużego błędu. Metody zwinne pozwalają oceniać projekt po każdej iteracji przez tych, którzy będą go używać. Z tego względu jeżeli projekt jest nietrafione często da się to wykryć już po drugiej/trzeciej iteracji i zlikwidować go przy dużo niższych kosztach niż w tradycyjnych metodach. Jest to kluczowe zwłaszcza dla firm działających w sferze wysoce innowacyjnej lub przy bardzo szybko zmieniającym się rynku.

Szacowanie przy użyciu prędkości

Pytanie, które pojawia się dość często jest następujące: jak oszacować kiedy zakończy się projekt (rozumiany w sensie dostępnej kolejnej wersji produktu)? Jak wszystkie inne problemy w sztuce zwinnego zarządzania projektami jest to proste, choć niekoniecznie zgodne z tym czego oczekiwaliby specjaliści od tradycyjnych metod zarządzania projektami.

Podstawą szacowania jest tzw. prędkość pracy zespołu. Prędkość ta określa ile jednostek funkcjonalności zespół jest w stanie ukończyć w trakcie jednej iteracji. To ile "warta" jest każda z funkcjonalności jest określane zgrubnie przez zespół na etapie planowania wersji. Później jest to doprecyzowane przy poszczególnych etapach planowania i/lub retrospekcji. W każdym razie po etapie planowania wersji powinno być dostępne oszacowanie ile jednostek funkcjonalności liczy cała zaplanowana wersja. Później sprawa jest już wybitnie prosta. Otóż po wykonaniu kilku (zwykle trzech) iteracji można z dużą dozą prawdopodobieństwa powiedzieć ile jednostek funkcjonalności produkuje zespół w jednej iteracji - tzw. prędkość zespołu. Następnie należy podzielić ilość jednostek, które zostały do zrealizowania przez prędkość zespołu i otrzymujemy ile iteracji pozostało do końca. Uwaga, iteracji a nie dni czy miesięcy. W zwinnym zarządzaniu projektami iteracja jest najmniejszą niepodzielną jednostką, więc to jej będziemy używać do określania ile jeszcze pozostało do końca. Przeliczenie iteracji na konkretne daty może już być zadaniem dla kogoś spoza zespołu projektowego.

Proste? Tak, pojawia się jednak pewne "ale". Co zrobić, jeżeli z jakichś powodów koniecznie musimy mieć oszacowanie przed pierwszą iteracją i nie możemy czekać do trzeciej iteracji aby określić prędkość zespołu? Cóż - po pierwsze trzeba spróbować wytłumaczyć tej osobie, która "nie może" czekać, żeby jednak zaczekała. Argumentacja jest prosta: czy lepsze są dane rzeczywiste dostępne za trzy iteracje czy dane wysoce niepewne (a.k.a. wróżenie z fusów) dostępne dzisiaj? Jeżeli nie uda się wyperswadować to też można sobie poradzić, choć jest to utrudnione. W takim wypadku należy jedną, dwie lub trzy iteracje po prostu bardzo dokładnie zaplanować. Rozbić na zadania i razem z zespołem dokładnie zaplanować co ile czasu zajmie. Na postawie planowania podaje się przybliżoną prędkość zespołu a potem liczy się już tak jak we wcześniejszym akapicie.

Proste? Wiem, że nie do końca. Ten temat jest akurat takim tematem, który rewelacyjnie tłumaczy się przy użyciu kartki papieru i dwóch, trzech wykresów. Niestety blog takich możliwości interakcji nie daje. W przypadku, gdyby ktoś był bardzo zainteresowany zapraszam do kontaktu.

Iteracja zero

Pojęcie iteracji zero nie jest popularne w świecie zwinnego zarządzania projektami a według mnie jest to jedno z bardziej przydatnych narzędzi, które powinno być częściej wykorzystywane.

Jak wiadomo jedną z podstawowych zasad zwinnego zarządzania projektami jest to, że każda iteracja ma dostarczyć produkt o zwiększonej wartości biznesowej dla klienta, czyli ze zrealizowanymi dodatkowymi funkcjonalnościami. Każda iteracja zakończona jest pokazem dla klienta, podczas którego ma on możliwość przetestowania dostępnej nowej funkcjonalności. Iteracja zero różni się tym, że nie dostarcza żadnej wartości dodanej dla klienta. Dostarcza ona natomiast wartość dodaną dla zespołu realizującego projekt.

Iteracja zero jeżeli jest stosowana musi być pierwszą z iteracji w projekcie. Stosuje się ją, gdy zespół z jakichś względów nie może rozpocząć od razu pracy nad merytoryczną częścią projektu. Jej celem jest przygotowanie wszystkiego co jest niezbędne, aby zacząć projekt. Mogą to być takie rzeczy jak zdobycie nowej wiedzy, przygotowanie środowisk pracy, nabycie materiałów niezbędnych do rozpoczęcia prac, decyzje strategiczne dotyczące architektury przyszłego rozwiązania itp. Ze względu na swój szczególny charakter iteracja ta może mieć długość inną niż pozostałe. Ważne jest, aby iterację zero zaplanować. Należy bardzo dokładnie określić co jest jej celem i jak oceni się, że została ona zakończona. Tu postępuje się podobnie jak w każdej innej iteracji. Podobnie po iteracji przeprowadza się spotkanie kończące na którym przedstawiana jest wartość dodana, którą zespół uzyskał po zakończeniu iteracji. Uwaga, iteracja zero może być jedna i tylko jedna. To znaczy, trzeba ją zaplanować tak dokładnie aby nigdy więcej w ramach projektu zespół nie musiał zatrzymywać się - należy w tej pierwszej iteracji zero zatroszczyć się o wszystko co jest koniecznie do prowadzenia prac.

Podstawowym błędem popełnianym przy używaniu tego narzędzia jest próba użycia go w celu "przemycenia" starych nawyków z podejścia kaskadowego. Syndromem jest tutaj poświęcenie całej iteracji zero na "zaplanowanie" albo "przeanalizowanie" sposobu realizacji wymagań. To nie jest celem iteracji zero. Planowanie i analizowanie wymagań użytkownika odbywa się w ramach normalnego procesu iteracyjnego w zwinnym zarządzaniu projektem. Dla porównania iterację zero powinno się zastosować, jeżeli na przykład nikt z zespołu nie zna przepisów, w ramach których musi pracować nasz produkt. To drugie jest warunkiem koniecznym do startu prac zespołu to pierwsze jest próbą powrotu z metod iteracyjnych do kaskadowych.

Przerwanie iteracji

Kilka osób pytało się jakie jest moje zdanie na temat przerywania iteracji w projekcie zarządzanym metodami zwinnymi. Zgodnie z pierwsza zasadą konsultanta prawidłowa odpowiedź powinna brzmieć "to zależy". I tak jest w rzeczywistości. Podjęcie decyzji o przerwaniu iteracji jest wynikiem działania czynników środowiska w którym przebiega dany projekt i trudno dać tu odpowiedź zawsze prawdziwą. Tym niemniej mogę podzielić się paroma wskazówkami.

Podjęcie decyzji o przerwaniu iteracji powinno być działaniem ostatecznym podejmowanym tylko wtedy jeżeli żadna inna technika zarządcza nie przyniesie lepszych biznesowo skutków. Podejście iteracyjne jest jedną z podstawowych zasad zarządzania zwinnego i jako taka nie może być w dowolny sposób łamana. Złamanie tej zasady musi mieć mocną podstawę biznesową i za każdym razem powinno być zatwierdzane przez najwyższe władze danego projektu (sponsora lub komitet sterujący). W interesie kierownika projektu jest jednak, aby takie decyzje nie były podejmowane. Podjęcie ich i złamanie tym samym umowy zawartej na początku iteracji może bowiem bardzo szybko doprowadzić do chaosu w projekcie. Jeżeli bowiem raz zapadnie zgoda na przerwanie iteracji to później powołując się na ten precedens bardzo łatwo będzie podjąć tego typu decyzje po raz kolejny. Dlatego kierownikowi projektu dla jego własnego przyszłego spokoju powinno zależeć na dotrzymaniu umów i nie przerywaniu iteracji.

Prześledźmy w jakich przypadkach najczęściej pojawia się pokusa przerwania iteracji i jakie są opcje w tych przypadkach.

Przypadek pierwszy i najczęstszy to sytuacja, kiedy w czasie trwania iteracji nagle okazuje się, że klient już nie chce produkowanej przez nas aktualnie funkcjonalności. W takim przypadku przerwanie iteracji nie powinno nastąpić. Iteracje w projektach zwinnych są dość krótkie (maksimum 8 tygodni), więc sytuacja kiedy w czasie trwania iteracji klient nagle przekonuje się, że pewna funkcjonalność na którą sam się zgodził kilka tygodni temu nie jest mu potrzebna nie powinna się wydarzyć. Jeżeli się zaś wydarzy to, choć to trudne, umów trzeba dotrzymywać. Na początku iteracji wszystkie strony zgadzają sie co do zakresu danej iteracji i podobnie jak klient oczekuje od zespołu, że nie wycofa się z podjętego zobowiązania tak samo zespół ma prawo oczekiwać, że nie wycofa się klient. Dodatkowo przerwanie iteracji z taką motywacją spowodowałoby, że w produkcie pozostałyby pewne ślady już wykonanej a nie dokończonej pracy. To mogłoby mieć negatywny wpływ na przyszłą stabilność i jakość produktu. Dlatego prace należy dokończyć. Sporne funkcjonalności mają być wykonane z pełną jakością a w produkcie końcowym mogą być na przykład zakomentowane czy w inny sposób ukryte. Ewentualne nowe funkcjonalności trzeba zrealizować zgodnie z procesem w następnej iteracji. Przed następną iteracją należy się tylko zastanowić, czy w związku z nagłymi zmianami zakresu nie należałoby zmodyfikować (skrócić) czasu trwania iteracji. Taka decyzja musi być podjęta w gronie kierownictwa projektu i nie może być pochopna.

Inny klasyczny przypadek to sytuacja kiedy w trakcie pracy nad funkcjonalnością w ramach iteracji zespół zorientował się, że nie ma możliwości technicznego stworzenia zakładanej funkcjonalności. Przypadek dużo trudniejszy od poprzedniego. Przede wszystkim jeżeli taka sytuacja nastąpiła należy rozważyć możliwość wykonania zakładanej funkcjonalności w technicznie inny sposób niż to było planowane na początku. Drugą opcją jest modyfikacja funkcjonalności w taki sposób, aby była ona wykonalna. Obie te decyzje muszą być skonsultowane ze wszystkimi zainteresowanymi w tym przede wszystkim z klientem / właścicielem produktu. To do niego bowiem należą wszystkie decyzje produktowe w projekcie i będzie on miał ostatnie zdanie w kwestii rozwiązania takiego problemu. Jeżeli nie ma możliwości wykonania danej funkcjonalności w inny technicznie sposób ani klient nie jest chętny zmienić funkcjonalności tak aby była wykonalna to są znowu dwie opcje. Albo zakańczamy iterację i przygotowujemy nową, albo w ramach danej iteracji zespół zobowiązuje się wykonać inną funkcjonalność. Zależy to od wielu czynników (z których najważniejszym jest czas jaki pozostał do końca danej iteracji), lecz w celu zapewnienia spójności zarządzania projektem w większości znanych przypadków lepiej zastosować podejście drugie.

Jedyny znany mi przypadek kiedy bez żadnych obiekcji należy wygasić (ale nie raptownie zakończyć) iterację to sytuacja kiedy znikło uzasadnienie biznesowe dla realizowanego projektu. Projekty są realizowane po to aby organizacje osiągnęły mierzalne rezultaty. Jeżeli nie ma możliwości osiągnięcia tychże rezultatów to kontynuowanie prac nad projektem i dalsze generowanie kosztów przestaje mieć sens. Jeżeli taka sytuacja zaistnieje to projekt należy poprawnie zamknąć, czyli dokończyć rozpoczęte prace, udokumentować wykonane prace, zarchiwizować dane, stworzyć "lessons learned" z projektu itp. Pod żadnym pozorem nie może to być rzucenie wszystkiego i odejście od biurek. Sygnał do podjęcia takich działań musi wyjść od sponsora projektu i być potwierdzona przez właściciela produktu/klienta.

Podsumowując: zwinne zarządzanie projektami rządzi się relatywnie małą ilością zasad. Zasady te powinny być jednak rygorystycznie przestrzegane, bo bardzo łatwo jest znaleźć się po drugiej stronie cienkiej linii, gdzie już rządzi czysty chaos. Iteracyjność jest jedną z tych podstawowych zasad i nie wolno jej łamać bez posiadania twardych, biznesowych dowodów na słuszność takiej decyzji.