Harmonogramowanie iteracyjnych projektów rozwojowych

Charles Schwartz, PMP

Rozwój iteracyjny stał się podstawą bardzo wielu projektów informatycznych. Bardzo długo pozostawałem orędownikiem filozofii rozwoju iteracyjnego i przeznaczyłem wiele czasu oraz sił lansując przez ponad 10 lat rozwiązania oparte na modelu iteracyjnym zarówno w nauczaniu, jak i w praktyce. Pamiętam wiele długich wieczorów przeznaczonych na rozmyślania o rozwiązaniach praktycznych, jeszcze nawet w latach osiemdziesiątych, kiedy większość tego, co dziś określamy mianem iteracyjnego lub zwinnego" nazywano rozwojem spiralnym. Jednakże ostatnio wygląda na to, że w wielu sytuacjach następuje gwałtowny zwrot ku iteracyjnym metodom harmonogramowania rozwoju.

Na czym polega rozwój iteracyjny?

Rozwój iteracyjny można w największym skrócie określić jako a proces rozwojowy, który przebiega stopniowo obejmując kolejne fragmenty czy iteracje aż do czasu, gdy gotowy jest produkt końcowy. Iteracje te obejmują ocenę wymagań, szczegółowe projektowanie, opracowanie i sprawdzenie danego elementu końcowego produktu. Za każdym razem działania te dotyczą tylko danej iteracji.

Istnieje niezliczona ilość odmian tego modelu. Różnice polegają między innymi na rożnych metodach nadawania priorytetów, planowania codziennych spotkań, przekazywania kolejnych wersji klientowi na koniec każdej iteracji i innych kwestii. Podstawowe elementy modelu pozostają jednak takie same.

O co chodzi?

Niedawno zacząłem obserwować kilka wdrożeń procesów iteracyjnych, w których jasne jest, że planowanie jest trudniejsze, a w związku z tym podejmuje się decyzję o rezygnacji z jakiegokolwiek planowania! Docierają do mnie tak dobrze znane stwierdzenia jak:

• Gdyby tylko kierownictwo się nie wtrącało wszystko byłoby jak trzeba.
• Dajcie nam spokój jak skończymy, wtedy was powiadomimy.
• Nie trzeba nam żadnego parszywego planu, ponieważ prowadzimy rozwój iteracyjny.
• Gdybyśmy stworzyli plan, wtedy musielibyśmy zastosować model kaskadowy.

Niektórzy z rzeczników tych metod prawdopodobnie sami się przyczynili do niektórych tych konfliktów i w związku z tym są naszymi najgorszymi wrogami. Na przykład niektórzy głosiciele ścieżki iteracyjnego oświecenia sugerują, że powinno się przedkładać reagowanie na zmiany nad przestrzeganiem planu, zupełnie jakby istniał jakiś powód zmuszający nas do wyboru tylko jednej z tych dwóch dróg. (A tak przy okazji: skoro nie przestrzegalibyśmy planu, to na jakiej podstawie stwierdzalibyśmy, że dane żądanie faktycznie stanowi zmianę? Ale wróćmy do tematu) Jednocześnie ci sami ludzie powiadają jednak, że z posiadaniem planu wiąże się jakaś wartość. Zależy im tylko na bardziej elastycznym sposobie radzenia sobie z ograniczeniami pozornie narzuconymi jako zmiany wymagań.

Do wdrażających te strategie zdaje się jednak docierać tylko pierwsza część tego komunikatu, w związku z czym stwierdzają oni, że zmiana:

1. To zawsze coś dobrego
2. Powinna być promowana za wszelką cenę

Pozostawienie zmian samych sobie stało się przyczyną niepowodzeń w wielu projektach. W skrajnych sytuacjach całkowicie pozbawiało nas stwierdzenia, czy projekt jest (lub w dalszym ciągu jest) wart realizacji. Znaczenie planów (wraz z płynącymi z nich wnioskami dotyczącymi kosztów i harmonogramu) polega na tym, że stanowią one mapę drogową, na podstawie której podejmujemy kluczowe decyzje dotyczące spożytkowania naszych deficytowych zasobów. Jeśli przewidywana wartość projektu miałaby wynieść milion dolarów, a prognozowane koszty związane z jego realizacją dwa miliony, wówczas trudno postrzegać jego produkt jako coś, co może przeobrazić firmę, nawet jeśli początkowo tak uważaliśmy. Bez planu i choćby podstawowych oszacowań to, co robimy przypominać będzie zabawę w chowanego, w środku pochmurnej nocy, w jaskini zasypywanej przez lawinę.

U podstaw wszystkich tych problemów związanych z planowaniem wydaje się leżeć nasza wrodzona obawa przed stworzeniem planu, który okaże się w taki, czy inny sposób nietrafiony (na przykład niedoszacowany, zarówno jeśli chodzi o czas jak i koszty). Spieszę jednak rozwiać te obawy, bowiem taki sposób myślenia jest błędny. Czyż to nie krzepiące, że podstawowym celem planowania nie jest przeprowadzenie obliczeń z dokładnością do centa, dolara, czy nawet tysiąca dolarów. Podobnie harmonogramowanie nie ma na celu wyznaczenie terminów realizacji z dokładnością, co do minuty. Nie jestem na przykład w stanie powiedzieć dokładnie ile minut poświecę jeszcze na pisanie tego artykułu (choć mój wydawca prawdopodobnie ma bardzo precyzyjne oczekiwania dotyczące terminu, w jakim powinien on być gotowy!).

Przezwyciężanie przeszkód

Jak sobie zatem poradzić z tym pozornym paradoksem?

Po pierwsze, trzeba zadbać o określenie jasnych planów bazowych zakresu, czasu i kosztów, a następnie konsekwentnie wdrożyć uzgodniony proces zarządzania zmianami.

Po drugie, przeprowadzamy proces harmonogramowania na dwóch poziomach szczegółowości. Tworzymy długoterminowy, podstawowy plan projektu (kompletny, ale niezbyt szczegółowy harmonogram oraz szacunki kosztów), a także ustalamy krótkoterminowe plany iteracji (dla każdej iteracji), stopniowo doprecyzowując je na podstawie harmonogramu podstawowego. Ów harmonogram iteracji obejmuje bardziej szczegółowy plan wraz z konkretną alokacją zasobów do wszystkich zadań ujętych w harmonogramie. Plany krótkoterminowe opracowujemy dla jednej, dwóch iteracji wprzód względem aktualnie wykonywanych prac w projekcie. Harmonogram podstawowy pomaga nam zrozumieć projekt jako całość. Na jego podstawie również wyższe kierownictwo podejmuje kluczowe decyzje dotyczące przyszłości projektu. Natomiast plan iteracji pozwala kierownikowi projektu prowadzić regularne (codzienne lub cotygodniowe) monitorowanie wykonania projektu.

Po trzecie, przeznaczamy więcej energii na odpowiednie techniki szacowania. Szacunki z sufitu nie wydają się wystarczająco dobrym punktem wyjścia, a mimo to pozostają tak często używaną techniką. Tymczasem powinno się zatrudniać specjalistów w danych dziedzinach, którzy zajmowali się w przeszłości podobnymi projektami, konsultować z ludźmi, którzy będą wykonywali poszczególne prace oraz sięgać do własnej historii, aby lepiej i bardziej szczegółowo rozumieć pracę, którą trzeba wykonać oraz związane z nią koszty.

Wreszcie, możemy ustalać rezerwę dodatkowy czas, środki finansowe oraz sprzęt i inne zasoby, z których skorzystamy w sytuacji, gdy trzeba będzie sobie poradzić z problemami wynikającymi z ryzyk nieodłącznie związanych z projektem lub z niedokładności szacunków. Rezerwę można alokować na podstawie poziomu ryzyka dotyczącego projektu. W bardziej ryzykownych projektach poziom rezerw powinien być wyższy. Wiem na przykład, na kiedy powinienem skończyć ten artykuł i na podstawie wcześniejszych doświadczeń zdaję sobie mniej więcej sprawę jak dużo czasu zajmie mi jego napisanie. Dlatego zaplanuję rozpoczęcie tego zadania z odpowiednim wyprzedzeniem względem terminu ukończenia, co pozwoli mi przezwyciężyć wszelkie nieoczekiwane problemy, jakie pojawią się na mojej drodze do zostania literacką gwiazdą.

Działania te mogą pomóc w skutecznej realizacji projektu według modelu iteracyjnego, pozwalając uniknąć przynajmniej pewnych pułapek, których skutki przypominałyby walkę z nocnym huraganem, na środku morza w małej szalupie bez wioseł.

Chip Schwartz jest założycielem i dyrektorem Coresoft, LLC. Chip posiada certyfikat Project Management Professional i dostarcza usługi szkoleniowe oraz konsultingowe w zakresie zarządzania projektami, inżynierii procesów oraz architektury systemów.

ESI International, Inc., 2005. All rights reserved.