„Powrót do waterfall” brzmi prawie jak tytuł filmu Roberta Zameckisa („Powrót do przyszłości„) prawda? W dobie coraz częstszego narzekania na metodyki zwinne po prostu się zastanawiam – czy powrót do waterfall ma sens?
Tam i z powrotem
Skąd narzekanie na metodyki agile? To chyba tak samo jak z wykonywaniem często tej samej, powtarzalnej czynności. Im częściej coś robisz, tym większa szansa, że w końcu się pomylisz. Popełnienie błędu jest nieuchronne. W końcu jesteśmy tylko ludźmi i nikt nie jest nieomylny. Wraz ze wzrostem liczby projektów w których wykorzystujemy zwinne podejście rośnie także liczba osób, która ma okazję wypowiedzieć się na jej temat. Czasem będą to czasem negatywne, częściej – pozytywne. Działa tu więc klasyczna statystyka i prawo wielkich liczb.
Ale nie tylko statystyczne trafienie na narzekającego członka zespołu zwinnego ma tutaj znaczenie. Często jest tak, że zwinne metodyki nie są wykorzystywane do tego, do czego zostały stworzone. Nie musimy korzystać ze Scrum, kiedy rozwiązujemy proste, powtarzalne czynności. Nie użyjemy też naszej ulubionej zwinnej metodyki w sytuacji, w której zajmujemy się utrzymaniem działającego systemu, a nasza praca skupia się tylko na rozwiązywaniu kolejnych problemów.
W niektórych przypadkach wystarczą nam elementy zwinności, a w nielicznych zwinne podejście po prostu się nie opłaci!
Waterfall jaki jest, każdy widzi
Nie jestem jego wielkim przeciwnikiem waterfalla. Moje nastawienie do niego opisałbym jako neutralne. Rozpoczynając lata temu pracę w IT to właśnie waterfall był sposobem, w którym przyszło mi pracować. Rozumiem więc jego zwolenników, ale dzięki pracy w podejściu zwinnym rozumiem też przeciwników.
Im więcej czytam o zasadach klasycznych metodyk wytwarzania oprogramowania, w tym na przykład o dokumentach, które powinny powstać w procesie uruchamiania projektu, tym częściej myślę sobie „to jest coś, czego potrzebują nasi klienci”. Bo nie oszukujmy się, dla wytrawnego managera czy CEO, który pracował naście lat prowadząc projekty IT, zwinne, lekkie podejście może budzić podejrzenia. Ale wiemy też, że zwykle są to obawy zupełnie niesłusznie.
Próbując rozwikłać tę zagadkę zawsze myślę nad tym, co jest najważniejsze dla takiej firmy. Z jednej strony możemy podążać za metodyką, tworzyć wymaganą dokumentację i formalizować coraz to nowe ustalenia z klientem. Z drugiej możemy przyrostowo oddawać działające oprogramowanie, na którym firma już od pierwszych chwil może zarabiać? Co powinno być najważniejsze?
Bądźcie „klasycznie” zwinni!
Bądźmy agile, ale w mądry sposób i tam, gdzie ma to swoje uzasadnienie. Pchanie zwinności wszędzie wyłącznie po to, aby „podążać za rynkiem” naprawdę mija się z celem. A co najważniejsze, mija się z potrzebami naszych ludzi. Nic skuteczniej nie obrzydzi pracy w zwinnych metodykach niż ich odgórne narzucenie w miejscach, które nie są gotowe na agile lub przy projektach, w których one nie pomogą.
Zwinność ma swoje granice. Agile to też nie chorągiewka na wietrze – nie możemy, w zależności od sytuacji raz z niej korzystać, raz nie. Nie powinniśmy również ograniczać zakresu, w którym staramy się być zwinni (patrz: Broken Window Theory). Jeśli tak się dzieje, to zastanówmy się, czy na pewno jej potrzebujemy.
Poszczególne elementy zwinnych metodyk nie są ich zastrzeżoną własnością. Możemy używać ich do woli. Ale nie oszukujmy siebie i innych, że pracujemy zwinnie. Zaraz po tym, kiedy nasi pracownicy zmienią pracodawcę i przedstawią modelową „wizję zwinności” z poprzedniej firmy wyjdzie na jaw, jak bardzo byliśmy daleko.
Nie ma wstydu w przyznaniu się przed wszystkimi, że pracujemy waterfallowo wykorzystując pewne techniki i narzędzia.
Powrót do waterfall
Klasyczne metodyki wytwarzania oprogramowania, wciąż mają wciąż wielu zwolenników. Teoretyczny porządek i udokumentowanie wszelkich możliwych aspektów prowadzenia projektu to tylko część z korzyści wynikających z ich wykorzystania. I niech tak pozostanie, są sytuacje w których jest to ważniejsze niż opisywany przez nas cel zwinności. Co powinien zatem uczynić Project Manager, kiedy okażę się, że zwinność nie jest idealna dla naszego projektu?
Jako osoba znająca oba podejścia, w pierwszej kolejności zastanowiłbym się, z czym przyszło nam się zmierzyć. Jeśli z czymś nowym, trudnym i skomplikowanym, to nie w metodyce prowadzenia projektu jest problem. Problemu powinniśmy poszukać w jej wykorzystaniu. Powrót do waterfall w przypadku innowacyjnych projektów wcale nie spowoduje, że osiągniemy zakładany cel. Będzie jedynie pretekstem, aby poszukać winnych opóźnień i przekroczenia budżetu.
Jeśli mamy do czynienia z projektem powtarzalnym, który wykonywaliśmy już wiele razy bądź z takim w którym kolejność wykonywania poszczególnych elementów jest z góry ustalona – zastanówmy się nad powrotem do waterfall. Jeżeli doskonale wiemy, co jest do wykonania, jeżeli z doświadczenia wiemy, że potrafimy to z góry zaplanować i potem wykonać – nie miejmy żadnych skrupułów. Upewnijmy się tylko, że faktycznie ma to szansę dać nam oczekiwane efekty.
