Artykuł

Czym tak naprawdę jest Agile?

Zwinne organizacje – blog o Agile

W ciągu ostatniej dekady termin „Agile” zyskał na popularności. Temat zwinnego zarządzania regularnie pojawia się podczas największych konferencji IT zarówno w Polsce jak i na świecie, a liczba transformacji, które zakończyły się sukcesem, tylko podnosi entuzjazm kadr zarządzających. Kolejne organizacje podążając za modą i współczesnymi trendami decydują się na porzucenie tradycyjnego modelu kaskadowego, aby uczyć się pracy zgodnie z filozofią Agile. Czy to oznacza, że odnaleźliśmy Świętego Graala zarządzania projektami?

Zapotrzebowanie na zmiany

Kaskadowe podejście do zarządzania projektami IT (z ang. Waterfall), wymusza bardzo długi czas oczekiwania od złożenia zamówienia przez klienta do wdrożenia oprogramowania. Jest to spowodowane tym, że metodologia zakłada sterowanie projektem przez wykonywanie czynności w określonych i staranie zaplanowanych etapach takich jak: planowanie, analiza, projektowanie, implementacja, testowanie i wdrożenie. Tradycyjne podejście pozwala na dostarczanie oprogramowania zgodnie z założonym harmonogramem, budżetem oraz zakresem. Model kaskadowy znajduje swoje zastosowanie w dużych i skomplikowanych projektach, gdzie kluczem do sukcesu jest ustrukturyzowanie prac zespołu, wysoka przewidywalność oraz odpowiedni nacisk na kontrolę (np. poprzez regularny audyt IT oraz kontrolę bezpieczeństwa).

Na początku lat 90-tych, z uwagi na gwałtowny rozwój technologii, pojawiło się duże zapotrzebowanie na oprogramowanie. Nieustannie zmieniające się otocznie biznesowe oraz wymagania klientów sprawiały, że projekty prowadzone kaskadowo regularnie zamykano, zanim zespół developerski przystąpił do prac. W takim przypadku, środki finansowe, czas przeznaczony na szczegółową analizę projektu oraz wymagań klienta, przynosiły stratę dla organizacji. Szacuje się, że w tamtym okresie, czas od pojawienia się potrzeby biznesowej do dostarczenia działającego oprogramowania zajmował średnio 3 lata. Projekty, które z sukcesem pozwoliły dostarczyć aplikacje klientowi końcowemu bardzo często były przedawnione, zdezaktualizowane oraz daleko w tyle za konkurencją.

Tradycyjnie stosowany model kaskadowy nie znalazł swojego zastosowania w projektach ryzykownych, charakteryzujących się dużym stopniem niepewności i nieustannie zmieniającymi się wymaganiami. Branża IT szybko zrozumiała, że próba zastosowania podejścia używanego na liniach produkcyjnych, w procesie wytwarzania oprogramowania, nie przynosi oczekiwanych efektów. W kolejnych latach zostały opracowane: Dynamic System Development Method (1994 r.), Extreme Programming (1996 r.), Crystal oraz Feature-driven Development Method (1998 r.), które zasłynęły, jako metody zwinne. Scrum, który często błędnie jest utożsamiany z Agile, został sformalizowany przez Kena Schwabera w 1995 r., który zainspirował się artykułem „The new new product development game” opublikowanym 9 lat wcześniej w magazynie Harvard Business Review.

Prekursorzy zmiany latami poszukiwali alternatywnego podejścia do wytarzania oprogramowania. W lutym 2001 r. reprezentanci nowych idei spotkali się w ośrodku wypoczynkowym Snowbird w Stanach Zjednoczonych, aby odpocząć, jeździć na nartach oraz znaleźć wspólne porozumienie w prowadzeniu projektów IT. Efektem ich rozmów stał się symboliczny „Manifest Zwinnego Wytwarzania Oprogramowania” (z ang. Manifesto for Agile Software Development), czyli deklaracja ogólnodostępnych zasad i wartości dla wszystkich zwinnych metod. Manifest rozpoczyna się od czterech krótkich założeń, które regulują, jakie wartości są szczególnie cenione przez sygnatariuszy.

Paradygmat filozofii Agile

Zarządzanie zwinne początkowo było odpowiedzią na liczne wyzwania, które stały przed przedsiębiorstwami zajmującymi się wytwarzaniem oprogramowania. Obecnie rośnie liczba organizacji, które decydują się na przeniesienie filozofii oraz technik Agile na pozostałe gałęzie biznesu. Zarządzanie zwinne w kontekście wytwarzania oprogramowania, to nic innego jak grupa metod, które łączy ze sobą elastyczność, transparentność oraz zdrowy rozsądek. Konsultanci Deloitte zebrali wszystkie metody Agile oraz nanieśli je na poniższy graf, aby w prosty i przejrzysty sposób pokazać zachodzące pomiędzy nimi powiązania i konotacje.

W przeciwieństwie do modelu kaskadowego, Agile zakłada, że na początku projektu nie jesteśmy w stanie dokładnie zaplanować jego całego przebiegu. W związku z tym, praca jest podzielona na krótkie cykle, nazywane sprintami (zazwyczaj od 1 do 4 tygodni), podczas których zespół samodzielnie planuje prace, projektuje rozwiązanie, programuje, testuje oraz otrzymuje informację zwrotną (z ang. feedback) od klienta. Iteracyjny tryb pracy pozwala na regularne dostarczanie mniejszych części finalnego rozwiązania oraz na dużą elastyczność w zakresie zmian zakresu projektu. Zespoły zwinne pracują z listą priorytetów (z ang. Product Backlog), która ewoluuje wraz z rozwojem projektu. Umieszczanie najistotniejszych elementów na szczycie listy gwarantuje, że zespół developerski w pierwszej kolejności wytworzy najważniejsze elementy rozwiązania. Podzielenie prac na krótkie iteracje pozwala również na podniesienie jakości produktu poprzez szybką i regularną identyfikację błędów w oprogramowaniu.

Organizacja zwinnych zespołów znacząco się różni od zespołów pracujących zgodnie z klasycznym cyklem życia oprogramowania, w którym kluczową rolę w ustalaniu harmonogramu prac, tempa wytwarzania oraz zarządzania produktem odgrywa kierownictwo. Filozofia Agile zakłada, że zespoły są samoorganizujące się i kros-funkcjonalne. W praktyce oznacza to, że zespoły samodzielnie decydują, w jaki sposób najlepiej wykonywać swoją pracę, a ich członkowie posiadają wszelkie kompetencje i umiejętności niezbędne do ukończenia poszczególnych iteracji. Przekazanie tak dużej odpowiedzialności zespołom developerskim bardzo korzystnie wpływa na motywacje pracowników, którzy będąc odpowiedzialnymi za tworzony produkt, wykazują większe chęci do codziennej pracy.

Ceremonie i artefakty (np. w Scrum) pozwalają na uzyskanie przejrzystego i rzetelnego obrazu przedstawiającego aktualne postępy zespołu, dostarczone w poprzednich iteracjach funkcjonalności oraz listę zadań, którymi zespół będzie zajmował się w najbliższym czasie. Przejrzystość, która stanowi jeden z fundamentów metodyki Scrum, zapewnia bieżący dostęp do rzetelnych informacji na temat funkcjonowania zespołu. Pozostałe fundamenty – inspekcja i adaptacja – umożliwiają ciągłe doskonalenie się zespołów. Zakorzenione w podejściu zwinnym przyglądanie się własnej pracy, obserwowanie, uczenie się na błędach i wyciąganie konstruktywnych wniosków, pozwala na stałe podnoszenie efektywności procesu wytwórczego, poszukiwanie i implementowanie rozwiązań podnoszących komfort oraz jakość pracy, jak i likwidowanie przeszkód, które nieustannie blokują zespoły w kolejnych sprintach.

Święty Graal zarządzania budową produktów

Odpowiednio zaplanowana, przemyślana i przeprowadzona transformacja Agile, która jest wspierana przez kierownictwo wyższego szczebla, pozwala na znaczne podniesienie efektywności zespołów oraz szybsze dostarczanie wyższej jakości produktów. Jednak, wiele organizacji błędnie zakłada, że zaadaptowanie wybranych technik, narzędzi, artefaktów czy ceremonii z wachlarza zwinnych metod gwarantuje sukces, a całą filozofię Agile traktuje, jako Świętego Graala zarządzania projektami.

Tylko czy my na pewno dalej rozmawiamy o zarządzaniu projektami? Może powinniśmy rozumieć Agile, jako możliwość stworzenia idealnych warunków do pracy zespołom developerskim, które dają im szansę na ciągłe doskonalenie się, oraz pracę nad własną efektywnością. Czy czas zarządzania projektami w strukturach wspierających pryncypium „dowódź i kontroluj” ustępuje powoływaniu samoorganizujących się zespołów skoncentrowanych na produktach?

Jeżeli chcesz poznać odpowiedzi na powyższe pytania i wiele, wiele innych to zachęcamy do lektury bloga Agile „Zwinne organizacje”.

Autor:

Artur Kożuch, Ekspert w zespole doradztwa Agile, Deloitte

„Zwinne organizacje”
Skuteczna pigułka wiedzy o agile

Nie przegap najnowszych treści

Czy ta strona była pomocna?