Żelazny trójkąt planowania

Stan ostatecznej równowagi i sposób osiągnięcia nirwany w sferze zarządzania projektami Agile

Tareq Aljaber By Tareq Aljaber
Przeglądaj tematy

Wszystkie projekty Agile związane z oprogramowaniem mają cele: określone wyniki, termin ich uzyskania oraz budżet przeznaczony na realizację projektu. Jednak zarządzanie tymi trzema ograniczeniami może być skomplikowaną żonglerką. Warto zatem skorzystać ze znanego od kilkudziesięciu lat żelaznego trójkąta planowania, aby dowiedzieć się, w jaki sposób zrównoważenie różnych zmiennych może ułatwić zespołom programistycznym Agile osiągnięcie nirwany w sferze zarządzania projektami według zasad Agile.

Tradycyjny żelazny trójkąt

Żelazny trójkąt ilustruje model ograniczeń zarządzania projektami, przy czym ograniczenia te uznawane są za „żelazne”, ponieważ nie da się zmienić jednego z nich, nie wywierając przy tym wpływu na pozostałe. Pierwotna wersja żelaznego trójkąta zaproponowana przez dr. Martina Barnesa w 1969 roku bazowała na kaskadowym podejściu do rozwoju produktów, zgodnie z którym zakres jest stały, a zasoby oraz czas są zmienne. W przypadku zespołu zajmującego się tworzeniem oprogramowania oznaczałoby to konieczność rozpoczęcia projektu od zdefiniowania wymagań dotyczących produktu w celu określenia zakresu projektu (listy jednostek pracy). Zasoby i harmonogram są zmienne i szacuje się je na podstawie stałego zakresu.

Ograniczenia żelaznego trójkąta
  • Zakres to praca, jaką trzeba wykonać — na przykład funkcje — w celu dostarczenia działającego produktu.
  • Zasoby obejmują budżet i członków zespołu pracujących nad dostarczeniem i realizacją.
  • Czas określa momenty dostarczania przez zespoły wyników prac na rynek, np. daty wydań i kamienie milowe.

Celem żelaznego trójkąta jest zapewnienie zespołom produktowym informacji koniecznych do podejmowania kompromisów działających na korzyść firmy. Załóżmy na przykład, że zespoły muszą zrealizować stały zakres prac, ale w połowie realizacji projektu zdają sobie sprawę, że nie są w stanie dotrzymać daty wydania. W tym przypadku jedynymi zmiennymi, jakie mają do dyspozycji, są: 1) czas — mogą przesunąć datę wydania, lub 2) zasoby — mogą przydzielić do projektu więcej ludzi, co z kolei podniesie jego koszt. Wraz z ewolucją procesu tworzenia oprogramowania, która rozpoczęła się w XXI wieku, kluczowe znaczenie zyskały lepsza współpraca oraz możliwość szybkiego reagowania na informacje zwrotne od klientów, co z kolei doprowadziło do powstania metodyki Agile.

Żelazny trójkąt w modelu kaskadowym | Atlassian Agile Coach

Odwzorowanie żelaznego trójkąta względem metodyki Agile

Zespoły, które stosują kaskadowy model programistyczny lub dopiero zaczynają pracować według zasad Agile, muszą pamiętać o różnicy między tym, co stałe, a tym co szacowane. W przeciwieństwie do modelu kaskadowego w projektach Agile stałymi są harmonogram oraz zasoby, natomiast zmienny jest zakres. Choć w przypadku tworzenia oprogramowania według zasad Agile zakres projektu może ulegać zmianie, zespoły zobowiązują się do wykonywania pracy w stałych iteracjach, stosując sprinty (w przypadku ram postępowania Scrum) lub limity WIP (w przypadku ram postępowania Kanban). Jest to również najlepszy sposób utrzymania stałych zespołów przez cały proces prac programistycznych. Dając zespołom możliwość skoncentrowania się na jednym produkcie lub projekcie, zwiększa się ich wydajność dzięki wytworzeniu zaufania i ciągłości.

Model kaskadowy i Agile | Atlassian Agile Coach

Koncepcja zakresu w programowaniu Agile jest taka sama i określa, jakie oprogramowanie trzeba opracować i dostarczyć. Jednak metodyka Agile koncentruje się raczej na ogólnych wymaganiach niż próbie zdefiniowania rozbudowanych i szczegółowych wymagań z wyprzedzeniem. Zakresem projektu zarządza się regularnie i porządkuje jego zawartość (nadając priorytet jego elementom). Odpowiada za to menedżer produktu i wykorzystuje w tym celu określone narzędzie, takie jak Jira Software. Menedżer produktu decyduje, które prace powinny być wykonane w kolejnym sprincie, bazując na ilościowych i jakościowych informacjach zwrotnych zgromadzonych zgodnie z zasadami Agile za pośrednictwem różnych kanałów (warunkach rynkowych, opiniach klientów, konkurencji itp.). Dzięki temu, że zasoby oraz czas są stałe, zespołom programistycznym łatwiej jest reagować na zmiany i szybciej dostarczać korzyści klientom. Taka przejrzystość ograniczeń umożliwia zespołom rzetelne podejście do spójnej i wysokiej kadencji wydawania, która jest kluczowym założeniem procesu programowania Agile. A spoglądając na projekty przez pryzmat żelaznego trójkąta, zespoły mogą dostosowywać swoje działania bez porzucania planu.

Planowanie długoterminowe Agile i żelazny trójkąt

W miarę jak projekty się rozrastają potrzeba coraz więcej zespołów, a okienko czasowe się wydłuża. W związku z tym koncepcja, w której zasoby oraz czas są stałe, a zmianie ulega zakres prac, nie zawsze sprawdza się w przypadku każdego projektu Agile. Planowanie długoterminowe Agile wymaga zastosowania bardziej elastycznego żelaznego trójkąta, który umożliwi zespołom planowanie z wyprzedzeniem oraz zagwarantuje osiąganie celów biznesowych. Zastanówmy się na przykład nad metodą Lean Startup oraz koncepcją „produktu o minimalnej opłacalności” (minimum viable product, MVP). MVP to z definicji niewielki zbiór funkcji (zakres), który dostarcza klientowi korzyści. Aby zrealizować taki produkt MVP, zespoły muszą trzymać się ustalonego zakresu (liczby funkcji), a jedyną zmienną jaką dysponują, jest czas (np. nie można wydać produktu bez konkretnych funkcji, dlatego trzeba przesunąć datę wydania). Dopiero po wprowadzeniu na rynek produktu MVP zespoły przechodzą na zmienny zakres.

Bez względu na różnice między tworzeniem oprogramowania według modelu kaskadowego i modelu Agile, nie ma dobrych ani złych sposobów zastosowania żelaznego trójkąta. Jego celem jest umożliwienie podejmowania najlepszych decyzji i znajdowania kompromisów, które pomogą osiągnąć cele biznesowe. Narzędzie, takie jak Roadmaps, pozwala wizualizować bloki konstrukcyjne planu — zakres, ludzi oraz czas — aby ułatwić zespołom planowanie w czasie rzeczywistym. W oparciu o istniejące dane zespołu dostępne w Jira Software można z łatwością manipulować zakresem, zespołami oraz czasem, planując kolejne wydanie produktu.