Battle for Agility

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