Algorytm szacowanie projekto%cc%81w

Oszacowanie kosztowe i czasowe to jeden z pierwszych etapów realizacji projektów. Klienci chcą wiedzieć ile ich projekty będą kosztowały, a właściciele produktów - ile potrwa ich wdrażanie. Poziom trudności wykonania takiej oceny przez zespół programistów jest zazwyczaj wprost proporcjonalny do stopnia złożoności projektu, niemniej jednak, takie szacowanie jest nieuniknioną częścią każdego projektu biznesowego.

Chciałbym się podzielić naszymi doświadczeniami z pewną modyfikacją narzędzia, które stosujemy w procesie oceny zadań, a mianowicie metody „White Elephant” (pl. „Biały słoń”). Nasza modyfikacja pozwoliła na znaczne przyspieszenie procesu szacowania, szczególnie w przypadku dużych projektów w Javie.

Jakiś czas temu pojawił się u nas nowy projekt. Zespół programistów Java musiał dokonać oszacowania kosztowego i czasowego, więc wybraliśmy metodę „białego słonia”. W tej metodzie przygotowuje się małe karty z user story, które należy oszacować. Wykłada się je na stół i porządkuje według ich poziomu trudności, a robi się to według ścisłych reguł. Dzięki temu, że nie oceniamy każdego zadania oddzielnie, oszczędzamy czas, a jednocześnie kontrolujemy to, jak każde user story wygląda w porównaniu z innymi.

 

Zmodyfikowana wersja “białego słonia”

Zanim zaczęliśmy szacowanie, wcześniej przygotowane karty podzieliliśmy na kilka tuzinów grup user stories. Szacowanie tak wielkiego projektu, z taką wielką liczbą zadań było dla nas ogromnym wyzwaniem, więc właśnie dlatego zdecydowaliśmy się zastosować szybką technikę szacunkową i wybraliśmy do tego celu „białego słonia”. W procesie wzięło udział pięciu programistów. Każdy z elementów został luźno przyporządkowany do grupy o numerze 1,3,5, etc., zgodnym z liczbą przyznawanych punktów wagowych.

Na początku, szacowanie szło dobrze, ale w pewnym momencie zauważyliśmy, że w przypadku niektórych zadań opinie były podzielone, co sprawiało, że ciągle zmieniały się ich pozycje w grupach danej wagi. Jeśli w jednej kolumnie znajdują się dziesiątki zadań, ciężko jest zauważyć karty, które ciągle zmieniają pozycje. 

Sesja szacunkowa zaczynała się przeciągać, a zespół wciąż nie podejmował decyzji w sprawie wielu z tych zadań. To co było najbardziej czasochłonne to czytanie opisów każdej funkcjonalności.

Jak to programiści, w końcu zdecydowaliśmy, że cały ten proces szacowania musi być zoptymalizowany i przyspieszony. Wpadliśmy na pomysł, że zadania które przesuwamy do innej grupy mają być zawsze układane jedno na drugim dokładnie tak jak w algorytmie Wieży Hanoi. 

 

Algorytm Wieży Hanoi

Teraz opiszę algorytm Wieży Hanoi dla tych, którzy o nim nie słyszeli. W układance Wieża Hanoi jest określona liczbą krążków różnego rozmiaru oraz określoną liczbą wież. Każda wieża składa się z krążków o różnych rozmiarach. Trzeba ułożyć wszystkie krążki w wieżę od największego krążka na spodzie, do najmniejszego na szczycie, przesuwając je z jednej wieży na drugą. Można kłaść wyłącznie mniejszy krążek na większym. Poniżej widać prostą animację ilustrującą ten proces. 

Animacja przedstawiająca modyfikację

 

W jaki sposób miało to nam pomóc? Zadania, co do których ogólnie się zgadzamy znajdują się na spodzie. Im niżej położone jest zadanie, tym mamy większą pewność i zgodność  w zespole co do jego czasochłonności.

 

Idzie ku dobremu

 

Co dalej?

Po kilku przełożeniach zdecydowaliśmy się odciąć zadania ze spodu. Założyliśmy, że jeśli zadanie nie zmieniło swojej pozycji przez kilka rund, wszyscy programiści zaznajomili się już z nim i szacują je podobnie. Dzięki tej procedurze duża liczba zadań zaczęła znikać z grup. Sesja zaczynała nabierać tempa. Wkrótce wyeliminowaliśmy te zadania, co do których się zgadzaliśmy, a na stole pozostały tylko te, co do których nie było zgodności.

 

Wynik

Po wielu przełożeniach, na stole pozostały już tylko niektóre z tych początkowych tuzinów zadań, a my wiedzieliśmy, że musimy je przedyskutować i lepiej się na nich skoncentrować. 

W przypadku zadań, które miały zbyt wiele niewiadomych, albo w przypadku których nie było zgody, przyjęliśmy najbardziej pesymistyczną opcję jaką mogliśmy, przypisując zadanie tej grupie wagowej, w której karta znajdowała się najczęściej.

Czasami w życiu prywatnym i codziennych sytuacjach doświadczenie programisty może okazać się bardzo przydatne w rozwiązywaniu mniej lub bardziej skomplikowanych problemów jakie napotykamy. W naszym przypadku, problemem był przeciągający się w czasie proces szacowania złożonego projektu. Wprowadzenie schematu Wieży Hanoi  w metodę Białego Słonia znacznie przyspieszyło proces szacowania. Od tamtego  momentu, kiedy po raz pierwszy zastosowaliśmy naszą zmodyfikowaną wersję metody „białego słonia”, stosowaliśmy ją jeszcze wiele razy, kiedy trzeba było oszacować projekt. Proces ten, dzięki temu, znacznie się skraca, oraz jesteśmy w stanie łatwiej wyłapać te zadania, które przesuwają się pomiędzy grupami wagowymi. To pozwala przypuszczać, że dane zadanie może być zbyt trudne lub skomplikowane dla niektórych członków zespołu i może powinno zostać rozbite na łatwiej wykonalne części. 

Mam nadzieję, że wam to pomoże, a jeśli macie jakieś pytania,pytajcie z profilu xSolve na Bulldogu w okienku "zadaj pytanie"

 

Grzegorz Kukla