6931258554

- 15 -

kilkumiesięcznym projektem dla Uniwersytetu w Ohio jako jedną z przyczyn dynamicznego zaistnienia potrzeby migracji na metodykę Agile w trakcie trwania projektu podaje rozrośnięcie się etapu analizy ponad zakładany w harmonogramie czas, co już na początku procesu wytwarzania poddało pod wątpliwość szansę na zakończenie projektu sukcesem w krótkim terminie, który narzucony został przez harmonogram. Narastającą frustrację w zespole TSO powodowało wiele czynników będących przyczynami opóźnień. Niektórzy członkowie zespołu pozostawieni sami sobie oraz metodyce nie czuli się upoważnieni do podejmowania ważnych decyzji. Inni, którzy nie mieli doświadczenia w pracy przy procesie wytwarzania oprogramowania założyli z góry, że zespół deweloperów po prostu poradzi sobie z wymaganiami i zaimplementuje je w całości za pierwszym podejściem. Jednak zmaterializowało się jedno z podstawowych ryzyk w takich przypadkach i w jednym z etapów kluczowy programista opuścił uniwersytet, który był miejscem prowadzenia prac. Zespołowi zabrakło elastyczności i nawiązania bliskiej współpracy z klientami systemu, jakimi byli wykładowcy uniwersytetu i to oni mogli podejmować decyzje i wspierać zespół w trwających pracach. Sama metodyka Waterfall nie zawiera praktyk wspierających dynamikę komunikacji między udziałowcami.

Innymi często podawanymi w literaturze uwagami krytycznymi metodyki kaskadowej są:

-    sztywna struktura „schodków”, która może być niedopasowana do wysokiej złożoności modelowanej rzeczywistości

-    brak pełnej i realnej możliwości przewidzenia trudności implementacyjnych w danej technologii przez projektantów na etapie projektowania (założenie: „zaprogramują!”)

-    niemożność lub zbyt duży koszt powrotu z fazy „następnej” do „poprzedniej” w przypadku zmiany wymagań klienta po zakończeniu jednego z etapów

-    wzrastający koszt zmian i modyfikacji wraz z wkraczaniem w kolejną fazę projektu cyklu kaskadowego

Czy zatem istnieje uniwersalna metoda, która pozwoliłaby zwiększyć zaufanie do metodyki waterfall? Praktyka pokazuje, że tak. Okazuje się bowiem, że cykl kaskadowy, z odpowiednio dobranym wzbogaceniem elementami metodyki Serum, na gruncie komunikacji z klientem może być szkieletem organizacyjnym dla wykonania nawet dużych, odpowiedzialnych przedsięwzięć. Jednym z powodów jest fakt, że przy odpowiednio intensywnej i skutecznej kontroli produktów każdego etapu oraz przy założeniu adekwatnego, kilkuprocentowego budżetu na zmiany, można wynegocjować i przeprowadzić duży projekt w metodyce kaskadowej, choćby ze względu na niezwykle wysoką zdolność tej metodyki do zapewnienia widzialności projektu u klienta. Jest ona w wysokim stopniu intuicyjna i „pozwala osobom na wielu szczeblach organizacji przybliżyć założenia organizacyjne niezrozumiałych prac informatyków”. Spowodowane jest to między innymi prostą strukturą metodyki waterfall, którą z powodzeniem można zaprezentować w sposób zrozumiały i, co ważne, przekonujący o potencjalnie wysokim stopniu możliwej kontroli przez klienta. Serum zakłada częsty bezpośredni kontakt między udziałowcami projektu. Praktykę tę wystarczy wdrożyć na wszystkich szczeblach komunikacji zapewniając ją choćby narzędziem Trać, a nawet prostym web-forum, dzięki czemu każdy kluczowy udziałowiec systemu pozostaje in-touch z aktualnymi i przewidywanymi problemami. Prowadząc projekt oficjalnie w metodyce waterfall nie należy zapominać o podstawowych założeniach manifestu Agile, mieć je na uwadze i wprowadzać w klimat prac zespołu jako osoba wspierająca odpowiednią metodykę prowadzenia projektu:

1. Individuals and interactions over processes and tools Ludzie i współpraca ponad procesami i narzędziami.

Maciej Pardo www.eti.pg.gda.pl ind 102141 „Aplikacja do jednoczesnego zarządzania wieloma projektami informatycznymi”