Quo vadis, Agile? Zwinne wytwarzanie oprogramowania

Wytwarzanie wielu produktów (nie tylko oprogramowania) charakteryzuje się dużą niepewnością. Tym artykułem otwieramy serię związaną z szeroko rozumianym Agile – omówimy w nim pokrótce przeszłość i teraźniejszość Agile na świecie, a także spróbujemy spojrzeć dalej – w przyszłość. Szykujcie zatem kryształowe kule i zapraszam do lektury!

Opowiem Wam historię… Stosunkowo nie tak dawno temu, ludzie spojrzeli w lustro i zadali sobie pytanie: czego chcemy i dokąd zmierzamy? Tradycyjne podejście (mające swoje korzenie w początkach ery industrialnej) do wytwarzania oprogramowania sprawdzało się w pewnych przypadkach, na pewno nie zawsze. Opiera się ono poniekąd na systemie masowej produkcji: produkt jechał na taśmie, gdzie następowały po sobie kolejne etapy produkcji…

…Wymagania, analiza, wycena, produkcja, testy, wdrożenie…

Miło, jeśli wszystko przebiegało zgodnie z planem – analiza była kompletna i przewidywała wszystkie ryzyka. Wycena to strzał w dziesiątkę, produkcja przebiegała bez zarzutu, nikt w projekcie nie chorował i nie brał urlopów, testy przechodziły na zielono, klienci byli wniebowzięci z dostarczonego rozwiązania i nie zgłaszali żadnych uwag, a wdrożenie było jak bułka z masłem.

Tyle, że takie projekty zdarzały i nadal zdarzają się niezbyt często, w szczególności jeśli mówimy o dużych produktach, gdyż planowanie w szerokim horyzoncie czasowym ma niską szansę powodzenia. Według Standish Group Chaos Report 2015, projekty na czas, w budżecie i osiągające cel (nazywane w raporcie jako Successful Chaos Resolution), to jedynie około 30% wszystkich projektów, a ryzyko ich niepowodzenia rośnie wraz z ich wielkością i sposobem ich realizacji.

Widać pewien trend, prawda?

Czym jest Agile?

Często, jeśli mieliśmy do czynienia z dużym produktem, ten zanim wyszedł na rynek był już przestarzały (na przykład program promów kosmicznych NASA, który wszedł do produkcji w latach ’80 bazował na rozwiązaniach z lat ’60 – „na szczęście” nie był komercyjny) lub nie spełniał wymagań klientów.

Pamiętacie Pana Spinacza z pakietu MS Office? To idealny przykład na to, jak brak konsultacji i reagowania na nastroje rynku może sprawić, że oddamy użytkownikom coś, co nie tylko nie spełni ich oczekiwań – ale czasami wywoła nawet irytację.

Problem trwał w latach ’60, ’70 i na początku ’80. W pewnym stopniu istnieje nawet do dziś. Ale przelała się czara goryczy.

Zainspirowani tezami Williama Edwarda Deminga dotyczącymi continuous improvement (stałej poprawy), członkowie społeczności deweloperskich w latach ’80 XX wieku dostrzegli potrzebę zmiany podejścia, które poprawiłoby sposób, w jaki podchodzimy do wytwarzania oprogramowania z tradycyjnego, które zyskało miano waterfall (czyli kaskadowego modelu) do modelu iteracyjno-przyrostowego, opartego na stałym dostarczaniu wartości biznesowej. W końcu Carpaccio z buraka jest przyjemniejsze w spożyciu niż cały burak.

W celu poprawy jakości wytwarzania produktów i zwiększenia decyzyjności, już w trakcie trwania procesów wytwórczych opracowano podejścia oparte na cyklach wytwarzania oprogramowania, zamiast budowania całego oprogramowania jako jeden wielki blok. Najwięksi przedstawiciele iteracyjnych metodyk tamtych czasów (to jest przed rokiem 1990) to m.in. Evolutionary Project Management, Adaptive Programming oraz Spiral Model. 

Potem nadciągnęła złota ‘era’ Agile. W latach ’90 powstał Scrum, Rapid Application Development, Extreme Programming.

Wciąż jednak dominowało podejście waterfall. Zaczęło się to dopiero zmieniać na początku XXI wieku (czyli właściwie stosunkowo niedawno), a to za sprawą Agile Manifesto (Manifestu Zwinności), który powstał w 2001 roku.

Treść tego manifestu można sprowadzić do kilku linijek (nie żeby sam manifest był opasłym dokumentem):

„Zaczęliśmy bardziej cenić:
Ludzi i interakcje od procesów i narzędzi;
Działające oprogramowanie od szczegółowej dokumentacji;
Współpracę z klientem od negocjacji umów;
Reagowanie na zmiany od realizacji założonego planu;”

Ja również po przeczytaniu tego po raz pierwszy pomyślałem, że Agile to chyba synonim chaosu. Ale na szczęście twórcy dodali jedno, zamykające (wręcz uspokajające) zdanie:

„Oznacza to, że elementy wypisane po prawej stronie są wartościowe, ale większą wartość mają dla nas te, które wypisano po lewej.”

Wiele osób, nawet dzisiaj, ignoruje przekaz zawarty w tym ostatnim zdaniu, który podkreśla fakt, że nie zaleca się w żadnym wypadku porzucenia procesów, narzędzi, dokumentacji, umów, planu. Te elementy nadal są istotne w procesie wytwórczym, ale w środowisku zwinnym, ciężar jest przeniesiony na lewą stronę.

Oprócz tego, Agile Manifesto zawiera 12 pryncypiów, które przyświecają tej filozofii (warto to podkreślić – filozofii, a nie metodyce!):

Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.

Bądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnienia klientowi konkurencyjności.

Dostarczajcie funkcjonujące oprogramowanie często, w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej, tym lepiej.

Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu.

Twórzcie projekty wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że wykonają powierzone zadanie.

Najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego jest rozmowa twarzą w twarz.

Działające oprogramowanie jest podstawową miarą postępu.

Procesy zwinne umożliwiają zrównoważony rozwój. Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy.

Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność.

Prostota – sztuka minimalizowania ilości koniecznej pracy – jest kluczowa.

Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów.

W regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków.

Ot, cała filozofia. Tyle trzeba, żeby wytwarzać produkty zwinnie. Tylko tyle i aż tyle.

Chciałbym w tym miejscu jeszcze raz to podkreślić, gdyż w dziedzinie wytwarzania oprogramowania powstał pewien dosyć niebezpieczny mit, jakoby implementacja (nie wdrożenie!) Scrum, tablic kanbanowych, User Stories lub praktyk Extreme Programming miałoby sprawić, że będziemy zwinni.

O ile sprawienie, że zespoły będą pracować w Scrum może pomóc, o tyle nie osiągniemy pełnej korzyści ze zwinnej transformacji tylko dzięki narzędziom. Transformacja zwinna to przede wszystkim zaadaptowanie nowej filozofii, a więc także zmiana myślenia, podejścia i sposobu działania biznesu – ta część jest najtrudniejsza.

Co mi daje ten Agile?

Ale co nam właściwie daje zwinne wytwarzanie produktu? Można wymienić kilka głównych punktów z biznesowego punktu widzenia, przede wszystkim:

• Zdolność do adaptacji (adaptibility) – w zwinnym modelu software budowany jest iteracyjnie, a więc możemy zmieniać wymagania w trakcie trwania procesu wytwórczego (w ramach określonych na początku granic).
• Widoczność (visibility) – biznes widzi postęp prac dzięki warsztatom i spotkaniom, które zwykle odbywają się znacznie częściej, niż w kaskadowym modelu (np. w Scrum byłoby to raz na Sprint, a więc w interwałach od tygodnia do miesiąca). Prezentowana jest konkretna wartość dobudowana w danej iteracji do produktu.
• Niższe ryzyko (risk) – im dłużej budujemy produkt, tym lepiej go rozumiemy i możemy dostosować rozwiązania do potrzeb technicznych lub biznesowych. Odrzucane jest ryzyko modelu waterfall, o którym wspomniałem na początku tego artykułu – ograniczamy ryzyko, że produkt końcowy nie będzie spełniał oczekiwań odbiorców końcowych poprzez stałe prototypowanie, releasowanie i zbieranie feedbacku od użytkowników.
• Wartość biznesowa (business value) – iteracyjno-przyrostowy charakter frameworków, metod i metodyk opartych o Agile pozwala na częstsze i wcześniejsze wypuszczanie przyrostu produktu, dzięki czemu pierwsze zyski z produktu osiągamy stosunkowo wcześnie, biorąc pod uwagę to, jak działo się to w modelu kaskadowym – czyli na końcu “taśmy produkcyjnej”.

Jeśli chodzi o stronę inżynierską, na pewno będzie to m.in.:

• Większa swoboda działania – nikt nie decyduje za programistów JAK coś ma być zrobione. Zespołom przekazywane są tylko ogólne wskazówki dotyczące działania lub designu, czyli CO jest do osiągnięcia, ale nie mechanizmów. Daje to korzyść obu stronom – programiści mogą znaleźć łatwiejsze rozwiązanie pewnego problemu, więc biznes będzie dysponował większym budżetem. Na pizzę na przykład.
• Preferowanie kontaktu bezpośredniego – osoba z którą programista rozmawia o ostatecznych rozwiązaniach ma kompetencje decyzyjne. Jest specjalistą w swojej dziedzinie. Często osoba taka jest delegowana od klienta. Można zatem wyciągnąć logiczny wniosek, że poprawek będzie znacznie mniej niż w przypadku, gdy o wymaganiach klienta rozmawiamy z przedstawicielem swojej firmy, będącym proxy. Bawiliście się w dzieciństwie w głuchy telefon?
• Wspomaga wymianę wiedzy – programiści dzięki niektórym technikom, które zostały przedstawione np. w Extreme Programming mogą zdobywać wiedzę szybciej, co po pierwsze, zwiększa ich wartość na rynku pracy, a po drugie – wydaje mi się, że jeśli ktoś skończył studia związane z programowaniem to musi to lubić, gdyż nie należą do najłatwiejszych. Sam rozwój dla wielu z programistów których znam jest wartością samą w sobie.

Najnowsze trendy

Przez niemal 2 dekady istnienia Agile Manifesto powstało dużo różnych podejść do wytwarzania oprogramowania. Bardzo dużo. Nie jest to moim zdaniem nic złego – każda organizacja mierzy się w różnym stopniu z różnymi wyzwaniami, na różnych rynkach i w różnych kulturach.

Do rozwiązywania odpowiednich problemów trzeba użyć odpowiednich narzędzi, żeby nie okazało się, że wbijamy gwoździe śrubokrętem. Dzisiaj na szczęście mamy do wyboru cały wachlarz podejść zwinnych – wystarczy sięgnąć do skrzyni z narzędziami i wybrać odpowiednie z nich.

Jakie są zatem pomysły na Agile?

Zajrzyjmy zatem do kryształowej kuli. Co będzie trendy? Co traci, a co zyskuje na popularności?

Jednym z badań przedstawiających popularność różnych podejść zwinnych jest coroczny raport tworzony przez VersionOne i CollabNet: State Of Agile. Dane o popularności różnych zwinnych podejść z edycji z 2018, 2017, 2016, 2015 i 2013 roku przeniosłem na jeden diagram.

Diagram przedstawia tylko te z frameworków (np. Scrum), metod (np. kanban) i metodyk (np. DSDM Atern), które są lub były najbardziej popularne. Widać na nim głównie niepodzielną dominację “czystego” Scrum (od 2013 jest to stale 56%±2p.p.).

Świadczy to o pewnej stabilności, jeśli chodzi o narzędzia, po które firmy najchętniej sięgają, by wspomóc zwinną transformację – na podstawie powyższych danych należy stwierdzić, że prym w najbliższej (i może nawet nieco odleglejszej) przyszłości wiódł będzie Scrum.

Należy jednak pamiętać o tym, że Agile to pewna filozofia, sposób myślenia, podejście do organizacji pracy i współpracy. Zanim sięgniemy po konkretne narzędzia koniecznym jest zrozumienie Agile i jego założeń, pochodzenia i przeznaczenia. Nie mając tych podstaw nawet najlepsze narzędzia będą niewłaściwie wykorzystywane i nie przyniosą oczekiwanego efektu. Z kolei ugruntowana wiedza pozwoli na świadomy ich wybór, często zaczynając od najprostszych i właściwie dobranych do sytuacji.

Zmierzam do tego, że nie trendy będą sterowały Agile a my wszyscy, którzy żyjemy z nim na co dzień. W jaki sposób? Korzystając z dostępnych narzędzi, wymyślając nowe, dostosowując je do potrzeb tak by były wygodne i efektywne, albo bezmyślnie sięgając po “gotowce” po krótkim czasie stwierdzając, że nie działają… A może działają, ale tylko we właściwych rękach? Może ten kto narzeka nie umie ich używać? To jest sedno wielu nieudanych implementacji Agile, czyli transformacji zwinnych w organizacjach. Nie zaczynajmy więc od narzędzi, poznajmy z czym się mierzymy, jakie problemy chcemy rozwiązać, nauczmy się Agile i dobierzmy właściwe rozwiązania. To klucz do sukcesu!

Warto podkreślić jeszcze raz, że Agile to nie tylko Scrum: Agile ukazuje się w wielu barwach i odcieniach, co w rękach uzdolnionego i doświadczonego managera, Scrum Mastera lub [tutaj wstaw nazwę swojej pozycji w organizacji] pozwala zaproponować odpowiednie narzędzia do rozwiązania realnych problemów.

Po które z narzędzi sięgniesz Ty? Może już z któregoś z nich korzystasz? Może z kilku?

Zachęcam do przeprowadzania eksperymentów w Waszej pracy, mierzenia wyników i wyciągania wniosków. Być może wśród czytelników znajduje się nowy Taiichi Ōno? Może za kilka lat właśnie Ty napiszesz artykuł, który na zawsze zmieni sposób w jaki wykonujemy swoją pracę i który sprawi, że będziemy bardziej efektywni i zadowoleni?

Tego nam wszystkim życzę!