Battle for Agility

Ile zespołów tyle podejść do szacowania. Czy to źle?

Jakiś czas temu pisałem na blogu tinyPM o tym czy szacowanie zadań w obrębie user stories w ogóle jest zasadne (Are you brave enough not to estimate your tasks?). Dzisiaj chciałbym podsumować w formie artykułu moją niedawną rozmowę z Marysią na temat estymacji i jej różnych wcieleń.

Zacznijmy trochę od końca (przynajmniej z mojego punktu widzenia) czyli od Scrum’a i burndown’u robionego na bazie pozostałej na dany moment pracochłonności zdań. W Scrum zalecane jest oszacowanie zadań na początek (w godzinach) i prowadzenie dziennika, w którym Scrum Master zapisuje informacje od członków zespołu, ile dane zadanie im zajęło w danym dniu i ile myślą, że jeszcze zostało. Tak każdego dnia, aż zadanie zostanie wykonane.

Co daje taka metoda? Początkowe szacowanie pozwala zorientować się czy zespół nie przeholował z deklaracją ile może faktycznie zrobić. Potem w ciągu trwania sprintu tworzony jest wykres na bazie sumy czasów pozostałych dla wszystkich zadań. To daje obraz tego co sądzi w danym momencie zespół na temat pracy jaka została jeszcze do wykonania. Ta suma może w danym dniu przewyższać estymację z dnia poprzedniego lub nawet początkową estymację co oznacza, że napotkaliśmy problemy, lub nie przewidzieliśmy jakiś zadań, których wykonanie jest konieczne do ukończenia user story.

Na koniec sprintu kończymy z zadaniami, które są powiązane z dwiema liczbami. Pierwotną estymacją oraz faktyczną sumą czasu spędzonego nad zadaniem. Daje nam to porównanie jak trafne są nasze oceny z początku sprintu. Dążymy oczywiście do tego, aby z czasem te dwie liczby okazywały się zbieżne :-)

A teraz do sedna. Po co nam takie śledzenie zadań? Czy nie da się prościej?

Szacowanie zadań wynika tak faktycznie z dwóch potrzeb:

Potrzeba nr 1
Mamy długą iterację. Np. 30 dni wg klasycznych zaleceń Scrum, a chcemy jak najdokładniej wiedzieć czy mamy jakiś problem z wykonaniem tego co w iteracji zadeklarowaliśmy. Chcemy to wiedzieć na bieżąco i chcemy wiedzieć czy idziemy dobrym kursem czy nie.

Potrzeba nr 2
Chcemy być w stanie ocenić to jak nam idzie szacowanie. Czy się mocno mylimy i w jakich sytuacjach najmocniej a w jakich najrzadziej.

I teraz każdą z tych potrzeb można zaspokoić na co najmniej kilka znanych mi sposobów, ale zależy to od przyjętej praktyki.

Małe user stories dające się ukończyć w ciągu jednego dnia. Bez podziału na zadania.

Jeśli stosujemy małe user stories, których realizacja nie ciągnie się przez całą iterację, to nie potrzebujemy w ogóle zadań ani ich estymacji bo burndown po ukończonych user stories zmienia się często i jest całkiem dokładnym odzwierciedleniem postępów zespołu. Jeśli dodatkowo user stories oszacowane są w punktach, to stwierdzenie, że ukończyliśmy w danym momencie 3 z 8 punktów daje nam całkiem dokładną informację o tym, w którym punkcie się znajdujemy.

Jeśli chodzi o dokładność szacowania, to wystarczy rejestrować czas pracy spędzony nad poszczególnymi user stories. Ocenę trafności szacowań da analiza informacji ile czasu średnio zajmują nam historyjki 1-punktowe, ile 2-punktowe itd. Okazać się może wtedy, gdzie mamy największe odchyłki. Należy się zastanowić z czego wynikają, aby uwzględnić to w kolejnym szacowaniu.

Większe user stories przy krótkich iteracjach.

Jeśli nasze user stories są zwykle większe i ich ukończenie zajmuje blisko całą iterację, to burndown po stories praktycznie nic nie mówi, bo przez całą iterację nic się nie dzieje a na koniec mamy skok i zaskoczenie.

W takiej sytuacji naturalną reakcją jest rozbicie user stories na zadania. Przy czym zadania tracą między sobą cechę porównywalności.

Można user stories rozbić na zadania nie większe niż jednodniowe, wtedy na poziomie zadań osiągniemy stan taki jak w poprzednim punkcie na poziomie stories. Można takich zdań nie estymować (skoro są wykonalne w ciągu jednego dnia), bo dokładność ruchów na wykresie będzie zadowalająca. Można powiedzieć ze skoro wykonaliśmy 12 z 25 maksymalnie jednodniowych zadań to jesteśmy mniej więcej w połowie pracy i porównać to z momentem iteracji.

W tym przypadku również bardziej interesujące wydaje się badanie jak nam idzie szacowanie user stories a nie zadań (których jeszcze nie zaczęliśmy estymować).

Długa iteracja i kilka naprawdę dużych user stories.

Przy np. 30 dniowej iteracji i user stories, które i tak zajmują prawie cały ten okres (iteracja zawiera np. 2-3 takie historyjki) dochodzimy do stanu w którym user stories tracą znaczenie z punktu widzenia śledzenia iteracji. Koniec jest zbyt odległy aby można sobie pozwolić na brak bieżącego i rzeczywistego obrazu tego jak nam idzie. Reakcja po 30 dniach może być zbyt późna.

Tutaj pojawia sie potrzeba estymacji zadań i potrzebujemy do tego jednostki, którą nadal można porównywać (np. godziny lub tez punkty). Z punktami jest ten problem, że ciężko rozbić story oszacowanego na 3 punkty, na 5 zadań i je także oszacować w takich samych punktach które w sumie dadzą 3.

No to może w godzinach… bliskie to wszystkim programistom. Ale jak wiemy, mocno się różnimy w szacowaniach godzinowych. Więc co z tego ze coś szacowaliśmy na 8 godzin, skoro w takcie miesiąca okazuje się: “oj pomylilem sie, to zajmie wiecej bo jeszcze musimy…”, itp.

Stąd pomysł ze Scrum na prowadzenie dziennika z czasem pozostałym do wykonania. Ta technika niweluje niedokładność szacowań godzinowych przy długich sprintach i ciągnących się przez wiele dni zadaniach. Codziennie mamy najbardziej rzeczywisty obraz stanu projektu.

Informacja o czasie pozostałym do wykonania nie daje nic jeśli chodzi o weryfikację estymacji po ukończeniu iteracji. Wtedy również istotny jest czas faktycznie spędzony nad zadaniami.

Można też spróbować weryfikować średnie czasu w grupach user stories szacowanych na tyle samo punktów. Ale przy długich iteracjach i dużych stories dokładność szacowania user stories bardziej zaczyna interesować samego właściciela produktu na poziomie planowania wydań. Zespół programistów bardziej obchodzą dokładności na zadaniach, bo w porównaniu do pierwszego punktu, to zadania zaczynają spełniać tę samą rolę co tam małe user stories.

Po co ten cały wywód?

Otóż wciąż często spotkam się z twierdzeniem, że do dobrego planowania potrzebujemy dokładnie takiego sposobu śledzenia zdań jak to proponuje Scrum, czyli szacowania zadań w godzinach, codziennego śledzenie czasu spędzonego i pozostałego na każdym zadaniu.

Tymczasem twierdzę, że tak faktycznie nie ma się co przywiązywać do tej metody, bo została ona opracowana z właśnie po to, by dać odpowiednią dokładność przy sprintach 30 dniowych i kilku dużych user stories wykonywanych w trakcie sprintu.

Natomiast coraz częściej obserwujemy zmianę w preferowanej długości iteracji i skracanie jej do 7 lub 14 dni. Także user stories są często dużo mniejsze niż początkowo zakładał Scrum czy XP. Dlatego zawsze należy dobrać narzędzia i środki do aktualnych warunków, bo być może to samo da się osiągnąć w dużo prostszy sposób.

Ja preferuje podejście na granicy pierwszego i drugiego i czyli iteracją 14 dniowa, małe stories z zdaniami dającymi się wykonać w ciągu jednego dnia. Tym samym interesuje mnie szacowanie user stories w punktach. Nie szacuję zadań. Natomiast śledzenie rzeczywistego czasu wykonania zdań, a w efekcie całego story, może dawać interesujący materiał do przemyśleń.

I jeszcze na koniec odsyłam do dobrego artykułu Mike’a Cohna na temat relacji user stories i ich faktycznego czasu wykonania: How Do Story Points Relate to Hours?

A wy którą metodę preferujecie / stosujecie?

Add comment February 22nd, 2010

Wady Agile? Mój głos w dyskusji.

Bitwa trwa, czas więc oddać swój strzał w dyskusji jaka rozgorzała na łamach Warszawskiego JUGa. Polecam poczytanie jej (urosła już do pokaźnych rozmiarów) a tymczasem ja postaram się ją tutaj (subiektywnie) streścić i odnieść się do paru rzeczy jakie mi wydały się tam najistotniejsze.

Tak więc dyskusja rozpoczyna się od słusznego spostrzeżenia Grzegorza Lipke (to on tą burzę wywołał :-), że Agile zdobywając popularność wśród polskich firm jest postrzegany jako proste rozwiązanie na trudne problemy, i że dużo ludzi liczy na pewnego rodzaju cudowne uleczenie po ich wdrożeniu.

Tymczasem rzeczywistość nie wygląda tak różowo. Podstawowy zarzut jaki pada w dyskusji to, że ta pozorna wolność jaką ludzie widzą w lekkich metodykach częściej prowadzi do chaosu i pogarsza sytuację pod przykrywką “samoorganizacji zespołu”.

Dyskusja zeszła też na tematy problemów:

• z wyceną i szacowaniem (o tym już parę razy pisałem, więc moje zdanie znacie),
• brakiem dokumentacji (która może być krytyczna)
• brakiem doświadczenia potrzebnego do prawidłowego zastosowania metodyk lekkich

Pojęcia
Po pierwsze czuję, że należy wyprostować trochę pojęć, bo w trakcie tej dyskusji przeplatają się wady Agile, czy Scrum czy może zamiast tego XP, albo prawie Agile = Scrum. To, dość typowe, utożsamienie Scruma z Agile wydaje mi się krzywdzące dla obu stron. Agile to pewna idea, zbiór czterech podstawowych wartości i zarys zasad jakie im towarzyszą. Scrum natomiast to jedna z implementacji tych wartości w dziedzinie lekkich metodyk (choć do końca metodyką nie jest). XP natomiast to zespół praktyk bardzo bliskich pracy programiście. Mało się w XP kładzie nacisku na zarządzanie ludźmi, projektami, produktami.

Jeśli więc mówimy o wadach Agile, to mówimy o wadach jakie dostrzegamy bądź w wartościach z Agile Manifesto, bądź w 12 praktykach, które tym wartościom towarzyszą. Pytanie czy któraś z nich wam się nie podoba? Co innego jeśli mówimy o ich wdrożeniu w życie. Tutaj jest już wiele pomysłów jak to zrobić. Jednym z nich jest Scrum, choć nie odpowiada on na wszystkie elementy z Agile Manifesto.

Może więc chodzi nam o wady Scrum? Na pierwszy rzut oka można zauważyć kilka:

• Scrum nie jest pełnym zbiorem, dlatego często uzupełnia się go w kontekście wytwarzania oprogramowania o praktyki z XP (uzupełnia a nie stosuje jedno zamiast drugiego)
• Scrum (z resztą jak cały ruch Agile) pierwszorzędny nacisk i całą odpowiedzialność kładzie na ludzi (tak na mnie i na Ciebie też :-) - czy to faktycznie wada?
• Scrum zakłada, że twoje otoczenie będzie równie zaangażowane jak ty, czyli zarówno sponsorzy jak i właściciele produktu, management, wszyscy mają swoje role. Problem w tym, ze nasze konteksty w życiu codziennym nie są takie różowe i w Scrum ciężko znaleźć na to odpowiedź.

Lekkość i prostota
Jacek Laskowski napisał w swoim komentarzu do dyskusji, że lekkie metody nie są, mimo swojej nazwy, wcale lekkie we wdrożeniu. A kto mówi, że są? Lekkość i prostota tych metod nie polega dla mnie na ich wdrożeniu. I nie mylmy prostoty z prostactwem (simple not simplistic). Ich lekkość leży w prostocie narzędzi jakich używają do osiągnięcia celu. Bezpośrednia rozmowa, krótkie spotkanie, mała kartka z user story, backlog (prosty w budowie). To są narzędzia, które są proste w zrozumieniu i nie wprowadzają zbędnego narzutu na zespół, który ma się skupić na swoim głównym celu, jakim jest dostarczenie wartości klientowi poprzez wytworzenie niezawodnego oprogramowania.

Zgadzam się z Pawłem Lipińskim w kwestii jakości. Każdy zarzut pod kątem pogorszenia się jakości w wyniku zastosowania lekkich metod jest nieuzasadniony, bo jednym z kluczowych problemów jakich Agile próbuje dotknąć jest właśnie jakość. Jeśli się pogarsza, to coś jest nie tak z zespołem a nie z założeniami metodyki (moja opinia).

Ludzie
Ludzie… W sumie to chodzi o dwie kwestie. Pierwsza to ta, że bardzo ciężko wprowadzać metodyki lekkie w niedoświadczonych zespołach. Moje pytanie brzmi - a którą metodykę wprowadza się łatwo w takich zespołach? Ja nie znam żadnej metodyki wytwarzania oprogramowania, którą wprowadzałoby się lekko i przyjemnie. Bo nie mówimy tutaj o produkcji masowej pana Forda, która była pomyślana właśnie pod kątem słabo wykwalifikowanej kadry. Więc jeśli mówimy o zespole, to jeśli ktoś poważnie myśli o podnoszeniu jakości jego pracy i w ogóle o zarządzaniu ludźmi, to nie zostawia słabo doświadczonych ludzi samych sobie.

Jeśli mówimy o dopiero formującym się zespole, np. w nowej firmie, gdzie brak nam doświadczenia z metodami lekkimi, to dlaczego oczekujemy, ze wszystko się nam uda? Wiadomo, będziemy eksperymentować. Nie zrzucajmy na karby metodyki naszych problemów z jej implementacją. Poza tym żadna z metodyk lekkich niczego nie narzuca pod rygorem kary śmierci. Te same problemy wystąpią w takim zespole podczas próby wprowadzenia PRINCE2 czy RUP (osobiście myślę, że większe). tutaj liczy się kontekst w jakim stosujemy dane praktyki. Coś co działa u mnie może nie działać u ciebie, więc się tego kurczowo nie trzymaj. To jest jedna z cech odróżniających metodyki lekkie od tych bardziej sformalizowanych.

Dla mnie małe doświadczenie nie jest problemem, bycie natomiast słabym programistą, managerem, testerem itd., mimo doświadczenia już problemem jest. Ja takich ludzi nie chcę. Rzadko wypowiadam się kategorycznie, ale w tym przypadku moje zdanie na ten temat jest jednoznaczne. Ja chcę mieć w zespole ludzi dobrych, ba… najlepszych. Idealnie lepszych ode mnie. Dla słabych, dla których to co robią to nic szczególnego, bo znaleźli się w IT przez przypadek, bo ta praca jest dobra jak każda inna, a przy tym można trochę zarobić, nie ma u mnie miejsca. Co mają ze sobą począć? Najlepiej znaleźć sobie inne zajęcie.

Dla mało doświadczonych, zapalonych do pracy, kreatywnych ludzi, wszystkie metodyki lekkie przygotowały narzędzia, aby uczynić z nich coraz lepszych specjalistów i to w wielu aspektach ich pracy. Trzeba tylko chcieć po to sięgnąć.

Po co Agile, czyli kontekst wdrożenia
Ach i jeszcze na koniec, bo zaczynam nudzić… Dla mnie podstawowym wyznacznikiem do podjęcia się wdrożenia metod lekkich jest odpowiedź na pytanie co tak faktycznie chcemy zmienić w obecnym procesie. Powszechna jest opinia, że z Agile będzie szybciej, lepiej, więcej, taniej, fajniej, lżej. WTF?

Może będzie szybciej, bo wcześniej klient dostanie to na czym mu zależało, a może szybciej się to wszystko wywróci i to też dobrze, bo można minimalizować straty. Czy będzie taniej? No pytanie dla kogo? Czasem faktycznie może się udać zmniejszyć koszty, ale częstsze będzie wykonanie produktu o wyższej jakości przy tym samym koszcie i czasie. Czy lżej? Na początku na pewno nie! Żadna z metodyk nie mówi nic o słodkim nieróbstwie (chyba, że coś przeoczyłem :-).

Tak więc Agile nie pomaga robić szybciej, taniej, więcej. Pomaga natomiast sprawnie ujawnić i rozwiązać problemy, które przed sobą postawimy - w naszym kontekście i z naszymi ludźmi.

3 comments November 4th, 2009

Zwinne Rozwijanie Oprogramowania

Dzisiaj chciałbym krótko zareklamować artykuł Pawła Lipińskiego z Pragmatists na temat “Zwinnego Rozwijania Oprogramowania”. Artykuł jest wprowadzeniem do filozofii kryjącej się za Agile Manifesto i zawiera interpretację zarówno czterech punktów manifestu, jak i dwunastu praktyk, które towarzyszą manifestowi (a o których często zapominamy).

Nie będę zbyt długo recenzował tego artykułu, bo nie mam się za bardzo do czego przyczepić :-) Zgadzam się zarówno z duchem całego artykułu jak i z interpretacją samego manifestu agile. Artykuł wypełnia lukę wśród materiałów na temat podstaw agile jakie można przeczytać po polsku, a jednocześnie zawiera wiele sugestii wynikających z praktyki.

Po lekturę odsyłam do Pragmatists oraz na bloga Pawła:

http://blog.pawellipinski.com/2009/10/wprowadzenie-do-zwinnego-rozwijania.html

Natomiast tekst polecam także jako czytankę, jaką można pokazać klientowi, którego chcemy uświadomić na temat tego, co do niego mówimy, kiedy próbujemy go przekonać, że te nasze czarne sztuczki to dla jego dobra :-)

Tymczasem czas samemu zabrać się za napisanie czegoś po polsku…

Add comment October 26th, 2009

Wakacyjne brakujące User Story

Właśnie wróciłem z krótkich wakacji, z których przywiozłem sobie osobliwą pamiątkę - ulotkę pizzerii oferującej pizzę na telefon z dostawą do domu. Czemu jest w niej coś dziwnego? O tym za chwilę :-) Najpierw zabawmy się w mini projekt tworzenia takiej ulotki. Jesteśmy pracownikami restauracji i zastanawiamy się jak też ma nasza ulotka wyglądać:

• Oferujemy pizzę z dostawą do domu… napiszmy to dużymi literami, żeby każdy się zorientował.
• Mamy promocję “Zamów 3 pizze, 4-tą dostaniesz gratis” - musi być na ulotce!
• Oczywiście musi tam być też lista naszych pizz i ceny (duży wybór, więc poświęcimy temu całą stronę)
• Mamy ograniczony budżet ulotka będzie więc czarno-biała
• Jeszcze trzeba wybrać jakieś ładne zdjęcia z pizzą na jedną i drugą stronę.

Macie już w głowie jakiś ogólny obraz ulotki? Taka zwyczajna… A nie brakuje na tej liście czegoś? To może inaczej… Spójrzmy na planowanie funkcjonalności ulotki oczami jej użytkownika i spiszmy user story:

• Jako klient chcę się dowiedzieć jakie pizze są dostępne (z jakimi dodatkami) i ile kosztują abym mógł wybrać odpowiednią pizzę dla siebie.
• Jako klient chciałbym się dowiedzieć czy są dostępne jakieś promocje, abym mógł ew. dokonać jakiegoś korzystniejszego zakupu.
• Jako klient chcę się dowiedzieć z ulotki jaki jest numer telefonu abym mógł zamówić pizze, które wybrałem.
• Jako klient chciałbym wiedzieć gdzie mieści się pizzeria, na wypadek gdybym chciał się jednak przejść i zjeść pizzę na miejscu zamiast zamawiać ją telefonicznie.

Teraz już chyba domyślacie się dlaczego ta ulotka z “pizzą na telefon” tak mnie rozbawiła… Autorzy zapomnieli o numerze telefonu i adresie. Jedyną wskazówką była nazwa restauracji, więc ostatecznie udało się znaleźć numer w internecie :-)

A cały ten wakacyjny epizod skojarzył mi się z user story dlatego, że patrzenie na wymagania z punktu widzenia użytkownika a nie z punktu widzenia technicznych aspektów projektu jest moim zdaniem szalenie istotne i może czasem uratować “projekt” :-). User stories doskonale się do tego nadają, zwłaszcza, że początkowo celowo ukrywają te techniczne, nieistotne na etapie formowania wizji, szczegóły (jak kolory, zdjęcia, rozkład na stronach).

Innym aspektem, który tylko teraz zasygnalizuję jest to, ze często same user story są pisane bardziej od technicznej strony z pominięciem tej części “aby…”, która niesie ze sobą wartość dla użytkownika. A więc dostarczajmy przede wszystkim wartość użytkownikom, a nie projekt odbiorcy.

Add comment August 3rd, 2009

O co nam chodzi z tym całym Agile?

Agile powoli staje się głównym nurtem w sferze zarządzania wytwarzaniem oprogramowania (przynajmniej na zachodzie). SCRUM wdarł się na dobre do zespołów i całych organizacji. Co raz częściej słyszy się o zmianie kierunku i adaptacji elementów systemu produkcyjnego Toyoty takich jak Kanban (przynajmniej dla mnie ten rok w zachodniej blogosferze minie pod znakiem szczególnego zainteresowania Lean Software Development i Kanban).

Jeśli więc hasła Agile, SCRUM, Lean, Kanban są dla Ciebie nowością, ale ktoś wokół zaczyna o tym rozmawiać i ciekawi Cię o co w tym wszystkim chodzi, to poniżej znajdziesz moją subiektywną selekcję miejsc od których możesz zacząć podróż w ten ciekawy świat…

Na początek lektura obowiązkowa!!!
http://www.agilemanifesto.org
http://www.agilemanifesto.org/principles.html

To drugie szczególnie, bo często zapominamy o tej części Agile Manifesto. Jak dla mnie ruch, którego promotorem jest “Uncle Bob”, czyli Rober C. Martin, jest nierozerwalną częścią kultury agile… A tak, czy mówiłem już kiedyś, że agile to kulutra, sposób myślenia i podejścia do wytwarzania oprogramowania, a nie tylko zbiór praktyk… jeśli nie to na pewno powiem, ale może innym razem :-). Także do lektury obowiązkowej dołączam też:

http://manifesto.softwarecraftsmanship.org

SCRUM:

Żeby nie startować od razu od Kanban, to na początek Scrum w pigułce od Mike’a Cohna (taki mini słowniczek):
http://www.mountaingoatsoftware.com/scrum

Książek na temat SCRUM i Agile jest na prawdę dużo i ciężko wybrać jakąś konkretną. Dla mnie najlepszym wyborem na start będzie książka Henrika Kniberga “Scrum and XP from the Trenches” (PDF za darmo dostępny na InfoQ):

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

Po pierwsze doskonałym uzupełnieniem do książki Henrika Kniberga o Scrum, jest jego artykuł “Kanban vs Scrum”:
http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf

A po drugie artykuł z InfoQ (polecam też śledzenie samego InfoQ!). Ten artykuł może jest ciut skomplikowany, ale są w nim zasygnalizowane wszystkie podstawowe rzeczy, więc to dobry start do ew. dalszych poszukiwań co te wszystkie dzwine rzeczy oznaczają:
http://www.infoq.com/articles/hiranabe-lean-agile-kanban

AGILE
Jeśli nie zmęczy Cię lektura i wciąż zafascynowany tematem dotrzesz do tego momentu, to polecam śledzenie blogów. Ja czytam między innymi (takie moje prywatne TOP 5):

http://agile-commentary.blogspot.com
http://blog.mountaingoatsoftware.com
http://www.agileforall.com/blog
http://blog.crisp.se/henrikkniberg
http://agileinaflash.blogspot.com

Zapytasz - A CZEMU TO WSZYSTKO PO ANGIELSKU!? A no bo w Polsce wciąż kiepsko z materiałami o Agile.
Tym bardziej warto się czegoś na ten temat nauczyć i poeksperymentować bo reszta świata ucieka…

Po polsku polecam posłuchanie sobie podcastów z AgileTuning:
http://agiletuning.pl

To tyle na start ode mnie… Ciekaw jestem co polecą inny czytelnicy (zwłaszcza w swerze Lean / Kanban). Właśnie zaczynamy eksperymenty z Kanban w 9-osobowym zespole utrzymaniowo testowym, więc już niedługo trochę wieści z tych eksperymentów na pewno ujawnię :-) Tymczasem miłej lektury.

4 comments July 11th, 2009

Zachęta, przynęta i takie tam…

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?

4 comments February 10th, 2009

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

Umowa fixed price w duchu agile

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

1. Strony zgodnie ustalają termin rozpoczęcia prac na dzień X a termin zakończenia prac na dzień Y.
2. Wykonanie umowy odbywać się będzie iteracyjnie, tj. w równych N tygodniowych etapach.
3. Po każdym etapie, począwszy od etapu nr 2, Zamawiający odbierze od Wykonawcy wykonane elementy Systemu oraz zgłosi uwagi i poprawki.
4. 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.
5. 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.
6. 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:

1. 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

1. Wynagrodzenie płatne jest w transzach po każdych … odebranych przez Zamawiającego etapach, proporcjonalnie do stopnia ukończenia prac nad Systemem.
2. 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.

6 comments December 10th, 2008

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

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…

2 comments December 8th, 2008

Harmonogram najważniejszy?

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.

2 comments June 10th, 2008