Czy Agile jest bardziej efektywne niz Waterfall?
Jeden ze Scrum Masterow, ktoryc h regularnie coachujemy, dzwoni do nas regularnie z problemami, z ktorymi sie boryka. Zartowal, ze powinnisMy najlepiej mowic „Agile Hotline, w czym mozemy pomoc?", gdy odbieramy telefon. Uznalismy, ze to swietny pomysl i dlatego zaczynamy od serii wpisow blogowych o nazwie Agile Hotline. Tutaj znajdziesz nasze odpowiedzi na pytania, ktore dostajemy od innych na temat Agile lub Scruma. Mamy nadzieje, ze Ty rowniez bedziesz mogl sie z tego czegos nauczyc.
Niedawno poproszono mnie o rade w dyskusji, ktora ktos mial z kolegiem. Chodzilo o to, czy Agile i Scrum moga dzialac w kazdym scenariuszu, w ktorym tworzone jest oprogramowanie. Kolega twierdzil, ze nie.
Scenariusz
Zarozmy, ze ma byc zbudowany produkt programowy, ktory umozliwia uzytkownikow przeprowadzanie ocen podczas czytania ebooka. Ma istniec co najmniej dwa rozne rodzaje tych ocen.
W podejsciu Agile / Scrum staralibysmy sie jak najwczesniej dostarczyc dzialajacy i wartosciowy produkt – czyli celem jest dostarczenie tylko jednej z mozliwosci oceniania, ktora jednak moze byc juz wczesnie uzywana przez uzytkownikow. Bylaby to wersja 1.0. Kilka Sprintow pozniej staralibysmy sie nastepnie wdrozyc druga mozliwosc oceniania jako wersja 2.0.
W modelu Waterfall przeznaczylibysmy tyle czasu, ile potrzeba, aby obie oceny dostarczyc w pierwszej wersji.
Kolega argumentowal w tym przypadku, ze Waterfall mialoby wiekszy sens, poniewaz inaczej ryzyko koniecznosci refaktoryzacji calego kodu w celu obslugi drugiej mozliwosci oceniania v2.0 byloby bardzo wysokie. Z Waterfall obie rodzaje ocen zostalby jednak opracowane razem. Choc trwalob y dluzej dostarczenie pierwszej dzialajace j wersji, nalezaloby mniej poprawiac.
Jest zdania, ze metoda Waterfall oszczedza czas i jest bardziej efektywna, poniewaz trzeba mniej refaktoryzowac, gdy rozpoczyna sie prace jednoczesnie z aktualnymi i przyszlymi wymaganiami. W Agile nasz fokus skupia sie jednak na „teraz" i tylko na jednym rodzaju oceny.
Co o tym myslisz? Jak poradzilbys sobie z grupa deweloperow, ktorzy uwazaja, ze przy Agile beda musieli pozniej duzo przerobia c, poniewaz „nie mogli planowac zbyt daleko do przodu"?
Co myslim y
Istnieja trzy glowne punkty, ktore nalezy rozumiec, aby odpowiedziec na to pytanie:
Po pierwsze: Agile i Waterfall maja kazde swoje zastosowanie. Agile jest przeznaczone do systemow skomplikowanych/zlozonych, np. gdy istnieje pewien stopien niepewnosci co do wymagan i/lub technologii. Waterfall najlepiej nadaje sie do prostych projektow, na przyklad gdy istnieje dobre zrozumienie wymagan i technologii i rzeczy te sie nie zmieniaja. Uzywamy macierzy Staceya, aby wyjasnic, kiedy po co siegnac. Rzecz w tym, ze Waterfall calkowicie zawodzi w zlozonym srodowisku, podczas gdy Agile w prostym srodowisku wiaze sie z wiekszym nakladem pracy, ale nadal dziala. Naszym ulubionym przykladem jest organizowanie konferencji. Mozna uzywac Agile, nawet jesli moze to wygladac na zbedny naklad pracy.
Po drugie: Agile NIE jest bardziej efektywne niz Waterfall. Jest bardziej skuteczne. Oznacza to, ze byc moze potrzeba wiecej roboczogodzin, aby cos dostarczyc z Agile, ale produkt bardzo prawdopodobnie moze byc wprowadzony na rynek wczesniej (poniewaz po kazdym Sprincie powinno byc wydanie, a nie dopiero po zakonczeniu projektu). Ponadto calkowite koszty operacyjne sa prawdopodobnie nizsze (poniewaz jakosc i projekt sa lepsze, a wiedza jest wspoldzielona, co ulatwia konserwacje).
Po trzecie: Agile nie polega na szybszym tworzeniu czegos konkretnego. Chodzi o sztuke maksymalizacji ilosci niewykonanej pracy. Badanie Chaos mowi, ze 65% oprogramowania nigdy lub rzadko jest uzywanych. Agile stara sie identyfikowac i tworzyc pozostale 35%, ktore maja szanse na uzycie; potem sie konczy. Wiec nawet jesli byc moze trwa troche dluzej tworzenie pierwszych 35%, zaoszczedzilismy na tworzeniu pozostalych 65%, ktore nikt nie bedzie uzywal.
Jak to wyglada teraz z naszym przykladem? Coz, przede wszystkim nie konczylibysmy najpierw calej pierwszej oceny, a potem drugiej. Identyfikowalismy dys najwartosciowsza czesc oceny. Moze to byc pewien rodzaj pytania (np. pytanie wielokrotnego wyboru). Budowalbysmy wiec tylko jedno pytanie do oceny, testowalbysmy je przez uzytkownikow i dowiadywalbysmy sie, czy dziala. Moglibymy nawet dostarczyc pierwsza mozliwosc oceniania tylko z pytaniami wielokrotnego wyboru. Nastepnie wbudowywalbysmy nastepny najwazniejszy typ pytania. Lub decydowali bysmy, ze jest wystarczajaco dobry i zaczeli nowy projekt.
Jesli zakres ocen jest naprawde ustalony, wiadomo tez, ze naprawde dziala dla uzytkownikow, i nie ma niepewnosci co do technologii, Waterfall moze byc lepszym wyborem dla tego projektu. Agile rowniez by dzialalo, tylko niekoniecznie oszczedzalo czas. Z doswiadczenia moge powiedziec, ze wiekszosc ludzi mysli, ze zna i rozumie wszystkie wymagania – ale zazwyczaj tak nie jest. Dodatkowy naklad pracy z Agile zazwyczaj sie wiec oplacal.
Niniejszy tekst pochodzi z bloga Growing Agile i zostal przez nas przetlumaczony na jezyk polski.
