Zanim przejdę za daleko, powiem, że Software Estimation: Demystifying the Black Art jest doskonałym źródłem informacji dla osób, które patrzą i myślą o szacunkach. Oba poniższe obrazy pochodzą z tej książki, podobnie jak rdzeń przedstawionych poniżej pomysłów.
Jak już zauważyłeś, szacunki są ważną częścią możliwości dokładnego przewidywania i planowania pracy. Brak oszacowań powoduje, że firma nie wie, jak długo to zajmie. Często zdarza się, że biznes ma całkowicie błędny pomysł na to, jak długo to zajmie - to, co uważają za łatwe, zajmuje sześć do ośmiu tygodni, a to, co uważa się za trudne, to piątek po południu.
Pierwszą rzeczą jest oszacowanie. Szacunek sam w sobie nie jest pojedynczą liczbą - to zobowiązanie. „Ile czasu zajmie ABC” -> „Około 5 dni” oznacza, że jest to około 5 dni. Jednak dobrym oszacowaniem jest zakres, w którym masz 90% pewności, że będziesz go mieć w tym zakresie. Jeśli chcesz powiedzieć „Jestem w 90% pewien, że zajmie to między 1 a 5 dni”, powiedz to. Nie pracuj od „Myślę, że zajmie to od 1 do 10 dni, więc 5 dni to prawdopodobnie średnio” - to nie jest szacunek i będziesz mylił się w 50% przypadków.
Cóż, 50% lub więcej czasu, programiści są znani z niedoszacowania czasów zadań.
Rozważ stożek niepewności:
Zdjęcie z http://www.construx.com - pełny artykuł na http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertainty/
Uświadom sobie, że pierwsze oszacowanie w tym zakresie to 16x. Jest to podobne do powiedzenia „Myślę, że zajmie to od popołudnia do dwóch tygodni” - ale jeszcze nie wiesz. W miarę postępów w projekcie zakres zawęża się do 4x. Ten sposób nie oznacza, że to zajmie jeden tydzień, oznacza to, że można zamiast mówić „po patrząc na ten kawałek, to zajmie od trzech tygodni” - tak, szacunek poszły w górę, ale również zakres oszacowania poszedł na dół.
Przy każdym podanym oszacowaniu musisz mieć 90% pewności, że oszacowanie mieści się w tym zakresie. Możesz się mylić - 10% czasu wypadnie poza ten zakres.
Istnieje wiele sposobów oszacowania wielkości projektów. Porównując go do poprzednich projektów, używając proxy (myślę, że zajęłoby to 1000 wierszy kodu, którego napisanie zajęłoby tak dużo czasu), używając punktów funkcyjnych (do konwersji na LOC ...), otrzymując oszacowania od wielu osób, a następnie udoskonalając iteracyjnie ... trochę pracy dla niektórych projektów, trochę pracy dla innych projektów.
Bardzo ważny rozdział w tej książce, że wspomniałem na początku jest nr 23, który zajmuje się polityką estymacji i radzenia sobie z menedżerów i kadry kierowniczej.
Kluczem do oszacowania jest iteracyjny proces udoskonalania go po odrobinie pracy.
Podanie zbyt dokładnego oszacowania zbyt wcześnie może być bardzo podatne na błędy. Jeśli nie jesteś tego pewien, podaj ogólną ocenę, a po pewnym czasie wróć z inną oceną, aby uzyskać więcej introspekcji problemu i być może naszkicować, jak to zrobisz, sprawdzając, ile kodu napisałeś ostatni podobny problem i inne czynniki, które będą miały wpływ na oszacowanie.
Szacunki wymagają przemyślenia - nie podawaj szacunków mankietu. Często wiążą się z nimi olbrzymie błędy w porównaniu z tym, czego potrzeba, gdy się nad tym trochę zastanowić.
Od Jak odpowiedzieć, gdy zostaniesz poproszony o wycenę?
Co powiedzieć, gdy zostaniesz poproszony o wycenę
Mówisz „Wrócę do ciebie”.
Prawie zawsze uzyskujesz lepsze wyniki, jeśli spowolnisz proces i poświęcisz trochę czasu na wykonanie kroków opisanych w tym rozdziale. Szacunki podane w ekspresie do kawy wrócą (podobnie jak kawa), aby cię prześladować.
Z rozdziału 4 Szacowania oprogramowania:
Zauważ, że pod tym względem szacunki po krótkim przeglądzie są systematycznie mniej dzikie i podatne na błędy niż szacunki pozorne. Nie rób szacunków mankietu. Usiądź i pomyśl o zadaniu i oszacuj je po krótkiej przemyśleniu.