W sumie poruszałem już ten temat we wpisie Agile vs Waterfall – jak przekonać zarząd i klienta, ale ponieważ znowu odbyła się ciekawa dyskusja na ten temat, to chciałbym jeszcze raz do tego wrócić może na bardziej konkretnym poziomie. Bo czasami zbyt wysoki poziom abstrakcji powoduje trudności w zrozumieniu tematu.

Początkiem dyskusji była opinia, że mimo wszystko czasami lepiej jest przygotować projekt z góry, opisać architekturę, wymogi itp. Takie podejście powinno pomóc uniknąć pułapek, które mogą pojawić się w trakcie tworzenia systemu, zaprojektować architekturę, przewidzieć technologię …

Opiszę tu pokrótce sytuację z jaką miałem do czynienia na początku mojej kariery. Odbywała się dyskusja jak często synchronizować dane do hurtowni danych (i raportów). Prezes firmy oczywiście naciskał, żeby to było tak często jak tylko się da – najlepiej co 5 minut. Wtedy właśnie obecna na spotkaniu księgowa zapytała (a to właśnie księgowość miała być źródłem tych danych): po co tak często, skoro my i tak wprowadzamy dane z kilkudniowym lub większym opóźnieniem? Okazało się, że księgowość wprowadza dokumenty kiedy zbierze się „większa kupka”, a nie w momencie, kiedy ktoś przyniesie fakturę. I jest to powszechna praktyka. Wynika ona również z faktu, że w księgowości ważna jest chronologia (ale to temat na inne rozważania).

Nie będę ciągnął tej historii dalej (może przy innej okazji) ale chciałbym jej użyć do naszkicowaniu różnic w podejściach waterfall i agile. Pominę również fakt, że księgowa była na tyle odważna, że zgłosiła problem natychmiast. Załóżmy hipotetycznie, że mamy Product Owner-a i tradycyjnego PM-a, którzy realizują projekt metodami agile i waterfall. Każdy z nich wybrałby się do prezesa, uzyskał informację o potrzebie pokazywania danych jak najszybciej i poszedł dalej po swojemu. PO prawdopodobnie wrzuciłby do backlogu pokazanie danych bez zwracania jeszcze uwagi na szybkość (pewnie raz na dzień), PM rozrysowałby projekt waterfall z mechanizmami i serwerami do synchronizacji (wydajność!) – dużo pracy. PO po prezentacji rezultatów pierwszego sprintu dostałby feedback i wywołałby dyskusję, jaka odbyła się w opisie powyżej. Rezultat – nie ma sensu robić następnych user story (synchronizacja w czasie rzeczywistym itp.). W waterfall-u też byłby ten feedback ale najprawdopodobniej po kilku sprintach kiedy synchronizacja już by działała co sekundę – masa zmarnowanej pracy.

Oczywiście, mogę się pojawić głosy, że analityk biznesowy mógłby zrobić podobne spotkanie i wykryć zagrożenie, że PO też może zacząć od czego innego (choć tu szansa nikła – pokazanie danych jako jedyne ma wartość biznesową) itp. Najważniejsze jednak jest to, że Agile, jak żaden inny sposób tworzenia oprogramowania jest nakierowany na unikanie tworzenia niepotrzebnych rzeczy. A dzięki oszczędności czasu z tym związanej pozwala rozwinąć znacznie bardziej obszary, które są używane.

Praktycznie nikt nie tworzy oprogramowania „czystym” waterfall-em, raczej są to kaskady kaskad (z grubsza naszkicowany plan, realizacja mniejszych kroków małymi kaskadami projekt-wykonanie). Mimo to brak wczesnej informacji zwrotnej od użytkowników powoduje wytwarzanie niepotrzebnych funkcjonalności. Niepotrzebnych w sensie nieużywanych lub używanych ale niewygodnych dla użytkowników. Zmiany na późnym etapie projektu wywołują również konieczność modyfikowania tych nieużywanych funkcjonalności co dodatkowo pogarsza tempo rozwoju.