Jak nauczyć się dokonywać lepszych szacunków? [Zamknięte]

Obciągam szacunki. Kiedy ktoś pyta mnie, jak długo to zajmie, nie mam nawet odwagi zgadywać, ponieważ zupełnie nie będę miał pojęcia. Zwykle jestem zbyt optymistyczny i prawdopodobnie powinienem pomnożyć moje domysły przez jakiś duży współczynnik X ...

Jak mogę nauczyć się dokonywać lepszych szacunków? Nie uczy się tego na moim uniwersytecie i chociaż mamy terminy wszystkich porodów, nigdy nie myślę o tym, ile czasu to zajmie. Które powinienem. Na litość boską (szczególnie moją).

Nadal nie jestem w tym świetny, ale odkryłem, że śledzenie tego, jak długo szacujesz dla zadań i jak długo faktycznie trwasz, może być bardzo pomocne. W ten sposób możesz dobrze zorientować się, jak daleko jesteś. Pomocne może być oprogramowanie do zarządzania problemami ze śledzeniem czasu (w moim przypadku Jira) lub arkusz kalkulacyjny.

Myślę, że bardziej niż cokolwiek innego to doświadczenie.

Prawo Murphy'ego Zarządzania czas: Aby dowiedzieć się, jak długo coś będzie podjąć, dowiedzieć się, jak długo należy podjąć i podwoić.

Następnie przejdź do następnej wyższej jednostki czasu. W ten sposób przeznaczamy dwa tygodnie na jednodniowy projekt.

Możesz się uczyć, wykonując je wspólnie .

Używam Planning Poker . Jest to technika szacowania oparta na konsensusie .

Twoja ocena musi być śledzona i porównywana z tym, co skutecznie zrobiłeś. Otrzymasz prędkość .

Za każdym razem, gdy coś oszacujesz, pomnóż ją przez ostatnią prędkość, aby uzyskać dokładne oszacowanie .

Ocena oprogramowania autorstwa Steve'a McConnella (MS Press) to dobra lektura.

Najważniejsze z oszacowaniem oprogramowania podsumowano w następujący sposób

Bez informacji historycznych twoje szacunki są bezużyteczne.

To jeden z powodów, dla których myślę, dlaczego projekty iteracyjne odnoszą znacznie większy sukces niż projekty z dużymi fazami wodospadów. Nie próbują opracowywać planu na rok z niewielką ilością informacji innych niż voodoo czarnej skrzynki o tym, co według nich powinno być. Podczas każdej iteracji przeprowadzają ponowną ocenę / ponowną analizę i mają kilka ostatnich iteracji, na których opierają swoje oszacowania.

Kilka innych kwestii, o których należy pamiętać:

1. Będzie tylko wolniej . Zastosowanie zasady 80/20 oznacza, że ​​cięższa praca przyjdzie później, chyba że zarządzanie projektem będzie bardzo zdyscyplinowane.
2. Oszacowanie! = Planowanie. Szacowanie to proces określania wysiłku wymaganego do wykonania zadania. Planowanie to proces dopasowywania go do harmonogramu.
3. 60% wydajności to wszystko, na co możesz liczyć. 70% to utopia. Jeśli szacujesz za kilka dni, włącz to. Jeśli szacujesz za kilka godzin, nie zapomnij zastosować go później.
4. Pamiętaj o długim ogonie . Szacunki przybliżają, jak długo potrwa „prawdopodobnie”, skorygowane o pewien poziom ryzyka i niewiadomych. W grę wchodzi długi ogon, ponieważ faktyczna ilość wymaganej pracy nigdy nie będzie mniejsza niż 0. OTOH, maksymalny czas, jaki zajmie, jest ograniczony tylko tym, ile czasu chcesz poświęcić na to, zanim się poddasz. Jak powiedział mój były szef „wszystkie szacunki wynoszą +/- x% i nigdy nie są minus”.

Dziwi mnie, że nikt nie wspominał o technice estymacji PERT opisanej w The Clean Coder Roberta Martina . W tej metodzie szacujesz, jak długo potrwa to w 3 scenariuszach: optymistycznym ( O), nominalnym ( N) i pesymistycznym ( P). Następnie oczekiwany czas trwania = (O+4N+P)/6i otrzymasz standardowe odchylenie (P-O)/6.

Wydaje się, że działa to całkiem dobrze i korzystałem z niego kilka razy, kiedy kierownictwo naprawdę dba o to, ile czasu prawdopodobnie zajmie.

Jak skomentowali inni, dokonałem również szacunków, analizując dane historyczne („Ile czasu zajęło zrobienie tego podobnego zadania?”).

Ale moją ulubioną metodą jest w ogóle nie dokonywanie szacunków czasowych, a jedynie szacowanie punktowe i uzyskiwanie prędkości nad iteracjami. Jeśli zespół jest dość konsekwentny w doborze i wykonywaniu pracy (historie użytkowników), oszczędzasz mnóstwo czasu, nawet nie pytając, ile czasu zajmie każda rzecz.

Szacunki godzinowe są piekielnie trudne do poprawienia i wymagają dużo pracy, aby rozbić rzeczy na wystarczająco małe kawałki, aby skutecznie zmierzyć. I nawet wtedy rzadko są poprawne, ponieważ istnieje zbyt wiele zmiennych, a my zapominamy brać pod uwagę takie rzeczy, jak choroba, wakacje, a nawet rozproszenie.

Jeśli muszę wykonać szacunkowe godziny, staram się je wykonywać tylko dla drobnych zadań w ramach iteracji. Wszystko mierzę w szacunkach półdniowych (4, 8, 12 godzin), chyba że wiem, że może być mniej. Ale rzadko oceniam coś w czasie krótszym niż 1 godzina.

Po pierwsze i najważniejsze, musisz zdefiniować proces i trzymać się go. Uwzględnij zmianę planu na końcu każdej fazy procesu. Możesz także zmienić proces, ale w uporządkowany sposób.

Po drugie, zrób jakiś projekt. Projektowanie jest pierwszym krokiem do planowania, nie budujesz domu bez rysunków.

Po trzecie, czas śledzenia (wysiłek). Powinieneś przynajmniej rozróżnić:

• Analiza
• Projekt
• Kod
• Testy jednostkowe (w tym usuwanie usterek)
• Testy integracyjne (w tym usuwanie usterek)

• Testy akceptacyjne z użytkownikiem (obejmują naprawę wad)

  Byłoby wspaniale, gdybyś zmierzył wysiłek naprawiania defektów dla każdego rodzaju testowania, ale dodaje to złożoności, więc możesz to zrobić później.

Po czwarte, zidentyfikuj kluczowe elementy podstawowe do oszacowania. Na przykład:

• Liczba procesów do zautomatyzowania (Analiza)
• Liczba encji modelu domeny (Projekt)
• Liczba formularzy i raportów (kod)

Po piąte, koreluj elementy podstawowe i wysiłek. Na przykład:

• Nakład analizy = X roboczogodzin / proces do zautomatyzowania
• Nakład projektowy = Y osobogodzin / jednostka modelu domeny
• Nakład kodu = Z roboczogodzin / formularz (lub raport); liczba formularzy = jednostki modelu domeny A *
• Wysiłek związany z testowaniem jednostkowym = M% * Nakład kodu
• Wysiłek związany z testowaniem integracji = N% * Wysiłek związany z kodem
• Nakład testowy przy akceptacji = P% * Nakład kodu

Po szóste, śledź wyniki i odchylenia od szacunków dla każdego projektu. Możesz więc dostroić współczynniki korelacji.

Po siódme, powtórz i popraw. Zdobędziesz wiele wglądu dopiero pod koniec pierwszego projektu, do trzeciego będziesz mógł swobodnie planować i szacować.

Spójrz na http://en.wikipedia.org/wiki/Personal_Software_Process , to naprawdę działa.

Ilekroć napotkasz problem z oszacowaniem, spróbuj podzielić je na mniejsze części. Następnie sprawdź, czy zrobiłeś już rzeczy podobne do elementów. Jeśli tak, powinieneś już mieć dobry pomysł na to, jak długo zajmuje każdy kawałek. Jeśli tego nie zrobisz, powinieneś zacząć aktywnie śledzić czas potrzebny na różnego rodzaju zadania. Pomoże to w przyszłych szacunkach.

Całkowity potrzebny czas będzie większy niż suma poszczególnych elementów, ponieważ potrzeba trochę czasu na integrację i testowanie.

Jeśli nie zrobiłeś czegoś podobnego, prawdopodobnie możesz polegać na doświadczeniach innych ludzi i uzyskać od nich szacunek. Nie bierz tego jednak za dobrą monetę. Nic nie uczy tak jak doświadczenia.

To trochę jak strzelanie do celu. Poprzednie strzały przy szacowaniu powinny powiedzieć ci, jak daleko od celu jesteś, abyś mógł to poprawić.

Najłatwiej jest mi wykonać proces podziału na minimalne zadania, jak wspomniano powyżej, opracować każde z nich, a następnie podwoić te szacunki. Następnie dodaję je razem i dodaję pięćdziesiąt procent. To daje mi przybliżony czas projektu w idealnych warunkach. Jeśli praca będzie praktycznie przebiegać równolegle z innymi, będzie potrzebować dłużej. Jeśli będziesz musiał czekać na innych ludzi, spodziewaj się, że zajmie to dwa razy więcej czasu, niż ci się wydaje. Oczekiwanie na treść, informacje zwrotne lub inne informacje często trwa znacznie dłużej, niż się wydaje.

W miejscu, w którym pracuję, opracowujemy szacunek najlepszego przypadku / oczekiwanego przypadku / najgorszego przypadku dla każdego etapu procesu, co jest użyteczne jako przewodnik, a także do oceny, jak twoje szacunki się sprawdziły.

Technika ta nie jest nigdy tak ważna, z wyjątkiem tego, że musisz być w stanie zwalczyć pokusę programisty, aby nie doceniać zadań, ale ważne jest zachowanie ostrożności, kiedy możesz coś dostarczyć. Jeśli zbudowanie czegoś zajmie Ci siedem tygodni, a obiecałeś osiem tygodni, możesz przyjść trochę wcześniej i dobrze wyglądać lub przeprowadzić dodatkowe testy i mieć pewność niezawodności. Jeśli obiecałeś sześć tygodni, możesz źle wyglądać, nawet jeśli to absolutnie nie twoja wina. W razie wątpliwości zachowaj ostrożnie.

Możesz spróbować zbudować historię szacunkową i rzeczywistą dla różnych zadań, aby zbudować wystarczającą ilość rekordu, aby następnie dowiedzieć się, jaki mnożnik ma się dla określonych rzeczy, które powtarzają się na twojej liście. To prawda, że ​​jest to ćwiczenie prób i błędów, ale wydaje mi się, że działa dobrze. Jest jeszcze coś do powiedzenia na temat wielu prób, zanim prawdopodobnie pojawi się ten wzór. Jest to prawdopodobnie podobne do wielu innych odpowiedzi, które mówiłyby, że można sprowadzić się do „Po prostu zrób to!” ponieważ tak naprawdę większość z nas rozwinęła tę umiejętność. Czy trudno jest zobaczyć, jak błędny może być szacunek? Tak, ale jeśli szacunki się poprawią, to w końcu wszyscy mogą być szczęśliwi.

Jeśli potrafisz rozłożyć projekt na mniejsze zadania i dokonać szacunków dla nich, będziesz bardziej dokładny. Każde zadanie dłuższe niż kilka dni powinno zostać dalej podzielone. Jeśli nie możesz go dalej rozbić, prawdopodobnie masz lukę w wymaganiach. Jeśli musisz dokonać wyceny z tyłu serwetki, aby spełnić wymagania dotyczące jednej linii, nic tak naprawdę nie może ci pomóc. Niestety wiele sklepów działa w ten sposób przez większość czasu.

Zamiast pisać na ten temat książkę, dam ci tylko małą radę, jak korzystać z metody szacowania „rozbić”:

• Podziel swoje zadanie na mniejsze zadania składowe. Oszacuj każde zadanie jak najlepiej.

• Dodaj zadanie do planowania i projektowania (które obejmuje to, co teraz robisz). Oszacuj.

• Jeśli jeszcze go nie masz, dodaj zadanie „zebranie zadań razem”. To zadanie może początkowo nie wydawać się przydatne. Jednakże, gdy używasz tej metody szacowania „rozbicia”, zawsze jest czasochłonne rzeczy, które polegają na „rozdzielaniu zadań” i „łączeniu zadań”. Ten może być trudny do oszacowania. Postaraj się.

• Dodaj zadanie do testowania i dokumentacji. Twoje zadanie może nie wymagać wielu testów i dokumentacji, ale powinieneś przynajmniej trochę się nad tym zastanowić.

• Dodaj prognozy zadań, aby uzyskać ogólne prognozy.

• Śmiało i pomnóż tę całkowitą wartość szacunkową przez dwa ††. To da ci czas na wypełnienie:

  1. Zakończ rzeczy, które przeoczyłeś na oryginalnej liście zadań
  2. Dokończ rzeczy, o których nie mogłeś wiedzieć, dopóki nie zaczniesz
  3. Wykorzystuj opinie innych osób i wprowadzaj zmiany
  4. Przerywaj się innymi rzeczami, takimi jak spotkania
  5. Zakończ przed oszacowaniem częściej niż za nim

I na koniec, nie bój się sporządzić dla siebie szacunków, które prawdopodobnie są całkowicie błędne. Czasami po prostu naszkicowanie wszystkiego, bez względu na to, jak potencjalnie może być ono niedokładne, może pomóc w rozpoczęciu drogi do lepszego zrozumienia tego, co się z tym wiąże.

†† W miarę zdobywania doświadczenia, ten „czynnik krówki” może być dostosowywany do Twojego osobistego stylu i środowiska pracy.

Formuła, która działa, gdy pracuję dla siebie:

1. dokonać podziału todo na ziarnistość 1–4 godzin. Uważam, że zazwyczaj jestem z nimi dokładny

2. „czynnik niewiadomych”: Pomnóż przez współczynnik 2 podniesiony do liczby niewiadomych. To znaczy, jeśli chcesz opracować aplikację couchdb, ale teraz wiesz coś o javascript i http .. dodaj 2 ^ 2 jako czynnik mnogi.

3. współczynnik przełączania kontekstu: wielokrotność przez 1,5, jeśli będziesz pracować w idealnym środowisku (w domu w kąciku nauki itp.), lub 2,5, jeśli będziesz pracować w niedoskonałym otoczeniu (biuro / zatłoczone miejsce itp.)

Uważam, że jest to w granicach +/- 20% faktycznego czasu zajętego !!

Naucz się własnego nastawienia. Jeśli twoje ostatnie oszacowanie było zbyt niskie dwa razy, następnym razem podwoj swoje początkowe oszacowanie. (Oczywiście prawo Hofstadtera utrudnia robienie tego dobrze ...)

Zawsze dobrze jest pamiętać, ile pracy było potrzebne po początkowym wydaniu poprzedniej pracy i dodać ją do następnej oceny. Np. Twoje ostatnie zadanie zajęło 2 miesiące, ale po uruchomieniu usługi, poprawki, poprawki i dodatkowe zmiany kosztują kolejny miesiąc, więc następnym razem oszacuj 3 miesiące na podobne zadanie.

Dla osób otwierających przeczytaj „Software Engineering Economics” autorstwa Barry Boehm i „Controlling Software Projects” autorstwa Tom DeMarco. Po przeczytaniu i przeanalizowaniu tych dwóch artykułów, przeczytaj „Szacunek kosztów oprogramowania z COCOMO 2” autorstwa Barry Boehm.

Jeśli chodzi o to, co powiem dalej, pomoże ci DUŻO wziąć klasę prawdopodobieństwa i statystyki, nawet podstawową książkę kucharską.

Żadne oszacowanie nie jest idealne. Istnieje pewne prawdopodobieństwo, że przyjdzie wcześnie, i pewne prawdopodobieństwo, że przyjdzie późno. Oryginalny szczegółowy model COCOMO firmy Boehm dał przewidywania, które okazały się zawierać w 30% rzeczywistego wyniku, lepiej niż w 60% przypadków. To było o wiele lepsze niż to, co było powszechne, kiedy napisał i opublikował książkę.

Kiedy zgadniesz, jak się domyślić (i to wszystko jest szacunkowe), bierzesz pod uwagę te prawdopodobieństwa. Jeśli oszacujesz, zwiększysz prawdopodobieństwo, że przyjdziesz późno. Jeśli zwiększysz szacunek, zwiększysz prawdopodobieństwo, że przyjdziesz wcześniej lub skończysz na czas. To, jak bardzo je wciągasz lub wypuszczasz, kontroluje zmiany prawdopodobieństwa i musi koniecznie zależeć od kar za spóźnienie lub spóźnienie. (Wstaw tutaj horrory - a było ich wiele przez lata!)

DeMarco zajmuje się tym do pewnego stopnia. Wskazuje również, że istnieje „region niemożliwości”: niektóre harmonogramy są po prostu zbyt napięte, aby można je było wykonać, bez względu na rodzaj heroiki.