Czy wielki kontenerowiec może być zwrotny niczym żaglówka? Jest to możliwe – dzięki tak popularnym dziś wśród liderów rynku zwinnym metodykom. Te, choć wydają się nowym rozdaniem, są powrotem do rozwiązań z przeszłości. Sprawdzonych i racjonalnych.
Pojedynek na miarę „Gry o tron”
Nikt nie ma licencji na pasmo zwycięstw, nawet największe biznesowe potęgi. Widzieliśmy niejednokrotnie, jak potężne firmy przegrywają w wyścigu z małymi start‑upami, bo ich zwinność okazywała się ważniejsza od siły giganta. Kilkuosobowe, zgrane kolektywy, nieskrępowane biurokracją i powolnością procesów decyzyjnych w hierarchicznych strukturach korporacyjnych, były zdolne szybciej reagować na zmieniające się wyzwania i szanse, w efekcie płynnie pokonywały każdy kolejny zakręt na drodze do mety. To konfrontacja wręcz archetypiczna: Goliat kontra Dawid czy też ciężkozbrojny, lecz powolny grecki hoplita kontra lekkozbrojny, miotający oszczepami tracki peltasta. W popularnej sadze „Gra o tron” dokładnie ten układ sił obrazuje słynna scena pojedynku potężnego Gregora Clegane’a zwanego Górą, giganta w ciężkiej zbroi, ze szczupłym, szybkim i zwinnym Oberynem Martellem – Czerwoną Żmiją.
Wielkość i siła nie zawsze wygrywa ze zwinnością i szybkością. Wszyscy się jednak zgodzimy, że najlepiej byłoby być i wielkim, i zwinnym. Okrętem, który mimo dużej wyporności potrafi lawirować między rafami ze zwinnością niewielkiej żaglówki. Czy to jest w ogóle możliwe? Tak. Właśnie temu służą zręczne metodyki (ang. agile).
Wątpliwy przepis na sukces
Do niedawna w świecie IT zdecydowanie dominował tak zwany kaskadowy (ang. waterfall) model realizacji zadań, w którym poszczególne etapy pracy realizowano krok po kroku. Jeśli trzeba było napisać dla klienta oprogramowanie, najpierw należało przejść przez żmudne i czasochłonne etapy ustalania wszystkich życzeń klienta, rozpoznawania wymagań funkcjonalnych i technicznych, pisania architektury, implementacji, testów etc., etc. Trwało to wszystko, w zależności od skali wyzwania, miesiące lub lata. W tym dość długim przecież czasie wymagania klienta nierzadko się zmieniały, co oznaczało przekreślenie olbrzymiego dokonanego już wysiłku.
Wiążące ręce procedury i utrudniająca zmiany inercja, długi czas realizacji zadań, wysokie koszty błędów i spore prawdopodobieństwo, że na koniec dostarczymy niepotrzebny już produkt – to wszystko nie wygląda jak przepis na sukces, prawda?
Na szczęście ktoś przez to wszystko przechodził już wcześniej. I znalazł rozwiązanie. Wystarczyło umiejętnie skorzystać z inspiracji.
Jak już zauważyliśmy, model kaskadowy polega na przepychaniu projektu przez kolejne etapy realizacji, krok po kroku. Czy to nie przypomina taśmy montażowej? Jak najbardziej, i zapewne nie przez przypadek prekursorem stosowania zwinnych metodyk w produkcji była wytwórnia samochodów.
Przypomniana rewolucja
Rewolucja zaczęła się w zakładach Toyoty w latach 50. XX w., kiedy zaczęto wprowadzać nowe metody pracy, aby zwiększyć efektywność i zminimalizować liczbę potencjalnych usterek w autach, które właśnie zjechały z taśmy. Dotychczas każdy pracownik przy taśmie odpowiadał wyłącznie za wykonanie swojego zadania. W nowym systemie przestawał być bezmyślnym trybikiem w maszynie – stawał się uważnym obserwatorem, a także jednostką decyzyjną. Nawet najniższy stażem montażysta miał bowiem prawo zatrzymać taśmę, jeśli uznał, że jest to niezbędne. W ten sposób wykrywano i eliminowano usterki, zanim jeszcze samochód wyjechał z hali produkcyjnej. I choć wprowadzając te zmiany, korzystano z teorii opracowanej przez W. Edwardsa Deminga, tak naprawdę główną zasługą Amerykanina było przypomnienie decydentom Toyoty o sensowności starej japońskiej filozofii kaizen, głoszącej potrzebę ciągłego, cierpliwego udoskonalania – także tego, co na pozór wydaje się już wystarczająco dobre.
Jeśli ktoś w fabryce Toyoty miał pomysł, jak można usprawnić produkt lub proces produkcji, wiedział, że zostanie uważnie wysłuchany, bez względu na to, jak nisko stoi w hierarchii służbowej. Dlatego skrót TPS, którym określano wdrożony przez Toyotę system produkcji (Toyota Production System), odczytywano czasem jako System Ludzi Myślących (Thinking People System). System Toyoty wkrótce przejęło wiele innych japońskich firm. Z jakim efektem – wiemy. Kraj, do niedawna kojarzony z bublami i tandetnym wykonaniem, stał się symbolem nowoczesnego przemysłu i produktów wysokiej jakości.
Pizza i innowacje
Zręczne metodyki czerpią garściami z tych rozwiązań. Zasadą jest sprawdzanie funkcjonalności produktu już na wczesnym etapie, by jak najszybciej wyłapać błędne założenia projektu i zwykłe usterki techniczne. Konsultowanie nowych pomysłów z klientem, aby nie brnąć w ślepe uliczki. Nieustanne sprawdzanie, co by jeszcze można poprawić. Omijanie mielizn wynikających z hierarchicznych zależności służbowych.
Jak to zrobić w przypadku dużej firmy, która czuje, że może przegrać wyścig z małymi, ale elastycznymi start‑upami? Przejmując ich atuty. Jeff Bezos, szef Amazona, nazywa tę strategię „2 pizza team” – trzeba bowiem powołać do istnienia specjalny zespół, na tyle mały, by mógł się wyżywić dwiema pizzami. Taka grupa do zadań specjalnych dostaje wydzielone pomieszczenie (open space zbyt rozprasza), gdzie może skupić się tylko na wyznaczonym zadaniu. W możliwie jak najbardziej komfortowych warunkach, nie zawracając sobie głowy żadnymi korporacyjnymi wymogami – jeśli chcą pracować w różowych piżamach i w klapkach, bo tak jest im wygodniej, a w przerwach grać na konsoli w „Tomb Raidera”, mają do tego prawo. Za wszelkie sprawy organizacyjne, ustalanie detali z klientem itd. odpowiada wyznaczony opiekun grupy.
Możliwość szybkiego brania zakrętów, gdy okazuje się to konieczne, i ciągłego udoskonalania to gigantyczna przewaga modelu agile.
Taki mały, zgrany, skupiony na celu zespół może w zaledwie miesiąc opracować roboczą wersję zamówionego oprogramowania, na tyle funkcjonalną, że na jej podstawie klient może już wydać opinię, czy jest to dobry kierunek i co należałoby zmienić. Możliwość szybkiego brania zakrętów, gdy okazuje się to konieczne, i ciągłego udoskonalania to gigantyczna przewaga modelu agile nad modelem waterfall. Tak oto wielki tankowiec zyskuje prędkość i zwrotność małego ścigacza. Innymi słowy, wielka firma, nie tracąc nic ze swych tradycyjnych atutów, staje się równie responsywna i szybka jak start‑up.
Zwinność poza oprogramowaniem
Zręczne metodyki obejmują nie tylko procesy tworzenia oprogramowania. Dotyczą też części operacyjnej. W idealnym, zaawansowanym modelu programiści piszą kod i wysyłają go do jednego repozytorium (zalety: jest w jednym miejscu, bezpieczny, łatwo śledzić zmiany). I reszta dzieje się automatycznie – wiele skryptów pobiera kod, buduje z niego program, którego funkcjonalność sprawdzana jest w najrozmaitszych testach, bez udziału i nadzoru człowieka, na samym końcu, w najlepiej rozwiniętych firmach, również w automatyczny sposób trafia na produkcję. Tak dzieje się na przykład w Amazonie, ale niewiele firm stać jeszcze na podobny poziom wyrafinowania. Człowiek wciąż zwykle bywa włączany w system kontroli.
Duchem zwinnych metodyk przesiąknięta jest też idea DevOps. Pomysł, by pogodzić psa z kotem, czyli połączyć razem w jednym zespole autorów oprogramowania i inżynierów operacyjnych, jak choćby administratorów systemu, okazał się doskonały. Na co dzień ci, którzy chcą jak najszybciej wprowadzać w oprogramowaniu zmiany, są w naturalnym konflikcie z tym, których obowiązkiem jest zapewnić stabilność, bezawaryjność i jak największą dostępność systemu. Współpraca uczy obopólnego szacunku i zrozumienia, pomaga przeprowadzać zmiany płynniej i z mniejszym marginesem dużego ryzyka. W systemie DevOps popełnia się bowiem, z premedytacją, wiele kontrolowanych błędów mniejszych, by wyłapać wszelkie słabości systemu i udoskonalić go, zapobiegając w ten sposób hipotetycznym awariom krytycznym.
Zwinne metodyki przynoszą wiele różnych korzyści, ale nade wszystko pozwalają zachować konkurencyjność. To po prostu wymóg cyfrowej transformacji – firma, aby utrzymać się na rynku, musi być konkurencyjna. Trwanie przy starych metodykach tego nie zapewnia. Przetrwają najzwinniejsi.
