Agile vs Waterfall – jak przekonać zarząd i klienta

W pierwszej odsłonie mojego bloga chciałbym dotknąć jednego z bardziej istotnych i nurtujących wszystkich tematów, czyli jak przekonać zarząd lub klienta do podejścia Agile. Inspiracją do tego artykułu jest argumentacja, której sam użyłem wobec zarządu oraz interesująca dyskusja, jaką miałem podczas konferencji Agile Update.

Zacznijmy od tego, że podczas rozmowy z zarządem użyłem porównania z branży budowlanej (tak, wiem – software development jest trudno porównywalny z tradycyjnymi metodami). Wyobraźmy sobie, że stosując klasyczne podejście Waterfall projektujemy 10-cio piętrowy budynek i planujemy wszystko, co w nim powinno się znaleźć. I zaczynamy go budować. Wtedy uczestnik rozmowy na konferencji Agile Update wtrącił: „No właśnie, a w Agile uzyskamy tylko 4 piętra tego budynku”.

Trudno się z tym nie zgodzić  – oczywiście przy założeniu, że projekt ma ograniczony budżet (nie wiem czemu w realnym świecie zawsze tak jest). Różnica polega na tym, że 4-piętrowy budynek Agile będzie w pełni wykończony wraz z instalacjami, oknami, dachem i gotowy do użytku. I znacznie lepiej dostosowany do potrzeb użytkowników. W 10-cio piętrowym budynku Waterfall uzyskamy szkielet 10-ciu pięter bez okien, drzwi i instalacji. I mamy problem.

Podejście Agile
Podejście Waterfall

CC BY-NC-ND 2.0

To chyba oczywiste jeśli weźmie się  pod uwagę fakt, że dostępność zasobów i budżet nie uległy zmianie. Warto jednak przyjrzeć się bliżej konsekwencjom podejścia Waterfall:

  • w Waterfall przed końcem projektu powszechnie znaną, aczkolwiek skrzętnie ukrywaną prawdą stanie się fakt, że nie damy rady. Zacznie się nerwowość i presja na development aby przyśpieszać nawet kosztem jakości
  • wątpliwą zaletą jest to, iż zetrzemy się z klientem/zarządem prawdopodobnie tylko raz i efektem wielkiej awantury będzie znaczące przesunięcie terminu lub zerwanie kontraktu
  • zwykle (znów ta brutalna rzeczywistość) przesunięcie nie będzie aż tak znaczące aby wszystko skończyć w dobrej jakości – od tego momentu mamy już projekt „pod kreską” i nerwowe próby załatania wszystkiego najtańszym kosztem bez zwracania uwagi na jakość

Na koniec warto chyba rozważyć również 2 inne scenariusze:

  • co jeśli budżet pozwalałby wykonać cały budynek w Waterfall (czemu tak nigdy nie jest w rzeczywistości)? W Agile skończylibyśmy go przed planem i znacznie lepiej dopasowany do potrzeb użytkowników – choć niestety tu już porównania z budownictwem zawodzą. Może dobrą analogią byłoby ile czasu spędzimy na przeróbkach budynku Waterfall do potrzeb użytkowników, którzy zobaczą go po raz pierwszy po oddaniu do użytku. I również sporym ryzykiem, że produkt finalny nie spełni ich oczekiwań
  • co jeśli budżet się zmniejszy w trakcie projektu? Zmienią się wymagania, skróci się termin itp. Tu zalet Agile chyba nie trzeba podkreślać. Również klient będzie zadowolony jeśli już po kilku sprintach okaże się, że zmierzamy w złym kierunku i będzie mógł całkowicie zmienić wymagania/zakres prac

Podsumowując, nawet pomijając wszystkie inne aspekty Agile/Waterfall (a można by o nich jeszcze długo się rozwodzić) łatwo zauważyć na tym prostym przykładzie, że Waterfall dobrze nie rokuje. Nawet jeśli materia jest dobrze znana, to ryzyko przeszacowania własnych możliwości jest bardzo duże. Czyli, wracając do pytania jak przekonać:

  • w ramach Agile jesteśmy w stanie uzyskać najlepszy produkt w obrębie zadanego budżetu
  • produkt ten będzie gotowy do użytkowania na każdym etapie rozwoju, nawet jeśli nie będzie w pełni funkcjonalny
  • nie istnieje ryzyko pozostania z nienadającym się do niczego szkieletem produktu
  • jakość zawsze będzie na lepszym poziomie (może poza scenariuszem, że Waterfall mieści się w budżecie i nie wymaga zmian – czy ktoś widział kiedyś taki projekt?)
  • unikniemy nerwowości, presji i związanych z tym konsekwencji

Na koniec chciałbym polecić artykuł z Agile247 uzupełniający zagadnienie w zakresie iteracyjnie czy przyrostowo:

http://www.agile247.pl/podejscie-iteracyjne-oraz-przyrostowe-agilestarte

Jeden komentarz do “Agile vs Waterfall – jak przekonać zarząd i klienta

  1. Marcin Góźdź

    Ja mógłbym dodać, że w ramach Agile oprócz w pełni funkcjonalnego budynku moglibyśmy jeszcze uzyskać kilka garaży dla właścicieli lokali 🙂 – stwierdzenie to zostało wyartykułowane przez klienta podczas prezentacji procesu Scrum. U niektórych można jednak zauważyć zrozumienie.

    Odpowiedz

Skomentuj Marcin Góźdź Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.