W ostatnim czasie Agile zyskuje coraz większą popularność, szczególnie w większych organizacjach i ma całkiem niezły odbiór. Z pozoru wydaje się, że to dowód, iż się świetnie sprawdza. Ale czy faktycznie tak jest, albo inaczej w czym na pewno Agile się świetnie sprawdza. Ale najpierw skąd ten cały Agile i o co w nim chodzi.

• 

Manifest Agile

Obiegowa opinia mówi, że zaczęło się od manifestu Agile ogłoszonego przez kilkunastu developerów w 2001 podczas urlopu na nartach. Tu pewnie każdy przypomni sobie ile to fajnych teorii powstało podczas długich wieczorów niekoniecznie na urlopie, no ale nie każdy zrobił z tego manifest. A te chłopaki to zrobiły, ale…

To byli developerzy. To tak jakby murarz znając się na stawianiu ścian określał jak projektować budynki.

Przez kilkanaście lat swojej pracy zawodowej byłem bardzo blisko programowania i potwierdzam, programiści wolą pisać kod, uruchamiać, debuggować, wstawiać msgboxy, rzucać logami, pić kawę, nosić koszule flanelowe, narty też lubią. Ale nienawidzą czytać dokumentacji a już na pewno projektować rozwiązań, których nie da się od razu uruchomić i sprawdzić jak to działa. Co nie znaczy, że tego nie potrafią.

Wracając do manifestu, który jest dość ogólny i tak naprawdę niewiele ma wspólnego z dzisiejszymi metodykami zwinnymi, weźmy kilka przykładów:

http://agilemanifesto.org/iso/pl/manifesto.html

Autorzy manifestu bardziej cenią:

• Ludzi i interakcje od procesów i narzędzi
  • kto nie woli iść zapytać się sympatycznej księgowej jak wypełnić  druk zamiast czytać opis w instrukcji, kto w ogóle wie gdzie jest taka instrukcja.
• Działające oprogramowanie od szczegółowej dokumentacji
  • tak jak wspomniałem, programiści wolą uruchamiać, debugować niż zajmować się w jakikolwiek sposób dokumentacją.
• Współpracę z klientem od negocjacji umów
  • programista to na pewno, pytanie czy szef albo księgowy, też wolałby aby programiści w nieskończoność dłubali coś dla klienta zamisat realizować uzgodniony zakres.
• Reagowanie na zmiany od realizacji założonego planu
  • to normalne lepiej od razu pisać niż projektować, tworzyć architekturę kodu, klasy, templaty itp.. a jak nie będzie działać to się odpali debugger albo coś dorobi.

Takimi technikami na pewno można stworzyć na szybko sporo kodu, on nawet będzie działać, ale nie da tak się zbudować np.. Systemu operacyjnego lub czegokolwiek poważniejszego i złożonego.

Murarz bez projektu nie zbuduje wieżowca czy mostu.

Co gwarantuje Agile

A teraz zastanówmy się co na pewno daje Agile. Posłużę się popularnym rysunkiem krążącym po sieci i różnych mediach społecznościowych. Rysunek trochę uprasza sprawę i nieco zniekształca ale mimo to jest całkiem niezłą analogią. Na górze jest klasyczne podejście na dole Agile.

Pierwsze co się rzuca, to jesteśmy od razu zadowoleni. Fakt, Agile daje szybkie początkowe efekty. Tylko pierwsza wątpliwość, czy skoro celem jest samochód, to jak długo będziemy zadowoleni z deski? I drugi aspekt, nawet jeżeli zespół agilowy będzie zadowolony z pierwszego produktu, to jak to odbierze organizacja? No dobra, nie czepiajmy się.

Zadowolony zespół i pełen energii tworzy hulajnogę a następnie rower. To już trzeci produkt, każdy lepszy, brzmi dobrze. Tylko pamiętajmy, że te 3 produkty kosztowały czas i pieniądze. W tym samym czasie w metodyce klasycznej mielibyśmy już kawałek podwozia. Jeździć się nie da ale widać postęp i światełko w tunelu. Tylko jeżeli samochód ma umożliwić przemieszczanie się w trasie, to ten rower w żaden sposób nie wspiera początkowego celu a tylko zaspokaja radość tworzenia zespołu i Wykonawcy, który zutylizował już sporo mendejsów.

Czwarty etap to już motor, produkt którym można się już sprawnie przemieszczać ale zespół jest już zmęczony w końcu to kolejny duży sprint a praca w Agilu jest wyczerpująca. W metodyce klasycznej byśmy już wchodzili w końcowy etap a tu dopiero jesteśmy przed rozpoczęciem pracy nad finalnym produktem, bo przecież też trzeba wykonać wszystkie etapy jak w waterfallu. Pewnie poszłoby szybciej, bo wiemy już coś o kołach, silniku i zawieszeniu.

• 

I teraz pojawia się olbrzymi dylemat, przepaliliśmy sporo czasu i sporo kosztów. Produkt nie spełnia początkowych założeń, co prawda motor jeździ i jest OK ale robimy testy i nie da się zawieźć motorem 4 osób z Warszawy do Krakowa, a w zimie i gdy pada, to nawet dla jednej osoby nie jest łatwo. Czy wnioskujemy o kolejny budżet i zmęczony zespół rozpoczyna pracę od nowa nad prototypem samochodu, czy obwieścimy sukces? W końcu motor to jednak potężny postęp w stosunku do deski.

W tym samym czasie w metodzie klasycznej mielibyśmy samochód, pewnie miałby sporo błędów i niedoróbek, możliwe, że nie byłby zbyt wygodny a silnik spalał więcej paliwa niż zakładaliśmy ale jednak to byłby samochód, bo od samego początku miał być samochód.

Możemy powiedzieć, że Agile gwarantuje:

• Początkowe zadowolenie z efektów.
• Przy tym samym czasie i koszcie znacząco mniejszy zakres.

Magia Agile

Konkluzja może sprawiać wrażenie, że Agile ma głównie wady, tylko dlaczego tego nie widać? Bo to jest spojrzenie z wyższego poziomu z poziomu organizacji, tylko kto patrzy z poziomu organizacji? A gdy zejdziemy niżej na poziom konkretnych interesariuszy, to zaczyna to wyglądać zupełnie inaczej.

Magią Agile jest, że wszyscy interesariusze są zadowoleni.

• Biznes/Użytkownicy – Agile zmienia punkt odniesienia. Produkt końcowy jest oceniany względem pierwszego sprintu. Czyli motor jest kolosalnym postępem w porównaniu do deski. Do tego dochodzi przyjemne poczucie współtworzenia.
• Wykonawca – za wyprodukowanie motoru, roweru, hulajnogi i deski zarobił tyle co mógłby zarobić na samochodzie, który jeszcze miałby sporo wad. Czysty zysk.
• Szef IT – budżet się zgadza, terminy dotrzymane, Biznes nie narzeka, brak odpowiedzialności za niedostarczenie zakresu początkowego. Więc można zmniejszyć OPEX i zwolnić co lepszych PM’ów i Analityków. Same korzyści.

Korzyści z Agile

Na postawie własnych doświadczeń, oczywiście jest to bardzo subiektywne, gdybym miał podać dwie realne i namacalne korzyści z podejścia zwinnego, to byłoby:

Gdy brak celu:

• Gdynie wiadomo czego oczekujemy, dokąd zmierzamy, to bez wątpienia Agile do czegoś nas doprowadzi, choć zawsze można zastanowić się nad podejściem opisanym tu:
  „JAK ZACZĄĆ ABY DOBRZE SKOŃCZYĆ: CZYLI WYMAGANIA, CELE CZY STRATEGIA”
• Zdarza się, że nie ma innego wyjścia jak eksperyment, gdy trzeba coś „rozpoznać walką” lub stworzyć tzw. PoC’a.

Defraudacje finansowe

• Niestety takie potrzeby ciągle istnieją. Agile doskonale się sprawdza przy wyprowadzaniu pieniędzy z organizacji. Przy innych podejściach są produkty, są kryteria odbioru itp. Tu się można rozliczać ze nieokreślone sprinty.
• Za zrobienie huśtawki płaci się raz, za robienie huśtawki można płacić w nieskończoność.

Podsumowanie

A więc kiedy i komu potrzebny jest Agile?

• Komu – każdemu komu nie zależy na rezultatach, ale chce czuć się spełniony zawodowo.
• Kiedy – gdy organizacja nie wie czego chce lub nie posiada odpowiedniej dojrzałości informatycznej.

Nie kwestionuję, że Agilem da się coś wytwarzać i wdrażać, że można czasem uzyskać ciekawe efekty. Tak samo, jak idąc gdzie oczy poniosą, może dotrzeć do jakiegoś ciekawego miejsca. Agile może być nawet super w kreatywnym zespole, który ma tworzyć innowacje.

•