Jak uwzględnić szacunkowe lub zmienione zadania?

10

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.

Andrzej
źródło
1
Pomnóż przez 3 ( programmers.stackexchange.com/questions/41004/… )
blueberryfields
Myślę, że będę musiał podać przykład, w jaki sposób wykonuję te obliczenia, a także problem, który próbuję rozwiązać. W tej chwili nie mam czasu, ale dojdę do niego jak najszybciej.
Andrew
W scrumie nie podajesz prognoz czasu; dajesz punkty historii, które dają pomysł innym. Nie wymiarujesz również oddolnie. Nie musisz - prędkość jest niejasna.
Job
@ Job Obecnie nie jesteśmy sklepem scrumowym. Ponadto, w przeciwieństwie do tego, co sugerował inny odpowiadający, odkryłem do tej pory, że szacunki oddolne poprawiły moją dokładność oszacowania, w dużej mierze poprzez znaczne zmniejszenie liczby zapomnianych zadań podczas szacowania na poziomie zadania.
Andrew
@blueberryfields - pomnożenie tylko przez 50% powinno wystarczyć, przynajmniej w firmie o wielu hierarchicznych poziomach, z których każdy dodaje własny współczynnik przeszacowania.
mouviciel

Odpowiedzi:

6

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.

Benji York
źródło
Dziękuję za odpowiedź. Metoda, której już używam, pozwala mi jednak robić to, co wydajesz się proponować, ale bierze również pod uwagę (pośrednio, poprzez zastosowanie historycznej wartości procentowej dokładności) mój poprzedni sukces z moimi szacunkami w celu wygenerowania procentu - pożądane są pewne szacunki. Pytam jednak o to, jak włączyć pominięte zadania do tej historycznej dokładności, kiedy dokładność jest w zasadzie obliczana na podstawie tego, czy ukończyłem zadanie w zakresie, który wykorzystałem do pierwotnego oszacowania.
Andrew
@Andrew, jeśli dobrze cię rozumiem, „pominięte zadania” wynikają z mniej niż 100% prawdopodobieństwa wykonania w danym momencie. Jeśli wykonałeś wiele projektów, takich jak bieżący, twoja krzywa szybko spadnie od 0% do (powiedzmy) 90%. Wynika to z faktu, że masz dużą pewność, że niewiele zadań zostało pominiętych. Jeśli masz niskie zaufanie, nachylenie będzie znacznie bardziej stopniowe. Dzieje się tak z dowolnego powodu, nie tylko zapomnianych zadań, ale także innych czynników ryzyka.
Benji York
Tak, pominięte zadania są uwzględniane w zbiorczych zakresach poziomów zadań, które liczą się do poziomów ufności, które podaję. Obliczam te poziomy przy użyciu metody, którą McConnell proponuje w rozdziale 10 Oszacowania oprogramowania, jak powiedziałem wcześniej. Zastanawiam się przede wszystkim, w jaki sposób uwzględniam brakujące lub zmienione zadania w raportowaniu godzin TFS, a także jak uwzględnić te godziny przy obliczaniu mojej historycznej dokładności.
Andrew
5

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.

Jon Hopkins
źródło
Dziękuję za Twoją odpowiedź. Podnosisz ciekawe punkty. Te trzy elementy już uwzględniam na różne sposoby w swoich szacunkach. Odkryłem, że twój pierwszy typ może być zazwyczaj artykułowany i powiązany z jednym lub większą liczbą zadań. Drugi typ został właśnie włączony do moich oszacowań zakresu zadań na poziomie zadania: nie wolno mi mieć dla niego dodatkowego przedmiotu (debatowaliśmy i na razie taka jest polityka naszego zespołu). Po trzecie, klienci wewnętrzni akceptują, że zmiany zwiększą nasze oszacowanie, a klienci zewnętrzni mają to na piśmie, więc nie powinniśmy brać pod uwagę zmian.
Andrew
Jeśli chodzi o to, czy McConnell obejmuje nieprzewidziane wydatki, moja kopia również działa, więc musiałbym to sprawdzić. Myślę, że pytam o to, jak uwzględnić brakujące / zmienione zadania podczas obliczania danych historycznych w celu poinformowania o kolejnym oszacowaniu, a także o tym, gdzie przypisać godziny w TFS, ponieważ zadanie awaryjne zwykle nie jest dozwolone w naszej grupie.
Andrew
0

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.

Rachel
źródło
Dziękuję za odpowiedź. Zakresy, które wymyślam, dają, ogólnie rzecz biorąc, wystarczająco dużo czasu, aby dodać zapomniane zadania, nie pomijając oszacowania dla całego projektu. Moje pytanie mówi więcej o korzystaniu z tych informacji w procedurze obliczeniowej, której używam z książki McConnella.
Andrew
0

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 ...

TGnat
źródło
Mogę tylko poczekać do jutra i powiedzieć to osobiście. :) Jestem bardziej zaniepokojony niedokładnością historii, jeśli dodatkowe zadania nie zostaną w jakiś sposób uwzględnione. Oczywiście pominięcie zadania podczas szacowania zadania jest „brakiem” co do dokładności - ale która dokładność? Tym, którego faktycznie używam w sensie ilościowym, jest to, czy moje rzeczywiste wykonanie zadania dla każdego zadania mieściło się w przewidywanym zakresie. Drugim, bardziej jakościowym miernikiem jest to, jak często spełniam moje 50-procentowe przekonania dotyczące jednego punktu. Zbyt daleko powyżej lub poniżej 50% i powinienem dostosować „ocenę ekspercką” do przyszłych 50% szacunków.
Andrew