niedziela, 16 grudnia 2007

Szacowanie przy użyciu prędkości

Pytanie, które pojawia się dość często jest następujące: jak oszacować kiedy zakończy się projekt (rozumiany w sensie dostępnej kolejnej wersji produktu)? Jak wszystkie inne problemy w sztuce zwinnego zarządzania projektami jest to proste, choć niekoniecznie zgodne z tym czego oczekiwaliby specjaliści od tradycyjnych metod zarządzania projektami.

Podstawą szacowania jest tzw. prędkość pracy zespołu. Prędkość ta określa ile jednostek funkcjonalności zespół jest w stanie ukończyć w trakcie jednej iteracji. To ile "warta" jest każda z funkcjonalności jest określane zgrubnie przez zespół na etapie planowania wersji. Później jest to doprecyzowane przy poszczególnych etapach planowania i/lub retrospekcji. W każdym razie po etapie planowania wersji powinno być dostępne oszacowanie ile jednostek funkcjonalności liczy cała zaplanowana wersja. Później sprawa jest już wybitnie prosta. Otóż po wykonaniu kilku (zwykle trzech) iteracji można z dużą dozą prawdopodobieństwa powiedzieć ile jednostek funkcjonalności produkuje zespół w jednej iteracji - tzw. prędkość zespołu. Następnie należy podzielić ilość jednostek, które zostały do zrealizowania przez prędkość zespołu i otrzymujemy ile iteracji pozostało do końca. Uwaga, iteracji a nie dni czy miesięcy. W zwinnym zarządzaniu projektami iteracja jest najmniejszą niepodzielną jednostką, więc to jej będziemy używać do określania ile jeszcze pozostało do końca. Przeliczenie iteracji na konkretne daty może już być zadaniem dla kogoś spoza zespołu projektowego.

Proste? Tak, pojawia się jednak pewne "ale". Co zrobić, jeżeli z jakichś powodów koniecznie musimy mieć oszacowanie przed pierwszą iteracją i nie możemy czekać do trzeciej iteracji aby określić prędkość zespołu? Cóż - po pierwsze trzeba spróbować wytłumaczyć tej osobie, która "nie może" czekać, żeby jednak zaczekała. Argumentacja jest prosta: czy lepsze są dane rzeczywiste dostępne za trzy iteracje czy dane wysoce niepewne (a.k.a. wróżenie z fusów) dostępne dzisiaj? Jeżeli nie uda się wyperswadować to też można sobie poradzić, choć jest to utrudnione. W takim wypadku należy jedną, dwie lub trzy iteracje po prostu bardzo dokładnie zaplanować. Rozbić na zadania i razem z zespołem dokładnie zaplanować co ile czasu zajmie. Na postawie planowania podaje się przybliżoną prędkość zespołu a potem liczy się już tak jak we wcześniejszym akapicie.

Proste? Wiem, że nie do końca. Ten temat jest akurat takim tematem, który rewelacyjnie tłumaczy się przy użyciu kartki papieru i dwóch, trzech wykresów. Niestety blog takich możliwości interakcji nie daje. W przypadku, gdyby ktoś był bardzo zainteresowany zapraszam do kontaktu.

sobota, 8 grudnia 2007

Metody zwinne w organizacji "stabilnej" cz. 1

Ostatnimi czasy metody zwinne zarządzania projektami stają się coraz bardziej popularne. Metody te najlepiej sprawdzają się w środowiskach bardzo dynamicznych, w projektach, w których występuje duża doza niepewności. Okazuje się jednak, że duża część firm działających w bardziej stabilnych środowiskach również wdraża zarządzanie zwinne. Jakie są powody tego? Na pewno swoista „moda”, ale czy tylko? Ze względu gwałtownie narastający charakter zjawiska napiszę w kilku postach, jakie mogą być powody, dla których organizacje pracujące w środowisku stabilnym wdrażają zwinne zarządzanie projektami.

Uzasadnienia nie będą w żadnej logicznej kolejności, dlatego na pierwszy ogień pójdzie powód bardzo ważny dla większości osób zaangażowanych we wdrożenia zwinnego zarządzania projektami, choć z drugiej strony być może mniej interesujący dla kierownictwa. Otóż skutkiem wprowadzenia zwinnych metod zarządzania projektami, jest to, że zespołom realizującym projekty pracuje się... przyjemniej.

Przyjemność ta wynika z kilku czynników. O jednym pisałem już kiedyś, przy okazji omawiania tematyki zmian w projekcie – w projektach zarządzanych metodami zwinnymi zespół pracuje nad zestawem funkcjonalności, które nie mają prawa się zmienić (w danej iteracji). To powoduje duży spokój psychiczny zespołu, jako że jasno określone są reguły, na podstawie których dokonywane są zmiany i nikt nie zaskakuje członków zespołu. Wbrew pozorom stabilność (choćby w ramach jednej iteracji) jest jednym z podstawowych wymogów zachowania przyjemności z wykonywania pracy.

Kolejnym bardzo dobrze wpływającym na pracę czynnikiem jest fakt, że ze swojej natury zespoły pracujące zgodnie z metodami zwinnymi są zespołami relatywnie małymi położonymi w jednej fizycznej lokacji. Bardzo częsta komunikacja między członkami zespołu powoduje dobrą atmosferę pracy choćby dlatego, że wszelkie niezrozumienia są błyskawicznie usuwane a problemy są komunikowane przynajmniej raz dziennie podczas spotkań. Poza tym w takim zespole ze względu na charakter spotkań (zarówno codziennych jak i podsumowujących iterację) każda z osób czuje się dowartościowana, bo jej zdanie jest brane pod uwagę.

Uwaga. Powyższe jest prawdą tylko o ile osoby zajmujące się koordynacją zespołów posiadają odpowiednie umiejętności komunikacyjne!!!

Praca w projektach zwinnych jest przyjemna również dlatego, że każdy z członków zespołu ma poczucie odpowiedzialności i szybką nagrodę w postaci osiągnięcia sukcesu – działający produkt na koniec iteracji. Mała wielkość zespołu w połączeniu z krótkimi iteracjami oraz tym, że na koniec każdej iteracji trzeba dostarczyć produkt wzbogacony o konkretną wartość dodaną dla klienta powoduje, że każdy z członków zespołu jest zaangażowany w dostarczanie tej wartości. Krótki czas realizacji sprawia, że każdy widzie efekty swojej pracy podczas prezentacji dla klienta. Człowiek natomiast skonstruowany jest tak, że lubi jak mu coś wychodzi.

Jak to się ma do zarządzania firmą jako całością? Ma się, gdyż jeżeli pracownikom pracuje się przyjemniej to pomaga im to pracować efektywnie. Poza tym pracownicy, którzy mają przyjemną atmosferę w pracy zwykle rzadziej myślą o zmianie pracodawcy. Jeżeli idzie to w parze z efektywnością (a idzie) to oczywistym jest, że lepiej mieć pracownika zadowolonego niż zdegustowanego.

sobota, 1 grudnia 2007

Iteracja zero

Pojęcie iteracji zero nie jest popularne w świecie zwinnego zarządzania projektami a według mnie jest to jedno z bardziej przydatnych narzędzi, które powinno być częściej wykorzystywane.

Jak wiadomo jedną z podstawowych zasad zwinnego zarządzania projektami jest to, że każda iteracja ma dostarczyć produkt o zwiększonej wartości biznesowej dla klienta, czyli ze zrealizowanymi dodatkowymi funkcjonalnościami. Każda iteracja zakończona jest pokazem dla klienta, podczas którego ma on możliwość przetestowania dostępnej nowej funkcjonalności. Iteracja zero różni się tym, że nie dostarcza żadnej wartości dodanej dla klienta. Dostarcza ona natomiast wartość dodaną dla zespołu realizującego projekt.

Iteracja zero jeżeli jest stosowana musi być pierwszą z iteracji w projekcie. Stosuje się ją, gdy zespół z jakichś względów nie może rozpocząć od razu pracy nad merytoryczną częścią projektu. Jej celem jest przygotowanie wszystkiego co jest niezbędne, aby zacząć projekt. Mogą to być takie rzeczy jak zdobycie nowej wiedzy, przygotowanie środowisk pracy, nabycie materiałów niezbędnych do rozpoczęcia prac, decyzje strategiczne dotyczące architektury przyszłego rozwiązania itp. Ze względu na swój szczególny charakter iteracja ta może mieć długość inną niż pozostałe. Ważne jest, aby iterację zero zaplanować. Należy bardzo dokładnie określić co jest jej celem i jak oceni się, że została ona zakończona. Tu postępuje się podobnie jak w każdej innej iteracji. Podobnie po iteracji przeprowadza się spotkanie kończące na którym przedstawiana jest wartość dodana, którą zespół uzyskał po zakończeniu iteracji. Uwaga, iteracja zero może być jedna i tylko jedna. To znaczy, trzeba ją zaplanować tak dokładnie aby nigdy więcej w ramach projektu zespół nie musiał zatrzymywać się - należy w tej pierwszej iteracji zero zatroszczyć się o wszystko co jest koniecznie do prowadzenia prac.

Podstawowym błędem popełnianym przy używaniu tego narzędzia jest próba użycia go w celu "przemycenia" starych nawyków z podejścia kaskadowego. Syndromem jest tutaj poświęcenie całej iteracji zero na "zaplanowanie" albo "przeanalizowanie" sposobu realizacji wymagań. To nie jest celem iteracji zero. Planowanie i analizowanie wymagań użytkownika odbywa się w ramach normalnego procesu iteracyjnego w zwinnym zarządzaniu projektem. Dla porównania iterację zero powinno się zastosować, jeżeli na przykład nikt z zespołu nie zna przepisów, w ramach których musi pracować nasz produkt. To drugie jest warunkiem koniecznym do startu prac zespołu to pierwsze jest próbą powrotu z metod iteracyjnych do kaskadowych.