Kategoria 'Agile dla klientów'
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.
November 4th, 2009
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…
October 26th, 2009
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.
August 3rd, 2009
Co prawda, to co za raz napiszę nie ma takiego bezpośredniego związku z agile, ale od jakiegoś czasu mnie to nurtuje. Zainspirowany lekturą książki “Implementing Lean Software Development” i korzystając z faktu, że mam akurat okazję obserwować tworzenie się zespołu typu nearshore, mam do was pytanie.
Jak zbudować relację firma matka - firma nearshore, tak aby obie opierały swoją pracę na modelu obopólnej korzyści? W języku angielskim jest takie zgrabne słowo incentive (zachęta? korzyść?). Gdzie szukać tej korzyści dla obu stron?W swojej książce Marry i Tom Poppendieck użyli przykładu outsourcingu usług typu help desk, gdzie wykonawcy wcale nie musi zależeć na rozwiązywaniu problemów klientów swojego zleceniodawcy jeśli jego model współpracy oparty jest na ilości obsłużonych błędów. W takim wypadku rozwiązywanie problemów odbiera pracę (i dochody) wykonawcy a to na pewno nie leży w jego interesie.
Mój przypadek jest bardzo pobony, tzn. firma typu nearshore buduje zespół głównie utrzymaniowy (być może w przyszłości także i rozwojowy). Spojrzmy na obie strony tego układu.
Klient:
- liczy na niższe koszty,
- potrzebuje nowych ludzi, a lokalny rynek się wyczerpał i bardzo trudno jest rekrutować specjalistów,
- zależy mu na tym, aby nowy zespół stał się równie wydajny jak jego własni ludzie
Wykonawca (firma typu nearshore):
- jest tańsza i łatwiej się jej pozbyć niż zwalniać własnych ludzi w razie kryzysu (modne słowo ;-),
- ma dostęp do ludzi i jest ich w stanie zrekrutować,
- zależy jej na trwaniu kontraktu i pozyskiwaniu coraz większej liczby zadań dla większej liczby ludzi bo zarabia na marży od ich pracy
No właśnie… pierwsze dwa punkty po obu stronach teoretycznie pasują do siebie i zwykle z połączenia właśnie takich celów rodzi się pomysł na nearshoring lub offshoring. Gorzej z punktem trzecim o którym jakoś cicho.
Zespół utrzymaniowy działa prawie jak help desk. Jeśli szybko rozwiąże problemy, to pozbawi się dochodu (jeśli rozliczany jest na godziny, czyli na zasadzie time and material). Z drugiej strony mamy jednak do czynienia z naprawianiem błędów oprogramowania. Gdyby przyjąć wynagrodzenie takiego zespołu oparte o ilość rozwiązanych problemów to byłoby to dość niebezpieczne dla wykonawcy, bo tego typu problemy bywają bardzo różne i jedne wymagają dużo więcej pracy niż inne.
Co powinny być w takim razie tą wspólną zachętą do współpracy dla obu stron, tak aby klient miał pewność, że jego partner wykona swoje zadania jak najlepiej i jak najszybciej, a wykonawca miał taki sam interes w takim właśnie podejściu do realizacji kontraktu? Czy to możliwe aby taki model współpracy nie wymagał skrupulatnej kontroli ze strony klienta, i ciągłego sprawdzania czy zespół nearshore pracuje a nie leży z założonymi rękami? Jak mierzyć wydajność takiego zespołu? Szacować pracochłonność zleceń tak jak szacujemy naszą pracę przy nowych projektach?
February 10th, 2009
Nie tak dawno powstała grupa, której celem jest wypracowanie pewnego szablonu kontraktu na wykonanie aplikacji wg metodyk agile.
Tak faktycznie w Polsce cały czas ciężko uciec od kontraktów typu fixed price ze względu na pewne przyzwyczajenia i strach przed innym rodzajem umowy, która nie zabezpieczałaby odpowiednio klienta (chociaż to raczej pobożne życzenie z tym zabezpieczeniem). No więc zamiast z tym walczyć może należy się z taką sytuacja “zaprzyjaźnić”. Żeby po raz kolejny nie wdawać się w pustą dyskusję na temat tego jakie to fixed price jest złe, postaram się tym razem zamieścić fragmenty faktycznych zapisów z umów jakie sami stosujemy u siebie. A więc podyskutujmy o konkretach…Na początek sekcja dotycząca trybu wykonania projektu:
TERMIN I SPOSÓB WYKONANIA UMOWY
- Strony zgodnie ustalają termin rozpoczęcia prac na dzień X a termin zakończenia prac na dzień Y.
- Wykonanie umowy odbywać się będzie iteracyjnie, tj. w równych N tygodniowych etapach.
- Po każdym etapie, począwszy od etapu nr 2, Zamawiający odbierze od Wykonawcy wykonane elementy Systemu oraz zgłosi uwagi i poprawki.
- Przed każdym kolejnym etapem Zamawiający określi elementy, które powinny być zrealizowane przez Wykonawcę w kolejnym etapie w pierwszej kolejności uwzględniając swoje uwagi zgłoszone po odebraniu etapu poprzedniego.
- Zamawiający może wprowadzić do zakresu projektu elementy nie przewidziane w załączniku nr 1. Pracochłonność nowych elementów zostanie oszacowana przez Wykonawcę i będą mogły one być zrealizowane w ramach niniejszej umowy bez zmiany wynagrodzenia, jeśli Zamawiający zrezygnuje z innych elementów o tej samej szacowanej pracochłonności. Uznaje się wtedy, że zakres projektu nie uległ zmianie. Nie ulega także zmianie termin ukończenia prac określony w pkt 1.
- W przeciwnym wypadku, tj. kiedy Zamawiający wprowadzi do planu nowe elementy bez usuwania z planu innych elementów Systemu, wynagrodzenie Wykonawcy może wzrosnąć proporcjonalnie do pracochłonności nowo wprowadzonych do planu elementów. W takim przypadku zmianie może ulec także termin ukończenia prac określony w pkt 1.
Jest też sekcja:
PRAWA I OBOWIĄZKI STRON
a w niej taki oto punkt, który określa nic innego jak proporcjonalność zapłaty do wykonanej do danego momentu pracy oraz wprowadza swobodę zakończenia projektu przy osiągnięciu odpowiedniej wartości przez klienta:
- Jeżeli wykonanie Systemu według zdefiniowanego w załączniku 1 zakresu okaże się niecelowe bądź jeżeli Zamawiający z przyczyn sobie wiadomych zrezygnuje z dalszego wykonywania umowy, Zamawiający będzie mógł odstąpić od niniejszej umowy za zapłatą odpowiedniej części wynagrodzenia za opracowanie Systemu na rzecz Wykonawcy, adekwatną do stopnia ukończenia Systemu.
I jeszcze może:
WYNAGRODZENIE
- Wynagrodzenie płatne jest w transzach po każdych … odebranych przez Zamawiającego etapach, proporcjonalnie do stopnia ukończenia prac nad Systemem.
- Wykonawca nie może żądać podwyższenia wynagrodzenia, jeżeli wykonał prace dodatkowe bez uzyskania zgody Zamawiającego na zasadach określonych w “TERMIN I SPOSÓB UMOWY”.
To nie są oczywiście wszystkie elementy umowy, ale pozostałe nie są tutaj interesujące bo zawierają raczej elementy standardowe nie związane z procesem agile w żaden sposób. Dodatkowo wyjaśnię tylko, że pojawiający się w powyższych punktach “załącznik nr 1″ (przecież każda dobra umowa musi taki załącznik zwierać :-) to nic innego jak lista user story z oszacowaniami w punktach (o tym jak taka listę do umowy budujemy w następnym poście).
Tym samym chciałbym zachęcić was do dyskusji na temat tego, co o takich zapisach myślicie? A może stosujecie inne, albo dodatkowe? Piszcie… a może uda się jakoś zebrać też i nasz polski sposób na kontrakt agile.
December 10th, 2008
Dlaczego decydujemy się na próbę wprowadzenia procesów agile? Najczęściej skuszeni jesteśmy obietnicą:
- szybszego dostarczania działającego oprogramowania (a co za tym idzie, lepszej wydajności naszych zespołów),
- lepszej jakości wytwarzania oprogramowania,
- szybszego reagowania na zmiany wymagań (i lepszego ukierunkowania się na klienta)
Pewnie w głowie każdy obiecuje sobie jeszcze kilka rzeczy, ale skupię się na tych trzech. A raczej na tym, co się stanie jeśli zaczniemy się skupiać na jednej z nich…
Dzisiaj usłyszałem od kogoś kogo mogę nazwać hmm… koordynatorem projektu? Niech będzie koordynator… No więc usłyszałem “jest dobrze, najważniejsze że mieścimy się w harmonogramie, harmonogram jest najważniejszy”. Jak to mierzymy? Chyba ilością zrealizowanych user story w stosunku do wyznaczonego w kontrakcie zestawu. Czyli mamy powiedzmy zakontraktowane 100 pkt, do dzisiaj powinniśmy mieć 30 pkt żeby projekt “wypalał” się nam w tempie gwarantującym dotrzymanie terminu. Może nawet jesteśmy do przodu w stosunku do planu.
Czyżby obietnica numer jeden była właśnie realizowana? Nic bardziej mylnego… niestety. Problem polega na tym, że nie w terminie jest klucz do sukcesu, ale w odpowiednich priorytetach. Co z tego, że dotrzymujemy terminów realizacji projektu jeśli na liście realizowanych funkcjonalności brakuje tych kluczowych. Ktoś może powiedzieć, że to oczywisty błąd, bo backlog projektu powinien być tak zbudowany, że na samym początku realizujemy najważniejsze user story. Więc jeśli tego nie robimy to sami kręcimy sobie pętlę na szyję.
Racja, chociaż sytuacja jak zwykle jest bardziej skomplikowana niż to się zakłada w tutorialach :-) Jeśli projekt cierpi na opóźnienie w dostarczaniu przez klienta niezbędnych informacji, to oprócz rozwiązywania tego problemu, na innym froncie trzeba robić co się da, nawet jeśli nie do końca jest to realizacja backlogu po linii priorytetów.
W takiej sytuacji może się okazać, że prosta statystyka zrealizowanych user story może nastrajać optymistycznie i uśpić czujność zarówno zespołu jak i klienta. A potem okaże się, że tak faktycznie to na tak powstałym produkcie nie da się realizować żadnego biznesu, bo składa się on głównie z terminowo zrealizowanych ozdobników.
Tak więc drodzy klienci… nie wierzcie samym statystykom… Zawsze patrzcie na wartość jaką niesie dla was każde nowe user story! Drogie zespoły (całe zespoły!) zawsze zadawajcie sobie podstawowe pytanie - do kogo skierowany jest produkt i czy to co właśnie macie zamiar zaimplementować pomaga użytkownikowi zrealizować jego podstawowe cele?
Z resztą ta druga rada jest bardzo podobna do porady na temat pisania dobrych user story. Zawsze kiedy piszemy lub implementujemy nowe story należy sobie zadać pytanie “jak mam zamiar zademonstrować wynik?”. To na pozór proste pytanie bardzo często ujawnia nasze braki w zrozumieniu zadania, podpowiada jak najlepiej zaimplementować dane user story, aby dobrze spełniało wymagania, wreszcie pozwala wskazać dużo testów akceptacyjnych.
Jeszcze raz… podstawą naszych działań jest wartość produktu a dopiero potem terminowość. Klient, kiedy terminy zaczną gonić, na pewno łatwiej poświęci mało istotne z punktu widzenia biznesu user story zamykające listę w backlogu jeśli zadania będą realizowane zgodnie z ich wartością, niż zdecyduje się na odpuszczenie istotnych user story, które zostały odłożone na koniec. I nie pomoże tutaj fakt, że do ostatniej chwili nasz harmonogram wyglądał idealnie.
June 10th, 2008
Podczas dyskusji na temat tinyPM, obiecałem odnieść się do opisanej przez Joela Spolsky’ego metody szacowania czasu wykonania projektu o nazwie “Evidence Based Scheduling“. Osobiście ta metoda wydaje mi się nieco przeładowana danymi jakie należy do jej poprawnego działania zbierać, no i w porównaniu z tym, co oferują techniki agile (story points, planning poker), zbyt czasochłonna i skomplikowana. Dodatkowo wydaje mi się, że jest obarczona pewnymi wadami, od których planning pokerowi udaje się uciec. Tak więc EBS bardziej pasuje mi do fixed time, fixed scope, ale po kolei…
Już na samym początku EBS zakłada, że cały nasz plan dla którego będziemy szacowali termin wykonania rozbijemy na zadania nie większe niż 16 godzin. Oczywiście zgadzam się z poglądem Joela Spolsky’ego, że jeśli ktoś mówi już o konkretnym zadaniu i twierdzi, że może ono zając 30 godzin, to zwykle nie wie o czym mówi, i nie zastanowił się nad tym co tak faktycznie będzie robił. Tylko, że jesteśmy na początku projektu i nie do końca chcemy rozbijać teraz wszystkie nasze user story na szczegółowe zadania. EBS wymaga szczegółowego planu całości, backlog z user story niekoniecznie - dopuszczamy tzw. epic stories, które maja większe oszacowania i zajmiemy się nimi jak przyjdzie ich czas (może nigdy nie przyjdzie, więc po co się nimi zajmować już teraz).
W EBS szacowanie odbywa się w idealnych godzinach, po czym śledzimy faktyczny czas wykonania każdego zadania. To da nam współczynnik velocity mówiący o tym ile tak faktycznie idealnych godzin dany programista jest w stanie wykonać w zadanym czasie (np. przez tydzień). Istotne jest to, że każdy szacuje zadania dla siebie a potem mierzy czas ich wykonania, aby uzyskać swoje indywidualne velocity. A co z programowaniem w parach - jak to oszacować? A co jeśli zadanie jednak weźmie ktoś inny niż ten, który je estymował? Czy zebrane w taki sposób velocity będą potem wiarygodne przy planowaniu następnych zadań, kiedy to już ten nowy wykonawca będzie sobie estymował pracę?
No to teraz weźmy planning poker. Podstawowe założenie - estymujemy jako zespół. Każdy programista poprzez swoją kartę z punktami wyraża opinię na temat każdego user story. Dyskutowane są wartości skrajne co daje całemu zespołowi pogląd na ew. obawy na temat zadań, prostsze rozwiązania czy założenia, które komuś mogły umknąć, a ktoś inny o nich pomyślał. W ten sposób powstaje wynegocjowane w zespole oszacowanie, z którym każdy czuje się komfortowo i nie będzie problemu z przejęciem zdania przez dowolną osobę.
Po drugie szacując w punktach nie musimy mierzyć ani indywidualnie, ani grupowo żadnych czasów wykonania. Po prostu w iteracji lub zadanym czasie widzimy ile dany zespół jest w stanie wykonać punktów. Zarówno w EBS jak i w metodzie punktowej na początek musimy coś założyć - ja wolę założyć velocity na zasadzie “przez pierwsze 2-3 iteracje przyjmijmy po 20 punktów” niż “no to teraz wygenerujmy dla każdego członka zespołu trochę losowych, ale jednak zbliżonych do siebie wartości velocity“. Już współczuję tym, których mieliby stosować EBS na kartkach, tablicy lub nawet w Excelu ;-)
No i pozostaje jeszcze jedna kwestia… EBS traktuje programistów jako osobne byty. Programista estymuje, programista wykonuje to co estymował, mierzy jak mu idzie, a swoje dane statystyczne dołączą do wielkiego planu. Programiści pracują różnie w różnych zespołach i dlatego widzę mały sens w śledzeniu ich indywidualnego velocity, które ma potem posłużyć jako dokładna baza przy kolejnych projektach. Moim zdaniem rozpoczynając nowy projekt można równie dobrze od nowa wygenerować trochę tych indywidualnych velocity na start. EBS próbuje zniwelować zmienność trafności oszacowań poszczególnych programistów poprzez jak najdokładniejsze rozbijanie zadań na części pierwsze.
W agile stawiamy na to, żeby to zespół jako całość zrobił wszystko najlepiej jak umie. Jeśli nasz zespół dostarcza określoną ilość user story w ciągu jednej iteracji i nie mamy zamiaru co chwilę zmieniać jego składu (prawda, że nie mamy? nie zmienia się przecież zwycięskiego składu), to velocity zespołu jest wystarczającą podstawą do szacowania terminu ukończenia projektu. Prostą metodą i kilkoma spojrzeniami na tablicę można zarówno dokonać prognozy jak i jej weryfikacji w dowolnym momencie. Metoda Monte Carlo… hmm doskonale nadaje się do narzędzia wspomagającego zarządzanie, no bo kto by to sobie liczył na piechotę… Tak się dobrze składa, że pomysłodawca zaimplementował te obliczenia w swoim produkcie. No dobrze, może o jedno szyderstwo za daleko - w końcu mam bardzo duży szacunek do Joela Spolsky’ego. Wolę jednak prostotę i przejrzystość velocity opartego na punktach i mierzonego na zespół i przez zespół.
Wreszcie ostatnia rzecz… Jaki jest sens podawania klientowi, że wszystkie zadania w określonym przez niego terminie wykonamy z prawdopodobieństwem 72%? Każdy klient z jakim miałem do tej pory do czynienia po takim oświadczeniu spojrzałby się na mnie z politowaniem i zadał mi pytanie jeszcze raz… To jesteście w stanie to zrobić czy nie? Ach… czyli jednak nie, no to ile jesteście w stanie zrobić? Przecież tak faktycznie każdego klienta w danym momencie interesuje prawdopodobieństwo 100% i to czy wszystkie zadania zmieszczą się w jego wymarzonym terminie. A i tak wiemy, że to 100% dzisiaj i tak nie daje żadnej gwarancji. Już po tygodniu okaże się, że to już jednak bliżej 98%.
Tutaj po raz kolejny lepsze wydaje mi się planowanie iteracji wg. priorytetów, oszacowań punktowych i założonego (na początku) lub zbadanego (w trakcie trwania projektu) velocity zespołu. Mamy listę user story uszeregowaną w kolejności od najważniejszych do tych “fajnie byłoby mieć”. Każde user story ma przydzielone punkty. Zespół wykonuje N punktów w ciągu tygodnia, więc na tej podstawie możemy określić kiedy projekt powinien się zakończyć. Za późno, no to patrzymy na tą bliższą naszemu sercu datę… Odpadają 2 iteracje i od razu widać co się w tych iteracjach nie załapało… Nie, nie możemy jednak żyć bez kliku user story ale i data jednak lepsza ta wcześniejsza… Trudno, bierzemy coś z tych dwóch iteracji, ale trzeba będzie (z ciężkim sercem) wyrzucić coś innego i to nie na 72%… Trzeba będzie coś wyrzucić na 100% :-)
Tak więc zacięcia detektywistycznego nie mam, wybieram jednak partyjkę pokera w story cards.
March 31st, 2008
No właśnie… W metodyce Scrum używamy określenia sprint dla, zwykle trzydziestodniowej, iteracji. I tak sobie myślę, że to bardzo trafne określenie. Tylko czy sprinter jest w stanie być długodystansowcem? Ideą iteracyjnego podejścia do tworzenia oprogramowania jest zachowanie stałego rytmu i dyscypliny pracy oraz skupienie się na ciągłym dostarczaniu działającego produktu.
Rytm. Iteracje z założenia są równe. Czasem robi się odstępstwo dla tych początkowych, ale później staramy się utrzymać już jednakową długość, bo tylko wtedy można coś sensownego wyczytać z liczonych po drodze metryk takich jak np. velocity (czyli wydajność zespołu) i obserwować jakieś trendy. Rytm dodatkowo pomagają utrzymać spotkania na początku i końcu iteracji, kiedy planujemy i podsumowujemy efekty naszej pracy.
Dyscyplina. Wymaganie dostarczania co iterację nowej, działającej wersji produktu powoduje, że czas jest lepiej wykorzystywany. Dobrze znany z podejścia kaskadowego efekt wypoczywających na początku projektu programistów, którzy potem nadrabiają przez ostatni tydzień braki w projekcie nie powinien zdarzyć się w podejściu iteracyjnym. Iteracje są na tyle krótkie, że nie można sobie pozwolić na zbyt długie rozluźnienie i bujanie w obłokach, albo na prywatne wycieczki programistów w rejony, które ich szczególnie kuszą, ale niekoniecznie muszą być związane z kluczowymi funkcjami systemu i wymaganiami klienta. Tutaj trzeba zamknąć kolejną wersję w 2-3 tyg. i ma ona działać. Opowiadanie klientowi, jaki to fantastyczny schemat bazy danych udało nam się w tym czasie zaprojektować nie pomoże, jeśli nie pokażemy systemu w działaniu. Liczą się zaimplementowane funkcjonalności.
Skupienie. Chodzi przede wszystkim o skupieniu się na głównym celu i kluczowych funkcjach. Czasu w iteracji jest stanowczo za mało, żeby pozwolić sobie na implementację funkcji o niskim priorytecie, bo nie zdążymy z rzeczami dla klienta najważniejszymi. I on szybko się o tym dowie - w najgorszym wypadku pod koniec iteracji.
Ten tryb pracy przynosi naprawdę dobre efekty. Ale ile takich iteracji jest w stanie wytrzymać programista? Czy stojąc właśnie u progu 30-tej iteracji nadal jest taki skupiony i zdyscyplinowany? Przyjęło się, że velocity powinno się w zespole ustabilizować po 2-3 pierwszych iteracjach i potem można już zacząć przewidywać kiedy zespół jest w stanie skończyć kolejne zaplanowane i oszacowane funkcje oraz ile ich wejdzie w każdą kolejną iterację. Jednak pracując iteracyjnie jesteśmy jak sprinter - wiemy, że mamy przebiec krótki dystans i wkładamy w to całą swoją energię. Nie jesteśmy tak jednak w stanie przebiec maratonu.
Rys. Utrata wydajności zespołu agile.
Wydaje mi się, że ta ustabilizowana z czasem wydajność zespołu agile musi prędzej czy później się załamać. Tylko kiedy jest ten moment? Ciekaw jestem jakie wy macie doświadczenia z tego typu projektami? Jaki był wasz najdłuższy projekt prowadzony wg. agile? Jaką długość iteracji uznajecie za idealną? Ja osobiście chyba najbardziej lubię iteracje dwutygodniowe a pojedynczy projekt nie przekroczył jeszcze w moim przypadku 7-8 miesięcy. Obawiam się jednak, że blisko już jestem maksymalnego pułapu.
January 24th, 2008
Jeden z pierwszych artykułów, jakie zamieściłem na tym blogu był moim atakiem na kontrakty o ustalonej cenie. Byłem przekonany, że ciężko tego typu kontrakty pogodzić z ideą agile, z gotowością do zmian oraz dobrą współpracą z klientem. Dzisiaj muszę nieco zrewidować ten pogląd. Największym problemem takich kontraktów wcale nie jest ustalona cena, czy termin, tylko ustalony zakres projektu. Barierą dla agile jest zamrożenie tych trzech elementów na raz w danym kontrakcie. Jeśli natomiast klient uwolni zakres, dopuści możliwość zmian funkcjonalności opisanych w umowie lub wymiany ich na inne, to stwarza to doskonałe warunki do tego, żeby jednak agile zastosować.
Co sie jednak stanie kiedy uwolnimy wszystkie trzy czynniki - czas, budżet i zakres? Coraz bardziej skłaniam się ku myśli, że taka wolność może być dużo bardziej problematyczna.
Od kilku miesięcy biorę udział w projekcie z rodziny Web 2.0. Finansowanie projekt opiera się o sprzedaż pewnej wizji osobom trzecim i oczekiwaniu zysku, kiedy strona zostanie uruchomiona (czyli raczej modelowy scenariusz współpracy pomysłodawca - inwestor). W tym projekcie wspomniane trzy elementy (czas, pieniądze i zakres projektu) są określone następująco (moja subiektywna ocena):
- Czas - chcemy wystartować jak szybko sie da.
- Pieniądze - mamy ich tyle ile dadzą nam inwestorzy. Budżet wyznacza nam także jak długo uda się utrzymywać zespół programistów. Niemniej budżet jest otwarty, bo jeśli pokażemy postępy inwestorom to wypłacą nam kolejne pieniądze.
- Zakres - plany mamy ogromne, dużo większe niż jesteśmy w stanie w tej chwili sfinansować.
Jak w takich warunkach podeszliśmy do realizacji projektu? Na początku przeprowadziliśmy warsztaty (3 pełne dni), podczas których zapoznaliśmy sie z wizją i zakresem projektu oraz pomysłami na biznes. Sami także mieliśmy możliwość zgłoszenia wątpliwości i własnych pomysłów. To wszystko doprowadziło do spisania kilkudziesięciu user story (mniej lub bardziej dokładnych). Wyceniliśmy każde z user story w punktach i wybraliśmy kilkanaście podstawowych, bez których nie da się ruszyć z miejsca. Na początek termin został ustalony sztywno - musimy mieć podstawową funkcjonalność po 3 miesiącach, bo tyle jest na początek pieniędzy.
Brzmi znajomo? Tak - warunki jak przy kontrakcie typu fixed price:
- pomysłodawcom było stosunkowo łatwo określić co jest teraz ważne a co może poczekać,
- nas zmusiło do skupienia sie na zaimplementowaniu najważniejszych funkcjonalności bez zbędnych wodotrysków,
- cotygodniowe spotkania podsumowujące iterację (iteracje mamy 1 tygodniowe) pozwoliły trzymać projekt na właściwym kursie i zaplanować 2 kolejne iteracje, ew. rozwiać wątpliwości czy przedyskutować pewne rzeczy.
Po pewnym czasie warunki uległy jednak zmianie. Perspektywa kolejnych inwestycji w projekt stała się bardziej realna, co spowodowało rozluźnienie czynnika ceny/budżetu. Po pierwszym pokazie i starcie wersji alpha zmalała także presja czasu. Wreszcie, projekt zaczęło oceniać szersze grono pierwszych testerów. Zaczęło go jednak oceniać wybiórczo, bo mając do dyspozycji system, który nie realizuje jeszcze całego procesu prowadzącego do zarabiania pieniędzy. Tak więc testerzy już proszą o ulepszenia i lukier na istniejących funkcjonalnościach, a w backlogu projektu czeka duża część user story koniecznych do zrealizowania początkowej wizji.
Najpierw zostaliśmy zarzuceni całą masą mały poprawek i usprawnień, które uzyskały wyższy priorytet niż kluczowe user story, bo stanowiły komentarz pierwszych użytkowników. Oczywiście zespół jest gotowy zrealizować dowolne user story w (prawie) dowolnym momencie. Akceptujemy zmiany priorytetów, zmiany w funkcjonalnościach (niektóre przerabialiśmy już kilkukrotnie). Wszytko to jest uzasadnione, skoro system dzięki tym zmianom będzie lepszy a klient i użytkownicy będą zadowoleni.
Jednak od kiedy nie gonią nas już tak mocno czas i pieniądze, coraz częściej nasz klient ulega pokusie dopieszczania istniejących funkcjonalności. Ostatecznie udało się nam przekonać go, żeby tylko część czasu w iteracji poświęcić na takie zmiany i wrócić na główny tor realizacji tych faktycznie kluczowych elementów systemu.
Jest też drugi aspekt tej swobody. W metodach agile nastawiamy się jawnie na zmiany, bo prowadzą one do powstania lepszego produktu. A lepszy produkt to zadowolony klient. Tylko czy zespół jest w stanie dobrze realizować ciągłe zmiany? Od kilku tygodniu obserwuję, że poniedziałkowy plan kolejnych dwóch iteracji w niczym nie przypomina tego, który oglądaliśmy jeszcze w piątek dwa dni wcześniej. W kolejnej iteracji prawie zawsze zastajemy inne user story, niż te na które mogliśmy sie już szykować. No dobrze, implementujemy, ale mam wrażenie, że zaczynamy tracić z oczu główny cel. Zaczynają w projekcie funkcjonować raczej cele “lokalne”, krótkoterminowe.
Ktoś porównał kiedyś prowadzenie projektu agile do prowadzenia samochodu. Aby dojechać do celu nie ustawiamy kierownicy w jednej pozycji i liczymy, że to wystarczy. Ciągle korygujemy kierunek jazdy aby dotrzeć na miejsce. Problem w tym, że za mocne szarpanie kierownicą także nie doprowadzi nas do celu, a raczej sprowadzi nas na przydrożne drzewo.
Agile bardzo mocno polega na dyscyplinie, a tą trudno jest utrzymać, jeśli nie mamy żadnych ograniczeń. W naszym projekcie jest nam coraz trudniej zamknąć kolejną iterację mając poczucie, że przybyła z nią kolejna ważna funkcjonalność. Częściej jest to całą seria drobiazgów i tylko 1-2 większe rzeczy. Być może zaczyna nam brakować czasu w 1 tygodniowej iteracji, bo funkcjonalności są trudniejsze w realizacji niż na początku. Ale wydaje mi się, że za daleko zabrnęliśmy w tej swobodzie.
Wyszliśmy od sztywnych ram projektu, gdzie standardowo niczego nie da się ruszyć, a dotarliśmy do drugiej skrajności gdzie swoboda zmian jest praktycznie nieograniczona. Decydując się na iteracyjne wykonanie projektu nie możemy tracić z oczu końcowego rezultatu. Iteracje nie mogą sie zamienić w owczy pęd polegający na wykonaniu kolejnych user story. Te user story mają składać się na pewien obraz iteracji, a kolejne iteracje mają krok po kroku prowadzić projekt do celu, który jest jasny dla całego zespołu…
Ciekawe jakie user story znajdę w planie kolejnej iteracji :-) Jeszcze dzisiaj były to…
November 24th, 2007
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 :-)
March 1st, 2007
Previous Posts
tinyPM
jest lekkim narzędziem służącym do zarządzania projektami według metod agile i wspierającym
iteracyjne wytwarzanie oprogramwania, wymagania na bazie user stories, estymacje punktowe,
tablice z kartami zadań czy wiki.