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.

Brak komentarzy: