Battle for Agility

10 komentarzy Dodaj komentarz

• 1. Jacek Laskowski  |  January 20th, 2009 at 16:13

  Wpis bajka. Potrzebuję tego więcej i na pewno nie będzie obaw przed rozpoczęciem “samowolki” ;-) Czy w “czyli 20 tygodni pracy dla 5 osobowego zespołu” nie powinno być 4-osobowego zespołu, gdyż 2 osoby pracują na 1/2 etatu?

• 2. Marcin Niebudek  |  January 20th, 2009 at 16:16

  Nie nie, celowo pisałem o faktycznych osobach… ale obliczenie jest już w etatach, więc wszystko powinno się zgadzać.

• 3. Łukasz Wojciechowski  |  January 25th, 2009 at 18:35

  Bardzo przydatne informacje.

  Jestem wielkim wyznawcą lekkich metodyk ale niestety znam temat tylko z teorii. Praktyka dopiero się rozpoczyna i tego typu informacje dla mnie jako szefa zespołu/właściciela firmy są na wagę złota.

  Dziekuję i pozdrawiam

• 4. Monika Antos  |  January 28th, 2009 at 03:52

  Ech te zafiksowane kontrakty :D. Marcin (mogę tak po imieniu? ;]), gryzie mnie tutaj kila rzeczy, z których ty pewnie dajesz sobie sprawę, ale niektórzy mogą nie wyczytać tego z twojego artykułu.
  Pierwsza to velocity. Ta wartosc poniekąd bierze się z chmur. Wiadomo, ze jeśli ktoś ma szczęście, i zna swój team, to będzie mu łatwiej oszacować ile wynosi wydajność zespołu. Co jednak, kiedy zespół specjalistów od Javy otrzyma nagle projekt w C#, i po 1 sprincie od podpisania kontraktu okaże sie, że zamiast szacowanej 50. punktowej velocity jest ona niższa? Co jeśli w połowie projektu z naszego zespołu odpadnie choćby jedna osoba? Co jeśli ktoś nagle dorzuci nam do zespołu nowego człowieka, który najprawdopodobniej zwolni pracę reszty przez następnych kilka sprintów? Jak oszacować velocity w przypadku projektów w których biorę udział, gdzie bawimy się w tak zwany cosourcing - programiści z mojego zespołu pracują z programistami z zespołu klienta nad jednym projektem, i każdy nowy projekt oznacza nowy zespół?
  Kolejna sprawa to wiarygodność i zmienność estymacji. Wszystko powinno być pod kontrolą, jeśli projekt jest niewielki i wymagania są w miarę kompletne, zrozumiale i stabilne. Ale czy po 1-2 dniach zbierania tych wstępnych wymagań ktokolwiek jest w stanie stwierdzić, że tak właśnie jest?
  Następne ryzyko pojawia się w kwestii wartości punktu. Co właściwie oznacza że jedna story jest warta 5 punktów? Czy oznacza to, że spędzimy nad nią 5 dni, 2.5 dnia, czy 5 godzin?

  Wiem, że wszystko sprowadza się do tego, że klient chce wiedzieć ile i jak, i nie bardzo chce zaakceptować fakt, że tak się nie da. Oferty na przetargach świadczą o tym, jak różne potrafią być wyniki takiego szacowania. Kilka z sugestii jak radzić sobie w takich sytuacjach usłyszałam wczoraj na małym spotkanku poświęconym Agile. Jeśli już podpisujesz fixed contract, zasugeruj podzielenie projektu na mniejsze/krótsze części, i kontraktuj każdą z nich po kolei. Bardziej spodobała mi się jednak druga wersja: zamiast próbować przekonać klienta, że powinien podpisać kontrakt na milion złotych, podpisz kontrakt na wstępny spike wart kilkadziesiąt tysięcy. Przez ten czas zbierzesz wymagania, przetestujesz technologię, sprawdzisz czy system jest wykonalny, oraz zbadasz wstępne velocity swojej grupy, wartość 1 punktu itp. Szacowanie będzie o wiele bardziej wiarygodne, kontrakt mniej ryzykowny. Pokażesz też klientowi na co cię stać.

  Się rozpisałam ;)

  Jeszcze jedno - polecam ten krótki artykuł od Alistaira opisujący zwięźle kilka innych metod kontraktowania projektów Agile.

• 5. Marcin Niebudek  |  January 28th, 2009 at 11:27

  No Moniko, faktycznie dużo tego, ale może spróbuje w komentarzu chociaż częściowo odpowiedzieć…

  @Velocity. Powiedzmy sobie jasno - velocity nie zamienia nam magicznie kategorii szacowania z prognozowania na stwierdzanie faktów. Każda wypowiedź na temat przyszłości czy to oparata na velocity czy na osobogodzinach jest tylko prognozą. No chyba, że mamy w zespole skuteczną wróżkę - ja nie mam ;-). Chodzi tylko o to, że ja osobiście mam już dość mówienia klientowi, że implementacja funkcji X zajmie 17 godzin, a funkcji Y 3 godz. 45 min ;-) Na jakiej podstawie mam to niby stwierdzić. Punkty, a pośrednio w wyniku ich stosowania także velocity, dają mi tylko możliwość ucieczki od wróżenia z pojedynczej funkcji na rzecz wróżenia na bazie całego zbioru.

  To prowadzi do kwestii punktów. Nie mam pojęcia co oznacza 5 punktów jeśli chcemy to wyrazić w godzinach. 5 punktów oznacza tylko ok 5x więcej roboty nad daną funkcją niż nad tą wartą 1 pkt. Tak faktycznie 5 pkt (z mojego doświadczenia) to już bardzo dużo, albo inaczej bardzo wiele nie wiemy o tej funkcji skoro chcemy jej dać 5 pkt i wiecej).

  Na stabilności wymagań wogóle mi nie zależy. Jak dla mnie mogą się one zmieniać co iterację. Na początku interesuje mnie ustalenie dla kontraktu pewnego zakresu i budżetu w ramach którego można wykonać coś sensownego. Więc 1-2 dni moim zdaniem wystarczą, żeby ustalić czy rozmawiamy o projekcie na 1-2 miesiace czy raczej na 1 rok. I to tak faktycznie jest moim celem. Bo ja chcę wiedzieć czy na tym etapie, że mogę zaproponować wstępnie wykonanie takich a takich pomysłów w takim czasie i za tyle, a tyle pieniędzy. Ale jednocześnie zostawiam zupełnie otwartą kwestię tego jak to się rozwinie. Idealnie byłoby także gdyby taki kontrakt mógł (o zgrozo :-) zakńczyć się wcześniej, jeśli klient stwierdzi, że już ma faktycznie co chciał. Ale takiego cudo jeszcze nie miałem okazji zobaczyć na własne oczy.

  Bardzo podoba mi się pomysł z pierwszym spikiem, pilotem czy jak kto chce to sobie jeszcze nazwać. To faktycznie ma duży sens, aby sprawdzić się nawzajem oraz zmierzyć się z problemem i ew. nową technologią lub jej częścią. Jeśli tylko klient zaufa nam na tyle, aby taką współpracę podjąć. Tym bardziej są tu istotne wszystkie założenia agile - ten piewszy spike musi dać klientowi coś używalnego a nie mockowy protoyp, z którym nic nie da sie zrobić. I to coś używalnego co zaczyna mieć chociaż zalążki funkcjonalności najistoniejszej z punktu widzenia klienta.

  Niemniej puentą tego wszystkiego jest dla mnie to, że user stories, velocity, punkty to narzędzia, które maja zminimalozować naszą niepewnoś, ale koniec końców to zawsze pozostanie wróżenie.

  Na koniec (bo za raz się z tego zrobi wpis większy niż sam pierwotny artykuł :-) jeszcze kwestia takich zmian w zespole, podjemowania się projektów w technologii o której nie ma się pojęcia itp. Może jestem nienormalny, albo nieprzystosowany do życia w tym brutalnym świecie, ale uważam, że takie rzeczy to problem software house’u a nie klienta. Ja jestem wykonawcą i jak mówię, że dam do projektu 3 wykwalifikowanych programistów to dam, jak nie mam to mój problem. Jak mi ktoś zachoruje albo zmieni pracę i velocity przez to spadnie, to moj problem a nie klienta. Ale za to jak proszę o coś po raz trzeci, piąty czy dziesiąty klienta, bo on miał mi to dać, jak klient nie ma czasu się ze mną spotkać, zeby powiedzieć mi co chce żebym dla niego zaimplementował, to to jest problem klienta. Każdy ma w projekcie swoją odpowiedzialność i wprowadzenie agile na poziomie umów i współpracy z klientem oznacza dla mnie wdrożenie pewnej kultury współpracy. My musimy chcieć i klient musi chcieć, a każdy ma do wykonania swoją robotę. Wiem wiem, napiszecie, że to jakaś utopia… być może… ja wolę o tym myśleć jak o celu wszystkich moich działań. Jeśli na starcie założę, że to fikcja, która się nie zdarzy, to przegrałem. A tak z każdym nowym kontaktem jestem wstanie dorzucić nowy kamyczek do tego wiaderka. To, że wiaderko nadal jest bardziej puste niż pełne to już inna kwestia… walka o zmianę myślenia trwa.

• 6. Tomek Dąbrowski  |  March 27th, 2009 at 09:40

  Marcin,
  Ciekawy post, który opisuje “z grubsza” sposób na wstępną estymację i ustalić koszty projektu. Zauważ, że user stories są wstępnie oszacowane przez zespół. Niestety często zdaża się tak, iż klient zmienia wymagania zawarta w user story całkowicie (np. przed kolejnym Sprintem, bądź też podczas wyjaśniania na etapie implementacji) i wtedy trzeba wyestymować raz jeszcze - jeżeli nowe estymaty będą w miarę podobno to wszystko OK, gorzej, jak zmienione story będzie o wiele większe (np. z 5SPs urośnie do 21SPs). W takim przypadku należy renegocjować z klientem pożądana funkcjonalność, tzn. termin projektu pozostaje ten sam, lecz jakieś inne user story “wyleci” z product backloga - czyli krótko mówiąc zespół zrobi zadania “znad kreski”, a magiczna kreska oznacza nasz budżet (w opisanym przypadku 200SPs).
  Fajnie, że wspomniałeś o “Definition of Done” - na pewno już czytałeś opis fajnego workshop-u, podczas którego zespół wspólnie określa znaczenie “DoD”. Jeżeli nie, daj znać, podeślę linka.

• 7. Marcin Niebudek  |  March 27th, 2009 at 10:00

  @Tomek,
  Co do zmiany zakresu to oczywiscie zgadza sie… tak jest intencja punktów, ktore opisalem w poście o umowie (patrz Termin i Sposób Wykonania).

  Generalnie chodzi właśnie o to, że jakiś budżet trzeba ustalić do umowy, i że ten budżet powinien być punktowy. A czy potem zmiana puli wynika z przeszacowania isteniejącego US, czy też jakiegoś nowego US to już nieistotne. Zarządza się taką zmianą tak samo - przybyło punktów, to musi ubyć gdzieś indziej.

  A linka podeślij, a najlepiej zamiejść tutaj w komentarzu, bo mogłem nie czytać, a i innym się przyda.

• 8. Tomek Dąbrowski  |  March 27th, 2009 at 10:14

  Oto linki do “Definition of Done”: http://www.scrumalliance.org/articles/107-how-do-we-know-when-we-are-done

  Ogólnie jest to trudny temat, moim zdaniem. Najważniejsze jest jednak, aby zespół wspólnie określił i zgodził się na jedną definicje “Done”, bo dla dewelopera “Done” = “implemented”, dla project leader-a/manager-a “Done” = “Signed off”. Ale to chyba nie miejsce na dyskusje :)

• 9. Kuba Zadrożny  |  May 8th, 2009 at 13:29

  Witam,

  Ciekawy post (a właściwie dwa), dotykający bardzo ważnego tematu. Szczególnie w polskich warunkach :-) Mam jednak kilka pytań, bo nie wszystko jest do mnie jasne.

  Najpierw sprawa mniej istotna. Jaka jest różnica pomiędzy wyceną w umowie w punktach i zł? W Waszym kontrakcie mówicie klientowi np. “Masz 200 punktów do wykorzystania (każdy za 983 zł) przez 5 miesięcy. Obiecujemy, że zrobimy w tym czasie funkcjonalność z załącznika 1., lub dowolną inną, którą będziesz chciał, o ile uznamy, że jest warta tyle samo punktów.”. Czy to się jakoś zasadniczo różni od “Masz do wykorzystania 58943589 zł przez 5 miesięcy…”? Oczywiście Wasz proces wyceny jest oparty o punkty (chociaż w pokera można grać też na pieniądze ;-)), ale w kontrakcie można to chyba przeliczyć klientowi na złotówki.

  Niezależnie jednak od tego, czy wyrazicie koszt w złotówkach, czy w punktach, zobowiązujecie się w umowie zrobić określoną funkcjonalność, za określoną kwotę, w określonym czasie. Oczywiście jest możliwość zamiany jednych funkcji na inne, ale taka możliwość jest właściwie zawsze. Jeżeli klient jest gotów zrezygnować z czegoś, na rzecz czegoś innego, to w przypadku bardziej sztywnej umowy można podpisać aneks. To jest normalna praktyka, która działa bez problemu, jeżeli obie strony są zainteresowane. Oczywiście też uważam, że zapisanie tego w umowie jest dużo wygodniejsze. Nie rozwiązuje jednak problemu rozrastania się wymagań, o którym wspomniał Tomek. Załóżmy, że na początku wydawało się, że jakieś story to jeden ekran. W połowie projektu klient mówi “Jeden ekran? Nie nie, my to sobie zupełnie inaczej wyobrażamy. To jest 5 ekranów.” Gdyby umowa nie była fixed price, moglibyście powiedzieć np. “Ok, żaden problem. Możemy to zrobić w całości teraz i to będzie jedyne story w tej iteracji. Możemy też zrobić kluczową część teraz i do tego kilka innych story, a resztę opiszemy w oddzielnym story i zrobimy, kiedy uznacie to za stosowne.” Przy sztywnym zakresie sprawy mają się inaczej. Napisałeś, że nie ma znaczenia “czy potem zmiana puli wynika z przeszacowania isteniejącego US, czy też jakiegoś nowego US”. W jaki sposób to wynika z Waszej umowy? Widzę zapis, że można wymieniać elementy z załącznika 1. na nowe, o tym samym koszcie (wycenionym przez Was). Macie też zapis, że przeszacowanie (przez Was) story z załącznika 1. może spowodować, że wyleci inne story, które również jest w tym załączniku?

  Pytam o to, bo taki zapis wydaje mi się tu kluczowy. Jeżeli jest, to podziwiam Wasze zdolności negocjacyjne, bo nie jest łatwo namówić klientów na branie ryzyka na siebie. Oczywiście w klasycznych kontraktach fixed price brak ryzyka jest fikcją, ale wszyscy wiemy jaka jest świadomość naszych kochanych klientów w tej sprawie :-)
  Jeżeli zaś takiego zapisu nie ma, to możecie być agile tylko na poziomie zakresu całego projektu, wyrażonego listą story, ale już nie na poziomie jednego story. Tu niestety wracamy do starego, (nie)dobrego walczenia ze zmianami. “Możesz sobie kliencie dowolnie żonglować listą story, ale w ramach każdego story z załącznika 1. zrobimy tylko to, co od początku planowaliśmy zrobić i nawet nie myśl o zmianie zdania, o ile za nią nie zapłacisz”

  Jakie macie doświadczenia ze zmiennością zakresu/wyceny punktowej poszczególnych story? Udaje Wam się przekonać klientów do traktowania wszelkich nowości, które wychodzą w trakcie projektu, jako nowych story (czyli do zmian w liście story, a nie w interpretacji poszczególnych story)?

  I jeszcze dwie uwagi. W komentarzu do poprzedniego posta napisałeś “Mamy ustalony zakres, ustalona cene i termin”. Wydaje mi się, że póki Ty rozumiesz “ustalony zakres” jako ustaloną ilość punktów, za które zrobisz co sobie klient wymyśli, a klient jako ustaloną funkcjonalność, z grubsza opisaną przez story, a w szczegółach do dogadania, to jesteście na kolizyjnym kursie. Ty uważasz, że w praktyce macie umowę na consulting, a klient, że na konkretny produkt.

  Druga uwaga dotyczy bardziej ogólnej kwestii. Piszesz w komentarzu, że klienta nie powinno martwić, jeżeli Tobie rozpada się zespół, a Ciebie, jeżeli klient nie ma czasu. W takim podejściu jest moim zdaniem dużo racji, ale jest też inna możliwość. Zakładając, że i Tobie i klientowi zależy na powodzeniu projektu, problemy jednej strony są również problemami drugiej. Jeżeli obie to rozumieją, mogą otwarcie o nich rozmawiać i wspólnie szukać rozwiązania. No ale to jest pewnie utopia, szczególnie w naszym kraju.

  Kuba

  P.S. To wszystko nie oznacza, że nie chciałbym znaleźć jakiejś formuły umowy fixed price, która zachęcałaby do wprowadzania dowolnych zmian w wymaganiach i takie zmiany umożliwiała, a jednocześnie byłaby do zaakceptowania dla klientów. Póki jednak klienci będą rozumieć minimalizację ryzyka jako podpisanie umowy fixed price z najtańszym oferentem, a potem oczekiwanie, że zrobi system, który się zwróci (a nawet coś zarobią), to jestem pesymistą.

• 10. Marcin Niebudek  |  May 10th, 2009 at 12:57

  @Kuba dzięki za tak obszerny komentarz… Pytania, które stawiasz są tak faktycznie częste, więc spróbuję się trochę wybronić :-) może się uda…

  Wycena w punktach i złotych. Tu nie ma wyboru czy tak, czy inaczej. Szacujemy w punktach bo to dobra technika do szacowania, ale kontrakt jest w złotych. Punkty oraz velocity jakie znamy w swoim zespole (+ trochę wróżenia na temat jakie uda się osiągnąć w nowym projekcie) dają nam przeliczenie na złote. Klient wie o jakim budżecie mówi, a punkty wprowadzamy do umowy jako wyznacznik zakresu. Zauważ, że w trakcie projektu te dwie rzeczy mogą się wypalać zupełnie w innym tempie, o czym pisałem trochę tutaj. Także w kontrakcie mamy i jedna i drugą liczbę.

  Ja nie twierdzę, że to nie jest kontrakt “fixed price”, ale normalnie intencja kontraktu tego typu jest inna. “Fixed” rozumiane jest dosłownie, czyli to na co umowilismy się na początku jest obierane literalnie i nie ma legalizacji zmian zakresu. Innymi słowy zwykłe kontrakty tego typu kończą się zamrożeniem wszystkich trzech składników - budżetu, czasu i zakresu. My wprowadzając nasze zapisy do umowy chcemy już na początku usankcjonować wolność zmian zakresu. Oczywiście jak w każdym kontrakcie, papier to jedno a praktyka drugie. Ja na to patrze tak - jeśli uda ci się doprowadzić do tego, że klient podpisze taki kontrakt (z tymi zapisami), to oznacza w praktyce, że stoczyłeś z nim już pierwszą rundę edukacji, że co najmniej jedno spotkanie spędziłeś na wytłumaczeniu mu jak działa proces wg. jakiego chcesz prowadzić projekt.

  Gdybym pokazał taki wzór umowy beż żadnej “gry wstępnej”, to pewnie domyślasz się co bym usłyszał od klienta… WTF? Co wy mi tu w tej umowie wypisujecie, jakie user story, jakie punkty - czy mu tu gramy w karty czy robimy software ;-)

  Zapisu o przeszacowaniu nie mamy. Przyznaję, że to jest jeden z cięższych aspektów do rozstrzygnięcia później, ale mam osobiście wątpliwości na temat takiego zapisu… a może po prostu nie mam na razie pomysłu na jego brzmienie. Dlaczego? Bo to nie takie proste… w praktyce jest tak, że jeśli zgrupujemy różne user story w projekcie wg przydzielonych im punktów, to one i tak będą trwały różnie w ramach jednej punktacji. Np. większość 1 pkt. story potrwa ok 1 dnia, ale trafią się dwa co potrwają 2 dni. Jednak wśród 2 pkt user story też trafią się takie co potrwały mniej niż 1 dzień, mimo, ze większość zajęła 1,5 dnia. Dlatego z tym przeszacowywaniem, to ja się staram go unikać dopóki nie stoję przed sytuacją, kiedy na podstawie dotychczasowych prac widzę, że gdzieś ukryta została mina i temat, który był zasygnalizowany tylko w jakimś story staje się problemem.
  Raczej wolę rozmawiać z klientem na temat tego, dlaczego w tej iteracji spadło nam velocity, i dlaczego wynikało to z komplikacji jakie się pojawiły. W ten sam sposób pokażę mu też, że coś było prostsze… zobacz zaoszczędziliśmy trochę czasu i zaczęliśmy już story X.

  Do czego zmierzam. To, że jakieś pojedyncze story okazuje się nietrafione w szacowaniu, nie oznacza jeszcze ruchów w backlogu. A przynajmniej nie ostatecznie. Może w danym momencie wyglądać, że coś się nie zmieści / wypadnie, ale po 2 kolejnych iteracjach okaże się że jednak się uda. Cała zabawa polega na tym, że klient dowiaduje się o tym od razu i obserwuje sytuację razem z tobą.

  Konflikt na temat rozumienia zakresu? Wprowadzanie user story, oszacowań w punktach i zapisów o iteracyjności jest właśnie dla mnie próbą ustalenia wspólnej definicji tego co oznacza zakres na początku projektu. Kurs kolizyjny mam moim zdaniem jeśli nie mam takich zapisów, bo wtedy takie rozróżnienie istnieje tylko w naszych głowach, a ja te dwie wizje chcę właśnie przedyskutować na początku i umieścić na papierze.

  Co do martwienia się o problemy drugiej strony, to może to było pewne uproszczenie. Oczywiście ideałem jest jeśli klient i wykonawca pracuje jako jedne zespół i każdego martwią problemy projektu. TAK to projekt ma problemy a nie któraś ze stron - całkowicie się z Tobą zgadam.

  W poprzednim komentarzu chodziło mi o to, że zdarzyło mi się wielokrotnie obserwować złe praktyki z obu stron i przerzucanie odpowiedzialności. Więc stawiam tą kwestię jasno… Dopóki pracujemy jako strony umowy, to są pewne kwestie, które są odpowiedzialnością odpowiednich stron, a ja często widzę próbę ustawienia tej odpowiedzialności po złej stronie.

  Kliencie… nie masz czasu na swój projekt, to go nie zaczynaj. Wykonawco, nie masz doświadczenia albo ludzi, to nie mów, że masz a potem nie opowiadaj, że się nie udało bo tak wyszło z powodów od ciebie niezależnych!

  I jeszcze na koniec… TAK przyznaję, że wciąż więcej naszych ofert przygotowanych według tych praktyk zostaje odrzuconych niż zaakceptowanych, ale może z czasem i nasze polskie bagienko się uda trochę osuszyć :-)

Skomentuj wpis

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed