Porównanie modeli zarządzania projektami: Agile i kaskadowego

Programowanie Agile najwcześniej wdrażano zwykle w małych, niezależnych zespołach pracujących nad niewielkimi, autonomicznymi projektami. To one udowodniły skuteczność modelu Agile ku zadowoleniu i poprawie sytuacji twórców oprogramowania na całym świecie. Okazało się, że w przypadku większości zespołów kaskadowy model tworzenia oprogramowania nie był tak skuteczny, jak zarządzanie projektami Agile.

Popularność zarządzania projektami Agile sprawiła, że coraz więcej organizacji skaluje ten model poza pojedyncze zespoły czy projekty, starając się stosować go do całych programów. Metodyka Agile rozprzestrzeniła się nawet poza zespoły programistyczne, obejmując swoim zasięgiem także zespoły IT, marketingowe, biznesowe i wiele innych.

Zarządzanie projektami Agile to iteracyjne podejście do dostarczania projektu, które koncentruje się na realizowanych w sposób ciągły wydaniach uwzględniających opinie klientów. Możliwość korygowania działań w trakcie każdej iteracji sprzyja zwiększaniu prędkości i adaptacyjności. To podejście różni się od liniowego, kaskadowego podejścia do zarządzania projektami, w którym proces realizuje się według określonej ścieżki, a odchylenia są ograniczone.

Współcześni klienci oraz firmy wymagają szybkiego reagowania i wprowadzania zmian, a model Agile zapewnia elastyczność niezbędną do dokonywania korekt i przeprowadzania iteracji w procesie programistycznym. Zarządzanie projektami Agile stwarza również podwaliny pod wdrażanie praktyk DevOps zakładających współpracę zespołów programistycznych i operacyjnych.

Podejście do zarządzania projektami według modelu kaskadowego zakłada precyzyjnie zdefiniowaną kolejność realizacji faz projektu. Prace nie są kontynuowane, dopóki dana faza nie uzyska ostatecznego zatwierdzenia. Powrót do poprzedniej, zakończonej już fazy może być trudny i kosztowny. Zespoły Agile mogą stosować podobną kolejność, jednak dzielą pracę na mniejsze przyrosty i regularnie uzyskują informacje zwrotne.

Zarządzanie projektami w modelu kaskadowym ma formułę liniową, sekwencyjną. Sprawdza się dobrze w przypadku prac z przewidywalnymi procesami cyklicznymi, ale stosujące go zespoły programistyczne mogą być nieprzygotowane do zmian i będą reagować na nie wolniej niż konkurencja.

A single missed deadline or scope change during a waterfall project can cause outsized impacts on subsequent releases. Additionally, when a team is fully focused on the next phase of work, resolving technical debt or fixing bugs can be painful if the team is fully allocated to new feature work and always pressing forward to the next stage.

Poniżej przedstawiono ilustrację projektu realizowanego według standardowego modelu kaskadowego ze sztywno określonymi blokami czasowymi. Prowadzi on do ukształtowania mentalności „wykorzystaj albo strać”, która zachęca programistów, product ownerów i interesariuszy do maksymalnego wydłużania czasu trwania każdego etapu, ponieważ nie będzie możliwości powrotu do niego w przyszłości. Zazwyczaj zespoły korzystające z modelu kaskadowego próbują ograniczyć pełzający zakres, stosując „kontrolę zmian”, zgodnie z którą każdy zgadza się, że kontrakt początkowy nie ulega zmianie.

Model kaskadowy może nasilić niektóre ze znanych wyzwań związanych z tworzeniem produktów:

• Zarządzanie blokerami i zależnościami: w tradycyjnych stylach zarządzania projektami często tworzy się „ścieżki krytyczne”, w których projekt nie może posunąć się naprzód, dopóki nie wyeliminuje się blokującego jego postęp problemu.
• Trudności w uzyskaniu opinii użytkowników i weryfikacji produktu: Na domiar złego klient końcowy nie może wchodzić w interakcje z produktem, dopóki nie zostanie on w pełni ukończony. W związku z tym poważne problemy z projektem produktu oraz jego kodem pozostają niezauważone do czasu wydania.

Zalety modelu kaskadowego

• Wymaga mniejszej koordynacji z powodu jasno zdefiniowanych faz sekwencyjnych procesów.
• Wyraźnie zdefiniowana faza projektu w czytelny sposób określa zależności między pracami.
• Koszt projektu można oszacować po zdefiniowaniu wymagań.
• Większa koncentracja na dokumentowaniu projektów i wymagań.
• Faza projektowania jest bardziej metodyczna i ustrukturyzowana przed napisaniem jakiegokolwiek oprogramowania.

Wady modelu kaskadowego

• Trudniej dzielić pracę i wykonywać ją wspólnie, ponieważ specjalizacja zespołów jest węższa z powodu bardziej rygorystycznych sekwencji faz.
• Ryzyko marnowania czasu z powodu opóźnień i komplikacji w trakcie przejść między kolejnymi fazami.
• Dodatkowe wymagania dotyczące zatrudniania przy kompletowaniu wyspecjalizowanych zespołów w odróżnieniu od podejścia Agile, w którym zespół jest bardziej interdyscyplinarny.
• Dodatkowa komunikacja podczas przekazywania prac między kolejnymi fazami.
• Poczucie własności produktu i zaangażowanie w jego tworzenie mogą nie być tak silne, jak w przypadku metodyki Agile, ponieważ wysiłki koncentrują się na bieżącej fazie.

Na początku model Agile stosowany był przez zespoły tworzące oprogramowanie, które przechodziły z tradycyjnego, sekwencyjnego podejścia kaskadowego na metodę obejmującą ciągłe zbieranie opinii i wprowadzanie korekt w trakcie całego cyklu programistycznego.

W zarządzaniu projektami Agile przyjmuje się iteracyjne podejście do programowania polegające na utworzeniu kilku wersji przyrostowych, którym towarzyszy regularne uzyskiwanie informacji zwrotnych. Ten model promuje zdolność do adaptacji, ponieważ zespół może wprowadzać korekty w trakcie całego procesu rozwoju produktu i nie musi ograniczać się do liniowej ścieżki. Pozwala również regularnie udostępniać istotne wydania, dzięki czemu z czasem zespoły mogą dostarczyć szereg udanych rozwiązań.

Wydania iteracyjne otwierają dla zespołu wiele możliwości:

• dostosowywania się do zmieniających się okoliczności w obliczu nowych wymagań, jakie się pojawią w odniesieniu do zablokowanej jednostki pracy;
• zbierania opinii od interesariuszy w trakcie procesu i reagowania w sposób iteracyjny bez obaw o niedotrzymanie ostatecznego terminu dostawy;
• budowania relacji i powiązań między różnymi stanowiskami, co ułatwia ludziom nawiązywanie kontaktów i skuteczne komunikowanie się.

Metodyka Agile zwiększa odporność zespołów na zmiany, które nieuchronnie pojawiają się w trakcie projektu.

Jeszcze większą korzyść stanowi wspólny zbiór umiejętności poszczególnych członków zespołu tworzącego oprogramowanie. Pokrywające się zbiory umiejętności członków zespołu zwiększają elastyczność pracy przy wszystkich częściach bazy kodu zespołu. Dzięki temu nie marnuje się energii ani czasu w razie wprowadzenia zmian w kierunku rozwoju projektu. (Więcej informacji zawiera artykuł o tworzeniu fantastycznych zespołów Agile).

• Projekt Agile jest podzielony na kilka etapów przyrostowych, które obejmują regularne uzyskiwanie informacji zwrotnych.
• Wymagania dotyczące projektu są podzielone na mniejsze części, którym z kolei nadaje się priorytet według ich ważności.
• Promowanie współpracy, zwłaszcza z klientem.
• Regularne wprowadzanie korekt w celu spełnienia potrzeb klienta.
• Integracja planowania z wykonaniem, dzięki czemu zespół może skutecznie reagować na zmieniające się wymagania.

Zalety zarządzania projektami Agile

• Szybsze cykle informacji zwrotnych.
• Identyfikacja problemów na wczesnym etapie.
• Większy potencjał osiągnięcia zadowolenia klienta.
• Znaczne skrócenie czasu wprowadzenia produktu na rynek.
• Lepsza widoczność / większa odpowiedzialność.
• Dedykowane zespoły z czasem zwiększają produktywność.
• Elastyczne ustalanie priorytetów z myślą o dostarczaniu wartości.

Wady modelu Agile

• Ścieżka krytyczna i zależności między projektami mogą nie być zdefiniowane tak wyraźnie, jak w przypadku modelu kaskadowego.
• Koszt wynikający z krzywej uczenia się organizacji.
• W pełni zgodna z metodyką Agile realizacja obejmująca pipeline ciągłego wdrażania wymaga opracowania wielu zależności technicznych i poniesienia kosztów prac inżynierskich.

Przejście na model Agile może być trudne, zwłaszcza jeśli działalność zespołu lub organizacji opiera się na bardziej tradycyjnym podejściu do zarządzania projektami. Wdrożenie praktyk Agile może wymagać wprowadzenia licznych zmian w procesach, szczególnie jeśli wprowadza się na podejście DevOps, w którym zespoły programistyczne i operacyjne ściśle ze sobą współpracują w procesie tworzenia i obsługi oprogramowania. Decydując się na wdrożenie zasad Agile, zespół oraz interesariusze muszą przyjąć dwa ważne założenia:

• Product owner koncentruje się na optymalizacji wartości wyników pracy zespołu. Z kolei zespół polega na priorytetach ustalonych przez product ownera i w pierwszej kolejności zajmuje się najważniejszymi pracami.
• Zespół programistyczny może przyjąć pracę tylko, jeśli ma odpowiedni potencjał wykonawczy. Product owner nie wypycha pracy do zespołu ani nie narzuca mu arbitralnych terminów realizacji. Zespół programistyczny pobiera pracę z backlogu programu, gdy jest w stanie podjąć się wykonania nowych zadań.

Przyjrzyjmy się mechanizmom wykorzystywanym w programach Agile do porządkowania, realizowania i strukturyzacji prac w sposób iteracyjny.

Harmonogram określa przebieg procesu opracowywania produktu lub rozwiązania w czasie. W procesie programistycznym Agile harmonogram dostarcza ważnego kontekstu, w oparciu o który zespoły mogą realizować cele przyrostowe i projektowe. Harmonogramy składają się z inicjatyw, czyli większych obszarów funkcji, i obejmują osie czasu, które wskazują, kiedy dana funkcja zostanie udostępniona. W miarę postępu prac i zdobywania wiedzy przez zespół dopuszcza się zmiany harmonogramu w celu uwzględnienia nowych informacji — zarówno na poziomie szczegółowym, jak i ogólnym. Istota tkwi w tym, aby harmonogram zawsze koncentrował się na aktualnych warunkach, które wpływają na projekt oraz cele długoterminowe, umożliwiając skuteczną współpracę z interesariuszami i reagowanie na sytuację konkurencyjną.

Poniżej przedstawiono prosty harmonogram dla zespołu produktowego, w którym inicjatywy są zapisane w polach, a na osi czasu na czerwono zaznaczono kamienie milowe.

Każda inicjatywa wchodząca w skład harmonogramu dzieli się na zestaw wymagań. W metodyce Agile wymagania mają postać uproszczonych opisów wymaganych funkcji, a nie 100-stronnicowych dokumentów, jak w przypadku tradycyjnych projektów. Z czasem wymagania ewoluują, uwzględniając sposób rozumienia klienta i pożądanego produktu wspólny dla członków zespołu. Wymagania w metodyce Agile zachowują oszczędny charakter, podczas gdy zespół buduje wspólną wizję w oparciu o ciągłe rozmowy i współpracę. Wszystkie szczegóły dopracowuje się dopiero na etapie przystępowania do wdrożenia.

Backlog wyznacza priorytety w programie Agile. Zespół uwzględnia w backlogu wszystkie jednostki pracy: nowe funkcje, błędy, ulepszenia, zadania o charakterze technicznym lub architektonicznym itp. Product owner ustala priorytety prac uwzględnionych w backlogu dla zespołu inżynierskiego. Następnie zespół programistyczny wykorzystuje backlog z ustalonymi priorytetami jako pojedyncze źródło rzetelnych informacji na temat prac, które należy wykonać.

Zespoły Agile czerpią korzyści ze wskaźników. Limity prac w toku (WIP) pozwalają zespołom oraz firmie skoncentrować się na dostarczaniu prac o najwyższym priorytecie. Wykresy, takie jak wykres spalania czy karta kontrolna, pomagają zespołom przewidywać kadencję dostarczania, a na podstawie diagramu ciągłego przepływu można wskazać wąskie gardła. Dzięki tym artefaktom i wskaźnikom wszyscy zachowują koncentrację na szerszych celach i zwiększa się zaufanie do możliwości dostarczania przez zespół kolejnych prac w przyszłości.

Procesy Agile nie mogą funkcjonować bez wysokiego poziomu zaufania wśród członków zespołu. Prowadzenie trudnych rozmów na temat tego, co jest właściwe z punktu widzenia programu oraz produktu, wymaga szczerości. Z uwagi na regularne odbywanie takich rozmów pomysły i obawy wyraża się na bieżąco. To oznacza, że członkowie zespołu muszą mieć wzajemne zaufanie do możliwości (i chęci) egzekwowania decyzji podejmowanych w trakcie takich rozmów.

Zarządzanie projektami Agile jest podejściem innowacyjnym nie tylko w przypadku projektów związanych z oprogramowaniem, ale też wszelkich innych rodzajów projektów. Dzięki zapewnieniu możliwości elastycznego reagowania na zmiany w trakcie cyklu opracowywania produktu, metodyka Agile pozwala zespołom dostarczać lepszej jakości produkty, które zaspokajają potrzeby klientów. Metodyka Agile zwiększa możliwości zespołów, rozwija odpowiedzialność i zachęca do wprowadzania innowacji, sprzyjając przy tym ciągłemu doskonaleniu. Umożliwia reagowanie na zmianę bez zbaczania z obranej ścieżki. A to dobra wiadomość dla każdego programu.

Learn more about agile project management and check out our free jira project management template. Plus, dive into agile adoption with agile tools for software teams, and learn how to communicate the progress of work across teams.