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.
January 19th, 2009
Nie tak dawno powstała grupa, której celem jest wypracowanie pewnego szablonu kontraktu na wykonanie aplikacji wg metodyk agile.
Tak faktycznie w Polsce cały czas ciężko uciec od kontraktów typu fixed price ze względu na pewne przyzwyczajenia i strach przed innym rodzajem umowy, która nie zabezpieczałaby odpowiednio klienta (chociaż to raczej pobożne życzenie z tym zabezpieczeniem). No więc zamiast z tym walczyć może należy się z taką sytuacja “zaprzyjaźnić”. Żeby po raz kolejny nie wdawać się w pustą dyskusję na temat tego jakie to fixed price jest złe, postaram się tym razem zamieścić fragmenty faktycznych zapisów z umów jakie sami stosujemy u siebie. A więc podyskutujmy o konkretach…Na początek sekcja dotycząca trybu wykonania projektu:
TERMIN I SPOSÓB WYKONANIA UMOWY
- Strony zgodnie ustalają termin rozpoczęcia prac na dzień X a termin zakończenia prac na dzień Y.
- Wykonanie umowy odbywać się będzie iteracyjnie, tj. w równych N tygodniowych etapach.
- Po każdym etapie, począwszy od etapu nr 2, Zamawiający odbierze od Wykonawcy wykonane elementy Systemu oraz zgłosi uwagi i poprawki.
- Przed każdym kolejnym etapem Zamawiający określi elementy, które powinny być zrealizowane przez Wykonawcę w kolejnym etapie w pierwszej kolejności uwzględniając swoje uwagi zgłoszone po odebraniu etapu poprzedniego.
- Zamawiający może wprowadzić do zakresu projektu elementy nie przewidziane w załączniku nr 1. Pracochłonność nowych elementów zostanie oszacowana przez Wykonawcę i będą mogły one być zrealizowane w ramach niniejszej umowy bez zmiany wynagrodzenia, jeśli Zamawiający zrezygnuje z innych elementów o tej samej szacowanej pracochłonności. Uznaje się wtedy, że zakres projektu nie uległ zmianie. Nie ulega także zmianie termin ukończenia prac określony w pkt 1.
- W przeciwnym wypadku, tj. kiedy Zamawiający wprowadzi do planu nowe elementy bez usuwania z planu innych elementów Systemu, wynagrodzenie Wykonawcy może wzrosnąć proporcjonalnie do pracochłonności nowo wprowadzonych do planu elementów. W takim przypadku zmianie może ulec także termin ukończenia prac określony w pkt 1.
Jest też sekcja:
PRAWA I OBOWIĄZKI STRON
a w niej taki oto punkt, który określa nic innego jak proporcjonalność zapłaty do wykonanej do danego momentu pracy oraz wprowadza swobodę zakończenia projektu przy osiągnięciu odpowiedniej wartości przez klienta:
- Jeżeli wykonanie Systemu według zdefiniowanego w załączniku 1 zakresu okaże się niecelowe bądź jeżeli Zamawiający z przyczyn sobie wiadomych zrezygnuje z dalszego wykonywania umowy, Zamawiający będzie mógł odstąpić od niniejszej umowy za zapłatą odpowiedniej części wynagrodzenia za opracowanie Systemu na rzecz Wykonawcy, adekwatną do stopnia ukończenia Systemu.
I jeszcze może:
WYNAGRODZENIE
- Wynagrodzenie płatne jest w transzach po każdych … odebranych przez Zamawiającego etapach, proporcjonalnie do stopnia ukończenia prac nad Systemem.
- Wykonawca nie może żądać podwyższenia wynagrodzenia, jeżeli wykonał prace dodatkowe bez uzyskania zgody Zamawiającego na zasadach określonych w “TERMIN I SPOSÓB UMOWY”.
To nie są oczywiście wszystkie elementy umowy, ale pozostałe nie są tutaj interesujące bo zawierają raczej elementy standardowe nie związane z procesem agile w żaden sposób. Dodatkowo wyjaśnię tylko, że pojawiający się w powyższych punktach “załącznik nr 1″ (przecież każda dobra umowa musi taki załącznik zwierać :-) to nic innego jak lista user story z oszacowaniami w punktach (o tym jak taka listę do umowy budujemy w następnym poście).
Tym samym chciałbym zachęcić was do dyskusji na temat tego, co o takich zapisach myślicie? A może stosujecie inne, albo dodatkowe? Piszcie… a może uda się jakoś zebrać też i nasz polski sposób na kontrakt agile.
December 10th, 2008
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…
December 8th, 2008
Dlaczego decydujemy się na próbę wprowadzenia procesów agile? Najczęściej skuszeni jesteśmy obietnicą:
- szybszego dostarczania działającego oprogramowania (a co za tym idzie, lepszej wydajności naszych zespołów),
- lepszej jakości wytwarzania oprogramowania,
- szybszego reagowania na zmiany wymagań (i lepszego ukierunkowania się na klienta)
Pewnie w głowie każdy obiecuje sobie jeszcze kilka rzeczy, ale skupię się na tych trzech. A raczej na tym, co się stanie jeśli zaczniemy się skupiać na jednej z nich…
Dzisiaj usłyszałem od kogoś kogo mogę nazwać hmm… koordynatorem projektu? Niech będzie koordynator… No więc usłyszałem “jest dobrze, najważniejsze że mieścimy się w harmonogramie, harmonogram jest najważniejszy”. Jak to mierzymy? Chyba ilością zrealizowanych user story w stosunku do wyznaczonego w kontrakcie zestawu. Czyli mamy powiedzmy zakontraktowane 100 pkt, do dzisiaj powinniśmy mieć 30 pkt żeby projekt “wypalał” się nam w tempie gwarantującym dotrzymanie terminu. Może nawet jesteśmy do przodu w stosunku do planu.
Czyżby obietnica numer jeden była właśnie realizowana? Nic bardziej mylnego… niestety. Problem polega na tym, że nie w terminie jest klucz do sukcesu, ale w odpowiednich priorytetach. Co z tego, że dotrzymujemy terminów realizacji projektu jeśli na liście realizowanych funkcjonalności brakuje tych kluczowych. Ktoś może powiedzieć, że to oczywisty błąd, bo backlog projektu powinien być tak zbudowany, że na samym początku realizujemy najważniejsze user story. Więc jeśli tego nie robimy to sami kręcimy sobie pętlę na szyję.
Racja, chociaż sytuacja jak zwykle jest bardziej skomplikowana niż to się zakłada w tutorialach :-) Jeśli projekt cierpi na opóźnienie w dostarczaniu przez klienta niezbędnych informacji, to oprócz rozwiązywania tego problemu, na innym froncie trzeba robić co się da, nawet jeśli nie do końca jest to realizacja backlogu po linii priorytetów.
W takiej sytuacji może się okazać, że prosta statystyka zrealizowanych user story może nastrajać optymistycznie i uśpić czujność zarówno zespołu jak i klienta. A potem okaże się, że tak faktycznie to na tak powstałym produkcie nie da się realizować żadnego biznesu, bo składa się on głównie z terminowo zrealizowanych ozdobników.
Tak więc drodzy klienci… nie wierzcie samym statystykom… Zawsze patrzcie na wartość jaką niesie dla was każde nowe user story! Drogie zespoły (całe zespoły!) zawsze zadawajcie sobie podstawowe pytanie - do kogo skierowany jest produkt i czy to co właśnie macie zamiar zaimplementować pomaga użytkownikowi zrealizować jego podstawowe cele?
Z resztą ta druga rada jest bardzo podobna do porady na temat pisania dobrych user story. Zawsze kiedy piszemy lub implementujemy nowe story należy sobie zadać pytanie “jak mam zamiar zademonstrować wynik?”. To na pozór proste pytanie bardzo często ujawnia nasze braki w zrozumieniu zadania, podpowiada jak najlepiej zaimplementować dane user story, aby dobrze spełniało wymagania, wreszcie pozwala wskazać dużo testów akceptacyjnych.
Jeszcze raz… podstawą naszych działań jest wartość produktu a dopiero potem terminowość. Klient, kiedy terminy zaczną gonić, na pewno łatwiej poświęci mało istotne z punktu widzenia biznesu user story zamykające listę w backlogu jeśli zadania będą realizowane zgodnie z ich wartością, niż zdecyduje się na odpuszczenie istotnych user story, które zostały odłożone na koniec. I nie pomoże tutaj fakt, że do ostatniej chwili nasz harmonogram wyglądał idealnie.
June 10th, 2008
