Battle for Agility

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