Battle for Agility

Jesteśmy we właściwej ciężarówce!

December 8th, 2008 Marcin Niebudek

Hotelowa nuda sprzyja pisaniu, a ja właśnie nudzę się w hotelu po szkoleniu… no dobrze - nie nudzę, ale nie bardzo wiem dzisiaj za co zabrać się najpierw, to może jednak czas na małe wynurzenie się z okopów.

Na początek małe wyjaśnienie do tego dziwacznego tytułu :-) Otóż chciałbym napisać dzisiaj parę słów na temat śledzenia projektu. Zdarzyło mi się jakiś czas temu słyszeć co iterację “We are on the right track!” (o matko minęło już prawie pół roku), co natchnęło mnie później do napisania niniejszego posta. No więc jak się pewnie domyślacie “We are on the right track!” miało ze stanem faktycznym tyle wspólnego co “We are in the right truck!”.

Ale po kolei. Na co wam to wygląda (brazek):

No tak… całkiem zwyczajny burndown. No może nie taki zwyczajny bo nie w punktach ale w procentach (ale to się za raz wyjaśni). No właśnie… na jego postawie można by nawet powiedzieć, że na pierwszy rzut oka faktycznie jesteśmy na dobrej drodze. Załóżmy, że wykres ten powstał na bazie jakiegoś projektu, który rozpoczął się od kontraktu z fixed price. Czyli w jakiś sposób (np. w punktach) zostaliśmy zmuszeni do oszacowania wstępnego zakresu projektu i wyszło nam np. 50 punktów - to jest nasze 100% na starcie. Jak fixed price to i cenę ustaliliśmy, przy czym cena nie jest tutaj taka istotna… najważniejsze, że ona się przekłada w głównej mierze na pewną pulę osobogodzin jaka się za tą ceną kryje (no bo zakontraktowaliśmy przecież X naszych programistów na Y tygodni / iteracji). Załóżmy że było to 500 osobogodzin - to też na starcie nasze 100%, ale budżetu.

Więc co jeśli, nasz wykres zacznie wyglądać tak:

No właśnie - już nie jest kolorowo… a wszyscy myśleli, że idzie tak pięknie. Każdy tymczasem w duchu rysował sobie ten wykres tak:

Do czego zmierzam? Otóż przy śledzeniu wypalania się projektu (albo przy śledzeniu samego velocity) istnieje pokusa do patrzenia się tylko na zakres, a wykres typu burndown chart ma to do siebie, że jedna krzywa nie wygląda groźnie dopóki opada w miarę równo, bo reagujemy zwykle tylko na zachwiania trendu. Nie widać natomiast po nim (zwłaszcza jeśli szacujemy w punktach), jak to sie ma do faktycznie przepracowywanych przez zespół godzin.

Stąd też te procenty… bo jak porównać wypalanie projektu w punktach do wypalania budżetu w pieniądzach lub osobogodzinach. Można to właśnie zrobić przeliczając obie wielkości na procent jaki do danego momentu został w projekcie wykonany / zużyty względem całkowitej wartości danego parametru. Wykonaliśmy 10 puntów, to daje nam 20% zakresu, przepracowaliśmy 125 godzin - to 25% budżetu. I co? już zapala się nam czerwona lampka… a samo 20% jeszcze nie wyglądałoby na nic złego. Tak faktycznie to może nie jest - może właśnie taki był plan. Tylko czemu w takim razie zużyliśmy na to wszystko już 25% naszego budżetu.

To jest ujęcie, które mi się osobiście podoba i chętnie go używam. Jeszcze tylko uwaga na koniec. W takiej metodzie, jeśli zmienia się zakres projektu w trakcie (czyli klient dorzuca coś nie wyjmując z listy nic w zamian), to wykres zaczyna wolniej opadać, ale nigdy nie zaczyna się podnosić. Podobnie z budżetem… jeśli dorzucimy trochę pieniędzy :-) to dźwignie to cały wykres a nie tylko iterację, w której następuje zmiana. Ale to nie przeszkadza w niczym, bo chodzi tu o obserwację rozbieżności między obydwoma liniami.

Ciekaw jestem waszych opinii oraz metod na to jak nie uśpić swojej uwagi i nie zgubić z oczu własnych pieniędzy. Ukończenie projektu w terminie to nie wszystko…

Kategorie: Agile dla managerów, Praktyki agile