Battle for Agility

Harmonogram najważniejszy?

Dlaczego decydujemy się na próbę wprowadzenia procesów agile? Najczęściej skuszeni jesteśmy obietnicą:

• szybszego dostarczania działającego oprogramowania (a co za tym idzie, lepszej wydajności naszych zespołów),
• lepszej jakości wytwarzania oprogramowania,
• szybszego reagowania na zmiany wymagań (i lepszego ukierunkowania się na klienta)

Pewnie w głowie każdy obiecuje sobie jeszcze kilka rzeczy, ale skupię się na tych trzech. A raczej na tym, co się stanie jeśli zaczniemy się skupiać na jednej z nich…

Dzisiaj usłyszałem od kogoś kogo mogę nazwać hmm… koordynatorem projektu? Niech będzie koordynator… No więc usłyszałem “jest dobrze, najważniejsze że mieścimy się w harmonogramie, harmonogram jest najważniejszy”. Jak to mierzymy? Chyba ilością zrealizowanych user story w stosunku do wyznaczonego w kontrakcie zestawu. Czyli mamy powiedzmy zakontraktowane 100 pkt, do dzisiaj powinniśmy mieć 30 pkt żeby projekt “wypalał” się nam w tempie gwarantującym dotrzymanie terminu. Może nawet jesteśmy do przodu w stosunku do planu.

Czyżby obietnica numer jeden była właśnie realizowana? Nic bardziej mylnego… niestety. Problem polega na tym, że nie w terminie jest klucz do sukcesu, ale w odpowiednich priorytetach. Co z tego, że dotrzymujemy terminów realizacji projektu jeśli na liście realizowanych funkcjonalności brakuje tych kluczowych. Ktoś może powiedzieć, że to oczywisty błąd, bo backlog projektu powinien być tak zbudowany, że na samym początku realizujemy najważniejsze user story. Więc jeśli tego nie robimy to sami kręcimy sobie pętlę na szyję.

Racja, chociaż sytuacja jak zwykle jest bardziej skomplikowana niż to się zakłada w tutorialach :-) Jeśli projekt cierpi na opóźnienie w dostarczaniu przez klienta niezbędnych informacji, to oprócz rozwiązywania tego problemu, na innym froncie trzeba robić co się da, nawet jeśli nie do końca jest to realizacja backlogu po linii priorytetów.

W takiej sytuacji może się okazać, że prosta statystyka zrealizowanych user story może nastrajać optymistycznie i uśpić czujność zarówno zespołu jak i klienta. A potem okaże się, że tak faktycznie to na tak powstałym produkcie nie da się realizować żadnego biznesu, bo składa się on głównie z terminowo zrealizowanych ozdobników.

Tak więc drodzy klienci… nie wierzcie samym statystykom… Zawsze patrzcie na wartość jaką niesie dla was każde nowe user story! Drogie zespoły (całe zespoły!) zawsze zadawajcie sobie podstawowe pytanie - do kogo skierowany jest produkt i czy to co właśnie macie zamiar zaimplementować pomaga użytkownikowi zrealizować jego podstawowe cele?

Z resztą ta druga rada jest bardzo podobna do porady na temat pisania dobrych user story. Zawsze kiedy piszemy lub implementujemy nowe story należy sobie zadać pytanie “jak mam zamiar zademonstrować wynik?”. To na pozór proste pytanie bardzo często ujawnia nasze braki w zrozumieniu zadania, podpowiada jak najlepiej zaimplementować dane user story, aby dobrze spełniało wymagania, wreszcie pozwala wskazać dużo testów akceptacyjnych.

Jeszcze raz… podstawą naszych działań jest wartość produktu a dopiero potem terminowość. Klient, kiedy terminy zaczną gonić, na pewno łatwiej poświęci mało istotne z punktu widzenia biznesu user story zamykające listę w backlogu jeśli zadania będą realizowane zgodnie z ich wartością, niż zdecyduje się na odpuszczenie istotnych user story, które zostały odłożone na koniec. I nie pomoże tutaj fakt, że do ostatniej chwili nasz harmonogram wyglądał idealnie.

2 comments June 10th, 2008

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

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

Agile po norwesku

Wczoraj obejrzałem wywiad z Mary i Tomem Poppendieck zamieszczony na InfoQ, który polecam. Ale nie o sam wywiad chodzi, a jedną drobną wypowiedź, która mnie szczególnie zainteresowała. Mary zapytana o to jak mają się kontrakty o ustalonej cenie (ang. fixed price) do idei Lean Software Development wspomniała o tzw. standardowym kontrakcie PS2000 jaki wypracowany został w… Norwegii.Z tego co wynika z krótkiego opisu tego kontraktu, został on opracowany przez Norwegian University of Science and Technology (NTNU) oraz przedstawicieli norweskiej administracji rządowej i wiodące norweskie firmy w ramach programu badawczego Project 2000.

Główne cechy tego kontraktu to:

• podnoszenie efektywności procesu wytwarzania oprogramowania
• wspieranie się zbiorem “dobrych praktyk”
• narzędzia do zarządzania niepewnością w projekcie (jego nieznanymi w danym momencie elementami)
• etapowy, iteracyjny model poznawania wymagań i tworzenia systemu
• bliska współpraca wykonawcy i zamawiającego
• zyski i sankcje w kontekście dotrzymania założonych kosztów
• procedury rozwiązywania konfliktów poprzez mechanizm mediacji

Jak pisze Mary Poppendieck w książce “Implementing Lean Software Development - From Concept to Cash“, ideą powstania takiego rodzaju kontraktu było przeświadczenie, że elastyczny iteracyjny model tworzenia oprogramowania najlepiej nadaje się do dużych projektów IT prowadzonych w warunkach sporej niepewności i wysokiego ryzyka (a do takich należą np. projekty rządowe). Takie podejście wymaga dodatkowo porozumienia pomiędzy obiema stronami (wykonawcy i odbiorcy) opartego na zaufaniu i współpracy. Założeniem takiej współpracy jest także zgoda co do tego, że tak zbudowany zespół jest najlepiej przygotowany do wypracowania wspólnego stanowiska prowadzącego do osiągnięcia celu, jakim jest oczekiwany system IT.

Innymi słowy, można zastosować z powodzeniem elementy metodyk lekkich do zarządzania tak dużymi projektami jak zamówienia publiczne. Najważniejszą cechą kontraktu PS2000 jest to, że sam kontrakt określa zasady współpracy pomiędzy stronami, sposób w jaki obie strony przedsięwzięcia będą współpracowały ze sobą, a nie to co zostanie dostarczone. Kontrakt określa kto będzie podejmował decyzje, jak będą rozwiązywane ew. spory (mediacja), natomiast same cele, funkcjonalności i koszty są zawarte w aneksach. Dodatkowo aneks dotyczący kosztów określa jak obie strony będą dzielić między sobą ew. oszczędności z wcześniejszego wykonania projektu oraz straty jeśli koszty zostaną przekroczone.

Kilka dodatkowych informacji można znaleźć pod adresem: http://dataforeningen.no

Add comment February 23rd, 2007

Kontrakty o ustalonej cenie i zakresie - mitologia stosowana.

Niedawno przeczytałem wywiad z Paulem Klippem, jakiego udzielił on na łamach portalu IT w Krakowie. Zapytany o to, czy jego firma realizuje projekty dla klientów z Polski wykorzystując metody agile, odpowiedział między innymi:

“Dopóki polscy klienci nie zdadzą sobie sprawy z tego, że oferty o ustalonej cenie i ustalonym zakresie funkcjonalności im szkodzą i dopóki nie zaczną zwracać większej uwagi na jakość oprogramowania, nie będę miał zbyt wielu okazji realizować tutaj projektów z wykorzystaniem agile.”

Z jednej strony zgadzam się z tym całym sercem, ale z drugiej strony jak polscy klienci mają sobie zdać sprawę z tego co tak faktycznie dostają prosząc o kontrakt z ustalonym zakresem i ceną? Ostatnio wydawało się, że jeden z klientów firmy w której pracuję da się namówić na poprowadzenie projektu wg założeń agile, jednak po kilku dniach poprosił o kontrakt z ustaloną ceną i zakresem. Poniosłem osobistą klęskę, ale skłoniło mnie to do zastanowienia się nad tym z czym kojarzy się naszym klientom wykonanie projektu technikami agile (o ile w ogóle z czymś im się kojarzy), a jaka jest percepcja zamkniętych kontraktów? Z czego wynika ich obawa przed agile? A z czego wynika to poczucie bezpieczeństwa jakie odnajdują oni w zamkniętych kontraktach.

Miałem okazję uczestniczyć w wielu rozmowach z klientami, które prowadziły do stworzenia słynnego dokumentu “Specyfikacja Wymagań Systemowych”, a który następnie stawał się załącznikiem do umowy. Jakich korzyści dopatruje się klient w zamkniętym kontrakcie?

Według klientów najlepsze cechy kontaktów zamkniętych to zwykle:

1. Ustalony zakres kontraktu. Przedstawiam wykonawcy moje oczekiwania. On przygotowuje dla mnie zestawienie, może także dokładną specyfikację tego co zostanie wykonane. Wszystko to ma formę załącznika do kontraktu. Obaj wiemy co zostanie wykonane.
2. Ustalona cena kontraktu. Wykonawca na podstawie zakresu podał mi ile godzin zajmie wykonanie projektu. Na tej podstawie wyliczył cenę za wykonanie (W uproszczeniu liczba godzin x stawka za godzinę). Na samym początku wiem czy stać mnie na program czy nie. Mogę także porównać wiele ofert i wybrać tą najkorzystniejszą cenowo.
3. Ustalony termin wykonania. Przedstawiłem wykonawcy co chcę otrzymać (mam załącznik do umowy) i ten zakres projektu został wyceniony zarówno w godzinach jak i w kwotach. Wiemy więc także kiedy projekt zostanie zakończony.
4. Karne odsetki. O tak, jeśli wykonawca się spóźni, to za każdy dzień zwłoki zapłaci mi karne odsetki.

Brzmi pięknie prawda? A jak jest naprawdę? I dlaczego jednak w większej części przypadków wykonanie takich kontraktów kończy się frustracją klientów, managerów i programistów.

Ustalony zakres kontraktu
W grze pod tytułem “budowanie specyfikacji” biorą udział dwie strony (mam nadzieję, że nie jest to w naszych realiach nadmierny optymizm) - klient i wykonawca. Aby można było z czystym sumieniem powiedzieć, że możliwe jest ustalenie stałego zakresu projektu musiałyby być spełnione pewne warunki.

Po pierwsze klient musi dokładnie wiedzieć co chce otrzymać. Jak taki system ma wyglądać, żeby dokładnie spełniał jego wymagania? Jakie powinien mieć funkcje? Ale przecież klient przychodzi do nas i prosi o zbudowanie systemu, którego nie posiada, którego nie widział nigdy na oczy, albo widział coś podobnego, co spowodowało, że przyszły mu do głowy nowe pomysły. Jednym słowem przychodzi do nas z wizją czegoś co ma mu ułatwić życie. Czy wizję można zamknąć w sztywne ramy specyfikacji? Zamknąć zakres?

Po drugie wykonawca musiałby wręcz czytać w myślach klienta, aby specyfikacja jaką stworzy w 100% odpowiadała temu co klient miał na myśli.

Oczywiście trzeba tu rozsądnie rozdzielić budowanie produktów w pewnym sensie innowacyjnych, dostosowanych do potrzeb klienta, od wdrożeń np. prostych stron internetowych czy gotowych rozwiązań. W tym drugim przypadku można oczywiście rozłożyć projekt na części pierwsze i powiedzieć, że będą konieczne określone elementy, zadania i zasoby. Jeśli taką pracę nasz zespół wykonywał już wielokrotnie i doskonale ją zna to ma to się nawet szansę udać. Postępujemy wtedy według schematu, więc i kontrakt może być schematyczny.

Ale czy klient przychodzący do nas z zapytaniem ofertowym o budowę np. systemu zarządzania pewnym procesem biznesowym w jego przedsiębiorstwie, w którym to procesie bierze udział kilkadziesiąt osób, jest nam w stanie powiedzieć jakiego dokładnie (z najdrobniejszymi szczegółami) oczekuje działania. Pewnie wielu z nas stwierdziłoby w tym momencie, że przecież od tego są analitycy i projektanci. Klient nie musi wiedzieć wszystkiego. Pomożemy mu dojść do tej wiedzy. Przeprowadzimy wywiady, będziemy projektować, modelować, rysować i pisać długie dokumenty. W optymistycznym wariancie na końcu tego długiego procesu otrzymamy faktycznie coś co będzie można nazwać szczegółowym zakresem oraz projektem systemu (osobiście jeszcze takiego dokumentu nie widziałem). Załóżmy nawet, że uda się określić co do godziny ile czasu zajmie każdy z elementów.

I co z tego ma klient? Spędził z nami tydzień, miesiąc. Ten czas zostanie mu oczywiście doliczony do ceny kontraktu, a cena analityka i projektanta akurat nie jest tutaj najniższa. I co dostanie w zamian… załącznik do umowy. Czy ten załącznik rozwiązał chociaż jeden z jego problemów biznesowych?

A co na to metody agile? Zaczynamy od krótkiego spotkania, może dwóch, na których identyfikujemy pewne wstępne priorytety, cele, pierwsze wymagania (nie ważne, czy będziemy tutaj posługiwali się user stories, przypadkami użycia, czy inną techniką). Najistotniejsze w tym wszystkim jest to, że wszystkie metody agile stawiają na rzeczy najważniejsze w pierwszej kolejności. Gwarantujemy, że zajmiemy się od razu tym co klient uznał za najistotniejsze z punktu widzenia jego biznesu.

Przy dużych systemach nie da się zwykle uniknąć tzw. “iteracji zerowej”, w trakcie której powstają pewne podwaliny dla architektury systemu. Ale słowo “powstają” jest tutaj kluczowe. Od pierwszych dni powstaje produkt, który będzie stanowił wartość dla klienta. Nie jakiś dokument opisujący jak będzie pięknie, tylko system, który można użyć, zobaczyć, mieć na jego temat jakieś zdanie. Drodzy klienci, czy nie lepiej zapłacić za coś co stanowi jakąś wartość zamiast za (bez)wartościowy dokument?

Co jeśli jednak klient po kilku tygodniach/miesiącach zmieni zdanie? Może zmieni się sytuacja biznesowa - konkurencja przecież nie śpi w tym czasie? A może po prostu ma już lepszy pomysł, bo w miarę upływu czasu przemyślał pewne rzeczy jeszcze raz. Co wtedy z naszym załącznikiem do umowy. Odpowiedź jest jedna - wchodzimy na mglistą ścieżkę procesu zmiany wymagań. A jest to ścieżka kręta i pełna niespodzianek. Umówiliśmy się przecież na początku co do zakresu projektu, a z niego wynikały koszty i terminy. Teraz trzeba to przeliczyć i dołączyć do umowy nowy załącznik. I co? Znowu dokument i koszty zamiast nowego kawałka systemu.

Wszyscy też doskonale wiemy co dzieje się z kosztem zmian wraz z upływem czasu. Całe szczęście jeśli klient będzie miał okazję zapoznać się z jakimś pośrednim stadium projektu zanim będzie za późno. Zwykle jednak przy kontraktach z zamkniętym zakresem produkt poddawany jest ocenie (tzw. testom akceptacyjnym) tuż przed jego finalnym oddaniem (programiści mogliby przytoczyć mnóstwo opowieści z okresu między rozpoczęciem tych testów a oddaniem projektu).

Znowu - co na to agile? Ha! Przecież “zmiany” to drugie imię technik agile. Stosując dowolne podejście agile zakładamy, że żadne z wymagań poza tymi, które weszły do bieżącej iteracji, nie jest trwałe i praktycznie w każdej chwili można je zmienić, przełożyć jego wykonanie, czy nawet zrezygnować z niego. Siła agile nie leży w tym, że metody te dają przyzwolenie dla częstych zmian. Powiedziałbym raczej, że metody te stwarzają dogodne warunki do dokonywania zmian i dają klientowi wolność wyboru, której nie ma kiedy podpisze kontrakt zamknięty i klamka zapadnie. Wynika to z nastawienia procesów agile na częste spotkania i prezentacje kolejnych zrealizowanych w pełni funkcjonalności oraz na krótkie etapy, w których tworzone są kolejne wersje systemu. Oczywiście proces ten ściśle angażuje klienta, ale w końcu chodzi mu o uzyskanie dobrego produktu - za to płaci.

Czy w takim razie zamknięcie zakresu projektu w kontrakcie chroni klienta? Sądzę, że to pierwszy z mitów jakie są związane z tego typu kontraktami. Oczywiście wykonawca będzie bronił jak lew takiego zakresu. Za to klient bardzo szybko dowie się, że drzwi, które cichutko zamknął zostały z hukiem zaryglowane z drugiej strony i otworzą się dopiero pod koniec projektu. Podejście agile wymagałoby wykluczenia z kontraktu zakresu i jedynie ustalenia budżetu oraz zasad wykonania kontraktu. Jednak pod tym pozornym brakiem zapisów umownych klient dostanie większą kontrolę nad tym za co faktycznie płaci.

Ustalona cena kontraktu.
Co tak faktycznie oznacza ona dla klienta? Nie oszukujmy się… cena w sztywnym kontrakcie, to cena jaką klient płaci za wykonanie zapisów załącznika do umowy stworzonego przez wykonawcę i zgodnie z tym jak go zrozumiał… właśnie wykonawca. Gdy nastąpi wreszcie ten sądny dzień oddania projektu obie strony, usadowione dotąd wygodnie w swoich okopach, wyjdą z nich i zaczną do siebie strzelać amunicją złożoną z zarzutów, argumentów i interpretacji tego nieszczęsnego dokumentu.

Dodatkowo do ceny kontraktu zostanie wpleciony koszt pracy jaka miała go zabezpieczyć, a która dała mu specyfikację wymagań systemowych w formie aneksu. Zamiast zapłacić za produkt sam sponsoruje sobie kaftan bezpieczeństwa w postaci aneksu do umowy.

Wspomniałem wcześniej o koszcie zmian przy kontraktach zamkniętych. Koszty te wynikają z faktu, że wykonawca wyczerpuje zwykle cały budżet zapewniony mu w kontrakcie dla wykonania pierwszej wersji, czyli zapisów załącznika z zakresem. Więc jeśli klientowi nie spodoba się osiągnięty efekt, to możliwości są trzy - albo dopłaci za zmiany, albo wyrzuci to co dostał do kosza, albo weźmie produkt taki jaki jest. W każdej sytuacji traci:

• dopłaca - przekracza automatycznie cenę kontraktu (a miał przecież wiedzieć ile zapłaci za swój system)
• wyrzuca do kosza produkt - czyli robi prezent wykonawcy, któremu i tak zapłaci, bo ciężko się będzie wycofać z zapisów umownych
• bierze to co jest - na chwilę usypia swoje sumienie (cena jest, jaka miała być) ale prędzej czy później i tak zgłosi się po zmiany (może w ramach kolejnego kontraktu z załącznikiem - tak czy siak cena zostanie przekroczona)

Ile kosztują zmiany kiedy stosujemy metody agile? Najczęściej zmiana wynika z tego, że klient podczas kolejnego spotkania i obejrzeniu swojego systemu wybiera inny kierunek prac niż ten pierwotnie planowany. Taka zmiana nie kosztuje nic a daje jedną podstawową przewagę nad procesem funkcjonującym za kontraktem o ustalonej cenie i zakresie. Taka zmiana jest po prostu możliwa, bo klient nie czekał do zakończenia kontraktu, kiedy okazało się, że można było zmienić kilka rzeczy w połowie drogi. Pomiędzy iteracjami klient ma wręcz możliwość zmiany zakresu. Chcę tu jasno podkreślić, że nie jest to żadne magiczne napełnianie worka bez dna. Możemy zmienić zakres, ale nie poszerzać go. Natomiast klient być może będzie musiał poświęcić jakieś mniej istotne szczegóły na rzecz tych kluczowych. To on decyduje, które są które i co zostanie wykonane najpierw a co potem.
Oczywiście często zdarzy się, że klientowi nie spodoba się efekt iteracji, i trzeba będzie wprowadzić poprawki z tym co do tej pory zostało zrobione. W zależności od wagi zmian, albo wykonujemy je od ręki albo tworzymy z nich nowe zadanie do zaplanowania w kolejnej iteracji (zepchnie ono automatycznie jakieś inne mało istotne z końca listy). Pamiętajmy jednak, że iteracje są możliwie krótkie więc nie ma zbyt dużych możliwości stworzenia implementacji znacząco odbiegającej od oczekiwań, czego nie można powiedzieć o efekcie kilkumiesięcznej pracy, jaki ogląda klient podczas odbierania projektu z kontraktu zamkniętego. Więc zmiany w wykonanych funkcjach będą zwykle niewielkie.
Jak w takim razie określić cenę kontraktu jeśli chcemy użyć technik agile. To chyba moment, który budzi największe obawy klienta - nie określać ceny! Możemy przyjąć stawkę dzienną, godzinową lub inną, wg. której będziemy się rozliczać. Możemy także ustalić budżet, tylko nie w odniesieniu do konkretnych zadań i zakresu projektu, ale w odniesieniu do np.ilości idealnych dni programistycznych wg jakich estymujemy funkcjonalności (to dość szeroki temat wart osobnego artykułu).

Chyba największym nieporozumieniem jakie wiąże się z kontraktami i technikami agile, jest przeświadczenie, że nie można określić i kontrolować kosztu takiego projektu. Wydaje mi się, że można to zrobić dużo dokładniej niż przy projektach z ustaloną ceną. Oczywiście nie powiemy klientowi pierwszego dnia, że program będzie kosztował dokładnie X złotych. Ale możemy przecież już na początku określić wstępnie jak duży jest projekt i ile może kosztować (określić jakieś rozsądne granice), co da klientowi pojęcie czy to jest to, czego się spodziewał i czy go na to stać. Poza tym techniki agile w żadnym wypadku nie stoją na przeszkodzie skrupulatnej kontroli budżetu. Za to dokładnie wiemy za co zapłaciliśmy i wiemy także, że wydaliśmy pieniądze najlepiej jak mogliśmy, bo z każdą iteracją dostajemy produkt co do którego mamy pewność, że ma to czego chcieliśmy i nić ponad to, za co wcale nie chcieliśmy płacić.

Każdy kto chce wydać pewną kwotę na oprogramowanie, powinien zadać sobie pytanie co dostanie w dniu wyznaczonym jako data zakończenia projektu przy kontrakcie z ustaloną ceną i zakresem, a co przy kontrakcie bez ceny, ale opartym na metodach agile? Moim zdaniem nie wiadomo co dostanie przy zamkniętym kontrakcie i mało prawdopodobne aby klient był z tego w pełni zadowolony. A co klient dostanie od firmy używającej agile? Dostanie produkt lepszy niż ten o którym myślał kiedy rozpoczynaliśmy projekt. Z każdym tygodniem powinien też być o to spokojniejszy. Możliwe, że zdarzy się tak, iż do tego samego terminu nie zostanie wykonana pewna funkcjonalność, ale przecież te, które zostały to samo sedno produktu. Być może to o czym myślał na początku w ogóle nie było potrzebne.

Dochodzimy tym samym do ostatniego elementu. Do terminu.

Ustalony termin wykonania.
Techniki agile kompletnie nie przeszkadzają w ustaleniu konkretnego terminu zakończenia projektu. Wręcz przeciwnie - wszystko co w agile robimy, wykonujemy przy dużej samodyscyplinie i w konkretnych terminach. Nie przeciągamy iteracji, nie ma w połowie wykonanych elementów. Wszystko jest z góry ustalone. Paradoks? Wcale nie. Agile uwielbia ten stały rytm pracy, to dzięki niemu możemy coraz dokładniej udzielać odpowiedzi na pytanie co i kiedy.

Przy zamkniętym kontrakcie ustalamy na początku zakres oraz termin wykonania i potem zespół przystępuje do pracy. Przypomina to bardzo ciężką lokomotywę, która rozpędza się powoli zanim osiągnie swoją optymalną prędkość. Wiadomo - termin zakończenia projektu jest tak odległy, że na pewno zdążymy - spieszymy się więc powoli. Zespół dobiera sobie zadania w wygodnej dla niego kolejności, co zwykle nie idzie w parze z priorytetami klienta. Ale przecież klient oceniać będzie efekt końcowy, więc kolejność po drodze nie ma znaczenia. I co się dzieje pod koniec projektu, kiedy okazuje się, że zostało więcej zadań niż czasu? Przecież wykonawca nie będzie płacił karnych odsetek. Jest łatwiejsze rozwiązanie. Kończymy wszystko byle jak, ale w terminie. Ważne, żeby podczas odbioru wszystko dobrze się zaprezentowało, a potem się zobaczy. Poświęcamy jakość. W końcu klient będzie płacił za support.
W projekcie agile nie ma zbyt dużo miejsca na taki scenariusz, bo klient na bieżąco określa kierunek i dba o to, aby powiedzieć zespołowi o swoich bieżących priorytetach. Efekt jest taki, że kiedy zbliża się termin określony w kontrakcie, wtedy mamy pewność, że mamy produkt, który zaspokaja możliwie najwięcej potrzeb klienta (nawet jeśli pewne drobne, mało istotne elementy nie zostały wykonane).

Jest tutaj miejsce na jeszcze jedną rzecz, na którą chciałbym zwrócić uwagę. Często okazuje się, że pewne zadania zajęły mniej czasu niż miały (tak… mimo panującej opinii, ze projekty informatyczne nie kończą się zwykle w ustalonym terminie). Chodzi o to, że tak wypracowany zysk zabierany jest później przez pracochłonne i niepotrzebne funkcje, które zespół wykona żeby spełnić wymagania załącznika do umowy. Albo po prostu klient nie dowie się o tym, że coś trwało krócej. Ilu z nas widziało kiedyś, aby firma IT na koniec projektu powiedziała klientowi, że umawialiśmy się co prawda na pewną kwotę ale poszło nam szybciej więc cena będzie niższa? Projekt agile w moim przekonaniu powinien być oparty na wzajemnym zaufaniu i zrozumieniu. Klient musi być przygotowany na to, że nie jesteśmy jasnowidzami i pewne rzeczy zajmą więcej czasu niż mogliśmy początkowo przypuszczać, ale dołożymy wszelkich starań żeby dostał to czego potrzebuje. Będzie miał za to zawsze szansę zdecydować, czy zmiana pracochłonności nie stanowi dla niego podstaw do obniżenia priorytetu zadania i przesunięcia go na później. Ale z drugie strony klient musi mieć pewność, że jeśli uda się nam skończyć coś wcześniej to wtedy zespół skontaktuje się z nim w celu wciągnięcia do iteracji jeszcze jakiegoś elementu z planu kolejnych etapów. Zamknięte kontrakty zawsze zakładają jedynie wzrost ceny jeśli coś pójdzie gorzej.

Na koniec chciałbym wyjaśnić, że dokonałem tutaj pewnego uproszczenia zakładając, że za kontraktem o stałej cenie i zakresie jest ukryty proces podobny do kaskadowego. Wiele osób pomyślało już na pewno, że można zastosować etapy pośrednie wykonując zamknięty kontrakt aby zminimalizować ryzyko nie trafienia w oczekiwania klienta. Jednak szybko dojdziemy do wniosku, że taka minimalizacja ryzyka przerodzi się prędzej czy później w coraz większe adaptowanie technik agile w tego typu projekcie (o tym może niedługo). Być może nawet finałem tej adaptacji będzie podpisanie kontraktu bez załącznika z zakresem projektu i ceną, a zespół (łącznie z Zarządem) stwierdzi, że jest jest już bardziej agile niż jeszcze pół roku temu…

Czego sobie i wszystkim Wam życzę :-)

9 comments October 2nd, 2006

Czy ta bitwa jest potrzebna?

Kiedy kilka lat temu po raz pierwszy zetknąłem się z pojęciem Extreme Programming (XP) byłem studentem, który zaczynał swoją przygodę ze światem dotcomów. Siedzieliśmy wtedy dniami i nocami w pracy próbując dotrzymać szalonych terminów, które zostały ustalone podczas spotkań “na szczycie”.

XP kojarzyło się wtedy z magicznym rozwiązaniem problemu wiecznego braku czasu. Od tamtego czasu miałem okazję pracować w kilku firmach IT, w których pełniłem rolę programisty i kierownika projektu w jednym. Rosła także moja świadomość istnienia całej grupy metod, które określa się dziś terminem “agile”. Każdego dnia staram się przemycić w swojej pracy trochę elementów tych metod. No właśnie… czemu przemycić?

Kilkakrotnie miałem okazję przekonać się, że terminy Extrem Programming i Agile są nadużywane przez managerów, kierowników, ale co gorsza także przez programistów. Metodyki lekkie są obecnie bardzo popularne na zachodzie i ta moda trafiła już także do Polski. Tylko czym ta moda jest dla nas w rzeczywistości. Czy lekkie metodyki nie stanowią dla nas twórców oprogramowania wymówki, usprawiedliwienia braku dokumentacji projektowej, ba… braku projektu. Czy sami przed sobą nie staramy się wmówić, że jesteśmy agile, że stosujemy XP, a tak faktycznie obcinamy wszystko co się da z i tak już wątłego procesu wytwarzania oprogramowania tylko po to, żeby być w stanie przedstawić klientowi korzystniejszy termin realizacji projektu i może niższą cenę (tak na zachętę)?

Jaka jest wśród nas świadomość prawdziwych technik agile? Każdego dnia przekonuję się, że stosowanie tych technik nie jest ani łatwe, ani nie stanowi rozwiązania wszystkich problemów. Agile wymaga pracy. Głównie pracy nad samym sobą oraz nad ludźmi nas otaczającymi. Czy więc bitwa o agile jest potrzebna w Polsce? Myślę, że tak. Potrzebna jest nam programistom, kierownikom, szefom, abyśmy lepiej mogli zrozumieć co tak faktycznie dają nam te techniki i jak je wykorzystać aby przekuć je w sukces projektu. Potrzeba jest także naszym klientom, bo wprowadzanie agile do projektów programistycznych wymaga zbudowania w naszych klientach zaufania do tych technik.

Przed napisaniem tego, krótkiego wstępu postanowiłem “zapytać Google” co wie na temat agile na polskich stronach internetowych. Wynik był dość zaskakujący. Pierwsze miejsce w polskim internecie pod hasłem “agile” zajmuje:

Agile*PL - hodowla kotów rasy Maine Coon

Tak… ta bitwa jest potrzebna! Agile zasługuje na to aby być w naszej branży czymś więcej niż szemranym hasłem wymienianym wśród programistów. A jak to zrobić… to już inne historia…

Add comment September 23rd, 2006