W zeszłym tygodniu miałem przyjemność uczestniczyć w warsztatach zorganizowanych przez PMI PC które prowadził Piotr Burdylo. Tematem warsztatu było szacowanie w zwinnych zespołach. Od jakiegoś czasu interesuję się projektami, których celem jest stworzenie oprogramowania i zwinnymi (agile) metodami zarządzania. Warsztaty skłoniły mnie do napisania tego artykułu, w którym przedstawiam różnice pomiędzy zwinnym a klasycznym prowadzeniem projektu tak, jak je obecnie rozumiem.
Piotr rozpoczął warsztaty od prezentacji istotnych elementów podejścia zwinnego do zarządzania projektami. Zwinna definicja projektu to tymczasowe przedsięwzięcie prowadzone w celu dostarczenia unikalnego produktu lub usługi. Jak widać jest taka sama jak w podejściu klasycznym (PMI/PMBOK). W podejściu zwinnym zwraca uwagę koncentracja na celu – produkcie projektu, który ma być osiągnięty w skończonym czasie. Piotr zwracał uwagę, że w klasycznym trójkącie zależności – zakres – czas – koszty, wszystkie elementy są ruchome ale zamiany zakresu często są ignorowane przez „klasyków”. Detaliczna definicja produktu na początku projektu i szczegółowo zaplanowana realizacja grozi wytworzeniem produktu, którego zamawiający już nie potrzebuje. PMI jako klęskę projektu definiuje wytworzenie produktu, którego nikt nie potrzebuje. Trudno zatem uważne zarządzanie zakresem, tak aby tworzony produkt spełniał potrzeby (biznesowe) stojące za uruchomieniem projektu, uznawać za odstępstwo od wytycznych PMI.
Piotr omawiał rolę właściciela produktu (product owner), mającego interes w powstaniu produktu spełniającego jego wymaganiami i dysponującego środkami do jego wytworzenia. Bliska współpraca właściciela produktu z zespołem projektowym, szybkość podejmowania decyzji i budowanie wspólnej wizji produktu mają kluczowe znaczenie dla ostatecznego sukcesu. Trudno oprzeć się wrażeniu, że Piotr opisywał zachowanie idealnego sponsora projektu. Piotr pokazywał w jaki sposób trudności w komunikacji przekładają się na zarządzanie zakresem projektu. Właściciel produktu ma wizję ale ma też trudności w jej zakomunikowaniu zespołowi. Często właściciel produktu nie jest jego użytkownikiem, reprezentuje więc swoje wyobrażenia tego, co użytkownicy chcą mieć. Wyobrażenia takie bywają błędne. Wyzbycie się lęku przed błędami i akceptacja rozwoju produktu przez budowanie kolejnych prototypów daje lepszy produkt końcowy. Akceptujemy ryzyko odrzucenia pierwszych wersji produktu i rozpoczęcia pracy od nowa – bez produktu ale z lepszym wyobrażeniem jaki produkt ma być. W zamian za to unikamy ryzyka dostarczenia produktu zgodnego z początkową specyfikacją i niezgodnego z faktycznymi wymaganiami. A to przecież oznaka fiaska projektu według PMI.
Należy zwrócić uwagę na ryzyko związane z budową perfekcyjnego WBS na początku projektu, kiedy świadomość ostatecznego wygładu produktu jest niska. Opisany w nim produkt będzie miał się nijak do pożądanego rezultatu. Nie ma powodu inwestować w opracowanie szczegółów, które nigdy nie powstaną, bo to tylko starta czasu i innych zasobów. Oczywiście ogólna wizja produktu powinna nabierać szczegółów w miarę skracania czasowej perspektywy. To co robimy w najbliższym tygodniu powinno być wzajemnie uzgodnione co nie oznacza, że wszystko musi być detalicznie udokumentowane. W zwinnym zarządzaniu duże znaczenie ma zaufanie członków zespołu i zaufanie do właściciela produktu. Zaufanie to jest budowane przez dostarczanie kolejnych wersji produktu. Opisane wyżej podejście to nic innego jak planowanie iteracyjne (Rolling Wave Planning), technika znana z PMBOK.
Piotr podnosił kwestię skuteczności formalizmów w projektach, których produktem jest oprogramowanie. Pod koniec ubiegłego wieku pojawił się trend szczegółowego dokumentowania pisanego oprogramowania. W rezultacie projekty, które miały robić software a produkowały dokumentację i opóźnienia. Przypomniało mi to opowieść kolegi, który budował detektor cząstek elementarnych w dużym eksperymencie (CERN / DELPHI). Niezbędne do funkcjonowania detektora było oprogramowanie do odczytu danych, które pisał przez kilka miesięcy osobny zespół liczący kilkanaście osób wykorzystujące najnowsze techniki inżynierii oprogramowania i zarządzania projektami. Projekt utknął na etapie definicji i dokumentowania funkcjonalności produktu, tymczasem kolega potrzebował oprogramowania bo właśnie zaczynał testy detektora. W desperacji zaprosił do współpracy innego kolegę i we dwóch zakodowali w dwa dni (i jedną noc) niezbędną im funkcjonalność. Oprogramowanie nie musi być ładne, musi mieć wymaganą w funkcjonalność wtedy, kiedy jest ona potrzebna.
Zwinne zarządzanie nie jest dla właścicieli produktu, którzy nie wiedzą czego chcą i boją się podejmować decyzje. Czy podejście do zarządzania zakresem, w którym pierwszeństwo ma produkt nad dokumentacją jest sprzeczne z filozofią PMI? Moim zdaniem nie. Projekt tworzy unikalny produkt lub usługę. Trudno oczekiwać, że unikalny produkt projektu będzie miał detaliczną dokumentację na wejściu. Jedną w cech zarządzania projektu według PMI jest przecież stopniowy rozwój produktu (progressive elaboration).
W trakcie warsztatów Piotr poprowadził dwa ćwiczenia z szacowania w oparciu o technikę znaną jako Planning Poker (http://en.wikipedia.org/wiki/Planning_poker). Uczestnicy warsztatów podzieleni na zespoły szacowali złożoność projektu budowy aplikacji złożonej z 20 scenariuszy użycia (user story). W zespole pracowało było 3-4 „programistów” i „właściciel produktu”. Pierwsze ćwiczenie wykorzystywało „klasyczne” karty Planning Poker. Drugie polegało na uporządkowani scenariuszy użycia od najłatwiejszego do najtrudniejszego (do budowy). Scenariusze porządkowano przyklejając odpowiadające im karteczki post-it na blacie biurka. To ćwiczenie można było wykonać przyklejając karteczki do ściany, ale wtedy trzeba by wstać od pokerowego stolika.
Podstawą obydwu technik jest teza, że człowiek dobrze radzi sobie z wyznaczaniem relacji większy – mniejszy, trudniejszy – łatwiejszy, lżejszy – cięższy jeżeli porównuje ze sobą obiekty. Znacznie gorzej wychodzi szacowanie wielkości danego obiektu względem skali. Każdy wie, że stół jest cięższy niż krzesło, ale ciężar stołu i ciężar krzesła podać trudno. Dlatego też łatwiej szacować zaczynając od uporządkowania obiektów przypisując im umowne jednostki wartości. Mając uporządkowane obiekty wyznaczamy wartość kliku z nich i na tej postawie kalibrujemy skalę naszego oszacowania. W przypadku aplikacji można to zrobić kodując wybrane scenariusze użycia w prototypie.
Planning Poker wykorzystywany przez Piotra był dla mnie narzędziem nowym. W technice tej używa się kart do głosowania oznaczonych (poza pewnymi wyjątkami ) liczbami z ciągu Fibonacciego. Ciąg Fibonacciego zaczyna się od dwóch jedynek, zaś każdy kolejny element jest sumą dwóch poprzednich. Ponieważ wiele rzeczy w naturze na proporcje będące stosunkiem liczb Fibonacciego, wykorzystanie ich do szacowania jest dobrym pomysłem. Każdy członek zespołu głosuje za pomocą zakrytej karty. Na dany znak karty odkrywane są równocześnie. Jeżeli pokazane wartości bardzo się różnią następuje krótka dyskusja. Osoba prezentująca skrajne oszacowanie uzasadnia dlaczego tak uważa porównując złożoność szacowanego zadania do zadań już oszacowanych. W ten sposób zespół oceniając kolejne zadania buduje równocześnie skalę trudności. Szacowanych działań było 20, czas wykonania oszacowania wynosił 20 minut. Wiadomo, że najtrudniejsze jest pierwsze oszacowanie, dla ułatwienia pracy zespołu Piotr wycenił pierwsze zadanie z listy na 2 punkty w „pokerowej” skali. Ten prosty manewr przyśpiesza pracę zespołu bez szkody dla rezultatu – wszak istotą ćwiczenia jest ustalenie proporcji. Jak pisałem wyżej kalibrację skali wykonujemy osobno. W moim zespole w miarę szacowania kolejnych zadań spadał rozrzut oszacowań a ewentualne rozbieżności uzgadniano coraz szybciej. Naturalne jest pytanie co będzie jeżeli nie uda się uzgodnić oszacowań? Zadanie ma limit czasu wykonania, przekroczenie limitu oznacza zapewne, że zespół nie ma jeszcze wspólnego zrozumienia zakresu – Piotr zgrabnie powiedział, że zespół nie zalicza zadania. Co robić w takiej sytuacji to już temat na inny warsztat.
W zwinnym zarządzaniu projektami najbardziej podoba mi się ścisła współpraca właściciela produktu z zespołem produkt tworzącym. Dzięki tej współpracy sponsor projektu dostaje produkt lepiej spełniający jego potrzeby, nawet jeżeli ostateczny rezultat różni się sporo od początkowych wymagań. Istotą każdej metodyki zarządzania projektami jest pomoc w stworzeniu produktu użytecznego dla zamawiającego projekt, nie zaś konsekwentna realizacja realizacja programu bez względu na użyteczność jego rezultatów. Jeżeli zarządzanie „klasyczne” rozumieć jako konsekwentną realizację ustalonego na początku projektu zakresu, to niewątpliwie zarządzanie zwinne lepiej reprezentuje ideę, która zapoczątkowała budowę metodyk zarządzania projektami takich jak PMBOK czy Prince2. Chodziło bowiem o tworzenie produktów unikalnych i użytecznych, nie o planowe marnowanie zasobów.