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

Agile w Nokia Siemens Networks

23 kwietnia 2008 na Politechnice Wrocławskiej w ramach IT Days 2008 obył się wykład pt. “Agile techniques in big IT venture” poprowadzony przez Marcina Kołtonowskiego i Marka Majchrzaka z Nokia Siemens Networks (dalej NSN). Poniżej przedstawiam garść informacji o tym co na wykładzie można było usłyszeć i o tym czego niestety nie usłyszałem, a nie ukrywam, że chciałem :-)

Prezentacja podzielona była na 5 części:

1. Ogólne informacje na temat NSN oraz na temat platformy @dvantage, przy której pracują obaj autorzy.
2. Krótkie przypomnienie modelu kaskadowego (ang. waterfall) i jego wad.
3. Manifest agile i główne założenia iteracyjnego tworzenia oprogramowania.
4. Wprowadzenie do Scrum z omówieniem cyklu projektu i ról w projekcie.
5. Część praktyczna, czyli spojrzenie na implementację Scrum w NSN jako dużej globalnej korporacji.

Jak się pewnie domyślacie, idąc na ten wykład liczyłem głównie punkt 5 i głównie na nim się skupię. Na prezentację zaplanowano 90 minut. Pierwsze cztery części zabrały w sumie około 50 min. Szkoda, bo zupełnie niepotrzebnie dużo miejsca zajęły szczegóły na temat platformy @advantage i związanych z nią narzędzi oraz teoria na temat Scrum, przez co na to, co faktycznie najciekawsze zostało już tylko pół godziny plus 10 min na pytania z sali.

Ale do rzeczy… Wrocławski odział NSN podjął próbę wprowadzenia Scrum kilka miesięcy temu. Autorzy prezentacji opowiadali o pracy ok 20 osobowego zespołu, który został podzielony na 4 podzespoły (Scrumy). Trzy z nich zajmują się oprogramowaniem trzech różnych linii produkcyjnych wspomnianej platformy @dvantage, czwarty to typowy “firefighting team” zajmujący się naprawą krytycznych błędów na wszystkich trzech liniach działającego już produkcyjnie kodu.

W każdym zespole rolę Scrum Mastera pełni osoba z większym doświadczeniem wybrana z pośród dotychczasowych programistów. Zespoły praktykują codzienne 15 minutowe spotkania, planning meetings na początku sprintu oraz retrospectives po sprincie. Scrum Masterzy ze wspomnianych czterech zespołów tworzą wirtualny zespół Scrum of Scrums aby synchronizować podobne prace toczące się na poszczególnych liniach platformy. Nie wiem tylko ja wygląda komunikacja w obrębie tego zespołu, ale odniosłem wrażenie, że nie mają swoich codziennych spotkań.

Na razie wygląda normalnie… wręcz zbyt dobrze, a przecież to duża korporacja… no to przejdźmy do problemów jakie udało mi się wychwycić.

Po pierwsze NSN pozostaje jako korporacja organizacją polegającą na modelu kaskadowym. Różne warstwy organizacji mają do osiągnięcie pewne kamienie milowe i etapy ich osiągnięcia są góry ustalone. Sam dział programistyczny mapuje Scruma na poziomie poszczególnych faz modelu kaskadowego. I tak mamy opracowanie specyfikacji wymagań, analizę i projektowanie, implementację, wdrożenie i w końcu utrzymanie aplikacji. Jeśli da się dany etap wykonać iteracyjnie, to zespół podejmuje próbę zaprzęgnięcia do tego Scruma w skali pojedynczego etapu. Przy czym Scrum na etapie implementacji jest tutaj najbardziej eksponowany.

Autorzy zapytani przeze mnie o to, jak w takim razie radzą sobie ze zmianą wymagań pochodzących z fazy specyfikacji wymagań odpowiedzieli, że tamte wymagania są na tyle ogólne, że raczej nie zmieniają się potem podczas implementacji. Tak więc możliwa jest co najwyżej reakcja na zmiany drobniejszych wymagań, które identyfikowane są już podczas fazy implementacji a do faz, które już minęły nie wracamy. Nie rozumiem tylko na podstawie czego powstaje w takim przypadku backlog produktu i czy to oznacza, ze on nie może się już zmienić?

Drugi problem jaki dotyczy tak dużej organizacji, to kooperacja pomiędzy działami. W NSN funkcjonuje duży dział testów, który wykonuje między innymi testy funkcjonalne aplikacji tworzonych przez programistów NSN (w tym tych wchodzących w skład 4 Scrumów platformy @dvantage). Problem polega na tym, że praca działu testów nie jest uwzględniona w sprincie a odbywa się już po. W ramach sprintu programiści wykonują jedynie testy jednostkowe (przy czym TDD to raczej opcja niż norma, choć w przypadku tego typu systemów to mnie raczej nie dziwi).

Szkoda, że nie dowiedziałem się z prezentacji więcej na ten temat, bo właśnie tego byłem ciekaw najbardziej. NSN jako duża sformalizowana organizacja jest dotąd raczej oparta na pewnych warstwach zadaniowych i działach, które zajmują się pewnym wybranym aspektem działania firmy. Tymczasem wprowadzanie metod agile, w tym Scrum wiąże się ze zmianą organizacji pracy na bardziej projektową i wymaga utworzenia bardziej kompletnych i samowystarczalnych zespołów. Oczywiście wymagałoby to rewolucji i likwidacji pewnych działów, albo przynajmniej fizycznego przemieszczenia pracowników, tak aby np. pojedynczemu zespołowi developerów przydzielić również osoby z takiego działu testów, a pewnie znalazłoby się jeszcze kilka innych działów, z których należałoby wyciągnąć ludzi. Z tego co autorzy przekazali podczas wykładu wynika, że nie udało się tego dotąd zrobić w NSN i działy pomiędzy sobą nie dzielą nawet wspólnych sprintów.

Na koniec sprawy bardziej techniczne a nie organizacyjne. Sprint w tych zespołach trwa 4 tygodnie. Szacowanie zadań dla poszczególnych sprintów odbywa się w godzinach, przy czym odniosłem wrażenie, że oszacowania dokonują pojedynczy programiści a nie zespół (ale może to niedopowiedzenie). Autorzy prezentacji wspomnieli o śledzeniu wykresów burndown, ale nie wspomnieli nic na temat tego w jaki sposób śledzą velocity (co w przypadku estymowania w godzinach jest szczególnie pomocne) i jak wykorzystują to do planowania i poprawiania swoich oszacowań godzinowych.

No i jeszcze taka ciekawostka - continous integration. W przypadku omawianej na wykładzie platformy zbudowanie, integracja i wstępne przetestowanie automatyczne kodu trwa całą noc. Więc nad ranem następnego dnia zespoły wiedzą, czy coś im nie wyszło dnia poprzedniego. No… oflagowanie tego procesu mianem CI jest moim zdaniem lekkim nadużyciem i uważam, że dużo wiarygodniej brzmiałoby stwierdzenie, że w skali całego projektu nie da się tam wdrożyć pełnego CI. Chciałem zadać jeszcze pytanie czy w ogóle da się w takiej organizacji i przy tak skomplikowanych i złożonych systemach zachować zasadę, że w każdej iteracji otrzymujemy w pełni wdrażalny produkt, zwłaszcza że do tego potrzeba właśnie ścisłego współdziałania działów korporacji? Po prezentacji mam wątpliwości.

Chcę podkreślić, że nie chcę wytykać tutaj żadnych błędów. Moje spostrzeżenia traktuję bardziej jako konfrontację teorii ze staraniami zespołów ograniczonych z wielu stron przez sztywne ramy korporacji. Mam nadzieję, że uda się np. za rok usłyszeć podobne wystąpienie, w którym będzie mowa o tym, jakie z tych problemów udało się, bądź nie udało się rozwiązać. Na razie wygląda na to, że próby wdrożenia Scrum w NSN nie są wspierane na wszystkich poziomach organizacji i raczej wyglądają jako taka inicjatywa na średnim i niższych szczeblach. NSN dysponuje ponoć 500 Scrum Masterami (informacja z wykładu) - pytanie jaki jest stosunek ilości programistów do SMów? Być może na wyższych szczeblach funkcjonuje to bardziej na zasadzie “wszyscy są teraz agile, więc my też bądźmy, ale nie zmieniajmy przy tym za wiele”. Obym się mylił a rozpoczęty w NSN proces ulegał doskonaleniu w praktyce a nie tylko na prezentacjach.

I jeszcze takie fundamentalne pytanie jakie nasuwa mi się jeśli myślę o wdrażaniu agile w takiej organizacji. Czy w trakcie wdrażania procesów Scrum okazało się, że jakieś stanowiska są niepotrzebne? Czy każdy trybik takiej organizacji znajdzie dla siebie miejsce w ramach nowych procesów, czy może pewne stanowiska okażą się nie potrzebne?

Kij w mrowisko wsadzony :-) Czekam na komentarze tych najbardziej zainteresowanych, jeśli takowi czytają tego bloga :-)

4 comments April 28th, 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

Brak wieści, to dobre wieści

Pół roku… bez postów… ale nie bez bitwy. Mój syn Tomek za kilka dni kończy cztery miesiące :-). W tym miesiącu uruchomimy wersję demo naszego nowego systemu do zarządzania projektami agile o nazwie tinyPM. Jesteśmy w trakcie dwóch nowych projektów, gdzie udaje się stosować coraz więcej praktyk agile. Bitwa trwa, a już niedługo nowe posty oraz więcej informacji na temat tinyPM’a.

3 comments October 3rd, 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

Planować czy startować?

Wydaje mi się, że dosyć mocno rozpowszechnione jest przekonanie, że techniki agile są chaotyczne i nie ma w nich miejsca na stary dobry plan. Nic bardziej mylnego! Chodzi o to, że nie bardzo jest w nim miejsce na stary “wielki” plan. Tradycyjne metodyki zarządzania projektami jaskrawo zaznaczają granice faz w cyklu życia projektu oraz nadmiernie wydłużają czasy ich trwania. To co chcemy osiągnąć, to szybki start projektu. Chcemy podzielić projekt na krótkie etapy (iteracje, sprinty, wszelkie inne nazwy dozwolone). Każdy etap stanie się dla nas mini projektem, który będzie zawierał pełne spektrum czynności - od planowania i projektowania po implementację bardzo mocno wspartą testami. Niby nic, a jednak to sprowadzenie dużych problemów do takiej mikro skali doskonale się sprawdza. Systemy które tworzymy są coraz bardziej skomplikowane. Coraz trudniej też przewidzieć wszystko na początku projektu. Ryzyko pomyłki jest wtedy bardzo duże, a zabrnięcie w ślepy zaułek kosztowne. Iteracyjne podejście pozwala zminimalizować ryzyko pomyłek i obniżyć koszty zmian.

Czy potrzebny jest nam szczegółowy plan?

Ostatnio oglądałem wywiad “Running Tested Features” podczas, którego Ron Jeffries użył pewnego wykresu dla zaprezentowania różnicy między długą fazą planowania na początku projektu oraz podejściem polegającym na konsekwentnym dostarczaniu klientowi kolejnych przybliżeń jego produktu. Poniżej drobna mutacja tego wykresu.

Nie ukrywam, że takie postawienie sprawy jest pewnym uproszczeniem, ale trafnie oddaje jeden z aspektów iteracyjnego podejścia do problemu i szybkiego startu implementacji.

Punkt przecięcia czarnych przerywanych linii wyznacza nasz cel - dostarczenie określonej funkcjonalności w danym terminie (typowy problem biznesowy, gdzie data wejścia na rynek jest z góry określona i na jej ustalenie ma wpływ wiele nietechnicznych czynników).

Punkt A wyznacza czas zakończenia fazy planowania (np. zamknięcie specyfikacji) i uruchomienie fazy implementacji. Aby zdążyć dostarczyć pełny produkt w wyznaczonym terminie musimy zakładać dość szybkie tempo “wspinania się” po osi funkcjonalności aby trafić w wyznaczony punkt w terminie B (tempo tym szybsze im dłużej trwa planowanie). Poza tym bardzo rzadko wychodzi tak, że zgodnie z planem dostarczamy pełną oczekiwaną przez klienta funkcjonalność. Zwykle po momencie B ciągnie się jeszcze faza poprawek i modyfikacji (więc czerwona linia w momencie B zwykle jest poniżej zakładanego zestawu funkcjonalności).

Stosując podejście iteracyjne zakładamy, że w możliwie krótkich odstępach czasu staramy się dostarczać klientowi kolejne elementy zamówionej funkcjonalności. Bardzo ważnym aspektem (który ma wpływ na planowanie w procesie agile) jest to, że zawsze staramy się dostarczyć klientowi coś co jest on w stanie zweryfikować, coś co stanowi dla niego jakiś użyteczny element systemu (dla przykładu kompletny projekt bazy danych nie stanowi dla klienta wartości użytkowej bez pozostałych warstw systemu). Zaczynając od początku dostarczać funkcjonalności zmniejszamy nachylenie krzywej (kolor niebieski), czyli teoretycznie pozwalamy sobie na spokojniejsze tempo. Tak faktycznie to tempo nie jest wolniejsze tylko trochę bardziej realne do utrzymania. Jeśli okaże się, że to jest właśnie tempo jakie będzie w stanie osiągnąć zespół to przy długim planowaniu nie zdążymy z funkcjonalnością (przerywana linia czerwona).

Linia niebieska w praktyce oscyluje raz powyżej, raz poniżej prostej prowadzącej do punktu przecięcia zakresu funkcjonalności i terminu. Ta oscylacja może wynikać np. z drobnego mijania się z koncepcją klientów/użytkowników, konieczności korekty projektu systemu, tak aby spełniał nowe pojawiające się po każdym etapie wymagania. Tempo takiej pracy na pewno okaże się wolniejsze niż po dokładnym projekcie, bo trzeba więcej w iteracjach eksperymentować. Jestem jednak przekonany, że iteracyjne projektowanie + refaktoryzacja kodu nie zajmą aż tyle czasu, żeby nie dało się go utrzymać na wymaganym poziomie. Pytanie czy przy mozolnym planowaniu i projektowaniu wszystkiego naprzód da się skończyć w pozostałym czasie.

1 comment December 20th, 2006

Czas to pieniądz?

O blaskach i cieniach zamkniętego kontraktu już co nieco wiemy. Załóżmy na moment, że jednak udało się nam go uniknąć chociaż częściowo. Mimo to każdy kierownik projektu i tak stanie przed słynnym pytaniem ze strony swojego szefa, który z kolei na to samo pytanie musi odpowiedzieć klientowi. Pytanie brzmi:

“No dobrze, ale czy w tych Waszych zwinnych metodach kompletnie nie wiadomo ile to będzie mniej więcej kosztowało?”

Oczywiście odpowiedź jest i zależy od tego jak dobrze znamy nasz zespół, jak zgrana jest ta grupa ludzi, i od wielu innych czynników. O dochodzeniu do odpowiedzi na to pytanie może następnym razem. A dzisiaj choć trochę rozprawić chciałbym się z tym, co następuje chwilę po tym jak klient już pozna tę upragnioną odpowiedź… O jak drogo! Czy nie da się tego jakoś “przyciąć”…

No właśnie. W dużym skrócie zaczynamy od tego, że nasz zespół po wstępnych rozmowach z klientem stara się stworzyć pierwsze oszacowanie pracochłonności projektu. W tej chwili nie ma znaczenia czy będą to godziny, dni robocze, dni idealne, gumisie, czy cokolwiek innego. Koniec końców jesteśmy w stanie przeliczać te jednostki na inne. Każdy manager wie ile kosztuje dzień pracy jego zespołu (prawda, że to wiemy…?!). Z wiedzy na temat kosztów i wstępnego oszacowania zakresu można już w jakiś sposób prognozować (również bardzo wstępnie) koszt projektu. Klient dostaje pierwszą informację na temat tego, na co powinien być przygotowany decydując się na realizację projektu.

I tu zwykle kończy się racjonalne podejście. Powiem więcej - racjonalność staje się odwrotnie proporcjonalna do usztywnienia ram kontraktu. Załóżmy, że oszacowaliśmy (wstępnie - pamiętajmy o tym) zakres i mamy okrągłą sumę 1000 godzin. Stawka za godzinę w naszej firmie to 100 PLN. Klient dowiaduje się, że projekt będzie go kosztował 100 tys. PLN.

Oczywiście pierwsze co słyszymy to, że to drogo (w końcu nie należy przyjmować pierwszej oferty). No i dochodzi do podstawowego złamania zasad zdrowego rozsądku. Wieść wraca z powrotem do zespołu wraz z poleceniem… ponownego rozważenie swoich oszacowań, bo może uda się coś przyciąć. Wielokrotnie byłem postawiony w takiej sytuacji. Wielokrotnie też ulegałem swoim przełożonym. Do dzisiaj nie potrafię znaleźć ani jednego argumentu uzasadniającego taki podejście.

Ustalmy klika faktów. Jest początek projektu. W większości przypadków śmiało możemy powiedzieć, że na temat tego co projekt tak na prawdę kryje więcej wciąż nie wiemy, niż wiemy. Pewnym jest wobec tego, że nasze szacunki raczej są za niskie.

Szacując jakąś pracę zwykle podświadomie szacujemy w tak zwanych idealnych jednostkach, czyli np. w idealnych godzinach/dniach pracy. “Idealny” oznacza tutaj czas kiedy nikt nie będzie nas odrywał od pracy, zajmował nas innymi rzeczami. Co więcej kiedy sami nie będziemy się od niej odrywać. Praktycznie nie zdarza się, żeby idealne jednostki przekładały się na rzeczywisty czas pracy w stosunku jeden do jednego. Wniosek jest taki, że nasze szacunki są jeszcze mniej zbliżone do faktycznego czasu pracy, a tylko taki da się wycenić. Tutaj pojawia się pole do popisu dla kierownika, dla dobrej znajomości zespołu i tego czy kierownik potrafi przełożyć te szacunki na faktycznie poświęcony czas pracy. Czy jest to czas optymalny i jak bliski w swoich prognozach może być kierownik zespołu. Kluczowym elementem staje się wiedza na temat tego ile tych oszacowanych godzin/dni zespół jest w stanie wykonać w ciągu np. jednego 5-dniowego tygodnia pracy, bo to wprost przekłada się na koszty.

Oszacowanie projektu na 1000 godz. to nie tylko koszt projektu, to także termin. Oczekujemy od zespołu, że magicznie przyspieszy pracę i wykona pewne zadania w krótszym czasie (więc za mniejsze pieniądze z punktu widzenia klienta). Często faktycznie tak się zdarza, że niektóre zadania są przeszacowane, ale jednak wciąż więcej jest tych niedoszacowanych. Tymczasem zespół sam zawiązuje sobie pętlę na szyję. Bo wszyscy szybko zapomną, które oszacowania zostały przycięte, ale ci którzy zapomną najszybciej, pierwsi zjawią się aby dopominać się o realizację tych zadań w nowych terminach.

O co więc chodzi? O to, że z całą pewnością będziemy negocjować koszt projektu, ale metoda, którą przyjmuje wielu managerów jest co najmniej chybiona. Dlaczego tnie się plany projektu na lewo i prawo zamiast dokonać najprostszego pod słońcem cięcia w stawce jaką oferuje się klientowi?

Wróćmy do naszego przykładu. Cięcie oszacowań doprowadzi do następującego stanu. Wymusimy na zespole aby zrezygnował np. z 50 godzin (nadal nie pojmuję idei kryjącej się za tą techniką). Nowe oszacowanie będzie mówiło o 950 godzinach, co da 95 tyś PLN. Ale przy tym zespół straci ok. 2 tygodni czasu dla jednego ze swoich członków. Czym bardziej sztywny kontrakt tym gorzej będzie to nadrobić. Co ciekawe takie cięcie przerzuca na zespół ciężar realizacji zadania, bo manager jednoznacznie daje sygnał, że obiecał klientowi 5 tys. zniżki, ale oczekuje, że zespół pracując “szybciej” zapewni mu pierwotnie zakładany zysk z operacji (bo szybciej pracując zmniejszamy także koszty). Manager ma powód do dumy… to nic, że za pół roku dowie się, że jego zespół się nie wyrobił i odda klientowi jeszcze trochę pieniędzy w karach.

Cięcie stawki wyglądałoby następująco. Chcąc dać 5 tyś. zniżki klientowi, zaproponujmy mu stawkę 95 PLN za godzinę. Projekt nadal pozostaje 1000 godzinnym przedsięwzięciem. Klient zakłada wstępny koszt na 95 tyś. PLN. Co więcej może przyjąć, że jeśli projekt okaże się większy to generalnie wynegocjowana została korzystniejsza stawka. Kto więc stracił? Manager, bo zmniejszył marżę, zamiast zmuszać zespół do podkręcenia tempa. Ale czy stracił tak naprawdę? Przykład jest bardzo uproszczony, ale w prawdziwych projektach, jeśli projekt z okrojonym harmonogramem się nie powiedzie, mamy do stracenia dużo więcej niż tylko różnicę w marży. Z resztą i tak mądry manager pewnie zaczynał ze stawką dla niego bezpieczną.

Techniki agile dostarczają doskonałych narzędzi zarówno do poznania własnych zespołów i ich możliwości. Pomagają także dobrze kontrolować budżet przedsięwzięcia zarówno klientowi jak i wykonawcy. Idąc krok dalej i przestawiając się na myślenie stawkami zamiast zamkniętymi zakresami i cenami można dużo zyskać. Gdzieś po drodze zginęła ta ważna informacja, że wszystko to były wstępne szacunki. Cena nie powinna być ostateczna. Ostateczna powinna być stawka. Bezpieczeństwo przed naciąganiem da klientowi sam proces wytwarzania. Nigdzie nie jest także napisane, że w razie wzrostu zakresu projektu stawka nie zacznie nieco spadać - pierwsze 1000 godzin 95 PLN/godz. ale każde kolejne 100 w tym projekcie już 85 PLN/godz. Wydaje mi się, że mądra polityka cenowa może przełamać bariery psychologiczne pojawiające się na styku metod agile i pieniędzy klienta.

Z całą pewnością opisane przeze mnie podejście w wielu firmach (zwłaszcza większych) nie ma miejsca, ale niestety w tak dużej liczbie innych firma nadal ma miejsce! Tak więc drodzy managerowie. Nie negocjujcie ceny przy pomocy czasu, tylko pieniędzy. Będzie to oznaką dojrzałości waszych firm.

2 comments November 22nd, 2006