Agile, ale… 

Najpopularniejszą obecnie metodyką do prowadzenia projektów jest „Agile, ale…”. Zazwyczaj jest to „Agile, ale bez klienta” lub „Agile, ale bez retrospekcji”. Często też słyszy się o projektach prowadzonych częściowe zgodnie z Agile, a częściowo wykorzystujących Waterfall. Prawie w ogóle nie słychać o projektach w czystym Agile lub w czystym Waterfall. Osobiście uczestniczyłem w projektach opartych na obu podejściach. Zdecydowanie więcej miałem do czynienia z Agile, wykorzystującymi Scruma - w sumie 3 projekty. Poza tym miałem okazje dość długo, bo 2,5 roku, pracować w projekcie opartym na podejściu Waterfall.

Eksperyment dwóch podejść

Nie jestem zwolennikiem mieszania metodyk. Z prostego powodu: jeśli jakieś rozwiązanie zostało opracowane w taki, a nie inny sposób, to jest to zapewne czymś uzasadnione. Scrum czy PRINCE2 nie powstały nagle i są efektem pracy grupy ludzi popartej wieloletnim doświadczeniem w prowadzeniu projektów. Rozbicie kompletnych, dobrze przemyślanych podejść i mieszanie dwóch różnych „ideologii” jest dużym eksperymentem, który zawsze będzie mniej efektywny i bardziej ryzykowny. Według mnie często modyfikacja lub mieszanie metodologii wynika z niedostatecznego zrozumienia zasad jej działania. Dobrym tego przykładem jest np. rezygnacja z retrospekcji w Scrumie. Jak chcemy usprawniać i doskonalić proces z pominięciem spotkania, które do tego właśnie służy?

Agile na miarę IT

Idea elastyczności i dopasowywania się do zmian pasuje do branży IT jak do żadnej innej. Jest jak uszyta na miarę. Wszyscy chcą być „Agile”, to po prostu stało się modne. Przez lata brakowało metodyki, która pozwalałaby klientowi i zespołowi dyskutować nad spodziewanym rezultatem na poszczególnych etapach pracy.

Agile dostarcza działający produkt w sposób ciągły i dużo silniej angażuje klienta w projekt. Niezaprzeczalną zaletą jest cyklicznie ustalany zakres prac, a tym samym dynamiczne dostosowanie do zmian, które wynikają w trakcie procesu wytwórczego. Bardzo szybko można zareagować na takie zmiany i wprowadzić je, co pozwala 'zadowolić' klienta. Wady Agile upatruję natomiast w niepoprawnym zastosowaniu samej metodyki poprzez niepełne zrozumienie, bądź co gorsza, wybieranie tylko niektórych elementów Agile (w tym przypadku Scruma) do prowadzenia projektu.

Agile pasuje bardziej do nowych projektów, w których na starcie nie ma jasnego obrazu, jak ma wyglądać finalny produkt. To dobra metodyka, w sytuacji gdy wymagania nie są do końca znane, bądź też ciągle ewoluują.

Waterfall też dobry

Są takie projekty, w których bezdyskusyjnie lepiej sprawdzi się Waterfall. Model kaskadowy, czyli właśnie Waterfall, to dobre rozwiązanie gdy zakres prac i wymagania są stabilne oraz znane na starcie projektu. Ważnym elementem jest również planowana do zastosowania w projekcie technologia. Jeśli planujemy wykorzystać sprawdzoną, znaną nam i stabilną technologię, jest to dodatkowy argument za wykorzystaniem właśnie Waterfall.

Główna zaleta tej metodyki to zmniejszone ryzyko niepowodzenia w przypadku ograniczeń w umowie. Mam tu na myśli ograniczenia kontraktowe (np. czas wykonania, budżet), szczególnie istotne w przypadku realizowania projektów dla sektora publicznego. Wśród wad dostrzegam dostarczanie działającego produktu dopiero na końcu procesu wytwórczego. Według mnie, tak istotna wada może spowodować, że efekt końcowy potrafi odbiegać od tego co zamawiał klient.

Jak wybrać?

Bardzo istotnym etapem dla projektu jest wybór metodyki. Zastanów się więc, jaki jest Twój klient. Jaki będzie projekt? Czy spodziewasz się zmiennego środowiska, czy stabilnej pracy? Czy zespół i Ty znacie technologie i czy macie doświadczenie w podobnych realizacjach? Czy kontrakt pozwala na zmianę wymagań? Niezależnie czy mówimy o Agile czy Waterfall, żaden projekt nie zakończy się sukcesem, jeśli nie będzie odpowiedniego zaangażowania zainteresowanych stron w projekt.

Odradzam mieszanie podejść, ale polecam uczestniczenie w dyskusjach nad nowymi metodykami. Powstanie kompletnie nowej metodyki, która popularnością dorówna Agile i Waterfall jest bardzo możliwe, a wręcz pewne. Branża IT zmienia się bardzo szybko, a tym samym zmieniają się metodyki wytwarzania oprogramowania. Podobnie jak to było z Agile, jeśli dotychczasowe metodyki nie sprawdzą się lub powstanie nisza, będziemy świadkami opracowania nowego podejścia do zarządzania projektami.

Przemysław Pierzchała, Senior Software Developer, Robert Bosch Sp. z o.o.

Źródło