Kategoria 'Agile dla managerów'
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 :-)
March 1st, 2007
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
February 23rd, 2007
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.
December 20th, 2006
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.
November 22nd, 2006
Od dłuższego czasu obserwujemy wzmożony wzrost popularności zjawiska nazywanego “leasingiem pracowniczym”. Mam nawet wrażenie (być może związane tylko z lokalnym rynkiem IT, z jakim mam kontakt), że firm wynajmujących programistów jest już więcej niż firm tworzących oprogramowanie na własne potrzeby. Wynajmują pracowników duże korporacje, wynajmują banki.
Kiedyś wystarczał “outsourcing” samej usługi do firmy zewnętrznej. Teraz firma IT ma fizycznie wstawić swoich pracowników do firmy klienta na kilka tygodni/miesięcy, żeby tam w ramach zespołu klienta wykonali (czy raczej podgonili) jakąś część projektu. Co to wszystko ma wspólnego z agile? No więc dla mnie agile to między innymi silne zespoły. Silne ze względu na swoją niezależność, samowystarczalność, zdolność adaptacji i utrzymania wysokiej jakości produktów - takie samojezdne, samonapędzające się machiny do zadań specjalnych. Tylko co dzieje się z zespołami kiedy zaczynamy fizycznie delegować naszych pracowników? Co z wydajnością takich zespołów. Co z jakością ich pracy?
Popularność leasingu/wynajmu pracowników ma kilka dość łatwych do odgadnięcia powodów. Od strony klienta to pewna mutacja outsourcingu z tą małą różnicą, że skoro wynajmuje firma IT, to woli dostać ludzi, nad którymi będzie miała kontrolę zamiast podpisywać kontrakty na wykonanie podsystemu i kontroli nie mieć. Posiadanie dodatkowych ludzi, których po skończonym projekcie/etapie można odesłać do ich własnej firmy pozwala ograniczyć koszty utrzymywania własnego rozbudowanego zespołu IT na stałe, ale także jest chyba mniej ryzykowne niż tradycyjny outsourcing.
Powodami ekonomicznymi kieruje się zapewne także firma wynajmująca swoich ludzi. Coraz trudniej jest znaleźć wykwalifikowanych i doświadczonych pracowników, więc wrosła cena pracy programistów, a skoro tak, to pojawiło się dużo firm, które z tej “górki” chcą w prosty sposób wziąć coś dla siebie. Często firmy działające jako tradycyjne software house są narażone na chwilowy przestój w zleceniach, co powoduje, że mają część zespołu, który przez moment może nie mieć co robić. Wtedy lepiej wynająć tych ludzi (i przy okazji na tym zarobić) niż ponosić koszty trzymania pracowników przez ten jałowy okres, czy zwalniać ich (bo potem będzie problem z odbudową zespołu).
Wydaje się, że nie ma co polemizować z takimi przesłankami. Ciekaw jestem tylko czy wynajmując programistów, osoby za to odpowiedzialne rozważają następujące czynniki:
- Czas aklimatyzacji programisty w zespole. Tworzenie oprogramowania nie jest czynnością mechaniczną tylko umysłową. Ĺťeby ją wykonywać człowiek musi mieć do tego odpowiednie warunki i predyspozycje. Pisali o tym już DeMarco i Lister w “Czynniku ludzkim” (ang. tytuł: Peopleware), przypominał także ostatnio na JDD2006 Bruce Eckel - programistów nie można dowolnie między sobą wymieniać. Ponadto każdy programista ma zupełnie inną wydajność w pierwszym tygodniu pracy, a inną po miesiącu. A czy wynajmując pracownika różnicuje się stawki w zależności od jego “stażu” w nowym miejscu pracy? Zatrudniając pracownika na stałe ponosimy koszt aklimatyzacji raz. Okresowo wynajmując pracowników koszt jest częstszy chyba, że mamy szczęście wynajmować za każdym razem tych samych ludzi.
- Konflikt interesów. Cele pracownika wynajmowanego nie są zgodne z celami firmy klienta. W interesie klienta jest szybkie zakończenie pracy, ale dłuższy czas gra na korzyść firmy wynajmującej pracownika, bo przecież wystawi ona fakturę za czas wynajęcia a nie za zadania (zadania to już sprawa klienta). Oczywiście aby firma świadcząca usługi wynajmu programistów mogła się utrzymać u klienta i liczyć na kolejne zlecenia, musi zapewnić odpowiedni poziom kwalifikacji swoich pracowników. Wydaje mi się jednak, że siłą rzeczy nie osiągną oni w swojej pracy 100% tego co mogliby osiągnąć dla swojej firmy, w swoim zespole. A co jeśli będą mieli nawet polecenie “z góry”, żeby się specjalnie nie spieszyć, bo są w końcu zatrudnieni na godziny. Ten konflikt interesów wydaje mi się najpoważniejszą wadą w stosunku do tradycyjnego modelu outsourcingu, gdzie na czasie zależy zarówno zleceniodawcy jak i wykonawcy, a wszyscy pracują u siebie.
- Ograniczona odpowiedzialność. Wpuszczamy do firmy programistów z zewnątrz, którzy niedługo nas opuszczą i pójdą do innych firm. Siłą rzeczy ograniczamy im możliwość podejmowania jakichkolwiek istotnych decyzji, ograniczamy dostęp do pewnych krytycznych dla firmy zasobów itd. To ogranicza im swobodę tworzenia oprogramowania, do którego ich zatrudniliśmy. Taka sytuacja albo spowoduje przestoje w ich pracy, albo zaangażuje dodatkowo członków naszych rodzimych zespołów pogarszając ich wydajność. No bo skoro tamci nie mają prawa wykonać pewnych rzeczy, to ktoś inny będzie to musiał zrobić w ich imieniu. Czy w rachunku ekonomicznym bierzemy pod uwagę takie koszty? Jak je uwzględnić? Taka organizacja pracy przeczy zasadzie samo organizujących się zespołów (chyba, że ich kierownik w firmie klienta pozwoli im się organizować w ramach ich ograniczonych możliwości). Z resztą chyba najczęstszym podejściem zarządzającego takim zespołem będzie jednak ścisła kontrola poczynań jego członków. Widzę tutaj także istotny problem umotywowania takich ludzi do pracy, skoro są niejako pracownikami trochę gorszej kategorii.
- Podkopywanie własnych zespołów. Jeśli zamiast tworzyć z wynajętych programistów odrębnego zespołu wcielimy ich do istniejących u nas zespołów, to po pierwsze zadziałają efekty przytaczane przez Brooks’a w “Mitycznym osobomiesiącu” - nasi ludzie zamiast zajmować się pracą zaczną zajmować się nowymi ludźmi. Poza tym jeśli mamy w zespole programistów “tymczasowych”, to możemy mieć do czynienia z sytuacją, kiedy zespół nie będzie chciał wziąć odpowiedzialności za kod ludzi z zewnątrz. Z resztą tymczasowi pracownicy także nie są skłonni do przyjmowania celów grupy jako własnych. A wspólna własność kodu to jedna z ważnych i wartościowych zasad stosowanych w praktykach agile. Ludzie będą raczej mieli skłonność do obwiniania tych, których nie ma już w firmie, za wszelkie zło w projekcie. Oczywiście ta sama zasada wspólnej własności kodu mogłaby pomóc w tym przypadku, ale jakoś ciężko mi to sobie wyobrazić.
To pewnie tylko kilka sytuacji, jakie mogą się wiązać z nowym pomysłem na życie coraz większej liczby firm w naszej branży. Wydaje mi się, że jest to jeden z trybów pracy jaki wyjątkowo nie sprzyja używaniu agile. Ale może się mylę i da się agile pogodzić czy wręcz wykorzystać na korzyść leasingu programistów (o czym chętnie usłyszę). Tymczasem namawiam do inwestycji we własne zespoły, bo silny kilkuosobowy zespół da radę dużo większej liczbie często przypadkowych ludzi.
Dobrze byłoby gdyby przynajmniej rachunek zysku i strat nie ograniczał się wyłącznie do przeliczenia stawki godzinowej, ale uwzględniał także tą drugą stronę medalu.
November 6th, 2006
Niedawno przeczytałem wywiad z Paulem Klippem, jakiego udzielił on na łamach portalu IT w Krakowie. Zapytany o to, czy jego firma realizuje projekty dla klientów z Polski wykorzystując metody agile, odpowiedział między innymi:
“Dopóki polscy klienci nie zdadzą sobie sprawy z tego, że oferty o ustalonej cenie i ustalonym zakresie funkcjonalności im szkodzą i dopóki nie zaczną zwracać większej uwagi na jakość oprogramowania, nie będę miał zbyt wielu okazji realizować tutaj projektów z wykorzystaniem agile.”
Z jednej strony zgadzam się z tym całym sercem, ale z drugiej strony jak polscy klienci mają sobie zdać sprawę z tego co tak faktycznie dostają prosząc o kontrakt z ustalonym zakresem i ceną? Ostatnio wydawało się, że jeden z klientów firmy w której pracuję da się namówić na poprowadzenie projektu wg założeń agile, jednak po kilku dniach poprosił o kontrakt z ustaloną ceną i zakresem. Poniosłem osobistą klęskę, ale skłoniło mnie to do zastanowienia się nad tym z czym kojarzy się naszym klientom wykonanie projektu technikami agile (o ile w ogóle z czymś im się kojarzy), a jaka jest percepcja zamkniętych kontraktów? Z czego wynika ich obawa przed agile? A z czego wynika to poczucie bezpieczeństwa jakie odnajdują oni w zamkniętych kontraktach.
Miałem okazję uczestniczyć w wielu rozmowach z klientami, które prowadziły do stworzenia słynnego dokumentu “Specyfikacja Wymagań Systemowych”, a który następnie stawał się załącznikiem do umowy. Jakich korzyści dopatruje się klient w zamkniętym kontrakcie?
Według klientów najlepsze cechy kontaktów zamkniętych to zwykle:
- Ustalony zakres kontraktu. Przedstawiam wykonawcy moje oczekiwania. On przygotowuje dla mnie zestawienie, może także dokładną specyfikację tego co zostanie wykonane. Wszystko to ma formę załącznika do kontraktu. Obaj wiemy co zostanie wykonane.
- Ustalona cena kontraktu. Wykonawca na podstawie zakresu podał mi ile godzin zajmie wykonanie projektu. Na tej podstawie wyliczył cenę za wykonanie (W uproszczeniu liczba godzin x stawka za godzinę). Na samym początku wiem czy stać mnie na program czy nie. Mogę także porównać wiele ofert i wybrać tą najkorzystniejszą cenowo.
- Ustalony termin wykonania. Przedstawiłem wykonawcy co chcę otrzymać (mam załącznik do umowy) i ten zakres projektu został wyceniony zarówno w godzinach jak i w kwotach. Wiemy więc także kiedy projekt zostanie zakończony.
- Karne odsetki. O tak, jeśli wykonawca się spóźni, to za każdy dzień zwłoki zapłaci mi karne odsetki.
Brzmi pięknie prawda? A jak jest naprawdę? I dlaczego jednak w większej części przypadków wykonanie takich kontraktów kończy się frustracją klientów, managerów i programistów.
Ustalony zakres kontraktu
W grze pod tytułem “budowanie specyfikacji” biorą udział dwie strony (mam nadzieję, że nie jest to w naszych realiach nadmierny optymizm) - klient i wykonawca. Aby można było z czystym sumieniem powiedzieć, że możliwe jest ustalenie stałego zakresu projektu musiałyby być spełnione pewne warunki.
Po pierwsze klient musi dokładnie wiedzieć co chce otrzymać. Jak taki system ma wyglądać, żeby dokładnie spełniał jego wymagania? Jakie powinien mieć funkcje? Ale przecież klient przychodzi do nas i prosi o zbudowanie systemu, którego nie posiada, którego nie widział nigdy na oczy, albo widział coś podobnego, co spowodowało, że przyszły mu do głowy nowe pomysły. Jednym słowem przychodzi do nas z wizją czegoś co ma mu ułatwić życie. Czy wizję można zamknąć w sztywne ramy specyfikacji? Zamknąć zakres?
Po drugie wykonawca musiałby wręcz czytać w myślach klienta, aby specyfikacja jaką stworzy w 100% odpowiadała temu co klient miał na myśli.
Oczywiście trzeba tu rozsądnie rozdzielić budowanie produktów w pewnym sensie innowacyjnych, dostosowanych do potrzeb klienta, od wdrożeń np. prostych stron internetowych czy gotowych rozwiązań. W tym drugim przypadku można oczywiście rozłożyć projekt na części pierwsze i powiedzieć, że będą konieczne określone elementy, zadania i zasoby. Jeśli taką pracę nasz zespół wykonywał już wielokrotnie i doskonale ją zna to ma to się nawet szansę udać. Postępujemy wtedy według schematu, więc i kontrakt może być schematyczny.
Ale czy klient przychodzący do nas z zapytaniem ofertowym o budowę np. systemu zarządzania pewnym procesem biznesowym w jego przedsiębiorstwie, w którym to procesie bierze udział kilkadziesiąt osób, jest nam w stanie powiedzieć jakiego dokładnie (z najdrobniejszymi szczegółami) oczekuje działania. Pewnie wielu z nas stwierdziłoby w tym momencie, że przecież od tego są analitycy i projektanci. Klient nie musi wiedzieć wszystkiego. Pomożemy mu dojść do tej wiedzy. Przeprowadzimy wywiady, będziemy projektować, modelować, rysować i pisać długie dokumenty. W optymistycznym wariancie na końcu tego długiego procesu otrzymamy faktycznie coś co będzie można nazwać szczegółowym zakresem oraz projektem systemu (osobiście jeszcze takiego dokumentu nie widziałem). Załóżmy nawet, że uda się określić co do godziny ile czasu zajmie każdy z elementów.
I co z tego ma klient? Spędził z nami tydzień, miesiąc. Ten czas zostanie mu oczywiście doliczony do ceny kontraktu, a cena analityka i projektanta akurat nie jest tutaj najniższa. I co dostanie w zamian… załącznik do umowy. Czy ten załącznik rozwiązał chociaż jeden z jego problemów biznesowych?
A co na to metody agile? Zaczynamy od krótkiego spotkania, może dwóch, na których identyfikujemy pewne wstępne priorytety, cele, pierwsze wymagania (nie ważne, czy będziemy tutaj posługiwali się user stories, przypadkami użycia, czy inną techniką). Najistotniejsze w tym wszystkim jest to, że wszystkie metody agile stawiają na rzeczy najważniejsze w pierwszej kolejności. Gwarantujemy, że zajmiemy się od razu tym co klient uznał za najistotniejsze z punktu widzenia jego biznesu.
Przy dużych systemach nie da się zwykle uniknąć tzw. “iteracji zerowej”, w trakcie której powstają pewne podwaliny dla architektury systemu. Ale słowo “powstają” jest tutaj kluczowe. Od pierwszych dni powstaje produkt, który będzie stanowił wartość dla klienta. Nie jakiś dokument opisujący jak będzie pięknie, tylko system, który można użyć, zobaczyć, mieć na jego temat jakieś zdanie. Drodzy klienci, czy nie lepiej zapłacić za coś co stanowi jakąś wartość zamiast za (bez)wartościowy dokument?
Co jeśli jednak klient po kilku tygodniach/miesiącach zmieni zdanie? Może zmieni się sytuacja biznesowa - konkurencja przecież nie śpi w tym czasie? A może po prostu ma już lepszy pomysł, bo w miarę upływu czasu przemyślał pewne rzeczy jeszcze raz. Co wtedy z naszym załącznikiem do umowy. Odpowiedź jest jedna - wchodzimy na mglistą ścieżkę procesu zmiany wymagań. A jest to ścieżka kręta i pełna niespodzianek. Umówiliśmy się przecież na początku co do zakresu projektu, a z niego wynikały koszty i terminy. Teraz trzeba to przeliczyć i dołączyć do umowy nowy załącznik. I co? Znowu dokument i koszty zamiast nowego kawałka systemu.
Wszyscy też doskonale wiemy co dzieje się z kosztem zmian wraz z upływem czasu. Całe szczęście jeśli klient będzie miał okazję zapoznać się z jakimś pośrednim stadium projektu zanim będzie za późno. Zwykle jednak przy kontraktach z zamkniętym zakresem produkt poddawany jest ocenie (tzw. testom akceptacyjnym) tuż przed jego finalnym oddaniem (programiści mogliby przytoczyć mnóstwo opowieści z okresu między rozpoczęciem tych testów a oddaniem projektu).
Znowu - co na to agile? Ha! Przecież “zmiany” to drugie imię technik agile. Stosując dowolne podejście agile zakładamy, że żadne z wymagań poza tymi, które weszły do bieżącej iteracji, nie jest trwałe i praktycznie w każdej chwili można je zmienić, przełożyć jego wykonanie, czy nawet zrezygnować z niego. Siła agile nie leży w tym, że metody te dają przyzwolenie dla częstych zmian. Powiedziałbym raczej, że metody te stwarzają dogodne warunki do dokonywania zmian i dają klientowi wolność wyboru, której nie ma kiedy podpisze kontrakt zamknięty i klamka zapadnie. Wynika to z nastawienia procesów agile na częste spotkania i prezentacje kolejnych zrealizowanych w pełni funkcjonalności oraz na krótkie etapy, w których tworzone są kolejne wersje systemu. Oczywiście proces ten ściśle angażuje klienta, ale w końcu chodzi mu o uzyskanie dobrego produktu - za to płaci.
Czy w takim razie zamknięcie zakresu projektu w kontrakcie chroni klienta? Sądzę, że to pierwszy z mitów jakie są związane z tego typu kontraktami. Oczywiście wykonawca będzie bronił jak lew takiego zakresu. Za to klient bardzo szybko dowie się, że drzwi, które cichutko zamknął zostały z hukiem zaryglowane z drugiej strony i otworzą się dopiero pod koniec projektu. Podejście agile wymagałoby wykluczenia z kontraktu zakresu i jedynie ustalenia budżetu oraz zasad wykonania kontraktu. Jednak pod tym pozornym brakiem zapisów umownych klient dostanie większą kontrolę nad tym za co faktycznie płaci.
Ustalona cena kontraktu.
Co tak faktycznie oznacza ona dla klienta? Nie oszukujmy się… cena w sztywnym kontrakcie, to cena jaką klient płaci za wykonanie zapisów załącznika do umowy stworzonego przez wykonawcę i zgodnie z tym jak go zrozumiał… właśnie wykonawca. Gdy nastąpi wreszcie ten sądny dzień oddania projektu obie strony, usadowione dotąd wygodnie w swoich okopach, wyjdą z nich i zaczną do siebie strzelać amunicją złożoną z zarzutów, argumentów i interpretacji tego nieszczęsnego dokumentu.
Dodatkowo do ceny kontraktu zostanie wpleciony koszt pracy jaka miała go zabezpieczyć, a która dała mu specyfikację wymagań systemowych w formie aneksu. Zamiast zapłacić za produkt sam sponsoruje sobie kaftan bezpieczeństwa w postaci aneksu do umowy.
Wspomniałem wcześniej o koszcie zmian przy kontraktach zamkniętych. Koszty te wynikają z faktu, że wykonawca wyczerpuje zwykle cały budżet zapewniony mu w kontrakcie dla wykonania pierwszej wersji, czyli zapisów załącznika z zakresem. Więc jeśli klientowi nie spodoba się osiągnięty efekt, to możliwości są trzy - albo dopłaci za zmiany, albo wyrzuci to co dostał do kosza, albo weźmie produkt taki jaki jest. W każdej sytuacji traci:
- dopłaca - przekracza automatycznie cenę kontraktu (a miał przecież wiedzieć ile zapłaci za swój system)
- wyrzuca do kosza produkt - czyli robi prezent wykonawcy, któremu i tak zapłaci, bo ciężko się będzie wycofać z zapisów umownych
- bierze to co jest - na chwilę usypia swoje sumienie (cena jest, jaka miała być) ale prędzej czy później i tak zgłosi się po zmiany (może w ramach kolejnego kontraktu z załącznikiem - tak czy siak cena zostanie przekroczona)
Ile kosztują zmiany kiedy stosujemy metody agile? Najczęściej zmiana wynika z tego, że klient podczas kolejnego spotkania i obejrzeniu swojego systemu wybiera inny kierunek prac niż ten pierwotnie planowany. Taka zmiana nie kosztuje nic a daje jedną podstawową przewagę nad procesem funkcjonującym za kontraktem o ustalonej cenie i zakresie. Taka zmiana jest po prostu możliwa, bo klient nie czekał do zakończenia kontraktu, kiedy okazało się, że można było zmienić kilka rzeczy w połowie drogi. Pomiędzy iteracjami klient ma wręcz możliwość zmiany zakresu. Chcę tu jasno podkreślić, że nie jest to żadne magiczne napełnianie worka bez dna. Możemy zmienić zakres, ale nie poszerzać go. Natomiast klient być może będzie musiał poświęcić jakieś mniej istotne szczegóły na rzecz tych kluczowych. To on decyduje, które są które i co zostanie wykonane najpierw a co potem.
Oczywiście często zdarzy się, że klientowi nie spodoba się efekt iteracji, i trzeba będzie wprowadzić poprawki z tym co do tej pory zostało zrobione. W zależności od wagi zmian, albo wykonujemy je od ręki albo tworzymy z nich nowe zadanie do zaplanowania w kolejnej iteracji (zepchnie ono automatycznie jakieś inne mało istotne z końca listy). Pamiętajmy jednak, że iteracje są możliwie krótkie więc nie ma zbyt dużych możliwości stworzenia implementacji znacząco odbiegającej od oczekiwań, czego nie można powiedzieć o efekcie kilkumiesięcznej pracy, jaki ogląda klient podczas odbierania projektu z kontraktu zamkniętego. Więc zmiany w wykonanych funkcjach będą zwykle niewielkie.
Jak w takim razie określić cenę kontraktu jeśli chcemy użyć technik agile. To chyba moment, który budzi największe obawy klienta - nie określać ceny! Możemy przyjąć stawkę dzienną, godzinową lub inną, wg. której będziemy się rozliczać. Możemy także ustalić budżet, tylko nie w odniesieniu do konkretnych zadań i zakresu projektu, ale w odniesieniu do np.ilości idealnych dni programistycznych wg jakich estymujemy funkcjonalności (to dość szeroki temat wart osobnego artykułu).
Chyba największym nieporozumieniem jakie wiąże się z kontraktami i technikami agile, jest przeświadczenie, że nie można określić i kontrolować kosztu takiego projektu. Wydaje mi się, że można to zrobić dużo dokładniej niż przy projektach z ustaloną ceną. Oczywiście nie powiemy klientowi pierwszego dnia, że program będzie kosztował dokładnie X złotych. Ale możemy przecież już na początku określić wstępnie jak duży jest projekt i ile może kosztować (określić jakieś rozsądne granice), co da klientowi pojęcie czy to jest to, czego się spodziewał i czy go na to stać. Poza tym techniki agile w żadnym wypadku nie stoją na przeszkodzie skrupulatnej kontroli budżetu. Za to dokładnie wiemy za co zapłaciliśmy i wiemy także, że wydaliśmy pieniądze najlepiej jak mogliśmy, bo z każdą iteracją dostajemy produkt co do którego mamy pewność, że ma to czego chcieliśmy i nić ponad to, za co wcale nie chcieliśmy płacić.
Każdy kto chce wydać pewną kwotę na oprogramowanie, powinien zadać sobie pytanie co dostanie w dniu wyznaczonym jako data zakończenia projektu przy kontrakcie z ustaloną ceną i zakresem, a co przy kontrakcie bez ceny, ale opartym na metodach agile? Moim zdaniem nie wiadomo co dostanie przy zamkniętym kontrakcie i mało prawdopodobne aby klient był z tego w pełni zadowolony. A co klient dostanie od firmy używającej agile? Dostanie produkt lepszy niż ten o którym myślał kiedy rozpoczynaliśmy projekt. Z każdym tygodniem powinien też być o to spokojniejszy. Możliwe, że zdarzy się tak, iż do tego samego terminu nie zostanie wykonana pewna funkcjonalność, ale przecież te, które zostały to samo sedno produktu. Być może to o czym myślał na początku w ogóle nie było potrzebne.
Dochodzimy tym samym do ostatniego elementu. Do terminu.
Ustalony termin wykonania.
Techniki agile kompletnie nie przeszkadzają w ustaleniu konkretnego terminu zakończenia projektu. Wręcz przeciwnie - wszystko co w agile robimy, wykonujemy przy dużej samodyscyplinie i w konkretnych terminach. Nie przeciągamy iteracji, nie ma w połowie wykonanych elementów. Wszystko jest z góry ustalone. Paradoks? Wcale nie. Agile uwielbia ten stały rytm pracy, to dzięki niemu możemy coraz dokładniej udzielać odpowiedzi na pytanie co i kiedy.
Przy zamkniętym kontrakcie ustalamy na początku zakres oraz termin wykonania i potem zespół przystępuje do pracy. Przypomina to bardzo ciężką lokomotywę, która rozpędza się powoli zanim osiągnie swoją optymalną prędkość. Wiadomo - termin zakończenia projektu jest tak odległy, że na pewno zdążymy - spieszymy się więc powoli. Zespół dobiera sobie zadania w wygodnej dla niego kolejności, co zwykle nie idzie w parze z priorytetami klienta. Ale przecież klient oceniać będzie efekt końcowy, więc kolejność po drodze nie ma znaczenia. I co się dzieje pod koniec projektu, kiedy okazuje się, że zostało więcej zadań niż czasu? Przecież wykonawca nie będzie płacił karnych odsetek. Jest łatwiejsze rozwiązanie. Kończymy wszystko byle jak, ale w terminie. Ważne, żeby podczas odbioru wszystko dobrze się zaprezentowało, a potem się zobaczy. Poświęcamy jakość. W końcu klient będzie płacił za support.
W projekcie agile nie ma zbyt dużo miejsca na taki scenariusz, bo klient na bieżąco określa kierunek i dba o to, aby powiedzieć zespołowi o swoich bieżących priorytetach. Efekt jest taki, że kiedy zbliża się termin określony w kontrakcie, wtedy mamy pewność, że mamy produkt, który zaspokaja możliwie najwięcej potrzeb klienta (nawet jeśli pewne drobne, mało istotne elementy nie zostały wykonane).
Jest tutaj miejsce na jeszcze jedną rzecz, na którą chciałbym zwrócić uwagę. Często okazuje się, że pewne zadania zajęły mniej czasu niż miały (tak… mimo panującej opinii, ze projekty informatyczne nie kończą się zwykle w ustalonym terminie). Chodzi o to, że tak wypracowany zysk zabierany jest później przez pracochłonne i niepotrzebne funkcje, które zespół wykona żeby spełnić wymagania załącznika do umowy. Albo po prostu klient nie dowie się o tym, że coś trwało krócej. Ilu z nas widziało kiedyś, aby firma IT na koniec projektu powiedziała klientowi, że umawialiśmy się co prawda na pewną kwotę ale poszło nam szybciej więc cena będzie niższa? Projekt agile w moim przekonaniu powinien być oparty na wzajemnym zaufaniu i zrozumieniu. Klient musi być przygotowany na to, że nie jesteśmy jasnowidzami i pewne rzeczy zajmą więcej czasu niż mogliśmy początkowo przypuszczać, ale dołożymy wszelkich starań żeby dostał to czego potrzebuje. Będzie miał za to zawsze szansę zdecydować, czy zmiana pracochłonności nie stanowi dla niego podstaw do obniżenia priorytetu zadania i przesunięcia go na później. Ale z drugie strony klient musi mieć pewność, że jeśli uda się nam skończyć coś wcześniej to wtedy zespół skontaktuje się z nim w celu wciągnięcia do iteracji jeszcze jakiegoś elementu z planu kolejnych etapów. Zamknięte kontrakty zawsze zakładają jedynie wzrost ceny jeśli coś pójdzie gorzej.
Na koniec chciałbym wyjaśnić, że dokonałem tutaj pewnego uproszczenia zakładając, że za kontraktem o stałej cenie i zakresie jest ukryty proces podobny do kaskadowego. Wiele osób pomyślało już na pewno, że można zastosować etapy pośrednie wykonując zamknięty kontrakt aby zminimalizować ryzyko nie trafienia w oczekiwania klienta. Jednak szybko dojdziemy do wniosku, że taka minimalizacja ryzyka przerodzi się prędzej czy później w coraz większe adaptowanie technik agile w tego typu projekcie (o tym może niedługo). Być może nawet finałem tej adaptacji będzie podpisanie kontraktu bez załącznika z zakresem projektu i ceną, a zespół (łącznie z Zarządem) stwierdzi, że jest jest już bardziej agile niż jeszcze pół roku temu…
Czego sobie i wszystkim Wam życzę :-)
October 2nd, 2006
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…
September 23rd, 2006
Next Posts
