fbpx

Zwinnie czy klasycznie – Agile vs Waterfall

agile vs waterfall

Zwinnie czy klasycznie – Agile vs Waterfall

Na samym początku chciałabym zaznaczyć, że nie jestem zawodowym project managerem. Posiadam certyfikat Agile PM więc jakąś wiedzą posiadam jednak wszelkie moje teksty związane z zarządzeniem projektem są oparte na doświadczeniu z perspektywy programistki oraz team lidera. W trakcie mojej pracy jako team lider bardzo często jeździłam do klienta, rozmawiałam z nim, ustalałam zakres prac czy priorytety. Zbierałam baty za błędy i pochwały za rezultaty.

Jednak podkreślę jeszcze raz, nigdy nie pracowałam na stanowisku project managera więc mogę się mylić lub czegoś nie wiedzieć. Jeśli Ty jako project manager znasz rozwiązanie na bolączki, o których będę pisać to pisz śmiało w komentarzu. Bardzo chętnie się dowiem czegoś nowego.

Wracając do głównego tematu dzisiejszego postu, chciałabym przybliżyć Ci podstawy dwóch metodyk wdrażania projektów – Agile vs Waterfall.

Waterfall czyli klasycznie

Waterfall cechuje się tym, że na starcie określamy co jest do zrobienia i jak ma to działać po zakończeniu. Wszystko spisujemy w obszernej dokumentacji, która staje się naszą wyrocznią podczas całego trwania projektu. Jak zostało zapisane w dokumentacji to jest święte i tak robimy. Czasami dochodzi wręcz do paranoi, kiedy coś jest wdrażane, bo tak zostało zapisane w dokumentacji, mimo że wiemy, że to nie ma sensu. Pewnie z takich sytuacji wynika ogólny sceptycyzm do tej metodologii.

Programiści wbrew pozorom lubią takie podejście, szczególnie Ci introwertyczni, ponieważ dokładnie wiedzą co mają zrobić. Na starcie mogą wyobrazić sobie cały projekt i teoretycznie nie mają nad głową PM’a, który co chwile chce czegoś innego i zmienia priorytety. Jednak z perspektywy klienta efekty otrzyma bardzo późno. Można to porównać do produkcji samochodów. Konfiguruje sobie konkretny model, który chce otrzymać, dostaje specyfikację oraz informację, kiedy będzie do odbioru i zgłaszam się za kilka miesięcy po gotowy samochód. Jednak jest ryzyko, że ten samochód, którym zamówiłam kilka miesięcy temu nie do końca zgadza się z moimi wyobrażeniami i obecnymi potrzebami.

O dziwo znam klientów, którzy bardzo chętnie właśnie w taki sposób zamawialiby oprogramowanie. Najczęściej są to firmy produkcyjne, które mają w swoich głowach zaszyty schemat działania fabryk i wydaje im się, że produkcja wszystkiego, nawet oprogramowania tak właśnie wygląda.  

Jak już pewnie zauważyłeś długi czas realizacji projektu nie jest tutaj sprzymierzeńcem. Stąd przyjęło się i jest poparte doświadczeniem, że Waterfall nie sprawdza się w długoterminowych i skomplikowanych projektach. Dlatego pewnie coraz mniej firm wybiera go do wdrożeń. Z resztą ostatnimi czasy nie słyszałam, żeby ktoś się chwalił, że wdrożył projekt w tej metodyce. W środowisku IT zostałoby to prawdopodobnie odebrane wręcz negatywnie, a na pewno nie na korzyść osoby chwalącej się tym.

Ostatni aspekt to testy. Zgodnie ze sztuką powinny rozpocząć się po zakończeniu wszystkich prac deweloperskich. Jednak doskonale wiemy, że tak się nie da. Można tak to zrobić, ale nikomu się to nie opłaca. Ani firmie, ani klientowi, a nawet deweloperom.  

  • Dobra dokumentacja.
  • Fajniejsze dla programistów, bo nie ma częstych zmian.
  • Gorsze dla klienta, bo jeśli projekt jest długi to na efekt musi bardzo długo czekać.
  • Po realizacji efekt niekoniecznie będzie spełniał jego potrzeby biznesowe a jedynie jego wyobrażenie o tych potrzebach, które miał na starcie.
  • Lepsze dla małych i krótkoterminowych projektów.
  • Wszelkie zmiany są droższe, trwają dłużej, bo zostały późno zdefiniowane i zlecone.
  • Teoretycznie proces testowania zaczyna się po zakończonej pracy deweloperskiej.

Agile czyli zwinnie

Co oznacza, że Agile jest metodyką zwinną? Zgodnie ze słownikiem, ktoś kto jest zwinny wykonuje zręczne i szybkie ruchy. W sumie jest to całkiem trafne określenie dla tej metodyki. Chodzi o to, że w metodykach zwinnych zmiana jest jedyną stałą.  Musimy sprawnie manewrować zadaniami, planujemy niedługie odcinki do przodu, sprawnie reagujemy na zmiany poprzez zmianę priorytetów i teoretycznie dzięki temu szybciej dowozimy rezultaty spełniające potrzeby biznesu.

Brzmi pięknie, wręcz idealnie. Jednak czy na pewno ta metodyka jest taka cudowna? Moim zdaniem nie do końca. Może gdyby rzeczywiście stosować się dokładnie do wszystkich jej założeń, działać zgodnie z wytycznymi, regularnie organizować i z zaangażowaniem uczestniczyć we wszystkich spotkaniach, skompletować zespół, jak to się pięknie nazywa samo organizujący się i cross funkcjonalny to działałoby to perfekcyjnie. Jednak pamiętajmy, że nie żyjemy w utopii.   

Nie da się mówić o metodyce Agile bez poruszenia tematu Scruma. Żeby dobrze to rozumieć, Agile to metodyka – filozofia podejścia do zarządzania projektem, a Scrum to szablon procesu, który pozwoli nam tą metodykę wdrożyć w swoim projekcie.

Myślę, że zgodzisz się ze mną, jeśli kiedykolwiek pracowałeś w scrumie, że Agile nie nadaje się do małych projektów. Byłby to zdecydowany przerost formy nad treścią. Chociażby z tego powodu, że Scrum wyróżnia kilka typów spotkań, które powinny odbywać się regularnie. Do tego zadania, które mają zostać zrealizowane opisywane są przez zespół zanim zaczną nad nimi pracować co sprowadza się do tego, że praktycznie 1/3 czasu sprintu jest spędzana na spotkaniach, w których uczestniczy cały zespół. Pomyślcie sobie, ile to jest pieniędzy przepalonych na gadaniu. W małych projektach się to po prostu nie opłaca.

Może i czasu na gadanie jest dużo jednak nie chcę żebyś pomyślał, że jestem przeciwnikiem Scruma, wręcz przeciwnie. Uważam, że sprawnie prowadzone daily, retro czy planning mają ogromną wartość dla projektu i często przyniosą większy zysk niż ten sam czas spędzony na programowaniu. Jednak pamiętajmy o skali.

Bardzo ważny jest również scrum master, który musi ogarniać swój zespół i pilnować dyscypliny na spotkaniach. Już pisałam o tym w poście o daily. Spotkania będą produktywne, ale musi je ktoś moderować i pilnować calu przez cały czas ich trwania.

To co bardzo podoba mi się w zwinnych metodykach to to, że zespół pracuje blisko z klientem. Wiem, może to brzmieć dziwnie z ust programistki. Jak to mówią niektórzy moi koledzy – nie zostałem programistą, żeby pracować z ludźmi. Jednak kontakt z klientem to coś co uważam za ważne podczas wytwarzania oprogramowania. Przede wszystkim dlatego, że oprogramowanie jest dla ludzi, a nie ludzie dla oprogramowania, więc to właśnie oprogramowanie powinno spełniać w jak największym stopniu potrzeby biznesowe klienta, a bez klienta nie znamy tych potrzeb. Po drugie dlatego, że zespół, który ma świadomość i czasami okazje spojrzeć w oczy człowiekowi, który im płaci za to co robią, jest dla nich mobilizujące i sprowadza na ziemię co poniektórych filozofów.

Wszystkie firmy szczycą się, że pracują zgodnie ze Scrumem i przeprowadzają wdrożenia w zwinnych metodykach. Jednak nie udało mi się jeszcze znaleźć osoby pracującej w IT, która by mnie zapewniła, że w 100% działają w scrumie. Oczywiście, wszyscy próbują pracować zgodnie z Agilem, fajne jest w nim to, że nie jest sztywny i można go dostosować do swoich procesów i kontekstu. Jednak błagam, nikt mi nie wciśnie, że pracuje zwinnie, kiedy na starcie projektu znamy jego deadline i upychamy zakres tak by się zmieścił w tym czasie.

Strictly speaking, they don’t focus on strict long-term deadlines but focus on short-term pace, and 1-3 weeks deadlines. Since Agile is flexible and adaptable, long-term deadlines don’t fit into an Agile framework. But that doesn’t mean that Agile processes are without timelines completely. Instead, Agile requires teams to conceive of finishing projects with a higher focus on market feedback and customer’s real needs.

  • Planowanie krótkoterminowe z celem długoterminowym.
  • Szybkie reagowanie na zmiany.
  • Zespoły są bardzo mocno zmotywowane i samoorganizujące się a co za tym idzie bardziej zaangażowane.
  • Zmiany są tańsze, ponieważ są wyłapywane na bardzo wczesnym etapie.
  • Nieopłacalne dla małych projektów
  • Potrzebna mocna osoba moderująca spotkania.
  • Opiera się na sporej liczbie spotkań, w której bierze udział cały zespół.
  • Klient jest zaangażowany w proces, szybciej dostaje pierwsze rezultaty, jednak do końca nie wie, kiedy otrzyma cały produkt.

Czy mieszanie metodyk jest dobrą praktyką?

Uważam, że dosłowne mieszanie metodyk nigdy nie kończy się dobrze, a zdarzało mi się w takich projektach pracować. Jeżeli grupa ludzi przez wiele lat opracowała jakąś metodykę to znaczy, że wiedzieli co robią, sprawdzili swoje hipotezy i mają w tym większe doświadczenie od nas. Dlatego otwarte mieszanie elementów metodyk jeszcze tak różnych od siebie jak Waterfall i Agile nie ma szans skończyć się dobrze.

Czym innym jest dopasowywanie metodyki do swoich procesów. Jeśli już naprawdę nie mamy możliwości pracować w pełnej metodyce to możemy ją modyfikować, lepsze coś niż nic. Dla przykładu, jeśli nie mamy czasu (czyt. nie mamy kasy) na przeprowadzanie z całym zespołem wszystkich spotkań scrumowych to skupmy się chociaż na daily i planningu, a np. retro róbmy co drugi sprint. To są modyfikacje, które nie wykluczają nas z prowadzania projektu w zwinnym podejściu, ale dopasowują się do naszego kontekstu.

Rynek IT jest tak dynamiczny, że na pewno będą się pojawiać nowe metodyki. Coraz modniejszy robi się Lean, nie raz firmy przyznają, że używają Kanbana i wiele, wiele innych. Oby tylko tempo pojawiania się tych metodyk nie dogoniła prędkości pojawiania się bibliotek frontowych.  

Podsumowując, w zależności od kontekstu projektu, wymagań i samego klienta musimy dostosowywać sposób zarządzania do sytuacji. Samo mieszanie metodyk nie jest zbyt dobrym rozwiązaniem, jednak praca nad własnym procesem już tak.

W tym tekście starałam się bardzo ogólnie nakreślić różnice między Agile vs Waterfall. Chciałabym, żeby głównym wnioskiem jaki płynie z tego tekstu jest to, żeby nie być wyznawcą danej metodyki i nie realizować np. wszystkiego zwinnie, bo to jest modne i tak robią wszyscy, a myśleć co się sprawdzi akurat w naszym projekcie.

Jakie są twoje doświadczenia z zarządzaniem projektem? Masz może jakieś sposoby, które się sprawdziły u Ciebie w projekcie? Jeśli tak to daj znać w komentarzu, bardzo chciałabym je poznać.

Zgarnij darmowy ebook i cotygodniową dawkę wiedzy

.
Magdalena Limanówka-Kuciel
magdalena@panizkomputerem.pl

Jestem programistką, która lubi mieć ręce pełne roboty. Do życia potrzebuje komputera z internetem i kubka gorącej kawy. Więcej na stronie o mnie.