Jak zwinna jest Twoja organizacja? Agile: scrum oraz kanban, SAFe czy waterfall. Dowiedz się jaki ekwipunek wybrać dla swojej organizacji?

Nowe metodologie rozwoju oprogramowania wyrastają dookoła nas jak grzyby po deszczu. Internet pełen jest artykułów na ich temat: wywyższających jedne, krytykujących drugie, zestawiających je i przedstawiających teoretyczne wady i zalety. Niestety, niekoniecznie przekazują nam one wiedzę niezbędną do podjęcia decyzji o tym, która z nich najlepiej sprawdzi się w naszej organizacji. Ideologia często wygrywa z merytorycznymi faktami, dlatego też chciałbym omówić brzemienny w skutkach dylemat na podstawie czterech historycznie ważnych metodologii. 

Agile Scrum, elastyczny i innowacyjny, często jest zbyt idealistyczny, co sprawia problemy wdrożeniowe w większości organizacji podejmujących się transformacji w jego kierunku. Kanban, również giętki i zoptymalizowany, ale bez sprintów, często utrudniają raportowanie wzwyż. SAFe (Scaled Agile Framework) rozwiązuje problem skalowalności agile’a w dużych organizacjach, ale kosztem wspomnianej elastyczności i jest krokiem w tył w stronę waterfalla. Waterfall jest zoptymalizowany, ale sztywny i archaiczny w oczach większości. Wszystkie z tych metodologii mają swoje wady i zalety..

Wybór metodologii często wynika z upodobań ideologicznych, a nie z obiektywnej analizy potrzeb danej organizacji. Skutkuje to często potrzebą zatrudnienia konsultantów do przeprowadzenia transformacji (z powodu braku odpowiedniej wiedzy i/lub kwalifikacji wśród obecnej kadry pracowniczej), powstania nowych ról wewnątrz organizacji oraz wzmożonej rotacji pracowników, sfrustrowanych zaburzeniem statusu quo lub trudnościami wynikającymi ze stanu przejściowego pomiędzy starą a nową metodologią. Produktywność spada z powodu czasu poświęconego na douczanie pracowników, wdrażanie nowych członków zespołu oraz zmiany procesowe i strukturalne, które wymagają czasu na implementację. Duże firmy i korporacje zdecydowanie najbardziej doświadczają spadku produktywności z powodu problemów skali, stąd też bierze się ich wzmożona chęć optymalizacji procesów wewnętrznych. Niestety, z tego samego powodu transformacje przebiegają w nich nierzadko latami, a rzadko – jeśli kiedykolwiek – kończą się sukcesem. Historycznie większość organizacji, które istnieją na rynku od wielu dekad, pracuje lub pracowała w metodologii waterfallowej, która została przeniesiona z sektora przemysłowego i dostosowana do potrzeb rozwoju oprogramowania. Dlatego też widziana jest jako przestarzała i archaiczna, przez co firmy, pragnące nadążyć za duchem czasu, odczuwają potrzebę transformacji, kompletnie ignorując lata pracy włożone w lokalną implementację i optymalizację tej metodologii na przestrzeni lat. Pomijane są jakiekolwiek metryki wydajności, a górę bierze maksyma „out with the old, in with the new”, zgodnie z którą nowe znaczy lepsze. Świat jest pełen konsultantów i ekspertów, którzy (często za niemałe pieniądze) z chęcią podejmą się takiego wyzwania, nie bacząc na logiczne przesłanki za lub przeciw, jednocześnie nie ponosząc żadnych konsekwencji w przypadku niepowodzenia. 

Mój wywód na temat metodologii dostarczania oprogramowania zacznę od japońskiego zagadnienia Kaizen oraz jego zachodniego kuzyna, Lean. Obie te filozofie wywodzą się z organicznej potrzeby optymalizacji wykonywanej pracy przy jednoczesnym podniesieniu jakości dostarczanego produktu. Tym samym są one intelektualnymi prekursorami ogólnie pojętych metodologii dostarczania oprogramowania, przy czym warto zaznaczyć, że rzadko są one brane pod uwagę w dyskusji na temat wyboru konkretnej metodologii, ponieważ decydującym argumentem są zazwyczaj pieniądze i pozostałe motywacje schodzą na dalsze plan. Dla przykładu: duże korporacje często wdrażają nowe metodologie w celu procentowej optymalizacji zysku, a wpływ tej zmiany na jakość dostarczanego oprogramowania jest po prostu efektem ubocznym. Z oczywistych powodów możecie nie usłyszeć tego od żadnego CEO/CTO/CIO, lecz być może powie wam o tym doświadczony programista z korporacyjnym stażem. 

Wróćmy jednak do tematu i przyjrzyjmy się omawianym metodologiom pod kątem wydajności oraz jakości, jednocześnie biorąc pod uwagę realia operacyjne różnego rozmiaru organizacji.

Agile scrum

Nowoczesna oraz elastyczna metodologia rodem ze start-upów właśnie w nich najlepiej się sprawdza. Jej największą zaletą jest bardzo szybki rozruch projektu i dostarczenie pierwszej działającej wersji produktu poprzez rozbicie monolitycznych procesów, wywodzących się z metodologii waterfallowej, i wprowadzenie relatywnie krótkich sprintów, które można uznać za mikroprojekty, bo z definicji zawierają wszystkie fazy projektowe (od analizy wymagań biznesowych oraz ich translacji na specyfikację techniczną, poprzez faktyczny development wraz z testami, aż po wdrożenie). Dodatkowo wszystkie osoby zaangażowane w projekt stają się równorzędnymi członkami zespołu cross-funkcyjnego, mającego jeden wspólny cel: dowiezienie sprintu. Pozwala to na zminimalizowanie czasu poświęcanego na czynności niezwiązane bezpośrednio z rozwojem oprogramowania, a także spłaszczenie hierarchii projektowej i skupienie się jedynie na bieżącej pracy oraz planowaniu krótkoterminowym. Niestety, metodologia ta jest słabo skalowalna i jej wdrażanie w dużych, a nawet średnich organizacjach obarczone jest znacznym ryzykiem, a to z powodu złożoności siatki zależności wewnętrznych oraz rozmiaru powstających zespołów cross-funkcyjnych. Dodatkowo Scrum wymaga współodpowiedzialności wszystkich stron i respektowania jego obrzędów oraz kontraktu sprintowego. Wraz ze wzrostem liczby osób zaangażowanych w projekt następuje rozproszenie wspomnianej odpowiedzialności do poziomu, na którym agile jest traktowany jako wymówka do pracy bez wymagań i przeniesienie odpowiedzialności na stronę techniczną, przy jednoczesnej marginalizacji świętości bieżącego sprintu. Mimo powyższego, dostarcza on doskonałych narzędzi raportowania, w postaci pseudonamacalnych jednostek pracy: punktów, określających wymierną zdolność produkcyjną zespołu, oraz wykresów spalania owych punktów w sprincie, które upiększają maile do zarządu. To, w połączeniu z nowoczesnymi narzędziami do zarządzania projektami (np. JIRA), sprawia, że jest on bardzo popularny po biznesowej stronie organizacji. Na zakończenie warto wspomnieć, że w tej metodologii brak jest jakiegokolwiek planowania długoterminowego, co stoi w konflikcie z potrzebą budżetowania, planowania rekrutacji oraz innymi aspektami polityczno-organizacyjnymi dużych firm. Skutkuje to często powstawaniem wyssanych z palca i/lub utopijnych planów projektowych, dostarcza przy tym frustracji osobom współodpowiedzialnym za ich tworzenie oraz powoduje spadek wydajności z powodu poświęconego czasu i energii.

Kanban

Agile to nie tylko Scrum, ale także Kanban, który zastępuje sprinty ciągłym strumieniem pracy, skupiając się przy tym na optymalizacji samego procesu dostarczania oprogramowania. Dzięki pozbyciu się iteracyjnego charakteru pracy, zamkniętego w sztywnych ramach czasowych, zyskujemy dodatkowy poziom elastyczności i możliwość ustalania priorytetów projektowych na bieżąco zamiast okresowo. Niestety, ceną za to jest utrata przejrzystości, którą daje cykliczne raportowanie podczas sprintu, co zazwyczaj jest negatywnie oceniane przez stronę biznesową w dużych organizacjach. Dodatkowo Kanban cierpi z powodu tych samych bolączek, co wcześniej omówiony Scrum, czyli braku długoterminowego planowania oraz podatności na wąskie gardła w poszczególnych etapach rozwoju oprogramowania, spowodowanych trudnościami w równomiernym rozłożeniu nakładu pracy pomiędzy wszystkie zaangażowane w proces osoby (analityków, designerów, deweloperów czy testerów).

SAFe

SAFe (Scaled Agile Framework) powstał ze względu na wyżej opisane problemy skalowalności i miał uzupełnić agile o element brakujący, a wymagany w dużych organizacjach, czyli planowanie długoterminowe oraz uwzględnianie rozbudowanej siatki zależności projektowych. Tym samym jest to krok wstecz, w stronę metodologii waterfallowej, skutkujący dodatkowym nakładem pracy i utratą elastyczności oraz przejrzystości na rzecz sztywniejszych ram projektowych, wymaganych przez struktury organizacyjne średnich i dużych firm. Pomimo, że zaspokaja przez to wysokopoziomowe potrzeby złożonej hierarchi organizacyjnej, robi to normalizując konflikt waterfalla z agile. Może to skutkować zjawiskiem interferencji, gdy – w przypadku udanego wdrożenia tej metodologii – znajdujemy złoty środek pomiędzy obydwiema metodologiami lub w – przypadku niepowodzenia – absolutną klęskę z najgorszymi elementami obydwu z nich.

Waterfall

Czarna owca w rodzinie. Nikt w dzisiejszych czasach nie chwali się pracą w tej metodologii, a nawet rzadko kto chce się do tego publicznie przyznać. W praktyce spora część organizacji agile’owych powinna pracować w tej metodologii. W wielu sektorach mamy do czynienia z bardzo jasnymi wymaganiami ze strony bezpieczeństwa danych, dostępności, regulacji prawnych, kompatybilności czy integracji z istniejącymi już systemami i pominięcie tych wymagań we wczesnych fazach projektu, po to, aby jak najszybciej wypuścić prototypową wersję oprogramowania ma często katastrofalne skutki. Metodologia ta bazuje głównie na planowaniu długoterminowym, przez co jest mało elastyczna, ale zapewnia doskonałe narzędzia do raportowania postępów w pracy. Bardzo słabo sprawdza się natomiast w dynamicznie rozwijających się projektach, gdzie ilość niewiadomych na początku i w trakcie trwania projektu utrudnia (lub wręcz uniemożliwia) wcześniej wspomniane planowanie. Waterfall jest również bardzo czuły na przesunięcia terminów, a to ze względu na chronologiczność wykonywanych prac, ale przy właściwym wdrożeniu i zapewnieniu odpowiedniego poziomu jakości na wszystkich etapach rozwoju oprogramowania, znacznie optymalizuje proces. 

Na koniec chciałbym pokrótce zilustrować dylematy związane z wyborem metodologii za pomocą prostej metafory, a tym samym skłonić do głębszej analizy potrzeb organizacji i porzucenia dogmatycznych pobudek na rzecz merytorycznie uzasadnionego wyboru. Wyobraźmy sobie, że rozpoczynamy projekt, którego celem jest zbudowanie rakiety. Na początku nie mamy żadnych wymagań poza tym, że rakieta ma wystartować. Metodą prób i błędów oraz wielokrotnych testów i modyfikacji osiągamy sukces. Książkowy agile. Może nawet regularnie, po każdej iteracji, testujemy prototyp małej rakiety. Jak zmieni się nasz proces, jeśli każdy test będzie niósł ze sobą określony koszt, a projekt będzie miał sztywny budżet? Co, jeśli warunki nie będą pozwalać na regularne przeprowadzanie testów, bo będziemy – przykładowo – potrzebować pozwolenia ze strony gminy, na terenie której pracujemy? Co, jeśli każda próba będzie bardzo kosztowna i tym samym będziemy mogli przeprowadzić ich tylko określoną i wcześniej zaplanowaną liczbę? Co, jeśli rakieta ma przelecieć z góry określony dystans? Co, jeśli ma być niebieska? Co, jeśli może wystartować tylko konkretnego dnia, a na pokładzie ma znajdować się człowiek? No i na koniec: co, jeśli dokładnie 15 czerwca człowiek ma odbyć podróż tą bardzo drogą niebieską rakietą na Księżyc i wylądować? Brak długoterminowego planu to nie tylko elastyczność, ale także ryzyko. Brak dogłębnej analizy wszystkich wymagań to nie tylko szybszy prototyp, ale również potencjalna klęska w pół drogi. Wszystko zależy od skali konsekwencji naszej porażki. Im większa skala, tym niższa jest nasza tolerancja na ryzyko oraz niewiadome – i tym bardziej rozsądnym wyborem wydaje się waterfall.