Battle for Agility

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

Akcent Agile na JDD 07

Piątek spędziłem na Java Developers Day 2007. Dlaczego piszę tutaj o konferencji Java? W zeszłym roku agile było praktycznie w każdym wystąpieniu. Wszystkie produkty, praktyki, frameworki były agile. W tym roku coś się zmieniło… terminem agile nie wiało już z każdej prezentacji, co w sumie jest nawet lepsze, bo przywykliśmy do zbytnich nadużyć w kwestii stosowania agile wszędzie gdzie się tylko da.

Ale nie myślcie, że agile zniknęło z JDD. Także i tegoroczna edycja miała swój akcent w postaci wystąpienia Jakuba Dziwisza na temat “Test Driven Development w Java”. Wykład powinien być niedługo dostępny w wersji wideo na stronach organizatora konferencji, a na blogu Jakuba powinien się pojawić artykuł uzupełniający samą prezentację. Zaczęło się nieźle… Jakub przekonywał o zaletach TDD w tworzeniu oprogramowania, z czym generalnie się zgadzam. Były założenia TDD, trochę o trybie red - green - refactor, później prosty test, który nie przechodził ale wyznaczył funkcjonalność, implementacja (test przeszedł - byliśmy w green), wreszcie przyszedł czas na “refactor”.

Niestety etap refaktoryzacji zaprezentowany podczas wykładu był dla mnie nieco kontrowersyjny. Mianowicie za jednym zamachem uległa zmianie implementacja testowanej klasy i bez uruchomienia testów od razu uległa zmianie także implementacja samego testu. Być może nie było to zamierzone a jedynie podyktowane ograniczeniami czasowymi samej prezentacji, ale chciałbym podkreślić, że w TDD właśnie po to najpierw piszemy test, żeby później w trakcie refaktoryzacji móc na nim polegać zmieniając kod. Jeśli programista zacznie jednocześnie zmieniać kod testowany i kod testujący to jaką ma pewność czy zielony pasek nadal wskazuje, że kod działa, a nie że właśnie dostosował test do tego, żeby przechodził z nowym kodem? A co jeśli po takich jednoczesnych zmianach test nie przejdzie? Czy to oznacza że źle zrefaktoryzowaliśmy kod, czy może nie wyszła nam modyfikacja testu? Test ma łapać błędy powstałe podczas refaktoryzacji. Dopiero później przychodzi czas na ew. refaktoryzację samego kodu testów. Z reszta Jakub wspomniał o tym, że dobrze napisane testy nie powinny tak często wymagać zmiany, kiedy tylko refaktoryzujemy kod aplikacji.

Chciałbym się także odnieść do pytania, które padło z sali. Mianowicie “Do czego TDD się nie nadaje?”. Odpowiedzią było, że “nie nadaje się do utrzymania oprogramowania”. Z drugiej strony Jakub stwierdził, że nie wyobraża sobie napisania linijki kodu produkcyjnego bez wcześniejszego napisania testów. Ani jedna, ani druga odpowiedź nie do końca mnie satysfakcjonuje.

To jest generalnie dobre pytanie jeśli chodzi o agile, bo będąc entuzjastą jakiejś konkretnej praktyki lub wszystkiego co agile, dość łatwo mówi się o tym jakie to wszystko jest piękne, ale pamiętamy formułę “there is no silver bullet” prawda?

Akurat według mnie TDD doskonale nadaje się do utrzymania oprogramowania. Nie mówię tu bynajmniej o rozpoczynaniu krucjaty w pisaniu testów do wielkiego istniejącego systemu, który takich testów nie posiada. Byłoby to niewiarygodnie męczące i praktycznie nieuzasadnione jeśli chodzi o koszty. Ale jestem zdania, że w takim wypadku doraźne aplikowanie TDD do napotkanych błędów w tego typu kodzie jest bardzo dobrą praktyką.

Załóżmy, że zostaje zgłoszony błąd w utrzymywanym przez nas oprogramowaniu. Co należy zrobić?

1. Najpierw piszemy test, który reprezentuje oczekiwane przez nas prawidłowe działanie aplikacji (jesteśmy w fazie RED, test nie przejdzie, bo przecież mamy błąd w aplikacji).
2. Naprawiamy błąd. A skąd wiemy, że go naprawiliśmy? Bo przeszedł test, które wcześniej napisaliśmy. Jesteśmy w GREEN.
3. Skoro mamy poprawkę i test, który przechodzi, to czas na ew. REFACTOR. Wiemy, że mamy test, który odpowie czy nie zepsuliśmy poprawki.

Oczywiście w przypadku systemów, które nie posiadały wcześniej testów, faza 2 i 3 są trudniejsze, bo nie wiemy czy poprawka i refaktoryzacja nie wpłynęły negatywnie na inne części systemu na które nie mamy testów, ale cóż. Jeśli znajdziemy inny błąd to wracamy do kroku 1. W ten sposób doraźnie reagując budujemy powoli bazę testów dla systemu, który mogliśmy dostać w spadku. Przy okazji pisania testów uczymy się także samego systemu, a napisane w tym momencie testy zabezpieczą nas przed powrotem tego samego błędu w kolejnym wydaniu oprogramowania.

Czy w takim razie rozpoczynając nowy projekt można zastosować TDD wszędzie i nie powstanie ani linijka kodu bez testów, które najpierw nie przechodziły? Niestety nie zawsze jest to możliwe. Wg. mnie nie warto pisać testów jednostkowych dla klas GUI w aplikacjach typu desktop. Ciężkie jest także testowanie w ten sposób kodu widoków w aplikacjach webowych. Oczywiście to nie znaczy, że nie należy automatyzować testów tego typu elementów. Chodzi tylko o to, że są to elementy, które raczej nadają się do testów funkcjonalnych, najlepiej “nagranych” przy pomocy specjalnego oprogramowania przez testerów, a nie przez samych developerów i przynajmniej w moim przypadku nie bardzo sprawdzało się tutaj TDD w swojej czystej formie.

TDD to jednak jedna z bardziej interesujących praktyk agile, więc na pewno jeszcze do tego tematu wrócę.

Add comment October 28th, 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

Zwinne działania zaczepne

Ponarzekałem sobie już sporo na skostniałe metody podejścia do projektów. Może nawet znajdziesz w tych narzekaniach trochę merytorycznych argumentów popierających przedstawiane tutaj tezy. Ale w końcu trzeba przejść do konkretów. Zaczynamy nowy projekt. Co zrobić aby wprowadzić do niego jak najwięcej praktyk agile. Po pierwsze nie należy starać się wprowadzać zbyt dużej liczby nowych elementów na raz. Wiele razy można było się spotkać z dyskusjami na temat tego, “jak bardzo agile się już jest”. Moim zdaniem dobry proces czerpiący ze zwinnych metodyk powinien przejawiać się w następujących aspektach:

• nastawienie na zmiany, jako naturalną kolej rzeczy (to jedna z cech przewodnich praktyk agile)
• iteracyjność przejawiająca się również (a może przede wszystkim) w samym wprowadzaniu agile do projektu - stosujmy te same praktyki na poziomie doskonalenia procesu, jak i na poziomie implementacji i doskonalenia samego systemu
• minimalizm w podejmowanych działaniach i maksymalizm w osiąganych efektach - najczęściej mylnie kojarzony tylko ze skracaniem czasu i obniżaniem kosztów pracy, podczas gdy chodzi także o ciągłe podwyższanie jakości i kompletności produktu oraz o doskonalenie “warsztatu”.

Wykonujemy pracę coraz szybciej i taniej nie dlatego, że robimy coraz słabsze systemy, tylko dlatego, że jesteśmy coraz lepsi, tak jak nasz lekki proces. Tak więc małymi krokami do celu. Proces wdrażania agile można zacząć od dołu, czyli od nas programistów. Nie koniecznie trzeba też od razu uświadamiać wszystkich managerów. Próbujemy wykonać mały krok. Jak się uda pochwalimy się sukcesem. Managerów od razu uspokajam… nie będę proponował samowoli, rewolucji, czy innych działań wywrotowych. Raczej nazwijmy je na razie drobnymi działaniami zaczepnymi. Pewne rzeczy można zrobić inaczej i to się opłaca. A zaczniemy od początku - czyli od szacowania i planowania.

Przed uruchomieniem projektu czas na krótki rekonesans - dochodzi do oszacowania zakresu i pracochłonności projektu (tak… trzeba klientowi podać cenę, a nie chcemy sobie strzelać w kolano). To pierwszy moment, kiedy możemy spróbować czegoś agile. Na temat zbierania i analizy wymagań napisano i powiedziano dotąd bardzo wiele. Ale mamy włożyć w to minimum środków, aby osiągnąć jak najlepsze wyniki. Potrzebujemy określić jaki system mamy zbudować.

Zebranie wymagań i zakres projektu

Zadaniem numer jeden będzie zebranie zespołu, który będzie wykonywał projekt i doprowadzenie do spotkania z klientem lub osobami, które będą określały wymagania. Każdy rzeczywisty użytkownik systemu będzie tutaj na wagę złota, ale pracujemy z tym kogo mamy. Podczas tego spotkania chcemy doprowadzić do pewnego rodzaju burzy mózgów wszystkich zebranych.

Pierwszym etapem spotkania będzie określenie, kto będzie użytkownikiem systemu. Chodzi o ustalenie ról użytkowników jacy mogą używać systemu (przerywamy wymyślanie, jeśli zauważymy, że z trudem przychodzą nam do głowy kolejne typy). Efektem może być krótka lista. Na koniec poświęćmy chwilę na ew. wyeliminowanie ról powtarzających się pod nieco inną nazwą, lub na pewną generalizację ról o podobnych zadaniach. Taka lista ułatwi nam realizację kolejnej części spotkania.

Podstawowa zasada - mamy zawsze dostarczać użytkownikom części systemu, które będą mogli użyć. Zaczynamy zastanawiać się jakie funkcjonalności ma ten system posiadać. Głównie opowiadać powinien klient, my dopytujemy o ew. szczegóły lub prosimy o wyjaśnienie niejasnych kwestii (często rzeczy oczywiste dla klienta nie są oczywiste dla programistów). Nie musimy być specjalistami w dziedzinie klienta, mamy się znać na tworzeniu systemów informatycznych. Dlatego pytajmy o wszytko czego nie rozumiemy - wyjaśnienia na tym etapie nic nie kosztują, później będzie gorzej. Sprawny kierownik czy analityk może często pomóc naprowadzać klienta na odpowiedni tor pytaniami, jeśli nie będzie on potrafił określić dobrze swoich potrzeb.

Wymagania będziemy spisywać w formie krótkich zdań objaśniających co użytkownik może lub chce zrobić z systemem (używajmy w tym celu wcześniej wyłowionych nazw ról). Np.:

“Klient sklepu internetowego może dodać do swojego koszyka produkt, którego szczegóły ogląda na stronie.”

“Pracownik BOK może zmienić na życzenie klienta zamówienie o podanym numerze. Wymaga to wcześniejszej autentykacji klienta sklepu”.

Takie krótkie opisy wymagań nazywamy historyjkami użytkownika (ang. user stories). Cała istota tych historyjek polega na tym, że powinny one być doskonale zrozumiałe dla klienta/użytkownika, a jednocześnie powinny stanowić dobry pogląd na to co system ma robić i co trzeba zaimplementować. User stories powinny być w miarę krótkie i powinny odpowiadać pojedynczym funkcjonalnościom, lub zestawom funkcjonalności, które nie mają sensu bez siebie nawzajem. Chodzi o to, żeby dało się je implementować osobno i w dowolnej kolejności. Tradycyjnie do zapisywania user stories polecane są niewielkie papierowe kartoniki (na tyle duże, aby takie user story się zmieściło, ale jednocześnie na tyle małe, żeby nie dało się na nich pisać całych opowiadań). Kartoniki są wygodne również z innego powodu - można je dowolnie mieszać, tasować, przekładać i wreszcie w dowolnej chwili taki kartonik można podrzeć.

Drugą ważną cechą user stories jest to, że zawsze powinny przedstawiać punkt widzenia użytkownika/roli. Dlatego aby zweryfikować czy dobrze myślimy o user story można zadać sobie klika pytań pomocniczych:

• Jak zaprezentuję implementację takiej pojedynczej historyjki klientowi?
• Jak użytkownik będzie mógł użyć tak przedstawionej funkcjonalności?
• Jak przetestować czy ta funkcja działa bez pisania dodatkowego kodu?
• Czy do implementacji tej funkcjonalności będę musiał ruszyć wszystkie warstwy systemu?

Znowu wyciągamy jak największą ilość historyjek od klienta/użytkownika. Kończymy kiedy zaczyna brakować pomysłów na nowe user stories. Cała taka sesja nie powinna trwać więcej niż kilka godzin. Jeśli zadanie jest wyjątkowo duże i skomplikowane, to warto podzielić je na mniejsze (np. podsystemy, moduły) i zorganizować klika sesji tematycznych. Z całą pewnością takie sesje zajmą mniej czasu niż tradycyjne wywiady analityków i tworzenie specyfikacji wymagań. Jeśli zespołowi i klientowi nie odpowiadają kartki, można użyć Excela lub innego prostego narzędzia. Chodzi o to, że nie zależy nam szczególnie na formie, tylko na treści.

To jest pewien model. Jeśli nie uda się go zrealizować za pierwszym razem, to trudno. Najważniejsze na tym etapie jest przejście na zapis wymagań odzwierciedlający punkt widzenia użytkownika, bez zbędnego narzutu technicznego. Z takim bagażem historyjek możemy przejść do szacowania…

Szacowanie czasochłonności

Jest wiele różnych technik szacowania. Najistotniejsze, aby w szacowaniu wzięli udział wszyscy członkowie zespołu, bo to oni potem będą mieli podjąć się realizacji poszczególnych zadań. Jeśli zespół jest niedoświadczony, to można do szacowania zaprosić również jednego czy dwoje bardziej doświadczonych kolegów z innych zespołów.

Szacujemy kolejno każdą z zebranych user stories. Każda osoba na własną rękę. Potem omawiamy krótko rozbieżności - ktoś mógł czegoś nie uwzględniać, albo wręcz przeciwnie - któryś z członków zespołu doskonale zna temat i wie, że pewne elementy można wykonać szybciej.

Największym problemem jest zwykle to w jakiej jednostce szacować? Tutaj pojawia się drugie miejsce gdzie można spróbować zastosować podejście najczęściej spotykane w technikach agile. Szacowanie w jednostkach “idealnych” lub wręcz wyimaginowanych (to drugie jest często wspominane ale osobiście uważam, że przynajmniej na start z agile nie bardzo się ono nadaje). Moja rada jest taka - jeśli do tej pory szacowaliśmy w firmie wszystko w osobogodzinach przechodźmy na idealne godziny programistyczne, jeśli w dniach przechodźmy na dni idealne. Jednym słowem, nie zmieniajmy radykalnie jednostki na jakieś punkty czy coś, do czego nie jesteśmy przyzwyczajeni.

Co to jest idealna godzina/dzień programistyczny? Jest to wyidealizowany czas, który poświęcilibyśmy tylko i wyłącznie na pracę nad wyznaczonym zadaniem. Czas zmierzony z zegarkiem w ręku, kiedy wszystkie nasze czynności wiążą się z wykonaniem zadania. Ĺťadnych rozmów z kolegami, żadnych odpowiedzi na rzucone w salę pytania, żadnych telefonów, kawy czy herbaty w kuchni, papierosa czy nawet wyjścia do toalety. Tylko praca w czystej formie. Każdy rozsądnie myślący człowiek powiedziałby w tym miejscu, że przecież takie dni czy godziny praktycznie się nie zdarzają. I oczywiście tak jest. Co więcej jest to zupełnie naturalne. W takim razie co to ma wspólnego z szacowaniem?

Każdy z nas udzielając odpowiedzi na pytanie “Ile potrwa zdanie X?” może jej udzielić, albo na bazie wcześniejszych doświadczeń związanych z takim samym lub podobnym zadaniem, albo starając się szybko w myślach rozłożyć zadanie na mniejsze znane mu elementy. Podświadomie porównujemy w takim momencie postawiony przed nami problem do innych, które już kiedyś rozwiązaliśmy. Chodzi o to, że myśląc o czasie, podświadomie myślimy w jednostkach idealnych. Tymczasem naszej pracy towarzyszy szereg innych czynności nie przekładających się bezpośrednio na tworzenie oprogramowania. Poza codziennymi nawykami, jak zrobienie sobie kawy, zdarza się też wiele zdarzeń nieprzewidywanych. Typowe z nich, to pytania od kolegów, odbieranie telefonów, itp. Nie jesteśmy w stanie przewidzieć ich ilości i zwykle tego nie robimy. “Zrobię to w maksymalnie 4 godziny” oznacza częściej “Zrobię to w maksymalnie 4 godziny, jak nic mi nie będzie przeszkadzać” niż “Jeśli uwzględnić 2 telefony po 5 min, jedno wyjście do toalety i może 3 pytania, którym poświęcę w sumie 10 min, to zadanie o które mnie pytasz zrobię w maksymalnie 4 godz.”

Każdy indywidualnie ma pewne tempo pracy, które można określi np. jako ilość idealnych godzin, jakie dana osoba jest w stanie faktycznie zrealizować w ciągu 8-godzinnego dnia pracy. Albo ilość idealnych dni jakie jesteśmy w stanie faktycznie zrealizować w 5-dniowym tygodniu. Ta wielkość często nosi nazwę wydajności (ang. velocity) i zależy zarówno od indywidualnych cech pracownika jak i od samego projektu czy też otaczającego nas środowiska pracy. Tradycyjne metodyki zarządzania projektami bardzo często nie uwzględniają takiego efektu. Agile natomiast zachęca do przejścia na szacowanie w jednostkach idealnych (skoro i tak okazuje się, że podświadomie właśnie tak szacujemy). Ważne będzie także ciągłe badanie velocity naszego zespołu, bo jest to narzędzie znacznie ułatwiające prognozowanie przyszłego stanu projektu.
Z każdym nowym projektem i przy w miarę stabilnym składzie zespołu powinno udać się nam zauważyć pewną średnią wartość takiej wydajności, a to już bardzo cenna informacja dla np. wycen projektu. Także w trakcie projektu należy badać wydajność, bo rozpoczynając dokonaliśmy pewnego przypuszczenia co do tego, na jakim poziomie będzie się ona kształtowała, a teraz czas to zweryfikować.

Tak więc naszą listę user stories oszacujmy w jednostkach idealnych przy zachowaniu używanej do tej pory wielkości (godzin lub dni). W dużym skrócie, aby podać klientowi przewidywaną cenę projektu, należałoby takie szacunki pomnożyć prze pewien współczynnik. Dla zespołu posiadającego już pewne doświadczenie i nie rozpraszanego zbyt często “zadaniami na boku” przyjąłbym przy pierwszym projekcie bezpiecznie taki współczynnik na poziomie 1,25 - 1,5. Wynik mnożenia da przewidywaną liczbę godzin lub dni roboczych, które już w miarę prosto da się przełożyć na koszty. Więc dalej manager może już z taką informacją przystępować do negocjacji. Niemniej na tym etapie nie robiłbym jeszcze takich mnożeń. Kolejnym krokiem będzie ubranie tak oszacowanych zadań w plan iteracji i ew, wydań, ale o tym następnym razem.

Tymczasem, jeśli kogoś zainteresowało podejście oparte na user stories i velocity (o którym też trochę więcej przy okazji planowania, bo tam będzie to użyteczna informacja), to polecam bardzo dobrą książkę Mike’a Cohna pt. “User Stories Applied” (niestety dostępna po angielsku).

Udanego pisania historyjek.

8 comments December 6th, 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

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