Battle for Agility

Pierwsze szacowanie dla fixed price

Ostatnio pisałem o tym jak usankcjonować iteracyjność w umowie fixed price (no przynajmniej tak jak to sami próbujemy robić). Wspomniałem też przy okazji o załączniku z zakresem. Poza tym, jak zauważył potem Wiktor w dyskusji dotyczącej poprzedniego posta, potrzeba nam jeszcze tych magicznych liczb - ile i do kiedy? No wiec dzisiaj postaram się wrócić na sam początek rozmów z klientem. Mamy dać ofertę i wiemy, że klient chce wiedzieć ile to bedzie kosztowało (a wiedzieć chce zawsze i od razu, najlepiej jeszcze przed szacowaniem :-) oraz do kiedy i dlaczego tak późno projekt możemy wykonac? No to zaczynamy…

Najpierw musimy poznać co jest przedmiotem systemu, czyli zakres. Oczywiście nie możemy poznać go dokładnie, bo klient nie opisze go nam podczas jednego czy dwóch spotkań, ale ten problem nie ma akurat nic wspólnego z agile. To dotyczy wszystkich projektów niezależnie od metody.

Wymagania spisujemy w formie user story (karty wymagań). Każda karta jest dobra. Zbieranie wymagań na początku projektu działa jak burza mózgów - spisujemy co klientowi przyjdzie do głowu i w dowolnej kolejności. Nie ma na tym etapie także znaczenia jaki priorytet będzie miała potem dana karta/funkcjonalność. Teraz interesuje nas zakres. Dobrze jest przyjąć sobie ograniczenie czasowe na takie zbieranie, np 1-2 dni. Po tym czasie zaczyna się niepotrzebne wymyślanie. Specjalnie nie chcę się teraz rozpisywać na temat samego procesu spisywania user story i polecam książkę “User Stories Applied” Mike’a Cohn’a.

Jeśli mamy już listę user stories, przystępujemy do szacowania. Osobiście bardzo lubie skalę punktową wzorowaną na ciągu Fibonacciego (1, 2, 3, 5, 8, 12, 20, 40, 100). Gramy w planning poker. Taka sesja daje nam zestaw stories + oszacowanie punktowe. Karty wymagań powstają na bazie dostępnych na tym etapie informacji przekazanych przez klienta, rozmów, dokumentów. Estymację… robimy na bazie doświadczenia zespołu, znajomości tematu itd. Czym dana funkcja mniej jasna tym dostanie wiecej punktów stając się epic story do rozwinięcia w przyszłości.

Nic nowego prawda? Tak - niezależnie od metody zwykle tak to wygląda… różnicę stanowi forma zebranych wymagań, która jest moim zdaniem formą najbardziej zrozumiałą dla klienta, a zespołowe szacowanie punktowe minimalizuje na etapie wstępnego określania zakresu ryzyko niedoszacowania lub przeszacowania projektu. Ale spokojnie bo to nie koniec…

To co powstało da nam właśnie załącznik do umowy. Dokładnie w takiej formie dajemy go dajemy klientowi… jako taki niepoukładany wg. priorytetów backlog (zwykle zbieramy user story tematycznie na potrzeby kontraktu). Ale to oczywiście nie daje jeszcze ani ceny ani terminu, a o te dwa kluczowe paramety nam teraz chodzi.

Załóżmy, że wyszło nam w sumie 200 pkt. Z terminem to jest tak, że zwykle klient myśli o jakimś konkretnym, do któgo koniecznie trzeba się wyrobić, albo też podaje nam “ma być jak najszybciej” (chyba nawet częściej :-). Można podejść do oszacowania terminu na dwa sposoby, albo przyjmiemy deadline i będziemy sie zastanawiać ilu ludzi nam potrzeba, albo na odwrót, czyli przyjmujemy wstępną wielkość zespołu i na bazie tej liczby oraz całkowietej watości punktowej projektu zastanowimy się nad terminem. Załóżmy, że klient chce produkt “jak najszybciej”. Przyjmujemy więc, że damy radę do projektu rzucić trójkę programistów i jednego testera, ale on będzie w projekcie na pół etatu. Do tego będzie nas wspomagał project manager (też na pół etatu).

No i teraz jak przejść z 4 etatami i 200 pkt. na terminy i koszty. Musimy przyjąć jakieś velocity (wydajność zespołu). Mimochodem docieramy do problemu definicji tego, co uważamy za wykonanie user story (tzw. definition of done). Tutaj tak faktycznie zaczyna grać rolę charakter projektu i to jak pracujemy. Co więcej chodzi też nie tylko o to co uważamy za ukończenie user story, ale także co uważamy za zakończenie iteracji. Załóżmy, że stosujemy itercje 2-tygodniowe. Musimy sobie w takim razie odpowiedzieć na pytanie ile punktów jest w stanie zrealizować nasz zespół w ciągu jednej iteracji, jeśli np:

• każde user story trzeba zaimplementować,
• programiści piszą testy / stosujemy TDD,
• każde user story trzeba przetestować i np. testy muszą być wykonane na różnych środowiskach (np. w zespołowi będzie przydzielony tester, który musi stworzyć automatyczne testy aplikaji webowej, żeby potem puścić je w 4 przeglądarkach, jakich wymaga klient, albo ma to poprostu przeklikać),
• musimy na bieżąco uzupełnić podręcznik użytkownika,
• raz/dwa razy w tygodniu będziemy mieli 1-2 godzinne spotkanie z klientem, w którym wezmą udział członkowie zespołu,
• raz na iterację będziemy mieli spotkanie w celu oddania iteracji i zaplanowania następnej,
• trzeba zaraportować gdzieś jeszcze aktywność w projekcie,
• 1-2 razy w tyg. jedna osoba z naszego projektu bedzie sie musiała zająć “niecierpiącym zwłoki błędem” z niedawno zakończonego projektu przez np. 2 godziny,
• komunikacja z klientem jest problematyczna (klient wiecznie zabiegany) lub lepsza (szybko odpowiada na nasze pytania),
• itd., itp.

To są tylko przykłady elementów na jakie należy zwrócić uwagę. Każdy zespół musi sobie sam określić co dla niego oznacza “zrobione/gotowe” oraz, które elementy go dotyczą. Chodzi bardziej o to, że z mojego doświadczenia wynika, że przy szacowaniu myślimy zwykle o implementacji, może o napisaniu testów, ale już o dokumentacji to mniej, a innych aktywnościach, ktore zabiorą nam czas wogóle nie myślimy.

Liczba którą przyjmiemy będzie wynikała z naszego doświadczenia w innych projektach, z tego co czujemy po pierwszych spotkaniach/wymianie maili z wciąż potencjalnym klientem. Im więcej nie wiemy, tym bardziej ostrożni w ocenie będziemy. W moich zespołach ta liczba kształtowała się jak dotąd w granicach:

• 7-9 pkt. / osobę / 2-tygodniową iterację

lub też np.:

• 20-25 pkt. / zespół / 2 tygodniową iterację

Od razu odpowiadam na pierwszy zarzut jaki ma się szansę pojawić… ale skąd takie liczby? Nie, nie ma magicznego sposobu, aby na etapie oferty trafić 100%… Chodzi tylko o to, że user stories, szacowanie punktowe w zespole, zastanowienie się nad definicją “skończonej pracy” oraz nasze doświadczenia z zespołem (im bardziej stały jego skład tym lepiej) dają w sumie (i to bardzo ważne, żeby zastosować je razem) dość dobrą metodą na poradzenie sobie z ryzykiem niedoszacowania projektu.

No więc przyjmujemy 20 punktów na iterację dla naszego zepołu. Punktów w sumie wyszło nam 200. Daje nam to 10 iteracji, czyli 20 tygodni pracy dla 5 osobowego zespołu. No to teraz już wiemy co będzie zawierał nasz kontrakt. Kończymy za 5 miesięcy, a przyjmując stawekę Y za dzień pracy członka zespołu, koszt pracy w projekcie będzie wynosił:

20 tygodni x 5 dni x 4 etaty x stawka Y

Co staje się naszym zobowiązaniem w takim kontrakcie? Otóż zobowiązujemy się do wykonania projektu o wartości 200 pkt. Wstępnie będą to user story opisane w załączniku jaki powstał na początku, ale jest to kwestia otwarta… Mamy w kontrakcie zawartą mechanikę wprowadzania zmian w ramach tych 200 punktów (o czym pisałem ostatnio). Dodatkowo zobowiązujemy się do oddawania co iterację, czyli co 2 tygodnie, 20 punktów z naszego zakresu. Zobowiązujemy się tym samym do skończenia projektu w terminie 20 tygodni od startu projektu. I będzie to kosztowało konkretnie wyliczoną kwotę.

Jeszcze tylko kwestia negocjowania takiej propozycji, bo przecież klient może powiedzieć, że 20 tygodni to stanowczo za dużo. Nasza opcja w tym przypadku - dać do projektu więcej ludzi. Jeśli klient mówi - to za drogo. Nasza opcja to negocjowanie stawki za osobę. NIGDY, ALE TO PRZENIGDY nie ważcie się powiedzieć klientowi, że w takim razie może zorbimy tym samym zespołem więcej punktów w iteracji (ludzie nie będą pracować 1,5 razy szybiej bo tak wynegocjowaliście). NIGDY, ALE TO PRZENIGDY nie mówcie też, że może faktycznie, zmnieszymy oszacowanie, bo to równie dobrze może być przecież projekt za 150 punktów i wtedy też będzie taniej i szybciej! NIE! To podważa cały sens szacowania zespołowego, a ufamy naszym zespołom. To nad czym mamy władzę jako negocjator, to wysokość stawki oraz liczba ludzi. Nie władamy czasem ani fizycznymi możliwościami ludzi.

10 comments January 19th, 2009