Kategoria 'Agile dla managerów'
Co prawda, to co za raz napiszę nie ma takiego bezpośredniego związku z agile, ale od jakiegoś czasu mnie to nurtuje. Zainspirowany lekturą książki “Implementing Lean Software Development” i korzystając z faktu, że mam akurat okazję obserwować tworzenie się zespołu typu nearshore, mam do was pytanie.
Jak zbudować relację firma matka - firma nearshore, tak aby obie opierały swoją pracę na modelu obopólnej korzyści? W języku angielskim jest takie zgrabne słowo incentive (zachęta? korzyść?). Gdzie szukać tej korzyści dla obu stron?W swojej książce Marry i Tom Poppendieck użyli przykładu outsourcingu usług typu help desk, gdzie wykonawcy wcale nie musi zależeć na rozwiązywaniu problemów klientów swojego zleceniodawcy jeśli jego model współpracy oparty jest na ilości obsłużonych błędów. W takim wypadku rozwiązywanie problemów odbiera pracę (i dochody) wykonawcy a to na pewno nie leży w jego interesie.
Mój przypadek jest bardzo pobony, tzn. firma typu nearshore buduje zespół głównie utrzymaniowy (być może w przyszłości także i rozwojowy). Spojrzmy na obie strony tego układu.
Klient:
- liczy na niższe koszty,
- potrzebuje nowych ludzi, a lokalny rynek się wyczerpał i bardzo trudno jest rekrutować specjalistów,
- zależy mu na tym, aby nowy zespół stał się równie wydajny jak jego własni ludzie
Wykonawca (firma typu nearshore):
- jest tańsza i łatwiej się jej pozbyć niż zwalniać własnych ludzi w razie kryzysu (modne słowo ;-),
- ma dostęp do ludzi i jest ich w stanie zrekrutować,
- zależy jej na trwaniu kontraktu i pozyskiwaniu coraz większej liczby zadań dla większej liczby ludzi bo zarabia na marży od ich pracy
No właśnie… pierwsze dwa punkty po obu stronach teoretycznie pasują do siebie i zwykle z połączenia właśnie takich celów rodzi się pomysł na nearshoring lub offshoring. Gorzej z punktem trzecim o którym jakoś cicho.
Zespół utrzymaniowy działa prawie jak help desk. Jeśli szybko rozwiąże problemy, to pozbawi się dochodu (jeśli rozliczany jest na godziny, czyli na zasadzie time and material). Z drugiej strony mamy jednak do czynienia z naprawianiem błędów oprogramowania. Gdyby przyjąć wynagrodzenie takiego zespołu oparte o ilość rozwiązanych problemów to byłoby to dość niebezpieczne dla wykonawcy, bo tego typu problemy bywają bardzo różne i jedne wymagają dużo więcej pracy niż inne.
Co powinny być w takim razie tą wspólną zachętą do współpracy dla obu stron, tak aby klient miał pewność, że jego partner wykona swoje zadania jak najlepiej i jak najszybciej, a wykonawca miał taki sam interes w takim właśnie podejściu do realizacji kontraktu? Czy to możliwe aby taki model współpracy nie wymagał skrupulatnej kontroli ze strony klienta, i ciągłego sprawdzania czy zespół nearshore pracuje a nie leży z założonymi rękami? Jak mierzyć wydajność takiego zespołu? Szacować pracochłonność zleceń tak jak szacujemy naszą pracę przy nowych projektach?
February 10th, 2009
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
23 kwietnia 2008 na Politechnice Wrocławskiej w ramach IT Days 2008 obył się wykład pt. “Agile techniques in big IT venture” poprowadzony przez Marcina Kołtonowskiego i Marka Majchrzaka z Nokia Siemens Networks (dalej NSN). Poniżej przedstawiam garść informacji o tym co na wykładzie można było usłyszeć i o tym czego niestety nie usłyszałem, a nie ukrywam, że chciałem :-)
Prezentacja podzielona była na 5 części:
- Ogólne informacje na temat NSN oraz na temat platformy @dvantage, przy której pracują obaj autorzy.
- Krótkie przypomnienie modelu kaskadowego (ang. waterfall) i jego wad.
- Manifest agile i główne założenia iteracyjnego tworzenia oprogramowania.
- Wprowadzenie do Scrum z omówieniem cyklu projektu i ról w projekcie.
- Część praktyczna, czyli spojrzenie na implementację Scrum w NSN jako dużej globalnej korporacji.
Jak się pewnie domyślacie, idąc na ten wykład liczyłem głównie punkt 5 i głównie na nim się skupię. Na prezentację zaplanowano 90 minut. Pierwsze cztery części zabrały w sumie około 50 min. Szkoda, bo zupełnie niepotrzebnie dużo miejsca zajęły szczegóły na temat platformy @advantage i związanych z nią narzędzi oraz teoria na temat Scrum, przez co na to, co faktycznie najciekawsze zostało już tylko pół godziny plus 10 min na pytania z sali.
Ale do rzeczy… Wrocławski odział NSN podjął próbę wprowadzenia Scrum kilka miesięcy temu. Autorzy prezentacji opowiadali o pracy ok 20 osobowego zespołu, który został podzielony na 4 podzespoły (Scrumy). Trzy z nich zajmują się oprogramowaniem trzech różnych linii produkcyjnych wspomnianej platformy @dvantage, czwarty to typowy “firefighting team” zajmujący się naprawą krytycznych błędów na wszystkich trzech liniach działającego już produkcyjnie kodu.
W każdym zespole rolę Scrum Mastera pełni osoba z większym doświadczeniem wybrana z pośród dotychczasowych programistów. Zespoły praktykują codzienne 15 minutowe spotkania, planning meetings na początku sprintu oraz retrospectives po sprincie. Scrum Masterzy ze wspomnianych czterech zespołów tworzą wirtualny zespół Scrum of Scrums aby synchronizować podobne prace toczące się na poszczególnych liniach platformy. Nie wiem tylko ja wygląda komunikacja w obrębie tego zespołu, ale odniosłem wrażenie, że nie mają swoich codziennych spotkań.
Na razie wygląda normalnie… wręcz zbyt dobrze, a przecież to duża korporacja… no to przejdźmy do problemów jakie udało mi się wychwycić.
Po pierwsze NSN pozostaje jako korporacja organizacją polegającą na modelu kaskadowym. Różne warstwy organizacji mają do osiągnięcie pewne kamienie milowe i etapy ich osiągnięcia są góry ustalone. Sam dział programistyczny mapuje Scruma na poziomie poszczególnych faz modelu kaskadowego. I tak mamy opracowanie specyfikacji wymagań, analizę i projektowanie, implementację, wdrożenie i w końcu utrzymanie aplikacji. Jeśli da się dany etap wykonać iteracyjnie, to zespół podejmuje próbę zaprzęgnięcia do tego Scruma w skali pojedynczego etapu. Przy czym Scrum na etapie implementacji jest tutaj najbardziej eksponowany.
Autorzy zapytani przeze mnie o to, jak w takim razie radzą sobie ze zmianą wymagań pochodzących z fazy specyfikacji wymagań odpowiedzieli, że tamte wymagania są na tyle ogólne, że raczej nie zmieniają się potem podczas implementacji. Tak więc możliwa jest co najwyżej reakcja na zmiany drobniejszych wymagań, które identyfikowane są już podczas fazy implementacji a do faz, które już minęły nie wracamy. Nie rozumiem tylko na podstawie czego powstaje w takim przypadku backlog produktu i czy to oznacza, ze on nie może się już zmienić?
Drugi problem jaki dotyczy tak dużej organizacji, to kooperacja pomiędzy działami. W NSN funkcjonuje duży dział testów, który wykonuje między innymi testy funkcjonalne aplikacji tworzonych przez programistów NSN (w tym tych wchodzących w skład 4 Scrumów platformy @dvantage). Problem polega na tym, że praca działu testów nie jest uwzględniona w sprincie a odbywa się już po. W ramach sprintu programiści wykonują jedynie testy jednostkowe (przy czym TDD to raczej opcja niż norma, choć w przypadku tego typu systemów to mnie raczej nie dziwi).
Szkoda, że nie dowiedziałem się z prezentacji więcej na ten temat, bo właśnie tego byłem ciekaw najbardziej. NSN jako duża sformalizowana organizacja jest dotąd raczej oparta na pewnych warstwach zadaniowych i działach, które zajmują się pewnym wybranym aspektem działania firmy. Tymczasem wprowadzanie metod agile, w tym Scrum wiąże się ze zmianą organizacji pracy na bardziej projektową i wymaga utworzenia bardziej kompletnych i samowystarczalnych zespołów. Oczywiście wymagałoby to rewolucji i likwidacji pewnych działów, albo przynajmniej fizycznego przemieszczenia pracowników, tak aby np. pojedynczemu zespołowi developerów przydzielić również osoby z takiego działu testów, a pewnie znalazłoby się jeszcze kilka innych działów, z których należałoby wyciągnąć ludzi. Z tego co autorzy przekazali podczas wykładu wynika, że nie udało się tego dotąd zrobić w NSN i działy pomiędzy sobą nie dzielą nawet wspólnych sprintów.
Na koniec sprawy bardziej techniczne a nie organizacyjne. Sprint w tych zespołach trwa 4 tygodnie. Szacowanie zadań dla poszczególnych sprintów odbywa się w godzinach, przy czym odniosłem wrażenie, że oszacowania dokonują pojedynczy programiści a nie zespół (ale może to niedopowiedzenie). Autorzy prezentacji wspomnieli o śledzeniu wykresów burndown, ale nie wspomnieli nic na temat tego w jaki sposób śledzą velocity (co w przypadku estymowania w godzinach jest szczególnie pomocne) i jak wykorzystują to do planowania i poprawiania swoich oszacowań godzinowych.
No i jeszcze taka ciekawostka - continous integration. W przypadku omawianej na wykładzie platformy zbudowanie, integracja i wstępne przetestowanie automatyczne kodu trwa całą noc. Więc nad ranem następnego dnia zespoły wiedzą, czy coś im nie wyszło dnia poprzedniego. No… oflagowanie tego procesu mianem CI jest moim zdaniem lekkim nadużyciem i uważam, że dużo wiarygodniej brzmiałoby stwierdzenie, że w skali całego projektu nie da się tam wdrożyć pełnego CI. Chciałem zadać jeszcze pytanie czy w ogóle da się w takiej organizacji i przy tak skomplikowanych i złożonych systemach zachować zasadę, że w każdej iteracji otrzymujemy w pełni wdrażalny produkt, zwłaszcza że do tego potrzeba właśnie ścisłego współdziałania działów korporacji? Po prezentacji mam wątpliwości.
Chcę podkreślić, że nie chcę wytykać tutaj żadnych błędów. Moje spostrzeżenia traktuję bardziej jako konfrontację teorii ze staraniami zespołów ograniczonych z wielu stron przez sztywne ramy korporacji. Mam nadzieję, że uda się np. za rok usłyszeć podobne wystąpienie, w którym będzie mowa o tym, jakie z tych problemów udało się, bądź nie udało się rozwiązać. Na razie wygląda na to, że próby wdrożenia Scrum w NSN nie są wspierane na wszystkich poziomach organizacji i raczej wyglądają jako taka inicjatywa na średnim i niższych szczeblach. NSN dysponuje ponoć 500 Scrum Masterami (informacja z wykładu) - pytanie jaki jest stosunek ilości programistów do SMów? Być może na wyższych szczeblach funkcjonuje to bardziej na zasadzie “wszyscy są teraz agile, więc my też bądźmy, ale nie zmieniajmy przy tym za wiele”. Obym się mylił a rozpoczęty w NSN proces ulegał doskonaleniu w praktyce a nie tylko na prezentacjach.
I jeszcze takie fundamentalne pytanie jakie nasuwa mi się jeśli myślę o wdrażaniu agile w takiej organizacji. Czy w trakcie wdrażania procesów Scrum okazało się, że jakieś stanowiska są niepotrzebne? Czy każdy trybik takiej organizacji znajdzie dla siebie miejsce w ramach nowych procesów, czy może pewne stanowiska okażą się nie potrzebne?
Kij w mrowisko wsadzony :-) Czekam na komentarze tych najbardziej zainteresowanych, jeśli takowi czytają tego bloga :-)
April 28th, 2008
Podczas dyskusji na temat tinyPM, obiecałem odnieść się do opisanej przez Joela Spolsky’ego metody szacowania czasu wykonania projektu o nazwie “Evidence Based Scheduling“. Osobiście ta metoda wydaje mi się nieco przeładowana danymi jakie należy do jej poprawnego działania zbierać, no i w porównaniu z tym, co oferują techniki agile (story points, planning poker), zbyt czasochłonna i skomplikowana. Dodatkowo wydaje mi się, że jest obarczona pewnymi wadami, od których planning pokerowi udaje się uciec. Tak więc EBS bardziej pasuje mi do fixed time, fixed scope, ale po kolei…
Już na samym początku EBS zakłada, że cały nasz plan dla którego będziemy szacowali termin wykonania rozbijemy na zadania nie większe niż 16 godzin. Oczywiście zgadzam się z poglądem Joela Spolsky’ego, że jeśli ktoś mówi już o konkretnym zadaniu i twierdzi, że może ono zając 30 godzin, to zwykle nie wie o czym mówi, i nie zastanowił się nad tym co tak faktycznie będzie robił. Tylko, że jesteśmy na początku projektu i nie do końca chcemy rozbijać teraz wszystkie nasze user story na szczegółowe zadania. EBS wymaga szczegółowego planu całości, backlog z user story niekoniecznie - dopuszczamy tzw. epic stories, które maja większe oszacowania i zajmiemy się nimi jak przyjdzie ich czas (może nigdy nie przyjdzie, więc po co się nimi zajmować już teraz).
W EBS szacowanie odbywa się w idealnych godzinach, po czym śledzimy faktyczny czas wykonania każdego zadania. To da nam współczynnik velocity mówiący o tym ile tak faktycznie idealnych godzin dany programista jest w stanie wykonać w zadanym czasie (np. przez tydzień). Istotne jest to, że każdy szacuje zadania dla siebie a potem mierzy czas ich wykonania, aby uzyskać swoje indywidualne velocity. A co z programowaniem w parach - jak to oszacować? A co jeśli zadanie jednak weźmie ktoś inny niż ten, który je estymował? Czy zebrane w taki sposób velocity będą potem wiarygodne przy planowaniu następnych zadań, kiedy to już ten nowy wykonawca będzie sobie estymował pracę?
No to teraz weźmy planning poker. Podstawowe założenie - estymujemy jako zespół. Każdy programista poprzez swoją kartę z punktami wyraża opinię na temat każdego user story. Dyskutowane są wartości skrajne co daje całemu zespołowi pogląd na ew. obawy na temat zadań, prostsze rozwiązania czy założenia, które komuś mogły umknąć, a ktoś inny o nich pomyślał. W ten sposób powstaje wynegocjowane w zespole oszacowanie, z którym każdy czuje się komfortowo i nie będzie problemu z przejęciem zdania przez dowolną osobę.
Po drugie szacując w punktach nie musimy mierzyć ani indywidualnie, ani grupowo żadnych czasów wykonania. Po prostu w iteracji lub zadanym czasie widzimy ile dany zespół jest w stanie wykonać punktów. Zarówno w EBS jak i w metodzie punktowej na początek musimy coś założyć - ja wolę założyć velocity na zasadzie “przez pierwsze 2-3 iteracje przyjmijmy po 20 punktów” niż “no to teraz wygenerujmy dla każdego członka zespołu trochę losowych, ale jednak zbliżonych do siebie wartości velocity“. Już współczuję tym, których mieliby stosować EBS na kartkach, tablicy lub nawet w Excelu ;-)
No i pozostaje jeszcze jedna kwestia… EBS traktuje programistów jako osobne byty. Programista estymuje, programista wykonuje to co estymował, mierzy jak mu idzie, a swoje dane statystyczne dołączą do wielkiego planu. Programiści pracują różnie w różnych zespołach i dlatego widzę mały sens w śledzeniu ich indywidualnego velocity, które ma potem posłużyć jako dokładna baza przy kolejnych projektach. Moim zdaniem rozpoczynając nowy projekt można równie dobrze od nowa wygenerować trochę tych indywidualnych velocity na start. EBS próbuje zniwelować zmienność trafności oszacowań poszczególnych programistów poprzez jak najdokładniejsze rozbijanie zadań na części pierwsze.
W agile stawiamy na to, żeby to zespół jako całość zrobił wszystko najlepiej jak umie. Jeśli nasz zespół dostarcza określoną ilość user story w ciągu jednej iteracji i nie mamy zamiaru co chwilę zmieniać jego składu (prawda, że nie mamy? nie zmienia się przecież zwycięskiego składu), to velocity zespołu jest wystarczającą podstawą do szacowania terminu ukończenia projektu. Prostą metodą i kilkoma spojrzeniami na tablicę można zarówno dokonać prognozy jak i jej weryfikacji w dowolnym momencie. Metoda Monte Carlo… hmm doskonale nadaje się do narzędzia wspomagającego zarządzanie, no bo kto by to sobie liczył na piechotę… Tak się dobrze składa, że pomysłodawca zaimplementował te obliczenia w swoim produkcie. No dobrze, może o jedno szyderstwo za daleko - w końcu mam bardzo duży szacunek do Joela Spolsky’ego. Wolę jednak prostotę i przejrzystość velocity opartego na punktach i mierzonego na zespół i przez zespół.
Wreszcie ostatnia rzecz… Jaki jest sens podawania klientowi, że wszystkie zadania w określonym przez niego terminie wykonamy z prawdopodobieństwem 72%? Każdy klient z jakim miałem do tej pory do czynienia po takim oświadczeniu spojrzałby się na mnie z politowaniem i zadał mi pytanie jeszcze raz… To jesteście w stanie to zrobić czy nie? Ach… czyli jednak nie, no to ile jesteście w stanie zrobić? Przecież tak faktycznie każdego klienta w danym momencie interesuje prawdopodobieństwo 100% i to czy wszystkie zadania zmieszczą się w jego wymarzonym terminie. A i tak wiemy, że to 100% dzisiaj i tak nie daje żadnej gwarancji. Już po tygodniu okaże się, że to już jednak bliżej 98%.
Tutaj po raz kolejny lepsze wydaje mi się planowanie iteracji wg. priorytetów, oszacowań punktowych i założonego (na początku) lub zbadanego (w trakcie trwania projektu) velocity zespołu. Mamy listę user story uszeregowaną w kolejności od najważniejszych do tych “fajnie byłoby mieć”. Każde user story ma przydzielone punkty. Zespół wykonuje N punktów w ciągu tygodnia, więc na tej podstawie możemy określić kiedy projekt powinien się zakończyć. Za późno, no to patrzymy na tą bliższą naszemu sercu datę… Odpadają 2 iteracje i od razu widać co się w tych iteracjach nie załapało… Nie, nie możemy jednak żyć bez kliku user story ale i data jednak lepsza ta wcześniejsza… Trudno, bierzemy coś z tych dwóch iteracji, ale trzeba będzie (z ciężkim sercem) wyrzucić coś innego i to nie na 72%… Trzeba będzie coś wyrzucić na 100% :-)
Tak więc zacięcia detektywistycznego nie mam, wybieram jednak partyjkę pokera w story cards.
March 31st, 2008
No właśnie… W metodyce Scrum używamy określenia sprint dla, zwykle trzydziestodniowej, iteracji. I tak sobie myślę, że to bardzo trafne określenie. Tylko czy sprinter jest w stanie być długodystansowcem? Ideą iteracyjnego podejścia do tworzenia oprogramowania jest zachowanie stałego rytmu i dyscypliny pracy oraz skupienie się na ciągłym dostarczaniu działającego produktu.
Rytm. Iteracje z założenia są równe. Czasem robi się odstępstwo dla tych początkowych, ale później staramy się utrzymać już jednakową długość, bo tylko wtedy można coś sensownego wyczytać z liczonych po drodze metryk takich jak np. velocity (czyli wydajność zespołu) i obserwować jakieś trendy. Rytm dodatkowo pomagają utrzymać spotkania na początku i końcu iteracji, kiedy planujemy i podsumowujemy efekty naszej pracy.
Dyscyplina. Wymaganie dostarczania co iterację nowej, działającej wersji produktu powoduje, że czas jest lepiej wykorzystywany. Dobrze znany z podejścia kaskadowego efekt wypoczywających na początku projektu programistów, którzy potem nadrabiają przez ostatni tydzień braki w projekcie nie powinien zdarzyć się w podejściu iteracyjnym. Iteracje są na tyle krótkie, że nie można sobie pozwolić na zbyt długie rozluźnienie i bujanie w obłokach, albo na prywatne wycieczki programistów w rejony, które ich szczególnie kuszą, ale niekoniecznie muszą być związane z kluczowymi funkcjami systemu i wymaganiami klienta. Tutaj trzeba zamknąć kolejną wersję w 2-3 tyg. i ma ona działać. Opowiadanie klientowi, jaki to fantastyczny schemat bazy danych udało nam się w tym czasie zaprojektować nie pomoże, jeśli nie pokażemy systemu w działaniu. Liczą się zaimplementowane funkcjonalności.
Skupienie. Chodzi przede wszystkim o skupieniu się na głównym celu i kluczowych funkcjach. Czasu w iteracji jest stanowczo za mało, żeby pozwolić sobie na implementację funkcji o niskim priorytecie, bo nie zdążymy z rzeczami dla klienta najważniejszymi. I on szybko się o tym dowie - w najgorszym wypadku pod koniec iteracji.
Ten tryb pracy przynosi naprawdę dobre efekty. Ale ile takich iteracji jest w stanie wytrzymać programista? Czy stojąc właśnie u progu 30-tej iteracji nadal jest taki skupiony i zdyscyplinowany? Przyjęło się, że velocity powinno się w zespole ustabilizować po 2-3 pierwszych iteracjach i potem można już zacząć przewidywać kiedy zespół jest w stanie skończyć kolejne zaplanowane i oszacowane funkcje oraz ile ich wejdzie w każdą kolejną iterację. Jednak pracując iteracyjnie jesteśmy jak sprinter - wiemy, że mamy przebiec krótki dystans i wkładamy w to całą swoją energię. Nie jesteśmy tak jednak w stanie przebiec maratonu.
Rys. Utrata wydajności zespołu agile.
Wydaje mi się, że ta ustabilizowana z czasem wydajność zespołu agile musi prędzej czy później się załamać. Tylko kiedy jest ten moment? Ciekaw jestem jakie wy macie doświadczenia z tego typu projektami? Jaki był wasz najdłuższy projekt prowadzony wg. agile? Jaką długość iteracji uznajecie za idealną? Ja osobiście chyba najbardziej lubię iteracje dwutygodniowe a pojedynczy projekt nie przekroczył jeszcze w moim przypadku 7-8 miesięcy. Obawiam się jednak, że blisko już jestem maksymalnego pułapu.
January 24th, 2008
Jeden z pierwszych artykułów, jakie zamieściłem na tym blogu był moim atakiem na kontrakty o ustalonej cenie. Byłem przekonany, że ciężko tego typu kontrakty pogodzić z ideą agile, z gotowością do zmian oraz dobrą współpracą z klientem. Dzisiaj muszę nieco zrewidować ten pogląd. Największym problemem takich kontraktów wcale nie jest ustalona cena, czy termin, tylko ustalony zakres projektu. Barierą dla agile jest zamrożenie tych trzech elementów na raz w danym kontrakcie. Jeśli natomiast klient uwolni zakres, dopuści możliwość zmian funkcjonalności opisanych w umowie lub wymiany ich na inne, to stwarza to doskonałe warunki do tego, żeby jednak agile zastosować.
Co sie jednak stanie kiedy uwolnimy wszystkie trzy czynniki - czas, budżet i zakres? Coraz bardziej skłaniam się ku myśli, że taka wolność może być dużo bardziej problematyczna.
Od kilku miesięcy biorę udział w projekcie z rodziny Web 2.0. Finansowanie projekt opiera się o sprzedaż pewnej wizji osobom trzecim i oczekiwaniu zysku, kiedy strona zostanie uruchomiona (czyli raczej modelowy scenariusz współpracy pomysłodawca - inwestor). W tym projekcie wspomniane trzy elementy (czas, pieniądze i zakres projektu) są określone następująco (moja subiektywna ocena):
- Czas - chcemy wystartować jak szybko sie da.
- Pieniądze - mamy ich tyle ile dadzą nam inwestorzy. Budżet wyznacza nam także jak długo uda się utrzymywać zespół programistów. Niemniej budżet jest otwarty, bo jeśli pokażemy postępy inwestorom to wypłacą nam kolejne pieniądze.
- Zakres - plany mamy ogromne, dużo większe niż jesteśmy w stanie w tej chwili sfinansować.
Jak w takich warunkach podeszliśmy do realizacji projektu? Na początku przeprowadziliśmy warsztaty (3 pełne dni), podczas których zapoznaliśmy sie z wizją i zakresem projektu oraz pomysłami na biznes. Sami także mieliśmy możliwość zgłoszenia wątpliwości i własnych pomysłów. To wszystko doprowadziło do spisania kilkudziesięciu user story (mniej lub bardziej dokładnych). Wyceniliśmy każde z user story w punktach i wybraliśmy kilkanaście podstawowych, bez których nie da się ruszyć z miejsca. Na początek termin został ustalony sztywno - musimy mieć podstawową funkcjonalność po 3 miesiącach, bo tyle jest na początek pieniędzy.
Brzmi znajomo? Tak - warunki jak przy kontrakcie typu fixed price:
- pomysłodawcom było stosunkowo łatwo określić co jest teraz ważne a co może poczekać,
- nas zmusiło do skupienia sie na zaimplementowaniu najważniejszych funkcjonalności bez zbędnych wodotrysków,
- cotygodniowe spotkania podsumowujące iterację (iteracje mamy 1 tygodniowe) pozwoliły trzymać projekt na właściwym kursie i zaplanować 2 kolejne iteracje, ew. rozwiać wątpliwości czy przedyskutować pewne rzeczy.
Po pewnym czasie warunki uległy jednak zmianie. Perspektywa kolejnych inwestycji w projekt stała się bardziej realna, co spowodowało rozluźnienie czynnika ceny/budżetu. Po pierwszym pokazie i starcie wersji alpha zmalała także presja czasu. Wreszcie, projekt zaczęło oceniać szersze grono pierwszych testerów. Zaczęło go jednak oceniać wybiórczo, bo mając do dyspozycji system, który nie realizuje jeszcze całego procesu prowadzącego do zarabiania pieniędzy. Tak więc testerzy już proszą o ulepszenia i lukier na istniejących funkcjonalnościach, a w backlogu projektu czeka duża część user story koniecznych do zrealizowania początkowej wizji.
Najpierw zostaliśmy zarzuceni całą masą mały poprawek i usprawnień, które uzyskały wyższy priorytet niż kluczowe user story, bo stanowiły komentarz pierwszych użytkowników. Oczywiście zespół jest gotowy zrealizować dowolne user story w (prawie) dowolnym momencie. Akceptujemy zmiany priorytetów, zmiany w funkcjonalnościach (niektóre przerabialiśmy już kilkukrotnie). Wszytko to jest uzasadnione, skoro system dzięki tym zmianom będzie lepszy a klient i użytkownicy będą zadowoleni.
Jednak od kiedy nie gonią nas już tak mocno czas i pieniądze, coraz częściej nasz klient ulega pokusie dopieszczania istniejących funkcjonalności. Ostatecznie udało się nam przekonać go, żeby tylko część czasu w iteracji poświęcić na takie zmiany i wrócić na główny tor realizacji tych faktycznie kluczowych elementów systemu.
Jest też drugi aspekt tej swobody. W metodach agile nastawiamy się jawnie na zmiany, bo prowadzą one do powstania lepszego produktu. A lepszy produkt to zadowolony klient. Tylko czy zespół jest w stanie dobrze realizować ciągłe zmiany? Od kilku tygodniu obserwuję, że poniedziałkowy plan kolejnych dwóch iteracji w niczym nie przypomina tego, który oglądaliśmy jeszcze w piątek dwa dni wcześniej. W kolejnej iteracji prawie zawsze zastajemy inne user story, niż te na które mogliśmy sie już szykować. No dobrze, implementujemy, ale mam wrażenie, że zaczynamy tracić z oczu główny cel. Zaczynają w projekcie funkcjonować raczej cele “lokalne”, krótkoterminowe.
Ktoś porównał kiedyś prowadzenie projektu agile do prowadzenia samochodu. Aby dojechać do celu nie ustawiamy kierownicy w jednej pozycji i liczymy, że to wystarczy. Ciągle korygujemy kierunek jazdy aby dotrzeć na miejsce. Problem w tym, że za mocne szarpanie kierownicą także nie doprowadzi nas do celu, a raczej sprowadzi nas na przydrożne drzewo.
Agile bardzo mocno polega na dyscyplinie, a tą trudno jest utrzymać, jeśli nie mamy żadnych ograniczeń. W naszym projekcie jest nam coraz trudniej zamknąć kolejną iterację mając poczucie, że przybyła z nią kolejna ważna funkcjonalność. Częściej jest to całą seria drobiazgów i tylko 1-2 większe rzeczy. Być może zaczyna nam brakować czasu w 1 tygodniowej iteracji, bo funkcjonalności są trudniejsze w realizacji niż na początku. Ale wydaje mi się, że za daleko zabrnęliśmy w tej swobodzie.
Wyszliśmy od sztywnych ram projektu, gdzie standardowo niczego nie da się ruszyć, a dotarliśmy do drugiej skrajności gdzie swoboda zmian jest praktycznie nieograniczona. Decydując się na iteracyjne wykonanie projektu nie możemy tracić z oczu końcowego rezultatu. Iteracje nie mogą sie zamienić w owczy pęd polegający na wykonaniu kolejnych user story. Te user story mają składać się na pewien obraz iteracji, a kolejne iteracje mają krok po kroku prowadzić projekt do celu, który jest jasny dla całego zespołu…
Ciekawe jakie user story znajdę w planie kolejnej iteracji :-) Jeszcze dzisiaj były to…
November 24th, 2007
Pół roku… bez postów… ale nie bez bitwy. Mój syn Tomek za kilka dni kończy cztery miesiące :-). W tym miesiącu uruchomimy wersję demo naszego nowego systemu do zarządzania projektami agile o nazwie tinyPM. Jesteśmy w trakcie dwóch nowych projektów, gdzie udaje się stosować coraz więcej praktyk agile. Bitwa trwa, a już niedługo nowe posty oraz więcej informacji na temat tinyPM’a.
October 3rd, 2007
Next Posts
Previous Posts
