W trzeciej części rozważań na temat story points i praktycznego podejścia do ich użycia w projektach, poruszę kwestię tak zwanej ścieżki krytycznej (critical path). Jeżeli nie widziałeś poprzednich części z serii – zapraszam do lektury.

Czym jest ścieżka krytyczna i do czego służy?

Zagadnienie critical path jest tematem często pomijanym przy okazji omawiania estymacji w story point. Być może wynika to z oddzielnych ról Project Managera oraz Scrum Mastera – a co za tym idzie – innych obowiązków i innego spojrzenia na projekt.

Wyznaczanie ścieżki krytycznej projektu służy do oszacowania minimalnego czasu jego wykonania i określenia elastyczności określonych zadań. Przybiera ona postać ścieżki logicznej, przedstawionej na poniższym modelu. Tyle w zakresie książkowej definicji. W praktyce, jest to ułożenie poszczególnych zadań w takiej kolejności, w jakiej możliwe jest ich wykonanie. Ma to na celu zidentyfikowanie, które zadania powodują oddalenie przewidywanej daty końcowej projektu (co nas blokuje) oraz jakie są między nimi zależności. Dzięki temu dowiadujemy się, czy poszczególne akcje musimy wykonywać po sobie czy mogą być realizowane niezależnie, a także ile czasu możemy wstrzymać konkretną czynność, aby nie spowodować przekroczenia wyznaczone terminu końcowego.

Wyznaczenie ścieżki krytycznej projektu pomaga w wycenie i estymacji czasowej projektu. Dzięki niej wiemy jak długo projekt powinien trwać, wiemy także jak alokować ludzi, aby nie powstały przestoje. Podsumowując – jest to bardzo użyteczne narzędzie dla każdej osoby odpowiedzialnej za rezultat projektu, nie tylko planującej budżet czy komunikującej się z klientem, ale także tej dbającej o wydajność pracy.

Poniżej zamieszczam wyczyszczony z wrażliwych danych diagram ścieżki krytycznej stworzony przeze mnie, na potrzeby jednego z projektów.

W powyższym przypadku do sporządzenia ścieżki krytycznej użyłem metody opisanej w PMBOK. Ma ona przewagi nad innymi metodami np. krytykowanym w świecie Agile wykresem Gantta. Wykres ten co prawda umożliwia łatwe wyczytanie informacji o terminie realizacji zadań oraz konkretnych czynnościach prowadzących do celu, jednak równocześnie daje fałszywe poczucie bezpieczeństwa, jakoby wszystko było zaplanowane i przemyślane, wystarczy tylko działać. Usztywnia to projekt i powoduje, że nie reaguje się na zmiany tak, jak przy użyciu zwykłego rejestru produktu (product backlog).

Chciałem uniknąć wyparcia rejestru produktu przez Gantta i wybrałem sposób proponowany przez PMBOK. Tak przedstawiona ścieżka krytyczna doskonale obrazuje zależności między zadaniami i nie kojarzy się jednocześnie ze spisem zakresu projektu, a to zasadniczy cel, na którym mi zależy przy użyciu ścieżki krytycznej. Dodatkowo tak ułożona ścieżka nie musi być bardzo dokładna, ponieważ od tego mamy backlog. W tym przypadku zależny nam na ogólnych zależnościach i czynnościach, których czas trwania wpływa na ostateczną datę dostarczenia projektu.

 

Po co mi ścieżka krytyczna w zwinnym projekcie?

Wydawałoby się, że w dobrze ułożonym i prioretyzowanym rejestrze produktu, tworzenie critical path nie jest w ogóle potrzebne, ponieważ bierze on już pod uwagę zależności między poszczególnymi zadaniami. W trakcie układania oraz przeglądu wymagań np. przeglądu rejestru produktu (backlog refinement), Product Owner wraz z zespołem deweloperskim identyfikują zależności między poszczególnymi wymaganiami oraz nadają im priorytet. Zespół projektowy sygnalizuje Product Ownerowi zależności np. natury technicznej, których on może nie być świadomy. Znajduje to odzwierciedlenie w treści oraz ułożeniu wymagań w backlogu produktu.

Ponadto – jedną z wytycznych przy układaniu dobrych wymagań projektowych (np. w formie user stories) jest dbałość o ich niezależność – czyli aby jedno wymaganie pokrywało użyteczną całość. Mając to na uwadze możemy identyfikować wymagania w taki sposób, aby stanowiły możliwie niezależny element całego systemu.

Jednak czy oznacza to, że critical path jest już niepotrzebna? Moim zdaniem nie, ponieważ ścieżka krytyczna jest uzupełnieniem opisanego zakresu, a nie jego zamiennikiem.

Ścieżka krytyczna odpowiada na pytania, na które nie znajdziemy odpowiedzi w rejestrze produktu, np.:

  • Skrócenie którego zadania przyśpieszy nam dostarczenie wartości?
  • Które zadania mogą być wykonywane niezależnie?
  • Czy opóźnienie w wykonaniu danego zadania będzie miało wpływ na inne?

Uzyskanie odpowiedzi na te pytania daje możliwość lepszego zarządzania projektem. Jeżeli jakaś czynność znacząco opóźnia resztę, warto ją podzielić na etapy lub przypisać do niej więcej osób. Jak widać, ścieżka krytyczna pomaga w uzyskaniu jednej z kluczowych wartości Agile – szybkim dostarczaniu gotowych rozwiązań.

Jak zbudować ścieżkę krytyczną bez użycia estymat czasowych?
W przypadku story points, nie jesteśmy w stanie zbudować tradycyjnie rozumianej critical path. Dla wielu jest to bardzo duża niedogodność, która podważa sens porzucenia estymacji czasowej.

Na szczęście brak wyceny czasowej nie oznacza, że nie jesteśmy w stanie przygotować critical path dla projektu. User stories również można mapować na diagramie zależności, sugerując się kolejnością ich wytwarzania oraz rozmiarem oszacowanym w postaci story points. Nieużywanie man days, pomoże odejść od podświadomego przypisywania dat, tworzenia sztywnych zobowiązań czy uznania zakresu za finalnie zamknięty. Jeżeli więc zastąpimy czas story pointem, nadal będziemy znali zakładaną kolejność działań. Będzie jednak ona na tyle ogólna, aby nie nakładać presji na zespół, a określić w jaki sposób dostosować zakres, aby dostarczyć wartość jak najszybciej.

Inną metodą użycia critical path w projekcie zwinnym, jest metoda zasugerowana przez Mike Cohna nazwana Rolling lookahead planning. Sposób ten polega na każdorazowym planowaniu, na kilka iteracji do przodu (3-4 iteracje), tak aby zidentyfikować wszelkie możliwe zależności i kolejność wykonywanych zadań. Takie planowanie ma miejsce na wyższym poziomie niż planowanie sprinta, a jednak na tyle dokładnym, aby móc przewidzieć zależności między user stories.
Podsumowując, jeżeli nauczymy się traktować critical path jak narzędzie do wizualizacji zależności, a nie plan działania, przyniesie on planowane korzyści, a użycie story points nie ogranicza sensu czy użyteczności jej stosowania. Critcial path jest tylko jednym z wielu narzędzi projektowych, jego stosowanie powinno być świadomą decyzją. W wielu sytuacjach praktycznych może okazać się, że pracochłonność tworzenia i utrzymania ścieżki krytycznej przewyższa jej korzyści.

 

Podoba Ci się ten artykuł, a może z czymś się nie zgadzasz?

Napisz do nas: info@craftware.pl

Autor

  • Piotr Majak
  • Lider Zespołu Project Managementu w Craftware
  • Od 7 lat zajmuje się zwinnym zarządzaniem. Swoje doświadczenie zdobywał w dużych korporacjach, startupach i organizacjach pozarządowych (NGOs).