Jak buforować prace w projektach agile?

Czy kiedykolwiek zdarzyło Wam się źle oszacować czas realizacji jakiegoś zadania? Jeżeli tak, to witam w klubie 😉 To podobno normalne, nawet jeżeli wykonywaliśmy szacowane zadanie wcześniej.

Daniel Kahneman nazwał to zjawisko „błędem planowania”. Kiedyś robił badania wsród studentów i tak mu wyszło – że zawsze źle szacujemy. Co ciekawe, lubimy przyznawać się, że źle szacujemy, a jednocześnie wierzymy, że nasze aktualne szacunki są dobre.

Szacowanie w naszych projektach

Szacowanie w większości projektów wygląda bardzo podobnie. Spotyka się kilku doświadczonych ekspertów (rzadko kiedy szacuje cały zespół), analizują wymagania, dyskutują szczegóły implementacji i, w końcu, pada długo oczekiwana przez kierownika projektu liczba: „To nam zajmie 12 tygodni”.

Wszyscy są szczęśliwi, bo w końcu jest jakiś konkret. W tym przypadku, prawdopodobieństwo, że nasz projekt potrwa 12 tygodni jest równe 100%. Ale czy faktycznie?

Ten, komu choć raz w życiu przyszło coś oszacować – wie, że jest to zwykła mrzonka. Bo „life jest full of zasadzkas” i nie da się wszystkiego dokładnie przewidzieć.

Punktowa estymata zakłada, że prawdopodobieństwo jej wystąpienia wynosi 100%. — Punktowa estymata zakłada, ze prawdopodobieństwo jej wystąpienia wynosi 100%.

W rzeczywistości, prawdopodobieństwo zrealizowania projektu zgodnie z założonym planem – jest bardzo różne. Mniejsze lub większe. Ale nigdy nie wynosi 100%.

Bo, nie możemy wszystkiego przewidzieć. Zawsze towarzyszy nam niepewność – nie wiemy, co czai się za rogiem. Mogą zmienić się wymagania – dojdą nowe, wzrośnie złożoność starych. Pojawią się nowe ryzyka, których wcześniej nie dostrzegaliśmy, nowa technologia, nowi ludzie…

To wszystko sprawia, że szacowany czas zakończenia projektu przedstawia się jako rozkład prawdopodobieństwa od 0% do 100% (powierzchnia pod wykresem).

Realny rozkład prawdopodobieństwa ukończenia projektu.

Zauważcie, że wykres nie jest symetryczny. Wynika to z faktu, że zazwyczaj niewiele możemy zrobić, żeby przyspieszyć realizację projektu.

Dlatego po lewej stronie, ogon wykresu jest mocno przycięty. Inaczej po prawej, gdzie widzimy, jak łagodnie opada w dół.

Taki kształt krzywej jest powodowany wspomnianym wcześniej czynnikiem niepewności projektu. Na etapie jego szacowania, nie jesteśmy w stanie przewidzieć, co pójdzie nie tak jak byśmy chcieli. Ile kłód zostanie nam rzuconych pod nogi? Ile znajdziemy błędów w aplikacji? Jak długo będziemy je naprawiać?

Na wykresie, najbardziej prawdopodobny moment zakończenia projektu znajduje się w miejscu, gdzie krzywa wznosi się najwyżej (wierzchołek).

Zauważcie, że prawdopodobieństwo zakończenia projektu w tym momencie jest mniejsze niż 50%. Dzieje się tak, ponieważ mniej niż 50% powierzchni krzywej znajduje się na lewo od wierzchołka wykresu. Jeżeli oszacujecie czas trwania projektu w tym punkcie, możecie przypuszczać, że będziecie potrzebowali trochę więcej czasu na dokończenie zaplanowanej roboty.

Stwórz bufor

Niepewność ma kolosalny wpływ na realizację naszych przedsięwzięć. I, możemy sobie spokojnie czekać na to, co się wydarzy i reagować doraźnie, albo spróbować się jakoś na to przygotować.

Dobrym rozwiązaniem jest stworzenie odpowiedniego bufora.

Gdzie można wykorzystać bufory w projektach zwinnych?

Buforowanie pracy w projektach zwinnych można wykorzystać w dwóch przypadkach:

Planowania wydania. Bufor na tym poziomie przydaje się do określenia możliwego „zapasu” przy planowaniu zakresu wydania (liczba dostępnych punktów lub osobodni), terminu dostarczenia prac (czas trwania wydania) lub przy prognozowaniu prędkości zespołu.
Planowania sprintu. Tutaj bufory przydają się do zaplanowania zadań utrzymaniowych w sprincie i wszelkich zadań niezaplanowanych: zadania, którymi musicie zająć się w trybie natychmiastowym (np. padł serwer i trzeba go naprawić); zadania, które „rozrosły” się w sprincie; czy zadania, których po prostu nie dało się przewidzieć podczas planowania.

Jak tworzyć bufory w projektach agile?

Ja używam do tego pewnych sekretnych przeliczników, które biorą się z tzw. „lejka niepewności”. (ang. cone of uncertainty).

Skąd wziął się „lejek niepewności”?

W 1981 roku pojawiła się książka Barry’ego Boehma Software Engineering Economics, która jest tak ciężka, że trudno ją utrzymać w rękach 🙂

Autor przebadał kilkadziesiąt projektów informatycznych i doszedł do wniosku, że to, jak bardzo są dokładne nasze szacunki, koniec końców zależy od tego, co niepewne w projekcie. Przedstawił to w formie prostego wykresu, który kilka lat później, w 1997 roku Steve McConnellnazwał „lejkiem niepewności”.

"Lejek niepewności" − pokazuje jak zmienia się dokładność estymat na kolejnych etapach prac wytwórczych. — „Lejek niepewności” − pokazuje jak zmienia się dokładność estymat na kolejnych etapach prac wytwórczych.

Na osi poziomej, umieszczone zostały kolejne fazy procesu tworzenia oprogramowania. Jak widać, są one mocno sekwencyjne i przypominają tradycyjne podejście kaskadowe.

Oś pionowa z kolei, pokazuje, o ile nasze szacunki mogą się rozminąć z prawdą. I tak, na początku, kiedy definiujemy zakres produktu, margines błędu może się wahać nawet od 60% do 160%.

Przykładowo, gdybyśmy na tym etapie stwierdzili, że na realizację projektu potrzebujemy 30 tygodni, możemy się spodziewać, że w rzeczywistości zajmie on nam od 18 do 48 tygodni.

Lejek zakłada, że im później szacujemy, tym mniejszy jest margines błędu. Wszystko zależy od czynnika niepewności projektu.

Podobne wyniki prezentuje Project Management Institute (PMI), który, trochę inaczej niż w lejku, skupia się tylko na 3 etapach szacowania, uwzględniając odpowiednie przedziały błędu.