Battle for Agility

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

Zbierać dowody czy grać w pokera?

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.

4 comments March 31st, 2008

Ile iteracji jesteś w stanie wytrzymać?

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.

4 comments January 24th, 2008

Cena swobodnych zmian

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…

4 comments November 24th, 2007

Akcent Agile na JDD 07

Piątek spędziłem na Java Developers Day 2007. Dlaczego piszę tutaj o konferencji Java? W zeszłym roku agile było praktycznie w każdym wystąpieniu. Wszystkie produkty, praktyki, frameworki były agile. W tym roku coś się zmieniło… terminem agile nie wiało już z każdej prezentacji, co w sumie jest nawet lepsze, bo przywykliśmy do zbytnich nadużyć w kwestii stosowania agile wszędzie gdzie się tylko da.

Ale nie myślcie, że agile zniknęło z JDD. Także i tegoroczna edycja miała swój akcent w postaci wystąpienia Jakuba Dziwisza na temat “Test Driven Development w Java”. Wykład powinien być niedługo dostępny w wersji wideo na stronach organizatora konferencji, a na blogu Jakuba powinien się pojawić artykuł uzupełniający samą prezentację. Zaczęło się nieźle… Jakub przekonywał o zaletach TDD w tworzeniu oprogramowania, z czym generalnie się zgadzam. Były założenia TDD, trochę o trybie red - green - refactor, później prosty test, który nie przechodził ale wyznaczył funkcjonalność, implementacja (test przeszedł - byliśmy w green), wreszcie przyszedł czas na “refactor”.

Niestety etap refaktoryzacji zaprezentowany podczas wykładu był dla mnie nieco kontrowersyjny. Mianowicie za jednym zamachem uległa zmianie implementacja testowanej klasy i bez uruchomienia testów od razu uległa zmianie także implementacja samego testu. Być może nie było to zamierzone a jedynie podyktowane ograniczeniami czasowymi samej prezentacji, ale chciałbym podkreślić, że w TDD właśnie po to najpierw piszemy test, żeby później w trakcie refaktoryzacji móc na nim polegać zmieniając kod. Jeśli programista zacznie jednocześnie zmieniać kod testowany i kod testujący to jaką ma pewność czy zielony pasek nadal wskazuje, że kod działa, a nie że właśnie dostosował test do tego, żeby przechodził z nowym kodem? A co jeśli po takich jednoczesnych zmianach test nie przejdzie? Czy to oznacza że źle zrefaktoryzowaliśmy kod, czy może nie wyszła nam modyfikacja testu? Test ma łapać błędy powstałe podczas refaktoryzacji. Dopiero później przychodzi czas na ew. refaktoryzację samego kodu testów. Z reszta Jakub wspomniał o tym, że dobrze napisane testy nie powinny tak często wymagać zmiany, kiedy tylko refaktoryzujemy kod aplikacji.

Chciałbym się także odnieść do pytania, które padło z sali. Mianowicie “Do czego TDD się nie nadaje?”. Odpowiedzią było, że “nie nadaje się do utrzymania oprogramowania”. Z drugiej strony Jakub stwierdził, że nie wyobraża sobie napisania linijki kodu produkcyjnego bez wcześniejszego napisania testów. Ani jedna, ani druga odpowiedź nie do końca mnie satysfakcjonuje.

To jest generalnie dobre pytanie jeśli chodzi o agile, bo będąc entuzjastą jakiejś konkretnej praktyki lub wszystkiego co agile, dość łatwo mówi się o tym jakie to wszystko jest piękne, ale pamiętamy formułę “there is no silver bullet” prawda?

Akurat według mnie TDD doskonale nadaje się do utrzymania oprogramowania. Nie mówię tu bynajmniej o rozpoczynaniu krucjaty w pisaniu testów do wielkiego istniejącego systemu, który takich testów nie posiada. Byłoby to niewiarygodnie męczące i praktycznie nieuzasadnione jeśli chodzi o koszty. Ale jestem zdania, że w takim wypadku doraźne aplikowanie TDD do napotkanych błędów w tego typu kodzie jest bardzo dobrą praktyką.

Załóżmy, że zostaje zgłoszony błąd w utrzymywanym przez nas oprogramowaniu. Co należy zrobić?

1. Najpierw piszemy test, który reprezentuje oczekiwane przez nas prawidłowe działanie aplikacji (jesteśmy w fazie RED, test nie przejdzie, bo przecież mamy błąd w aplikacji).
2. Naprawiamy błąd. A skąd wiemy, że go naprawiliśmy? Bo przeszedł test, które wcześniej napisaliśmy. Jesteśmy w GREEN.
3. Skoro mamy poprawkę i test, który przechodzi, to czas na ew. REFACTOR. Wiemy, że mamy test, który odpowie czy nie zepsuliśmy poprawki.

Oczywiście w przypadku systemów, które nie posiadały wcześniej testów, faza 2 i 3 są trudniejsze, bo nie wiemy czy poprawka i refaktoryzacja nie wpłynęły negatywnie na inne części systemu na które nie mamy testów, ale cóż. Jeśli znajdziemy inny błąd to wracamy do kroku 1. W ten sposób doraźnie reagując budujemy powoli bazę testów dla systemu, który mogliśmy dostać w spadku. Przy okazji pisania testów uczymy się także samego systemu, a napisane w tym momencie testy zabezpieczą nas przed powrotem tego samego błędu w kolejnym wydaniu oprogramowania.

Czy w takim razie rozpoczynając nowy projekt można zastosować TDD wszędzie i nie powstanie ani linijka kodu bez testów, które najpierw nie przechodziły? Niestety nie zawsze jest to możliwe. Wg. mnie nie warto pisać testów jednostkowych dla klas GUI w aplikacjach typu desktop. Ciężkie jest także testowanie w ten sposób kodu widoków w aplikacjach webowych. Oczywiście to nie znaczy, że nie należy automatyzować testów tego typu elementów. Chodzi tylko o to, że są to elementy, które raczej nadają się do testów funkcjonalnych, najlepiej “nagranych” przy pomocy specjalnego oprogramowania przez testerów, a nie przez samych developerów i przynajmniej w moim przypadku nie bardzo sprawdzało się tutaj TDD w swojej czystej formie.

TDD to jednak jedna z bardziej interesujących praktyk agile, więc na pewno jeszcze do tego tematu wrócę.

Add comment October 28th, 2007

Początki są trudne, ale końcówki…

No właśnie… końcówka projektu, w którym próbujemy wprowadzać techniki agile może okazać się dużo trudniejsza niż pierwsze iteracje. Częściowo sami sobie na to zapracujemy, ale od początku. Posłużę się dwoma nieco różnymi kontekstami, z którymi przyszło mi się zmierzyć.

W pierwszym przypadku klientem była firma lokalna, w której miałem bezpośredni dostęp do właściciela produktu (czyli osoby zamawiającej) oraz jednocześnie osoby, która bardzo dobrze znała dziedzinę problemu i wymagania dla systemu. Jednak osoba ta nie była typowym użytkownikiem docelowej aplikacji. Krótko mówiąc raz w tygodniu miałem do dyspozycji tzw. user proxy, czyli kogoś kto nie jest sam użytkownikiem, ale w dużym stopniu może go reprezentować.

Druga sytuacja dotyczyła firmy zagranicznej, w której z kolei dostępny był (ale na odległość) bezpośredni użytkownik produktu (konsultant, który miał używać tworzonego narzędzia w swojej codziennej pracy).

W obydwu przypadkach mieliśmy do czynienia z kontraktem o ustalonej cenie, która wyznaczyła w oczywisty sposób budżet projektu a zatem i termin, którego nie powinniśmy przekroczyć. Wyceny zostały zrobione na bazie w miarę dokładnych list funkcjonalności (krótkie zdania co użytkownik może zrobić, takie pseudo user stories).

Co zdecydowaliśmy się zastosować?

• 1-2 tygodniowe iteracje,
• przed każdą iteracją wybór (z klientem) kolejnych funkcji do implementacji,
• po każdej iteracji prezentacja osobista lub zdalna (w formie wersji instalacyjnej działającej aplikacji),
• dziennik projektu + burndown chart do wewnętrznego śledzenia postępu pracy.

Jeden z projektów był pewnym wyzwaniem merytorycznym (ze względu na bardzo słabą znajomość dziedziny problemu), a drugi mógł przysporzyć raczej kłopotów technicznych (wydajność, bezpieczeństwo rozwiązań). Mimo założonego z góry zakresu i ustalonego sztywno kontraktu chcieliśmy dzięki powyższym technikom zapewnić sobie szybką informację na temat tego, że coś idzie nie tak jak zaplanowaliśmy i jak daleko ew. oddalamy się od budżetu. Poza tym chcieliśmy, aby klienci, którzy nie potrafili do końca sprecyzować wszystkich wymagań, ale jednocześnie wymagali od nas określenia z góry kosztu, mogli od samego początku śledzić kierunek rozwoju ich aplikacji (prezentacje po iteracjach).

Na początku trudność w iteracyjnym podejściu sprawia zespołowi głównie ta specyficzna dyscyplina jaką narzuca tygodniowy lub 2-tygodniowy rytm plan-implementacja-prezentacja. Z uporem maniaka będę przy takiej okazji powtarzał tym, którzy uznają metodyki lekkie za chaotyczne, aby spróbowali taką dyscyplinę pracy utrzymywać w swoim zespole i to tak, żeby wszyscy członkowie zespołu byli przekonani o wartości i jakości takiego sposobu. Ale nie o tym miało być…

Co się okazało. Otóż wszystko szło wyjątkowo dobrze. Klienci byli bardzo zadowoleni - cały czas widzieli jak ich produkt rośnie i podobało im się to (ten cel udało się osiągnąć najlepiej). Nam udało się utrzymać w terminie, tzn. w wyznaczonym czase klienci dostali produkty, które bardzo dobrze spełniały ich wymagania. Prawdopodobnie gdyby nie krótkie iteracje i częste konsultacje postępu prac, nie udałoby się to tak dobrze.

Końcówki obu projektów przyniosły jednak zaskoczenie. Lokalny klient (czyli ten, który nie był bezpośrednim użytkownikiem) dopiero w końcowej fazie projektu przekazał wersję beta znajomym użytkownikom i wróciło do nas kilka istotnych uwag. Dodatkowo czekamy teraz także na wieści “z placu boju”, czyli na wrażenia użytkowników z ich codziennej pracy.

Zagraniczny klient z kolei dopiero pod koniec poświęcił więcej uwagi na dokładniejsze zapoznanie się z programem i także zgłosił więcej uwag niż czynił to po poszczególnych iteracjach. Dodatkowo zbyt mocno zlekceważyliśmy chyba dług projektowy, któremu pozwoliliśmy urosnąć do kilkunastu godzin. Weszliśmy więc na koniec projektu w dobrze znaną fazę poprawek i zaczęliśmy konsumować naszą marżę.

Nie można oczywiście winić klienta za takie postępowanie. Po pierwsze jest do takiego trybu przyzwyczajony. Po drugie zawsze będzie miał uwagi. Na czym więc polegał błąd, bo oczywiście leży on po naszej stronie (sam się do niego przyłożyłem). Wydaje mi się, że wprowadzając do projektów elementy zwinnych metodyk za bardzo skupiliśmy się na poprawie własnego procesu wytwarzania, aby sprostać wymaganiom kontraktów, a za mało myśleliśmy o zaangażowaniu klienta w cały ten proces. Oczywiście wciągnęliśmy go bardziej niż zwykle (miał większy wgląd w postępy prac, wyznaczał kierunek rozwoju), tylko nie do końca z tego skorzystał a my zrobiliśmy za mało, żeby skorzystał więcej.

Być może gdybyśmy przerzucili rygor iteracyjnej pracy także na naszych klientów, to udałoby się uniknąć tej znacznie za długiej końcówki projektu. Gdyby końcowe problemy rozproszyły się na poszczególne iteracje, to może z projektów wypadłyby 1-2 funkcjonalności (zepchnięte na koniec dziennika jako najmniej ważne), a tak wilk (klient) został syty i bardzo zadowolony, ale owca (my) już nieco nagryziona.

Morał dla mnie taki, że klient jest nieodzowną częścią technik agile i nie można o tym zapomnieć, bo inaczej ulegamy tylko złudnemu przeświadczeniu, że wszystko idzie dobrze “po nowemu”, a na koniec i tak klient zrobi swoje. Nasza w tym głowa, żeby od samego początku klient stał się członkiem zespołu.

PS: Jak myślicie ile z wymagań zawartych w kontraktach zostało zrealizowanych inaczej niż to zakładały załączniki do umowy? To były krótkie projekty, ale w każdym znalazłbym co najmniej kilka przykładów :-)

2 comments March 1st, 2007

Zwinne działania zaczepne

Ponarzekałem sobie już sporo na skostniałe metody podejścia do projektów. Może nawet znajdziesz w tych narzekaniach trochę merytorycznych argumentów popierających przedstawiane tutaj tezy. Ale w końcu trzeba przejść do konkretów. Zaczynamy nowy projekt. Co zrobić aby wprowadzić do niego jak najwięcej praktyk agile. Po pierwsze nie należy starać się wprowadzać zbyt dużej liczby nowych elementów na raz. Wiele razy można było się spotkać z dyskusjami na temat tego, “jak bardzo agile się już jest”. Moim zdaniem dobry proces czerpiący ze zwinnych metodyk powinien przejawiać się w następujących aspektach:

• nastawienie na zmiany, jako naturalną kolej rzeczy (to jedna z cech przewodnich praktyk agile)
• iteracyjność przejawiająca się również (a może przede wszystkim) w samym wprowadzaniu agile do projektu - stosujmy te same praktyki na poziomie doskonalenia procesu, jak i na poziomie implementacji i doskonalenia samego systemu
• minimalizm w podejmowanych działaniach i maksymalizm w osiąganych efektach - najczęściej mylnie kojarzony tylko ze skracaniem czasu i obniżaniem kosztów pracy, podczas gdy chodzi także o ciągłe podwyższanie jakości i kompletności produktu oraz o doskonalenie “warsztatu”.

Wykonujemy pracę coraz szybciej i taniej nie dlatego, że robimy coraz słabsze systemy, tylko dlatego, że jesteśmy coraz lepsi, tak jak nasz lekki proces. Tak więc małymi krokami do celu. Proces wdrażania agile można zacząć od dołu, czyli od nas programistów. Nie koniecznie trzeba też od razu uświadamiać wszystkich managerów. Próbujemy wykonać mały krok. Jak się uda pochwalimy się sukcesem. Managerów od razu uspokajam… nie będę proponował samowoli, rewolucji, czy innych działań wywrotowych. Raczej nazwijmy je na razie drobnymi działaniami zaczepnymi. Pewne rzeczy można zrobić inaczej i to się opłaca. A zaczniemy od początku - czyli od szacowania i planowania.

Przed uruchomieniem projektu czas na krótki rekonesans - dochodzi do oszacowania zakresu i pracochłonności projektu (tak… trzeba klientowi podać cenę, a nie chcemy sobie strzelać w kolano). To pierwszy moment, kiedy możemy spróbować czegoś agile. Na temat zbierania i analizy wymagań napisano i powiedziano dotąd bardzo wiele. Ale mamy włożyć w to minimum środków, aby osiągnąć jak najlepsze wyniki. Potrzebujemy określić jaki system mamy zbudować.

Zebranie wymagań i zakres projektu

Zadaniem numer jeden będzie zebranie zespołu, który będzie wykonywał projekt i doprowadzenie do spotkania z klientem lub osobami, które będą określały wymagania. Każdy rzeczywisty użytkownik systemu będzie tutaj na wagę złota, ale pracujemy z tym kogo mamy. Podczas tego spotkania chcemy doprowadzić do pewnego rodzaju burzy mózgów wszystkich zebranych.

Pierwszym etapem spotkania będzie określenie, kto będzie użytkownikiem systemu. Chodzi o ustalenie ról użytkowników jacy mogą używać systemu (przerywamy wymyślanie, jeśli zauważymy, że z trudem przychodzą nam do głowy kolejne typy). Efektem może być krótka lista. Na koniec poświęćmy chwilę na ew. wyeliminowanie ról powtarzających się pod nieco inną nazwą, lub na pewną generalizację ról o podobnych zadaniach. Taka lista ułatwi nam realizację kolejnej części spotkania.

Podstawowa zasada - mamy zawsze dostarczać użytkownikom części systemu, które będą mogli użyć. Zaczynamy zastanawiać się jakie funkcjonalności ma ten system posiadać. Głównie opowiadać powinien klient, my dopytujemy o ew. szczegóły lub prosimy o wyjaśnienie niejasnych kwestii (często rzeczy oczywiste dla klienta nie są oczywiste dla programistów). Nie musimy być specjalistami w dziedzinie klienta, mamy się znać na tworzeniu systemów informatycznych. Dlatego pytajmy o wszytko czego nie rozumiemy - wyjaśnienia na tym etapie nic nie kosztują, później będzie gorzej. Sprawny kierownik czy analityk może często pomóc naprowadzać klienta na odpowiedni tor pytaniami, jeśli nie będzie on potrafił określić dobrze swoich potrzeb.

Wymagania będziemy spisywać w formie krótkich zdań objaśniających co użytkownik może lub chce zrobić z systemem (używajmy w tym celu wcześniej wyłowionych nazw ról). Np.:

“Klient sklepu internetowego może dodać do swojego koszyka produkt, którego szczegóły ogląda na stronie.”

“Pracownik BOK może zmienić na życzenie klienta zamówienie o podanym numerze. Wymaga to wcześniejszej autentykacji klienta sklepu”.

Takie krótkie opisy wymagań nazywamy historyjkami użytkownika (ang. user stories). Cała istota tych historyjek polega na tym, że powinny one być doskonale zrozumiałe dla klienta/użytkownika, a jednocześnie powinny stanowić dobry pogląd na to co system ma robić i co trzeba zaimplementować. User stories powinny być w miarę krótkie i powinny odpowiadać pojedynczym funkcjonalnościom, lub zestawom funkcjonalności, które nie mają sensu bez siebie nawzajem. Chodzi o to, żeby dało się je implementować osobno i w dowolnej kolejności. Tradycyjnie do zapisywania user stories polecane są niewielkie papierowe kartoniki (na tyle duże, aby takie user story się zmieściło, ale jednocześnie na tyle małe, żeby nie dało się na nich pisać całych opowiadań). Kartoniki są wygodne również z innego powodu - można je dowolnie mieszać, tasować, przekładać i wreszcie w dowolnej chwili taki kartonik można podrzeć.

Drugą ważną cechą user stories jest to, że zawsze powinny przedstawiać punkt widzenia użytkownika/roli. Dlatego aby zweryfikować czy dobrze myślimy o user story można zadać sobie klika pytań pomocniczych:

• Jak zaprezentuję implementację takiej pojedynczej historyjki klientowi?
• Jak użytkownik będzie mógł użyć tak przedstawionej funkcjonalności?
• Jak przetestować czy ta funkcja działa bez pisania dodatkowego kodu?
• Czy do implementacji tej funkcjonalności będę musiał ruszyć wszystkie warstwy systemu?

Znowu wyciągamy jak największą ilość historyjek od klienta/użytkownika. Kończymy kiedy zaczyna brakować pomysłów na nowe user stories. Cała taka sesja nie powinna trwać więcej niż kilka godzin. Jeśli zadanie jest wyjątkowo duże i skomplikowane, to warto podzielić je na mniejsze (np. podsystemy, moduły) i zorganizować klika sesji tematycznych. Z całą pewnością takie sesje zajmą mniej czasu niż tradycyjne wywiady analityków i tworzenie specyfikacji wymagań. Jeśli zespołowi i klientowi nie odpowiadają kartki, można użyć Excela lub innego prostego narzędzia. Chodzi o to, że nie zależy nam szczególnie na formie, tylko na treści.

To jest pewien model. Jeśli nie uda się go zrealizować za pierwszym razem, to trudno. Najważniejsze na tym etapie jest przejście na zapis wymagań odzwierciedlający punkt widzenia użytkownika, bez zbędnego narzutu technicznego. Z takim bagażem historyjek możemy przejść do szacowania…

Szacowanie czasochłonności

Jest wiele różnych technik szacowania. Najistotniejsze, aby w szacowaniu wzięli udział wszyscy członkowie zespołu, bo to oni potem będą mieli podjąć się realizacji poszczególnych zadań. Jeśli zespół jest niedoświadczony, to można do szacowania zaprosić również jednego czy dwoje bardziej doświadczonych kolegów z innych zespołów.

Szacujemy kolejno każdą z zebranych user stories. Każda osoba na własną rękę. Potem omawiamy krótko rozbieżności - ktoś mógł czegoś nie uwzględniać, albo wręcz przeciwnie - któryś z członków zespołu doskonale zna temat i wie, że pewne elementy można wykonać szybciej.

Największym problemem jest zwykle to w jakiej jednostce szacować? Tutaj pojawia się drugie miejsce gdzie można spróbować zastosować podejście najczęściej spotykane w technikach agile. Szacowanie w jednostkach “idealnych” lub wręcz wyimaginowanych (to drugie jest często wspominane ale osobiście uważam, że przynajmniej na start z agile nie bardzo się ono nadaje). Moja rada jest taka - jeśli do tej pory szacowaliśmy w firmie wszystko w osobogodzinach przechodźmy na idealne godziny programistyczne, jeśli w dniach przechodźmy na dni idealne. Jednym słowem, nie zmieniajmy radykalnie jednostki na jakieś punkty czy coś, do czego nie jesteśmy przyzwyczajeni.

Co to jest idealna godzina/dzień programistyczny? Jest to wyidealizowany czas, który poświęcilibyśmy tylko i wyłącznie na pracę nad wyznaczonym zadaniem. Czas zmierzony z zegarkiem w ręku, kiedy wszystkie nasze czynności wiążą się z wykonaniem zadania. Ĺťadnych rozmów z kolegami, żadnych odpowiedzi na rzucone w salę pytania, żadnych telefonów, kawy czy herbaty w kuchni, papierosa czy nawet wyjścia do toalety. Tylko praca w czystej formie. Każdy rozsądnie myślący człowiek powiedziałby w tym miejscu, że przecież takie dni czy godziny praktycznie się nie zdarzają. I oczywiście tak jest. Co więcej jest to zupełnie naturalne. W takim razie co to ma wspólnego z szacowaniem?

Każdy z nas udzielając odpowiedzi na pytanie “Ile potrwa zdanie X?” może jej udzielić, albo na bazie wcześniejszych doświadczeń związanych z takim samym lub podobnym zadaniem, albo starając się szybko w myślach rozłożyć zadanie na mniejsze znane mu elementy. Podświadomie porównujemy w takim momencie postawiony przed nami problem do innych, które już kiedyś rozwiązaliśmy. Chodzi o to, że myśląc o czasie, podświadomie myślimy w jednostkach idealnych. Tymczasem naszej pracy towarzyszy szereg innych czynności nie przekładających się bezpośrednio na tworzenie oprogramowania. Poza codziennymi nawykami, jak zrobienie sobie kawy, zdarza się też wiele zdarzeń nieprzewidywanych. Typowe z nich, to pytania od kolegów, odbieranie telefonów, itp. Nie jesteśmy w stanie przewidzieć ich ilości i zwykle tego nie robimy. “Zrobię to w maksymalnie 4 godziny” oznacza częściej “Zrobię to w maksymalnie 4 godziny, jak nic mi nie będzie przeszkadzać” niż “Jeśli uwzględnić 2 telefony po 5 min, jedno wyjście do toalety i może 3 pytania, którym poświęcę w sumie 10 min, to zadanie o które mnie pytasz zrobię w maksymalnie 4 godz.”

Każdy indywidualnie ma pewne tempo pracy, które można określi np. jako ilość idealnych godzin, jakie dana osoba jest w stanie faktycznie zrealizować w ciągu 8-godzinnego dnia pracy. Albo ilość idealnych dni jakie jesteśmy w stanie faktycznie zrealizować w 5-dniowym tygodniu. Ta wielkość często nosi nazwę wydajności (ang. velocity) i zależy zarówno od indywidualnych cech pracownika jak i od samego projektu czy też otaczającego nas środowiska pracy. Tradycyjne metodyki zarządzania projektami bardzo często nie uwzględniają takiego efektu. Agile natomiast zachęca do przejścia na szacowanie w jednostkach idealnych (skoro i tak okazuje się, że podświadomie właśnie tak szacujemy). Ważne będzie także ciągłe badanie velocity naszego zespołu, bo jest to narzędzie znacznie ułatwiające prognozowanie przyszłego stanu projektu.
Z każdym nowym projektem i przy w miarę stabilnym składzie zespołu powinno udać się nam zauważyć pewną średnią wartość takiej wydajności, a to już bardzo cenna informacja dla np. wycen projektu. Także w trakcie projektu należy badać wydajność, bo rozpoczynając dokonaliśmy pewnego przypuszczenia co do tego, na jakim poziomie będzie się ona kształtowała, a teraz czas to zweryfikować.

Tak więc naszą listę user stories oszacujmy w jednostkach idealnych przy zachowaniu używanej do tej pory wielkości (godzin lub dni). W dużym skrócie, aby podać klientowi przewidywaną cenę projektu, należałoby takie szacunki pomnożyć prze pewien współczynnik. Dla zespołu posiadającego już pewne doświadczenie i nie rozpraszanego zbyt często “zadaniami na boku” przyjąłbym przy pierwszym projekcie bezpiecznie taki współczynnik na poziomie 1,25 - 1,5. Wynik mnożenia da przewidywaną liczbę godzin lub dni roboczych, które już w miarę prosto da się przełożyć na koszty. Więc dalej manager może już z taką informacją przystępować do negocjacji. Niemniej na tym etapie nie robiłbym jeszcze takich mnożeń. Kolejnym krokiem będzie ubranie tak oszacowanych zadań w plan iteracji i ew, wydań, ale o tym następnym razem.

Tymczasem, jeśli kogoś zainteresowało podejście oparte na user stories i velocity (o którym też trochę więcej przy okazji planowania, bo tam będzie to użyteczna informacja), to polecam bardzo dobrą książkę Mike’a Cohna pt. “User Stories Applied” (niestety dostępna po angielsku).

Udanego pisania historyjek.

8 comments December 6th, 2006