Wszystko zaczęło się w roku 2001 w ośrodku narciarskim w stanie Utah. Grupa krytyków tradycyjnego, kaskadowego podejścia do tworzenia oprogramowania sformułowała i podpisała tzw. manifest agile. Jego treść jest dzisiaj znana chyba wszystkim w informatyce, nie ma więc sensu go cytować.
Jakub Chabik
Choć sam manifest dystansuje się od rewolucyjnych metod („doceniamy to, co po prawej, ale wyżej cenimy to, co po lewej”), to podejście agile stało się przyczyną rewolucji. Początkowo tylko w rozwoju oprogramowania. Miejsce ciężkich i zbiurokratyzowanych modeli, takich jak PRINCE2 czy CMMI, zajęły podejście adaptacyjne. Praca w małych zespołach, bliska interakcja z klientem, dostarczanie realnej wartości biznesowej i reagowanie na zmiany – wszystko to stało się codziennością zespołów roboczych. W działach IT przedsiębiorstw – także polskich– zagościło podejście zwinne, zaś terminy takie jak „sprint”, „scrum master” albo „wykres spalania” zaczęły być rozumiane nawet przez menedżerów wysokiego szczebla.
Po 14 latach możemy dostrzec już skutki zmian, które przyniosło agile. Także poza działami informatyki. Tworzenie zwinnych, interdyscyplinarnych zespołów pracujących blisko klienta, z dużą podatnością na zmianę i koncentrujących się na dostarczaniu realnej wartości biznesowej zagościło także w marketingu, sprzedaży czy działalności operacyjnej. Takie zespoły nie myślą o IT jako o kimś, kto wykona system według zadanych wymagań opisanych w księdze. Oczekują, że informatyk będzie pełnił aktywną rolę w wypracowywaniu rozwiązania, przez cały czas wspierając je za pomocą makiety lub prototypu i współdecydując o ostatecznym kształcie produktu lub usługi.
Półtorej dekady to w technologiach informatycznych dostatecznie długo, aby poznać nie tylko zalety, ale i wady podejścia. Agile jest z nami dostatecznie długo, byśmy mogli poznać ciemne strony metodyk zwinnych i móc spokojnie zastanowić się, co można, a czego nie można nimi zrobić.
Największym zarzutem wobec agile jest to, że się nie skaluje. Metody sprawdzające się w małych, dobrze znających się zespołach pracujących nad przedsięwzięciami, których horyzont działania obejmuje kilka miesięcy, może rok, nie pasują do rozwiązań klasy enterprise. Tam, gdzie trzeba zbudować rozwiązanie, nad którym pracuje kilkadziesiąt albo setka osób, a cały cykl trwa dwa-trzy lata, zaś w jego skład wchodzi nie tylko wykonanie, ale i utrzymanie, agile osiąga swoją granicę.
Rozwiązania zwinne nie wspierają też bezpośrednio ładu – architektonicznego i regulacyjnego. Tworzone szybko, pod dyktando klienta, „grzeszą” architektoniczną lekkomyślnością, brakiem przewidywalności. Te elementy rozwiązania, których klient biznesowy nie dostrzega lub które nie przynoszą mu bezpośredniej korzyści (np. bezpieczeństwo, audytowalność albo stosowanie technologii mniej wygodnych w rozwoju, za to tańszych i prostszych w utrzymaniu), będą zawsze poświęcane na rzecz innych, które klient postrzega jako ważne i bezpośrednio przekładające się na korzyść biznesową.
Krytycy wykorzystują często podobieństwo słów agile (zwinny) i fragile (chwiejny) , aby uwydatnić największą słabość podejścia zwinnego. Przy niezdefiniowanym stanie końcowym projekty tego typu mają tendencję do niekończenia się. Po trzech sprintach przychodzi czwarty, po czwartym piąty, po piątym dziesiąty, a klient nadal mówi, że to jeszcze nie to, o co mu chodzi. Brak udokumentowanych wymagań, warunków brzegowych, dokumentacji i sformalizowanych decyzji, obraca się ostatecznie przeciw zespołowi, prowadząc do nieprzewidywalnego rezultatu i eksplozji kosztów.
Ale najpoważniejsza krytyka agile pochodzi chyba z obszaru kultury organizacji. Otóż zwinne podejście wymaga specyficznego środowiska, w którym jego zalety mogą uwydatnić się w pełni. Duże zaufanie między poszczególnymi członkami zespołu, jego zdolność do samoorganizacji, zrozumienie dziedziny, świadomość własnych ograniczeń oraz zdrowy rozsądek – to wszystko cechy, które albo w organizacji istnieją, albo nie. Agile „zaszczepione” na gruncie organizacji opartej o formalizmy, hierarchie i rozwlekłe ścieżki decyzyjne kończy się zderzeniem dwóch kultur i katastrofą. Tymczasem taki właśnie model organizacji dominuje w wielu przedsiębiorstwach, zwłaszcza w tych większych i zwłaszcza w Polsce.
Zanim zastanowimy się „co zamiast agile”, wykonajmy krok wstecz i spójrzmy na fundamenty informatyki. U podstaw komercyjnej inżynierii oprogramowania tkwią dwa założenia. Pierwsze, że pieniądze zarabia się na zaspokajaniu oczekiwań klienta. Drugie, że klient biznesowy (wewnętrzny) wie, jakie są te oczekiwania, zaś informatyk powinien je pozyskać, a potem zawrzeć w algorytmach i strukturach danych przedsiębiorstwa. Tradycyjne metody (kaskadowe) od zwinnych różnią się jedynie szczegółami: w tych pierwszych wymagania należy zawrzeć w formalnym dokumencie, w tym drugim – uzyskać w wyniku iteracyjnego dialogu i zapisać w postaci nieformalnej opowieści (user stories).
Problem w tym, że oba te założenia AD 2015 nie sprawdzają się. Po pierwsze, pieniędzy nie zarabia się już na zaspokajaniu oczekiwań klienta. Klient rzadko potrafi zwerbalizować, czego oczekuje; często oczekuje czegoś, czego jeszcze nie ma. Zdanie Henry’ego Forda, wypowiedziane na początku XX wieku („gdybym pytał klientów, czego oczekuję, powiedzieliby mi, że szybszych koni”) jest dziś aktualniejsze niż kiedykolwiek. Który z klientów powiedziałby, że nie chce aparatów z kliszami, tylko cyfrową matrycą? Czy powiedzieliby, że chcą telefonu z dotykowym ekranem, kolorowymi ikonkami, aplikacjami dostępnymi w sklepie, w którym właściwe telefonowanie jest funkcją marginalną? A jednak te dwa opisy pasują do jednego z największych sukcesów ostatnich dwóch dekad: cyfrowego aparatu fotograficznego i smartfona.
Odpowiedź może przynieść koncepcja lean startup, wywodząca się ze środowiska innowacyjnych przedsiębiorstw, a skodyfikowana przez Erica Riesa w książce o tym samym tytule. Można określić lean startup jako „szczupłą” organizację uczącą się. Esencją jest tzw. minimum viable product, czyli wersja narzędzia, która jeszcze nie jest gotowa, ale już dostatecznie dobra, by „przeżyć” na rynku. Klienci wykorzystując ją jednocześnie testują rozwiązanie i kształtują swoje oczekiwania. Lean startup w odróżnieniu od tradycyjnego agile, bardzo dużą wagę przywiązuje do pomiarów. Dane z rzeczywistego użycia narzędzia – a nie „wewnętrzni klienci” pod postacią działu biznesowego – mówią prawdę o zachowaniach klientów. Poprzez szybkie, adaptacyjne cykle zmian lean startup szuka tzw. pivota, czyli dobrego dopasowania między produktem a rynkiem, które zapewni przełom i wzrost.
Koncepcja lean startup poniekąd rehabilituje „twarde” artefakty zarządzania operacyjnego i zarządzania projektem: finanse, daty, terminy, normy. Na końcu klienci chcą jednak przewidywalnej, wysokiej jakości produktów lub usługi. A wiec, jeśli produktem jest aplikacja dostępna w chmurze, to chce, by była przyjazna w użyciu i miała wysoką dostępność. Jeśli oprogramowanie działające u klienta – chcą, by nie miało błędów, a te, które istnieją, były błyskawicznie naprawiane. Akceptując innowacyjny charakter całego produktu i zmienność otoczenia, każe zwrócić uwagę na stabilność dostarczanej usługi i poświęcić uwagę nie tylko zdobyciu klienta, ale także utrzymaniu go – akcentując outstanding customer experience w całym cyklu jego życia.
W realiach działów IT filozofia lean startup może różnie się materializować. W firmie budowlanej, wydobywczej czy turystycznej nikt nie oczekuje od CIO kształtowania nowych produktów. Oczekuje natomiast – na co bardzo wyraźnie wskazują np. ubiegłoroczne badania Gartnera – aktywnego oferowania nowych technologii dla usprawniania pracy firmy i ulepszania jej działania. Zamiast więc czekać, aż ktoś z biznesu przyjdzie i zapyta „czytałem właśnie o nowym zastosowaniu big data, chciałbym wdrożyć to narzędzie” albo „jak możemy wykorzystać biometrię”, lepiej aktywnie zaproponować rozwiązania – najlepiej w formie działającego prototypu, który będzie w krótkich, iteracyjnych cyklach i w oparciu o „żywe” dane z rynku doskonalony, aż do uzyskania pivota.
Dzisiaj takie pytania są chyba trochę nie na czasie. A więc – tak, oczywiście być, pytanie raczej „kiedy”, „do jakiego stopnia” i „w jakiej klasie projektów”. Zbyt daleko posunięta „lekkość” może przekształcić się w, par excellence, „lekkie obyczaje”, czyli lekceważenie dla spójności i zdrowego rozsądku oraz chaos.
Koncepcja lean startup wydaje się być pozbawiona tych wad; jednoczenie wydaje się lepiej „skrojona” do czasów dużej niepewności i zmienności, a także lepiej zaspokajać współczesną charakterystykę rynku – gdzie sławę i pieniądze zdobywa się nie tyle wychodząc naprzeciw uświadomionym i nazwanym oczekiwaniom klientów, ile wyprzedzając je i stymulując. I z takim przesłaniem należy dziś nieść posłanie „zwinności” pomiędzy biznes.
22 kwietnia 2015 odbędzie się seminarium CIONET Polska „Agile in Business”. Jeśli już jesteś zarejestrowanym członkiem CIONET wejdź na stronę eventu na platformie cionet.com i potwierdź swój udział http://www.cionet.com/events/88847/. Uczestnictwo jest bezpłatne dla członków CIONET!
