Na przykład, jeśli podzielę projekt na n dyskretnych produktów pracy (powiedzmy klasy, funkcje lub komponenty), czy jest taki czas t, że n * t jest odpowiednią ilością czasu na oszacowanie?
estimation
Michael Behan
źródło
źródło
Odpowiedzi:
Jeśli masz wystarczająco dużo informacji, aby rozbić je na ten poziom, nie powinieneś spędzać więcej niż minutę na każdym z nich. I tak nie będziesz miał racji, ale będziesz tak samo poprawny po minucie, jak po godzinie.
Jeśli natomiast mówisz o historiach użytkowników , proponuję zaprosić interesariuszy do pokoju i poświęcić pięć minut na zadawanie pytań przed oszacowaniem.
Niezależnie od tego, nie marnuj dużo czasu na dokonywanie szacunków. Nie są one przydatne ani wystarczająco dokładne, aby były warte wysiłku.
źródło
Z mojego doświadczenia wynika, że jednym z podstawowych „tak, które naprawdę działa” elementów zwinnego podejścia jest wytyczna „Zadania powinny trwać krócej niż jeden dzień”. Jeśli oceniasz rzeczy, które trwają dłużej niż jeden dzień, będziesz bardzo daleko.
Po ich rozbiciu, abyś mógł to zrobić, zrobiłeś wystarczająco dużo; bez względu na to, czym są te rzeczy.
źródło
W zwinnej metodologii scrumowej Planning Poker jest postrzegany jako skuteczny sposób wykorzystania całego zespołu do szybkiego oszacowania wysiłku wymaganego od historii użytkownika podczas sprintu (zakładając, że o tym mówisz). W przeciwnym razie nie poświęciłbym więcej niż kilka minut na oszacowanie pojedynczego zadania, które jest częścią historii użytkownika.
Zdecydowanie polecam stosowanie tej techniki opartej na konsensusie, jeśli próbujesz dokonać oszacowań dla zespołu programistów.
Planowanie pokera oznacza, że możesz uzyskać całkiem dobre prognozy dla każdej historii użytkownika w ciągu jednej sesji (nie więcej niż 1-2 godziny).
Przeczytaj to i spróbuj!
Co do zasady, żadne zadanie w historii użytkownika nie powinno przekraczać 7,5 godziny (jednego dnia pracy). Jeśli tak, musisz podzielić zadanie na mniejsze.
źródło
Myślę, że to zależy od tego, czego potrzebujesz. Jeśli na przykład przydział zasobów twojego projektu zależy od tego (jak to czasami bywało tutaj), lepiej to zrobić ostrożnie. Z drugiej strony, jeśli wykonujesz projekt, który nie ma takiej konieczności, możesz nie wdawać się w zbyt wiele szczegółów. Spędzanie na nim zbyt wiele czasu nie jest dobrym pomysłem, ponieważ dokładne oszacowanie jest bardzo trudne.
Istnieje znana koncepcja o nazwie Stożek Niepewności i Stożek Niepewności na Wikipedii, która mówi, jak często dokładne może być oszacowanie. Warto przeczytać.
źródło
Co zyskujesz ze swoich szacunków?
W zależności od tego, nad czym pracujesz, dokładne indywidualne szacunki mogą być istotne (klient płaci ci pod koniec tygodnia lub zadanie / historia blokuje innym i wymagana jest dokładna ETA) lub nie (masz 200 historii w zaległościach, nikt nie umrze, jeśli historia zmieni się na tydzień, a Ty liczysz na błędy szacunkowe, które uśrednią się na dużej ich liczbie).
Po prostu poświęć minimalną ilość czasu, aby uzyskać oszacowanie, które jest wystarczająco dobre dla twoich potrzeb. Nie ma formuły.
Osobiście uważam, że więcej niż minuta lub dwie oznaczają, że prawdopodobnie oceniasz niewłaściwą rzecz (podziel ją lub zaplanuj odkrycie).
źródło
W rzeczywistości potrzebujesz oszacowania, aby pomóc innym zainteresowanym stronom w wyznaczeniu względnego priorytetu - tak szeroko zakrojone szacunki, że przynajmniej powiedzą, że zadanie1 to około 3 razy wysiłek w porównaniu do zadania2 (nawet jeśli pod względem godzin nie jest zbyt dokładne na końcu), są przydatne. Poświęć tyle czasu, aby zrozumieć, jakie są te zadania (dla osiągnięcia określonych celów), a następnie mieć dla nich przybliżone szacunki.
Gdy będziesz mieć względny priorytet, skoncentruj się na robieniu rzeczy i dostosuj prognozy na trasie. Innymi słowy, spędzaj mało czasu na wstępnych szacunkach, ale dopracowuj swoje szacunki w miarę upływu czasu, aby plan projektu dał dobry pomysł na to, co zostanie zrobione.
źródło
Dobre szacunki są oparte na faktach, a nie na założeniach.
Tak więc, jeśli masz już podobne projekty i przechwyciłeś swój poprzedni czas oszacowania, może to być dobry początek bazy oszacowań . Jednak w zależności od zakresu projektu mogą istnieć nieznane artefakty , które lepiej wyjaśnić za pomocą licencjata lub właściciela produktu jak najszybciej.
Prawdą jest również stwierdzenie, że: Szacowanie projektu oprogramowania jest z natury niedokładne . Istnieją jednak realistyczne metody szacowania, które mogą pomóc:
źródło