Skąd tyle narzekania na "metodykę agile"?

Jednym w najczęstszych powodów do marudzenia wśród programistów jest wybrana w pracy metodyka rozwoju oprogramowania. Nie jest to problem u każdego – istnieją rzecz jasna ludzie zakochani w "korpo", którzy uznają pracę w (dowolnym) kombinacie informatycznym za wyróżnienie, nierzadko o skali nieprzystającej do realiów. Częściej jednak można się spotkać ze zdecydowanie bardziej obojętną opinią na temat pracy w korporacjach. A wraz z nią – silnymi opiniami o "procesie". Mowa tu najczęściej o zastrzeżeniach wobec wierności wdrożenia metodyki "agile", a przypadku wzorcowych wdrożeń, o inherentnej nieskuteczności tejże.

Jak to zwykle bywa z marudzeniem, nie zawsze idzie ono w parze z sugestiami lepszych rozwiązań. Uniwersalnych alternatyw oczywiście nie brakuje, ale ich mnogość sugeruje że mamy do czynienia z tym samym problemem, co z książkami o zarządzaniu. Mianowicie gdyby istniała jedna dobra metoda zarządzania, księgarnie nie potrzebowałyby dedykowanych ścian na regały z publikacjami tylko o tym. Zresztą, obranie właściwej metodyki developmentu jest sytuacyjne i zależy od projektu i (niestety) od ludzi.

Skądś jednak wzięło się to niefortunne branżowe powiedzenie "We do agile" is the most common lie in IT. Wiąże się ono z częstym poglądem, że agile obiecuje wiele zachwycających rozwiązań, posługując się przy okazji całkiem racjonalnymi argumentami, ale jest dziwnie podatne na nieprawidłową implementację. Niektórzy żartują nawet, że pod tym względem agile jest jak komunizm: kolejne jego wdrożenie się nie powiodło, ale to nie szkodzi, bo to najwyraźniej nie był prawdziwy agile, więc wszystko w porządku.

Trudno jednak przyjąć do wiadomości, że spora część branży IT się myli, wyrzuca pieniądze przez okno i pracuje w nieprawidłowy sposób. Jednak lata mijają, a krytyka agile'a nie ustaje, czas więc przyjrzeć się temu zjawisku z kilku punktów widzenia. Zacznijmy od podstaw, czyli od Manifestu Agile.

Podstawą merytoryczną metodyki agile jest dwanaście punktów, w tym kilka dziwnie ogólnych, i pięć haseł przewodnich, opartych o wieloletnie doświadczenie w zespołowym rozwoju oprogramowania. Skupmy się zatem na głównych punktach i spróbujmy zdiagnozować, dlaczego tak wielu programistów boli od nich głowa i nawet ich autor zaleca ostrożność w ich stosowaniu.

• zadowolenie klienta osiągane przez szybkie dostarczenie wartościowego produktu (MVP + inkrementacje)
• wymagania mogą się zmieniać podczas trwania prac (w przeciwieństwie do modelu kaskadowego, z wydzieloną fazą planowania)
• ciągle dostarczanie działających, nowych wersji, w okresie kilkutygodniowym
• współpraca programistów z biznesem (celem monitorowania spójności celu)
• projekt oddany pod kierownictwo programistów obdarzonych zaufaniem (innymi słowy, wierzymy że programiści wiedzą co robią)
• kontakt osobisty jest najlepszą formą komunikacji i wymiany wiedzy
• miarą postepu jest działające oprogramowanie (lepsze sprawne minimum niż doskonale zaprojektowana beta)
• planowanie pod kątem zapewnienia stałej prędkości rozwoju
• ciągłe zwracanie uwagi na dobry design
• minimalizacja zbioru zadań do wykonania poprzez forsowanie prostoty
• najlepsza architektura i design pochodzą z samo-organizujących się zespołów
• zespół regularnie pracuje nad ulepszeniem swojego procesu

Jedną z pierwszych świetlanych obietnic agile jest odrzucenie monolitycznego, "ciężkiego" procesu, w którym wszystko jest drobiazgowo planowane i projektowane, a następnie – niemal jak odlane z formy – z planów powstaje oprogramowanie. Ten klasyczny model ma być niemożliwy do pogodzenia ze zmieniającymi się wymaganiami, pochodzącymi nie tylko od klienta, ale i od biznesu - dzisiejszy krajobraz software'owy zmienia się bardzo szybko. Ponadto, na każdą firmę oferującą powolny proces o wysokiej jakości przypada kilka innych, obiecujących efekty szybciej i taniej. "A jeść trzeba!"

Dlatego agile nie stosuje etapu wielodniowego siedzenia nad detaliczną dokumentacją techniczną, zamiast tego tworząc jedynie zarys finalnej implementacji, wstępne definicje protokołów i interfejsów (z możliwością nanoszenia zmian) oraz podział na wiele zatomizowanych, krótkich zadań prowadzących do celu "z perspektywy użytkownika" (user stories). Zamysłem tego podejścia miało być wykluczenie procesu tworzenia dokumentacji jako składania pięknie wydanej książki, zamiast tego "drukując streszczenie na papierze brudnopisowym" – definiując cele i pozostawiając większą swobodę implementacji samo-organizującym się zespołom.

Niewątpliwie zdarzają się sytuacje, w której powyższa maksyma metodyki agile jest realizowana właśnie w taki sposób. Często jednak dzieje się inaczej. Najbardziej rażącym wariantem owego podejścia jest stworzenie dokumentacji na slajdach PowerPointa, rękami starszego programisty natychmiast potem oddelegowanego do innego projektu. Nie trzeba jednak sięgać po scenariusze rodem z horroru żeby zidentyfikować potencjalne kłopoty ze zbyt liberalnym podejściem do dokumentacji.

Widać to zwłaszcza w projektach utrzymaniowych: brak dokumentacji utrudnia implementację usprawnień i zwiększa ryzyko wprowadzenia niekompatybilności, ponieważ "interfejs" udokumentowano w sposób nieformalny, w praktyce polegając na ludziach, a nie na dokumentach (zwiększając słynny "bus factor"). Trudniejsze staje się również planowanie: w jaki sposób poprawnie podzielić na zadania i wyestymować zmianę czegoś, co dla wielu osób w zespole jest czarną magią bez manuala, z nieaktualnymi komentarzami spisanymi łamaną angielszczyzną?

Oczywiście, tutaj często dochodzą do głosu obrońcy metodyki zwinnej, twierdzący, że doprowadzenie do sytuacji, w której dokumentacja jest bezwartościowa to "nie był prawdziwy socjalizm" i stanowi przykład błędnego stosowania metodyki. Zapewne. Z drugiej strony jednak dlaczego problem ten jest tak częsty i dlaczego tak trudno się potem z niego wspiąć na powierzchnię?

Marna dokumentacja nie jest problemem dlatego, że brakuje eleganckich wykresów UML przez co nie można być podręcznikowo poprawnym. Stanowi ona problem, bo pozbawia prostej drogi do nabrania szerszej perspektywy w projekcie. Z tego powodu poprawne zatomizowanie zadań i wycena ich złożoności może się nie powieść. W efekcie, duże zadania, na przykład obiektywnie niezbędne przeprojektowanie na większą skalę, nie są podejmowane w ogóle. Zamiast tego idzie się w kierunku "zaliczenia" góry mniejszych zadań, mniej od siebie zależnych. Zresztą, "to się przecież nie zmieści w tym sprincie!".

Poprawne zidentyfikowanie potrzebnej pracy, sformułowanie głównych celów i podział na zadania to obowiązki architekta projektu. Zakładając, że architekt nie został obdarzony przez los kiepsko udokumentowanym projektem o niejasnych celach, niniejszy podział może przebiec w sposób szybki i bezbolesny. Należy jednak pamiętać o tym, że zdefiniowane zadania są potem implementowane przez zespół, niekoniecznie posiadający taki sam stan wiedzy, co architekt (zarówno w kwestii produktu jak i umiejętności ściśle technicznych). Gdy projekt jest górą kodu opisaną PowerPointem, łataną dziesiątkami mniejszych zadań, żaden epic nie zostanie zaimplementowany koherentnie, zwłaszcza gdy ma się to odbywać niedoświadczonymi rękami. Plan jest bowiem rozpisany dla ludzi, którzy nie istnieją.

Łatwość zderzenia z tym problemem sprawia, że trudno brać poważnie jeden z punktów Manifestu, jakim jest stwierdzenie "najlepsza architektura i projekt pochodzą z samo-organizujących się zespołów". Naturalnie, chodzi tu o to, że zespół mający czas (i nerwy) na wewnętrzną dyskusję, nieobarczony zewnętrznym, niekonsultowanym projektem, zaproponuje najbardziej eleganckie rozwiązanie samodzielnie, ponieważ jest najbliżej problemu. To jednak zakłada, że zespół wie co robi. A jeżeli nie wie, to może się prędko nauczyć, np. z dokumentacji i wytycznych.

Manifest Agile mówi o ciągłej współpracy z klientem. Oprogramowanie ma być dostarczane wcześnie i w sposób ciągły, małymi "inkrementami", konsultowanymi na bieżąco (punkt 1. M.A.). Wskutek owych rozmów konieczne może się okazać zmodyfikowanie wymagań (punkt 2. M.A.), co być może czasem pojawia się późno, ale w modelu wodospadowym byłoby niemożliwe i skutkowałoby obniżeniem satysfakcji klienta. Produkt ma też uniknąć losu nadmiernego przeprojektowania, poprzez włączenie biznesu w rozmowy, celem ustawicznego przypominania, po co tak naprawdę produkt w ogóle powstaje.

Pięknie. Tylko, że nie wszystko jest rozwijane w ciągłym kontakcie z klientem, a mimo to stosuje się agile. Oprogramowanie dla samolotów, serwerowe systemy operacyjne i API dla aplikacji Web to przykłady produktów, które nie są "sprzedawane w pudełku". Kontakt z klientem może być momentami wręcz szkodliwy. Często klientami są jednak... inne zespoły. W teorii, nie powinno to być problemem ze względu na zbieżność celu. W praktyce jednak wprowadza to konflikt interesów: różne, współzależne zespoły mogą mieć rozbieżne definicje tego, co tak naprawdę oznacza "działające oprogramowanie" (punkt 7 M.A.).

Dobra rzecz, która z tego wynika, to niejako przymus zaimplementowania procesu ciągłej integracji (punkt 3 M.A.) i ciągłego dostarczania (CI/CD). Niemniej, jest on dopiero szansą na pozytywną zmianę, a nie jej gwarancją. Bardzo łatwo zmarnować wysiłek włożony w implementację CI, stosując błędną politykę rozgałęzień i nieadekwatne pokrycie testami automatycznymi. Pamiętajmy zatem, że wprowadzenie ciągłej integracji nie skazuje nas na sukces.

Narzekanie na agile można sprowadzić do jednej rzeczy: głębokiego przekonania, że proces przeszkadza w pracy. Że pracę należało zdefiniować, podzielić i wykonać w zupełnie inny sposób, a mechanizmy agile'owe mające na celu autokorektę w niczym nie pomagają. To zuchwałe przekonanie nie musi być jednak dowodem na słabość procesu. Źródeł frustracji może być bardzo wiele, a proces bywa pierwszym podejrzanym, ponieważ nie może się głośno bronić.

Zinstytucjonalizowany proces wytwarzania oprogramowania jest niezgodny z tym, jak działa ludzka wyobraźnia. Zrywy kreatywności i niepohamowana wola optymalizacji i przeprojektowania nie są dobrym sposobem finalizowania projektów w celach zarobkowych. Bliżej im do hobbystycznej improwizacji. Są bez wątpienia ciekawą ścieżką samodoskonalenia, ale zazwyczaj kończą się, poza poszerzeniem wiedzy, kolejnym niedokończonym projektem "do szuflady". Dlatego warto skonfrontować swoje przekonanie "ja zrobiłbym to zupełnie inaczej!" z rzeczywistymi celami projektu. Podpowiedź: samodoskonalenie do nich zazwyczaj nie należy. Czasem trudno się z tym faktem pogodzić niektórym młodym programistom.

Być może nabranie innej perspektywy pozwoli ocenić, że z procesem wcale nie jest tak źle? Zresztą, obiektywna ocena jest tu niezwykle trudna. Brałem udział w projekcie, który uznawałem za kompletny chaos, będąc w tej opinii zupełnie odosobnionym. Podobnie zdarzało mi się słuchać ciągłego narzekania na proces w innym projekcie, rzekomo niezgodnym z agile, i w którym problemy brały się z zupełnie innych źródeł. Metodyka zwinna nie jest lekiem na całe zło, nie jest jednak wynalazkiem diabła. Faktycznie ma tendencje do błędnych wdrożeń i mimo, że są one winą wdrażających, powszechność problemów budzi poważne wątpliwości.

Ponieważ jednak agile stał się dziś modą, może warto czasem zabawić się w "No true Scotsman" i sprawdzić, czy szwankujący proces jest "prawdziwym agilem". Na przykład:

• Czy dostarczona w sprincie deweloperska wersja produktu została wydana bo zrealizowano cele sprintu i zaliczono ścieżkę testów, czy dlatego że... skończył się sprint (i obniżono jakość na potrzeby kalendarza)?
• Jeżeli wprowadzono późne zmiany w projekcie, to czy problemem były późne zmiany, czy kiepskie określenie tego jakie zmiany są rzeczywiście oczekiwane?
• Czy ciągłe wdrażanie jest czymś więcej, niż tylko \ciągłe merge'owanie? Innymi słowy: jeżeli produkt nie działa, czy CI ma moc sprawczą we wstrzymywaniu procesu?
• Sprzedawcy, menedżerowie i programiści zawsze będą mieli sprzeczne interesy. Czy pod pozorem \kontaktu z biznesem\ nie wprowadza się po prostu strumienia nowych wymagań?
• Jeżeli w zespole znajdują się charyzmatyczne, utalentowane lub w inny sposób szczególne jednostki – czy ich wpływ na projekt na pewno jest inspiracją dla innych? Czy poprawnie przekazują swoją wiedzę? Czy może są niezastąpionymi chodzącymi encyklopediami, bez których reszta zespołu nie może pracować?
• Czy komunikacja w zespole, mająca na celu zastąpienie monolitycznej dokumentacji, na pewno działa? Nie można usunąć dokumentacji a zamiast niej polegać na kapryśnym interfejsie niekomunikatywnych, wiecznie nieobecnych ekspertów. Nie da się efektywnie komunikować z zespołem oddalonym o pięć stref czasowych. I nie wolno zakładać, że każdemu przekazywanie wiedzy przychodzi z taką samą łatwością.
• Czy metody pomiaru jakości są odporne na presję harmonogramu/szefostwa?
• Czy na pewno wszyscy rozumieją zaplanowane zadania? Czy jesteśmy w stanie stwierdzić, że są poprawnie zatomizowane? Nie kryją się wśród nich żadne kluczowe, skokowe przełomy, otoczone zbiorem malutkich zadań? Może warto jednak zrobić dodatkowe spotkanie, na którym nikt nie będzie się bał o to zapytać?
• Czy istnieje przestrzeń (czas, nastroje...) na dyskusje na temat designu? Jak często podejmowana jest decyzja \robimy tak, bo na lepszą implementację nie ma czasu? MVP nie oznacza fuszerki!
• Czy frazes o \samo-organizującym się zespole\ nie jest przypadkiem wymówką maskującą kiepskie przywództwo lub jego całkowity brak? Na czym polega samo-organizacja w zespole?
• Czy wolno narzekać? W jaki sposób identyfikuje się słabości, czy jest wola o nich rozmawiać i w jaki sposób bada się skuteczność wdrożonych rozwiązań?

Lubimy twierdzić, że jesteśmy mądrzejsi od procesu. W przypadku agile'a i częstych problemów z nim, przekonanie to wydaje się tym bardziej atrakcyjne. Często jednak problem nie leży w procesie, a w ludziach. Wreszcie, może też chodzić o nas samych. Nie każdy firmowy projekt informatyczny musi być pasjonującą, porywającą przygodą, w która pozwala w pełni realizować potencjał i zasoby kreatywności programistów. Na szczęście świat to nie tylko agile. Istnieje więcej okoliczności i sposobów podejmowania wyzwań, również na polu zawodowym. O jednym z nich już wkrótce.