Pewnie słyszałeś już, że szacowanie to niezobowiązanie. Czasami zdarza się, że w zespołach, które stosują techniki szacowania, pojawia się jakaś forma rozliczania z trafności szacowania. Nie jest to dobre z kilku powodów:
a) po pierwsze szacowanie to przybliżenie (z pewnym prawdopodobieństwem), to nie jednoznaczny wynik
b) po drugie w momencie rozliczania pojawiają gry projektowe
c) jest przynajmniej kilka czynników, które wpływają na to, że szacowanie rozmija się z rzeczywistym czasem poświęconym na dane zadanie:
• niewielkie doświadczenie w technologii
• niewielkie doświadczenie dziedzinowe
• wiele równoległych zadań
• tendencja optymistyczna/pesymistyczna
• niewielkie/brak umiejętności szacowania
• niedoprecyzowane wymagania
• zmiany ze strony biznesu
• szacuje inna osoba niż wykonawca
• używane heurystyki rozwiązywania problemów
• sposób organizacji pracy nad zadaniami
Część z nich to czynniki zewnętrzne lub na takie na które nie mamy większego wpływu w krótkim okresie czasu (te żółte, wybrane całkowicie arbitralnie) jako programiści. Najczęściej są to elementy, które powinny być sterowane poprzez odpowiedni proces/organizację pracy zespołu. W 95% przypadków - nie są, a już w szczególności nieprecyzyjne wymagania i zmiany w wymaganiach. Pozostałe elementy to głównie umiejętności, których można się nauczyć, choć to również wymaga czasu i wkładu sił.
Reasumując: szacowanie to nie zobowiązanie, ze względu na wielość czynników, których wpływ można minimalizować, ale nie uda nam się ich całkowicie pozbyć.
0 komentarze:
Prześlij komentarz