Narzędzi typu issue-tracker – czyli narzędzi wspomagających ewidencję i zapisywanie zadań – jest cała masa. Zrobienie przeglądu i recenzji przynajmniej najważniejszych z nich przekracza zdecydowanie skromne możliwości autorów tego serwisu… Ale zdecydowanie warto przyjrzeć się jednemu z nich – narzędziu FogBugz. A to dlatego, że narzędzie to wspiera ciekawą metodę planowania zadań, nazwaną Evidence-Based Scheduling albo EBS.
Sama koncepcja EBS jest opisana bardzo ładnie i żywo w artykule Joela Spolsky’ego – i nie ma sensu jej tutaj szeroko opisywać. A zatem bardzo skrótowo – metoda ta bazuje na następujących założeniach:
- Rozbijamy wszystkie rzeczy do zrobienia na małe zdania – sugerowaną maksymalną wielkością zadania jest 16 godzin.
- W trakcie wykonywania zadań zapisujemy, ile trwało każde zadanie. Akurat tutaj narzędzie bardzo ładnie to wspiera: po wybraniu opcji „I’m working on…” i wpisaniu numeru zadania, czas pracy nad nim jest zliczany i automatycznie wpisywany w odpowiednie miejsce.
- Wyliczenie dla każdego dewelopera velocity, czyli współczynnika sprawdzalności jego szacowań.
Do tej pory nie ma nic odkrywczego, ani rewolucyjnego, prawda? Ale następne dwa punkty są dużo ciekawsze:
- Na podstawie zdekomponowanych zadań EBS wylicza nie termin zakończenia projektu (albo kolejnej fazy w projekcie), ale za pomocą metody Monte Carlo wylicza rozkład prawdopodobieństwa zakończenia projektu w poszczególnych terminach. Na pierwszy rzut oka może brzmieć to trochę zawile, ale tak naprawdę rzecz sprowadza się do bardzo prostego wykresu i bardzo ładnie obrazuje stopień naszej niepewności w określeniu terminów zadań dla zadanego projektu i pracujących w nim programistów.
- Dużym problemem ludzi pracujących w projektach IT jest ilość przerwań – czyli ilość nieplanowanych zadań, wrzutek, problemów, które przerywają bieżący ciąg zadań. Tutaj EBS proponuję bardzo prostą, aczkolwiek skuteczną metodę – nie rozdrabniaj się w ewidencję wszystkich przerwań, a potraktuj przerwanie jako część zadania, które właśnie wykonujesz. A Joel w swoim artykule bardzo ładnie udowadnia, że dzięki takiemu postępowaniu (a może lepiej: mimo takiego postępowania) szacowania terminów generowane przez metodę EBS będą poprawne!
Tyle skrótowego opisu narzędzia. Jeżeli ktoś po przeczytaniu tego chciałby dowiedzieć się więcej, to zapraszam go albo do przeczytania ww. artykułu, albo – jeszcze lepiej – do zarejestrowaniu się do testowej wersji narzędzia i próby zastosowania go dla jakiegoś przykładowego projektu. Oczywiście sam Fogbugz to nie tylko szacowanie zadań, to również bug tracer, to sporo pomysłów na wsparcie komunikacji z klientem, wiki i ścisła integracja z autorskim systemem kontroli Kiln opartym na Mercurialu.
Do tej pory wszystko brzmi cudownie – od jutra zaczynamy stosować EBS i za miesiąc będziemy mieli śliczne rozkłady prawdopodobieństwa dla terminów zakończenia naszych zadań, nieprawdaż? Skoro jest tak pięknie, to dlaczego jest tak źle – dlaczego tyle projektów ma poważny problem z oszacowaniem terminu zakończenia? Być może dlatego, że zamierzając wprowadzić w jakimś dziale IT metodę EBS, musimy wykonać kilka niebanalnych czynności…
Po pierwsze, trzeba zapłacić za narzędzie. EBS jest wbudowany w system Fogbugz, który jest narzędziem komercyjnym. Fogbugz ma oprócz EBS-a jeszcze kilka innych ciekawych cech, ale to już temat na inną opowieść. Za licencję dla 5-osobowego zespołu zapłacimy 125$ na miesiąc (wersja dostępna przez sieć) lub 1.000$ za wersję instalowaną lokalnie. Ale zakup licencji to tak naprawdę najmniejszy problem.
Po drugie: musimy zastanowić się, czy nasze zadania są w ogóle szacowalne. Jeżeli robimy podobne do siebie serwisy internetowe i większość zadań jest potwarzalna – świetnie. Jeżeli natomiast rozwiązujemy nietypowe problemy lub w dziale R&D rozpoznajemy nowe technologie, to szacowanie atomowych zadań może być kwestią niebanalną.
Po trzecie: żeby szacowanie było wiarygodne, to musimy w tym narzędziu umieścić wszystkie nasze projekty – innymi słowy, Fogbugz musi być centralnym i jedynym narzędziem typu issue tracker i bug tracker. Jeżeli zaczynamy od zera prace nad jakimś projektem i z nowym zespołem – świat jest nasz. Instalujemy Fogbugza, uczymy się go i cieszymy się z pięknych szacowań. Gorzej, jeżeli pracujemy w firmie, gdzie już są wdrożone inne narzędzia – wtedy musimy zmigrować wszystkie dane do Fogbugza. Może boleć.
Po czwarte: większość programistów woli po prostu pracować niż pracować, planować i raportować swoją pracę. Planowanie, dekompozycja zadań i raportowanie są dodatkowym wysiłkiem, który rzadko kiedy jest podejmowany spontanicznie i z radością. Dlatego szalenie ważna jest informacja: dlaczego wdrażamy takie narzędzie i do czego potrzebujemy takich planów.
Bo wszystkie te starania są tylko po to, aby móc udzielić jednej informacji: na kiedy nasz projekt będzie gotowy. Kusi perspektywa, aby dać sobie spokój ze wszystkimi ewidencjami, planami i raportami – i skupić się na samym radosnym wytwarzaniu oprogramowania. Sęk w tym, że to tworzenie zawsze odbywa się dla jakiegoś klienta i bardzo często ten klient domaga się podania tej jednej, kluczowej informacji: kiedy mój projekt będzie gotowy i kiedy będę mógł za jego pomocą prowadzić swój biznes.
EBS jest sposobem na udzielenie bardzo dokładnej odpowiedzi (albo: odpowiedzi tak dokładnej, jak to tylko możliwe) na podstawie bardzo detalicznego rozbicia zadań, skrupulatnej ewidencji czasu trwania tych zadań oraz matematyce wykorzystanej do symulacji przyszłości. Ciekawe jest to, że jest to metoda w zasadzie niezależna od metodyki tworzenia projektów – można stosować ją w projektach prowadzonych w klasycznym modelu kaskadowym, można też stosować ją dla Scrum’owych iteracji. Czy warto stosować EBS – na to już każdy projekt musi odpowiedzieć sobie sam…
Macie jakieś ciekawe doświadczenia z dobrymi (lub złymi) metodami estymacji i/lub narzędziami wspierającymi ten proces? Podzielcie się w komentarzach!