Dlaczego ścisłe trzymanie się Agile i jego zasad nie jest najlepszym pomysłem

Jakoś dwa albo trzu lata temu (czyli w 2017 lub 2016 roku) doszły mnie słuchy, iż w w Unii Europejskiej będzie w 2020 roku około miliona nieobsadzonych wakatów w branży IT. Niestety przewidywania te nie sprawdziły się. Już w końcówce 2018/na początku 2019 roku dobito do takiej liczby. Część tych stanowisk stanowią administratorzy, część testerzy, część programiści, analitycy i tak dalej.

Rafał Kozłowski. Senior Software Engineer w Credit Suisse. Posiada grubo ponad 10 lat profesjonalnego doświadczenia, zbliżającego się nieubłaganie do 20. Pracuje głównie w technologiach .NET (zarówno Framework jak i Core) oraz jest wielkim sympatykiem Angulara i architektury używającej mikroserwisy. Zagorzały zwolennik Domain Driven Design, Command Query Responsibility Segregation oraz Single Page Application.

Część ludzi, tych, którzy nie zaliczają się do świata IT, bardzo często nie rozumie czymże jest IT. Bo i skąd mają to wiedzieć? Dla nich IT to ten osobnik, co się umie z komputerem dogadać i wymienić w nim wentylator jak ten się robi głośny. Albo Windowsa umie zainstalować. Ewentualnie to ten, co każdego dnia “klika w komputer i jeszcze na tym pieniądze zarabia”, kiedy mógłby coś pożytecznego dla świata zrobić, na przykład zostać hydraulikiem albo mechanikiem.

A teraz tak bardziej na poważnie. To, że ludzie spoza świata IT nie wiedzą o nim wiele nie dziwi nikogo. Ja też o chirurgii naczyniowej nie wiem zbyt dużo i wydaje mi się to niemal jakąś magią albo wiedzą tajemną, bo po prostu się na tym nie znam. Gorzej, jak ludzie którzy pracują w naszej branży, sami nie wiedzą czymże ona jest i po co powstała. Serio, zdarzają się tacy. Kiedyś słyszałem od jednego człowieka z branży, że IT to skrót od InformaTyka. Nic bardziej mylnego – IT to skrót od Information Technology! Co to znaczy na ludzkie? To znaczy tyle, że IT, to nic innego jak nauka na temat tego, jak przechowywać, przetwarzać oraz przesyłać informacje (głównie za pomocą urządzeń elektronicznych zwanych komputerami).

Komputery same z siebie nie przetwarzają konkretnych informacji. To tylko głupie pudełka, a dzięki wynalezieniu jakiś czas temu pierwszych programowalnych mikrokontrolerów możemy programować, czyli przekazać sekwencję instrukcji, dzięki którym wykonają jakieś polecenie.

Jak kiedyś wytwarzano oprogramowanie

Dobra, taki komputer, ponieważ sam nie jest alfą i omegą, musi mieć oprogramowanie, które ułatwia ludziom życie. Tak to działa. To co ludzie uruchamiają nie bierze się na ekranie z kosmosu – ktoś to musiał wymyślić, napisać, przetestować, sprzedać i dostarczyć.

Jeśli nie jesteś osobą pracującą w IT, to nie masz pojęcia jak wygląda proces wytwarzania oprogramowania. To nie jest tak (chociaż czasem się tak zdarza), że jakiś kujon siedzi w swoim pokoju i z wypiekami na twarzy pisze jakiś program. W przypadku większości dużych rozwiązań, aby coś takiego mogło powstać, w tle stoi za tym cały sztab ludzi.

W latach dziewięćdziesiątych (i nie tylko, niektóre firmy do dziś się tego trzymają, chociaż przy tym podejściu nie wróżę im świetlanej przyszłości), wytwarzanie oprogramowania wyglądało prawie tak samo jak produkcja czegokolwiek. Czyli był proces wielomiesięcznej analizy, gdzie dyskutowano co stworzyć i jak ma to działać. Następnie był proces wielomiesięcznej (a raczej wieloletniej) implementacji przez całe zastępy programistów. Po tym była faza testów oraz poprawek czasami przeplatana akceptacją ze strony “góry”.

Dzięki takiemu rozwiązaniu, już po kilku latach od wymyślenia hiper mega fajnego pomysłu na program, po wydaniu kilku milionów dolarów na analizę, implementację, testy i poprawki można było z dumą lub z przerażeniem w oczach stwierdzić, że to co zostało dostarczone już jest nieaktualne i konkurencja oddała podobne oprogramowanie rok wcześniej zagarniając większość rynku. Poza tym, oprogramowanie, pomimo wielomiesięcznych testów dalej ma niedoskonałości i rozwiązania różnią się od tego, co autorzy mieli na myśli. Aczkolwiek oprogramowanie robiło dokładnie to, co było rozpisane w wielostronnicowej analizie przygotowanej przez całe zastępy analityków…

Szukano rozwiązania, bo po miesiącach pracy, często nie było co pokazać szefostwu

Co zatem poszło nie tak? Gdzie popełniono błąd? Wiele osób próbowało odpowiedzieć na to pytanie i wiele osób poległo. Jednak w 2001 roku znalazła się grupa osób z branży IT, której udało się zbliżyć do odpowiedzi. Może nie ustalili co poszło nie tak, jednak ustalili, jak robić wszystko tak, żeby prawdopodobieństwo sukcesu zwiększało się z czasem, a nie zmniejszało jak to ma miejsce w podejściu z lat dziewięćdziesiątych (czyli Waterfall).

W Waterfall mamy fazę planowania i analizy a następnie implementacji, po której następuje faza testów i wdrożenia, tak w wielkim uproszczeniu. Każda z tych faz obarczona jest ryzykiem – ktoś coś źle zrozumie, ktoś coś źle zinterpretuje, ktoś coś źle zaimplementuje, ktoś coś źle przetestuje – jak w rysunku poniżej.

Tak narodził się agile

Idea ta zachęcała do tego, by mieć krótki sprint, gdzie biegiem gonimy do mety i naszym zadaniem jest dowieźć COKOLWIEK. Dlaczego cokolwiek? Bo to i tak lepsze niż wcześniejsze, wielomiesięczne dowożenie NICZEGO.

W związku z tym, że każda faza jest obarczona ryzykiem, a systemy budowano od razu jako kombajny robiące wszystko, włącznie z kawą z pianką i rysunkami na niej, na koniec projektu cieszono się jak dowieziono 60% albo i mniej funkcjonalności. Dlatego grupa z 2001 roku zebrała się (a był w niej m. in. Martin Fowler, Kent Beck, Robert C. Martin i kilku innych) przy dobrym alkoholu próbując znaleźć rozwiązanie. I udało się! Tak narodził się Agile wraz z Agile Manifesto.

Jego głównym założeniem w odróżnieniu do klasycznego podejścia było to, by wytwarzać oprogramowanie w krótkich okresach, tak zwanych sprintach, gdzie biegiem gonimy do mety i naszym zadaniem jako zespołu jest dowieźć cokolwiek. Dosłownie cokolwiek. Dlaczego tak mało? Bo jest to i tak więcej niż dowiezienie niczego w cyklu wielomiesięcznym, co się często zdarzało przy podejściu Waterfall.

Pierwsze sprinty trwały 6 tygodni, co dziś jest nie do pomyślenia, następnie skracano je i dziś miewamy sprinty tygodniowe a czasem i nawet krótsze. Na tamte czasy, “krótko” znaczyło 6 tygodni. Dosłownie – wtedy uważano, że sześciotygodniowy sprint to prawdziwy sprint! Dziś potrafimy mieć sprinty tygodniowe, a czasem i krótsze. Nie od razu Rzym zbudowano, więc naście lat temu, zaczęto od okresu, który był akceptowalny dla ogółu – nikt nie uwierzyłby przecież, że coś co wcześniej zajmowało dosłownie lata, może być skrócone do miesięcy lub tygodni.

Te 6 tygodni było okresem na tyle krótkim, że biznes, managerowie i cała reszta była w stanie uwierzyć, że coś zostanie zrobione. Po udowodnieniu, że to podejście działa, stopniowo skracano okres i mamy dziś to co mamy – czasem sprinty trwające godziny.

Problem z Agile i z jego zbyt dosłowną implementacją

Dziś ciężko sobie wyobrazić, że można pracować nie w sposób Agile. Niemal w każdej ofercie dla programistów lub testerów, metodyka ta jest wymieniana jako jeden z atutów. W innych brak tego wymienienia, jednak w domyśle każdy wie, że Agile gdzieś tam jest. Bo niby cóż innego? Na niedziałającym Waterfallu zbyt wielu już się przejechało, aczkolwiek jest jeszcze garstka takich, którzy się tego trzymają. Może akurat dla nich działa. Kto wie.

Metodyka ta wygląda na doskonałe remedium problemów z wytwarzaniem oprogramowania, czy jest tak aby na pewno? Czy nie ma minusów, które potrafią zamiast usprawniać to psuć? “Młody, dynamiczny zespół, składający się z sześciu osób” – to dość prawdopodobny i częsty, cząstkowy opis występujący w propozycjach pracy. I dla takich grup omawiana technika się sprawdza doskonale. Samoorganizujące się zespoły sprawdzają się dość dobrze, do momentu, gdy ktoś nie bierze Agile zbyt dosłownie i traktuje wszystkie jego zasady literalnie.

Jakie problemy generuje Agile?

Takie literalne i przesadne podążanie za pryncypiami może wygenerować następujące problemy:

1. Ślepe nastawienie na klienta i tylko na niego – może generować spięcia w samym zespole oraz próbę zadowolenia klienta za wszelką (nawet niesłychanie wysoką) cenę.
2. Pozwolenie na ciągle i nieustanne zmiany wymagań na każdym etapie rozwoju – może generować problemy z samym klientem, który do samego końca nie będzie wiedział co chce, utrudniając tym samym zakończenie projektu na jakimkolwiek etapie
3. Zbyt krótkie sprinty – w Agile mamy sesje planowania i retrospektywy, które zajmują czas. Zbyt krótkie sprinty sprawiają, że mamy narzuty czasowe, które sprawiają, że nie da się dynamicznie i szybko dostarczać rozwiązań klientowi
4. Bezgraniczne skupienie na technologicznej doskonałości – może sprawić, że zamiast dowieźć rozwiązanie działające i spełniające wymagania klienta, będziemy zmieniać technologię, bo pojawiło się coś nowego (a pojawia się każdej godziny) i będziemy robić refactoring, by dogonić mityczną technologiczną doskonałość.

Przykładów można by mnożyć i mnożyć. Czy to znaczy, iż taki sposób pracy jest zły? Nic bardziej mylnego, chodzi po prostu o to, by zachować umiar. Każde ekstremum jest groźne i dążące raczej do samozagłady niż do dostąpienia mitycznej Nirvany. Ważne, by zachować umiar. Tak jak we wszystkim – 12 zasad Agile nie należy stosować zbyt dosłownie, gdyż zamiast pomóc w rozwiązaniu problemów, mogą zaszkodzić.

Zakładając, że wszystko jest robione bez przesadności, omawiana technika potrafi generować zaskakujące efekty. Można dostarczać rozwiązania szybko i sprawnie. Ale – bo zawsze musi jakieś być „ale”. Wszystko to pięknie działa na poziomie pojedynczego zespołu. A co w przypadku współpracy wielu zespołów pracujących w takim systemie?

Zgodnie z zasadami Agile, zespół ma dostarczać wartość bazując na informacji zwrotnej i ma dostarczać wartość/robić wdrożenie na produkcję tak często jak tylko się da. Przy jednym zespole to działa perfekcyjnie. Przy wielu działa to, hmm, tak naprawdę nikt do końca nie wie jak.

Można powiedzieć “ale jak to, przecież zawsze musi być wiedza jak to działa”. I wiedza zawsze jest. Zawsze możesz wiedzieć na jakim etapie jest jeden, pojedynczy zespół. Ale na jakim etapie jest całe oprogramowanie, nad którym pracuje na przykład 10 grup? Zwłaszcza gdy dochodzi do zależności między nimi i jeden zależy od drugiego, drugi od piątego a piąty od siódmego? Nie wspominając, że siódmy zależy od pierwszego. Tak mnożyć można w kółko.

Scrum of scrums, spotkania managerów, przedstawicieli zespołów – wszystko to jest po to, by ustalić gdzie jesteśmy. Ale nawet i to jest obarczone ryzykiem, bo przedstawiciel/scrum master/product manager mogą mieć niepełną wiedzę lub wiedzę zafałszowaną. Takie rozwiązania pomagają, jednak komplikują cały system, którego podwaliną była prostota – między innymi o to chodziło ojcom założycielom Agile – Waterfall obarczony jest ryzykiem, gdyż jest zbyt dużo elementów pośrednich (analiza/deweloperzy/testerzy/managerowie/zarząd/klient/itp), a każdy element to zwiększająca się złożoność, czyli większa szansa na… porażkę.

Jak takie problemy można obejść?

A jak rozwiązać takie problemy? W bardzo prosty sposób – po prostu usiąść i rozwiązać. A tak bardziej na poważnie, to w przypadku problemów ze zbyt literalnym traktowaniem zasad należy… poluźnić trochę szelki, rozwiązać krawat i rozpiąć górny guzik koszuli. Następnie wziąć głęboki oddech i przypomnieć sobie co mówi Agile:

• Ludzie i interakcje są ważniejsi niż procesy oraz narzędzia,
• Działające oprogramowanie jest ważniejsze niż dobra (lub jakakolwiek!) dokumentacja techniczna,
• Współpraca z klientem jest ważniejsza od negocjacji z nim i zrzucania winy,
• Reagowanie na zmiany ważniejsze niż sztywne trzymanie się planu.

Taki trochę paradoks – zlikwidować problemy jakie generuje Agile za pomocą zasad jakie promuje tenże Agile. Metodyka ta została wymyślona po to, by reagować na zmieniające się środowisko i dostosowywać się do tych zmian. Inaczej będziemy mieć swoistą formę zamiatania problemu pod dywan.

Jeśli ktoś w zespole mówi, że ktoś kto jest z jego otoczenia nie jest członkiem zespołu (mimo tego, że może to być prawda), to znak, że ktoś może podchodzić zbyt dosłownie do zasad Agile. Jeśli ktoś w zespole mówi, że zespół jest niezależną jednostką i on decyduje o wszystkim co się wewnątrz niego dzieje – pomimo tego, że ma rację, znaczy tyle, że ktoś zbyt dosłownie podchodzi do procesów i zaczyna je przedkładać ponad ludzi i interakcje z nimi. Jeśli ktoś w zespole mówi, nie będzie robił tego albo i tamtego bo Agile/Scrum/Kanban, to znak, że pora poluzować guzik koszuli, rozwiązać trochę krawat i wziąć głęboki wdech. Ktoś po prostu zaczyna bardzo dosłownie traktować zasady, mówiące m. in. by nie traktować ich zbyt dosłownie.

A co w przypadku kilku/kilkunastu zespołów pracujących używając tej metody? Jak je zgrać, żeby było dobrze? Po pierwsze – trzymać się tego, co Agile mówi (ale nie nazbyt dosłownie!), po drugie – testuj i reaguj na zmiany. Próbuj nowych rozwiązań. Jak nie działają, to je zmień, a jak działają to utrzymaj. Pamiętaj że tylko szaleniec będzie robić dokładnie to samo i oczekiwać różnych rezultatów.

Nikt nie ma dobrego rozwiązania takiego problemu. Waterfall nie jest doskonały, ale i z niego można czerpać pewne rozwiązania – na przykład planowanie i milestone. Mimo to, że nie jest to coś lubianego przez zespoły zwinne, w przypadku współpracy kilku grup, może zadziałać. A jak nie zadziała? To zmienić co nieco i zobaczyć jak to będzie działało w kolejnym tygodniu albo sprincie. “Reagować na zmiany ważniejsze niż sztywne trzymanie się planu”. To zawsze działało i zadziała w Twoim przypadku.

Gwarantuję. Agile nie jest doskonałą metodą pracy, ale lepszej – jeszcze nie wynaleziono. Dlatego próbuj i dziel się swoją wiedzą i doświadczeniem z członkami projektu. Może razem zbudujecie coś, co będzie działać świetnie i będzie możliwe do zastosowania w innych projektach jak i firmach podobnie jak to się stało z Agile?

Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z