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 zarządzania projektami ma ograniczenia uznawane 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 zarządzania projektami 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 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.
- 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 zarządzania projektami 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.
Odwzorowanie żelaznego trójkąta względem metodyki Agile
Zespoły, które stosują kaskadowy model zarządzania projektami 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.
Koncepcja zakresu w programowaniu zgodnym z 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. Zakres projektu wymaga regularnego zarządzania i porządkowania (ustalania priorytetów). Odpowiada za to menedżer produktu i wykorzystuje w tym celu określone narzędzie, takie jak Jira. 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 (na temat warunków rynkowych, opinii 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 zarządzania projektami
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.
Pomimo różnic między tworzeniem oprogramowania według modelu kaskadowego i modelu Agile nie ma dobrych ani złych sposobów stosowania ż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 Timelines 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 można z łatwością manipulować zakresem, zespołami oraz czasem, planując kolejne wydanie produktu.