Dlaczego nie powinniśmy zapominać o metodologii Waterfall?

mfirlejtolszewskiIlu z was pracuje w projektach prowadzonych w Agile? A ilu z was potrafi o sobie powiedzieć, że są Agile? I uwaga, agile niekoniecznie oznacza, że musicie godzic sie na wszystko i minute przed terminem zmieniac pół aplikacji 😉

Agile ma lepszy PR niż Waterfall – jest bardziej „cool”, ale to nie znaczy że jest lepszy.

W koncu trzeba teraz wymyślić coś nowego, sprzedać dużo książek, no bo tak naprawde czy jednocześnie jesteśmy testerami manualnymi, automatycznymi, developerami, scrum masterami, asystentkami, project managerami ? Większość z Nas mówi, że pracuje w Agile. A kiedy tak naprawde testujecie? Pierwszego dnia sprintu czy tak naprawdę ostatniego? Kiedy rozpoczynacie cały proces testowania? Na etapie planowania czy, gdy cała dokumentacja jest gotowa?

Praca w Agile wymaga zaangażowania klienta. Klienta, który w pełni poświeci się w dany projekt. Nie bedzie oczekiwał konkretnej estymacji do nie do końca sprecyzowanych wymagań.

Jest cała masa projektów, które zwyczajnie muszą być prowadzone w “stary” sposób. I tutaj zwykle wracamy do waterfalla. No bo kto wsiadłby od samolotu którego hamulce rozwijane byłyby w metodologiach zwinnych – w ostatnim sprintcie dodamy user story “As a owner of this Boeing 747  I want it to break before end of the airstip so that nobody from passengers die” ? a może: “As a NASA we want this mars rover to land so we don’t waste milions of dolars” ?

Chcemy Wam dziś pokazać, że zamiast na siłę wdrażać w projektach zwinne podejście, może lepiej skupić się na eliminacji strat, stałej poprawie i na przykład zastosować LEAN software development.

Zacznijmy od początku –  od tego czym jest metodologia zarządzania projektami zwana Waterfall. To sekwencyjna metodologia wytwarzania oprogramowania, gdzie poszczególne procesy przebiegają etapami:

waterfall

Ze względu na powtarzalność możliwa jest pełna przewidywalność wszystkiego co będzie działo się w trakcie prowadzenia projektu. Klient, a może raczej wykonawca oprogramowania musi mieć jasną wizję tego co ma powstać. Umożliwia to stworzenie dokładnego planu, harmonogramu dostarczania, a co za tym idzie określenia konkretnej daty zakończenia. Dzięki temu łatwy do oszacowania jest koszt projektu.

Czy to umożliwia stworzenie czytelnego planu działania? Napewno…

Wracając do sedna:

Które projekty powinny być zarzadzane w metodologii Waterfall szybciej niż w metodologiach Agile? Na przykład:

  • Safety Critical Systems – W firmach, których produkty określamy jako safety critical są na przykład z branży: bankowej, automotive, healthcare. Właśnie w nich cały proces wytwarzania oprogramowania musi być pod stałą kontrolą. W takich projektach każdy komponent musi byc w pełni audytowalny, a wszystkie elementy specyfikacji powinny mieć pokrycie w testach. W firmach, w których każdy najmniejszy błąd może mieć potworne konsekwencje dla użytkownika końcowego i samej firmy jak np. utratę życia przez klienta. W firmach tych niedopuszczalne jest oprogramowanie niskiej jakości. A każde wdrożenie obarczone jest ogromnym ryzykiem.

Duże, rozbudowane i skomplikowane projekty – Nie mówimy, że nie można łączyć metodologii. Sugerujemy, że przy dużych projektach możliwe jest zastosowanie metodologii Agile do testów poszczególnych komponentów, testów integracyjnych czy unit testów. Jednak cały projekt lub program wymaga natomiast dużo bardziej ustrukturyzowanej pracy. Dobrym przykładem będzie tutaj projekt integracyjny, w którym pracuję. Niby pracujemy w Agile, ale dostawca oprogramowania, do którego mamy się integrować pracuje w waterfall z dostawami raz w miesiącu. Wraz z nową wersją oprogramowania dostarczane są także poprawione defekty. Sam klient wymaga bardzo określonego procesu testowania z tworzeniem dokumentacji testowej i zarządzaniem konkretnymi, z góry zadanymi zdaniami. Przez sam proces Agile zamienia się w Waterfall.

Warto pamiętać o dobrych i złych stronach Waterfalla:

Wady:

  • późno widoczne efekty dla klienta
  • wprowadzenie zmian jest kłopotliwe

Zalety:

  • pełna kontrola
  • znany:
    • budżet
    • zakres projektu
    • harmonogram
  • bez problemu przejdzie audyt

Chcielibyśmy zaproponować branie togo co najlepsze z rożnych metodyk i nie staranie się być na siłę Agile. Nie zawsze podążanie za modą jest najlepszym wyjściem. W swoim zespole wprowadziliśmy pewne elementy Agile jak: daily meetingi by szybciej i lepiej się komunikować, retrospektywę po wdrożeniach, ograniczoną liczbę zadań rozpoczynanych przez poszczególnych QA – czy to spowodowało że projekt jest agile – nie, ale zdecydowanie poprawiło jakość naszej pracy.

 


Tagged under:
TwitterFacebookLinkedInGoogle+