Jak uwzględnić szacunkowe lub zmienione zadania?

Aby obsłużyć szacunki na poziomie zadania i raportowanie czasu, używałem (z grubsza) techniki opisanej przez Steve'a McConnella w rozdziale 10 Szacowania oprogramowania. W szczególności, kiedy przychodzi czas na tworzenie oszacowań na poziomie zadania (tuż przed rozpoczęciem kodowania w projekcie), określam zadania na dość szczegółowym poziomie, aby w miarę możliwości nie miałem zadań z jednym punktem 50 % - szacunek zaufania dłuższy niż cztery godziny. W ten sposób proces szacowania zadań pomaga w konstruowaniu oprogramowania, jednocześnie pomagając mi nie zapomnieć o zadaniach podczas szacowania. Wymyślam też zakres godzin możliwych dla każdego zadania, a korzystając z obliczeń statystycznych, które McConnell opisuje wraz z moimi historycznymi danymi dotyczącymi dokładności, mogę generować szacunki przy innych poziomach ufności, gdy jest to pożądane. Wydaje mi się, że ta metoda działa dla mnie całkiem dobrze. Jesteśmy zobowiązani do umieszczenia zadań i ich szacunków w TFS w celu śledzenia, dlatego używam tych szacunków w procentach ufności, z których mam korzystać.

Nie jestem jednak pewien, co zrobić, gdy zapomnę o zadaniu lub w końcu będę musiał wykonać pracę, która nie mieści się w jednym z zadań, które oszacowałem. Oczywiście najlepiej jest unikać takiej sytuacji, ale jak mogę uwzględnić zapomniane / zmienione zadania? Chcę mieć najlepsze dane historyczne, które mogą mi pomóc w przyszłych oszacowaniach, ale w tej chwili po prostu obliczam, czy dokonałem oszacowania 50% pewności i czy dokonałem go wewnątrz oszacowania dystansowego.

W razie potrzeby chętnie wyjaśnię, o co pytam - daj mi znać, co jest niejasne.

Książka Waltzing With Bears: Managing Risk on Software Projects (autorstwa DeMarco i Lister, autorzy Peopleware) ma do tego wspaniałe podejście. Oto moja reinterpretacja:

Dokonaj oceny „wszystko idzie idealnie”. Oczywiście, wszystko rzadko idzie idealnie, więc prawdopodobieństwo wystąpienia takiego zdarzenia jest niskie, powiedzmy 0,1 procent. Innymi słowy, tylko jeden projekt na tysiąc pójdzie idealnie do planu. To jest to, co większość ludzi używa jako „szacunku”, co jest oczywiście szalone.

Zamiast tego powinniśmy myśleć o oszacowaniach jako rozkładach prawdopodobieństwa. Oszacowanie „idealnego świata” jest najbardziej wysuniętym na lewo punktem szacunkowego rozkładu prawdopodobieństwa.

Następnie dokonaj oszacowania „jeśli tak się dzieje w przypadku podobnych projektów”. To oszacowanie pomaga wziąć „widok zewnętrzny” ( http://wiki.lesswrong.com/wiki/Outside_view ), uciekając przed błędem planowania ( http://wiki.lesswrong.com/wiki/Planning_fallacy ).

Następnie oszacuj „Jestem w 90% pewien, że skończymy z X”. Bądź bardzo, bardzo pewny, że masz na myśli 90% pewności. Innymi słowy, spodziewasz się, że zajmie to więcej niż jeden szacunek tylko raz na każde dziesięć projektów, które wykonujesz.

Możemy teraz użyć twojego pierwszego oszacowania jako oszacowania prawdopodobieństwa 0,1%, a drugiego jako oszacowania prawdopodobieństwa 50% (od sezonu do smaku), a trzeciego jako oszacowania 90%, co da ci ładną krzywą.

Załóżmy, że twoje szacunki 0%, 50% i 90% były z 1 maja, 1 czerwca i 1 sierpnia, wtedy twoja krzywa szacunkowa wyglądałaby mniej więcej tak:

     100 |                                  ......
         |                        ..........
% chance |                ........
of being |          ......
  done   |      ....
         |   ...
         |...
       0 +-----------------------------------------
          \           \           \           \
           May 1st     June 1st    July 1st    August 1st

Zwróć uwagę, jak wzrost prawdopodobieństwa spowalnia w czasie. Jeśli ktoś poprosi Cię o oszacowanie na 99,9% w tym scenariuszu, może to być 1 stycznia następnego roku.

Jednym słowem - przypadek.

Nieprzewidziana kwota to kwota, którą dodajesz za „inne rzeczy” - rzeczy, których nie możesz uwzględnić w innych miejscach swojego oszacowania. Czy SMc obejmuje to w Oszacowaniu oprogramowania? Nie pamiętam, a moja kopia jest w pracy (jestem na wakacjach, odpowiadam - jak mi smutno) ...

Tak czy inaczej, ogólnie rzecz biorąc, są trzy rodzaje nieprzewidzianych okoliczności, na które zaleciłbym przyjrzenie się:

1) Nieprzewidziane ryzyko - w tym miejscu identyfikujesz konkretne ryzyko i dodajesz określoną ilość czasu na pokrycie potencjalnego przekroczenia związanego z tym ryzykiem. Pierwszą rzeczą, którą należy wyjaśnić tutaj, jest ryzyko - jest to coś, co może się zdarzyć, co negatywnie wpłynie na projekt, który jest poza twoją kontrolą .

Ta ostatnia część jest krytyczna - nie chodzi tylko o „trochę dłużej, niż myślałem”, ale o „moduł planowania innej firmy, o którym mówiono nam, że musimy go używać, ponieważ jest to standard firmy, który może nie sprostać zadaniu”. Sposób, w jaki obliczasz, ile dodać ryzyko, to procent szansy, że ryzyko może się zdarzyć, wyrażony w postaci dziesiętnej (czyli 50% = 0,5), razy wpływ tego ryzyka (w tym przykładzie powiedz, że musisz ręcznie napisać CRON zadania zamiast korzystać z harmonogramu, a to zajmie 10 dni, ta liczba to 10 dni).

Jeśli więc istnieje 50% szansa, że ​​Twoje ryzyko minie, a obejście go zajmie 10 dni, dodaj 5 dni. Zsumuj wszystkie wartości dla wszystkich zidentyfikowanych ryzyk w projekcie i dodaj je do całości.

2) Cholera zdarza się nieprzewidziane zdarzenia - najlepszy opis, jaki kiedykolwiek słyszałem, nawet jeśli nie jest elegancki. To projekt IT, cholera się zdarza. Nigdy nie pójdzie tak, jak myślisz, że rzeczy będą trwały dłużej, zostaną pominięte itd. Zasadniczo SH będzie wynosić od 10% (absolutne minimum) do 25% (choć może być wyższy), przy czym 15% będzie mniej więcej typowe, dokładny poziom zależy od poziomu niepewności i ogólnego ryzyka (ruchome słupki bramkowe, niepewne wymagania i tak dalej) ).

Jeśli twój PM nie akceptuje Awaryjne SH (i jest to możliwe, może nie mieć doświadczenia w projektach IT lub być ślepym optymistą), to po prostu dodaj to do wszystkich indywidualnych kwot. Jeśli będzie wiedział, co robi, będzie miał własny dziennik ryzyka i będzie cię kochał za myślenie o tym. Z pewnością, jeśli ma jakiekolwiek kwalifikacje PM (takie jak PRINCE2), będzie o tym wiedział.

3) Nieprzewidziane zmiany - w tym miejscu masz całkowitą pewność, że klient zgłosi zmiany, ale nie chcesz, aby było to przedmiotem sporu. Dodaj X dni lub X% i trafi do puli na zmiany, które podnosi klient. Istnieją dwa sposoby radzenia sobie z tym: albo im o tym powiesz i ich należy wydać, albo im nie powiesz.

Pierwszy sposób jest najlepszy, ale wymaga dość wykształconego i uczciwego klienta - rzeczy są klasyfikowane jako zmiany i może wydawać swoją pulę według własnego uznania (na podstawie oszacowania rzeczy na ich podstawie).

Drugi sposób, w jaki wspominasz, że to zmiana, ale nie staraj się go dodatkowo obciążać. Musisz zanotować wszystkie rzeczy, na które wydajesz, więc jeśli dojdzie do punktu, w którym się skończy, musisz wrócić do klienta i poprosić o więcej czasu lub pieniędzy, a oni powiedzą „poczekaj, ja” m płacę bla bla bla "możesz wskazać wszystkie rzeczy, które już zmienili, za które nie naliczyłeś, jako znak, że nie jesteś całkowicie nierozsądny. Nie zawsze działa, ale prawie zawsze wzmacnia twoją rękę w dyskusjach.

Żadna z tych trzech nie obejmuje rzeczy, o których zapomniałeś, ale myślę, że między nimi wypełnisz wiele luk, które masz.

Gdy zostaniesz poproszony o wycenę zadania, podaj szacunek końcowy zespołowi i oszacuj wynik końcowy dla siebie, robiąc to, że zawsze będziesz miał czas po wykonaniu zadania na pracę nad czymś, o czym mógłbyś zapomnieć na pierwszym miejscu.

Czy obawiasz się, że dodając dodatkowe zadania, zmienisz swoją historyczną dokładność? A może uważasz, że nieuwzględnienie dodatkowych zadań zniekształci dokładność?

Myślę, że dla najlepszego projektu zadania powinny zostać wprowadzone do systemu śledzenia. Jestem pewien, że kierownik projektu będzie w stanie przedstawić odpowiednie wyjaśnienie dla kierownictwa dotyczące rozbieżności ...