Jak długo wydawać oszacowanie zadań programistycznych?

9

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

9

To jest łatwe. Po prostu zaplanuj trochę czasu, aby spojrzeć na swoje obciążenie pracą i oszacować w przybliżeniu, ile potrwa oszacowanie i ... och, poczekaj.

— joshin4colours

Ponieważ twoje szacunki cały czas będą błędne, zero zwrotu z inwestycji = zero czasu spędzonego. Och, z wyjątkiem bossów zmusi cię do tworzenia fałszywych prognoz. Zwinne szacunki, w których wybierasz losową liczbę Fibonacciego w jakiejś losowej jednostkowej jednostce miary zwanej BogoEstimons lub coś takiego, wydają się lepsze niż szacunki w rzeczywistych jednostkach czasu pracy człowieka.

— Warren P

Szacowany czas na oszacowanie zadania. Niech rozpocznie się estymacja

— użytkownik

13

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.

— pdr
źródło

3

+1. ale nie zgadzam się, że szacunki nie są zbyt przydatne. Pomagają lepiej planować, a zatem są bardziej produktywne.

— superM

4

@ superM: Nie powiedziałem, że w ogóle nie były przydatne. Z pewnością są. Powiedziałem, że nie są warte wiele czasu. Działające oprogramowanie jest znacznie bardziej przydatne, więc poświęć na to dużą część swojego czasu.

— pdr

@ superM: Czy kiedykolwiek dokonałeś porównania swoich szacunków z rzeczywistymi wartościami? To da wspaniałą lekcję na temat rzeczywistej wartości zgadywania (która jest szacunkiem z definicji). Oszacowanie jest klasyczną rzeczą Pareto: otrzymujesz dość dobre oszacowanie w 20% przypadków. Marnowanie więcej czasu sprawi, że będzie to tylko 5% lepsze.

— JensG,

Im dłużej pracuję nad projektem, tym lepszych szacunków dokonuję. Jest zbyt wiele czynników i niektórych z nich nie mogę kontrolować, a znajomość tych [specyficznych dla projektu] czynników wiąże się z doświadczeniem. Czasami po prostu nie można uniknąć oszacowania, a czasem należysz do tych, którzy cierpią z powodu twoich niedokładnych oszacowań.

— superM

2

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.

— Telastyn
źródło

2

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.

— Ciaran Gallagher
źródło

1

Planowanie pokera szacuje Punkty, które nie znajdują się w rzeczywistych jednostkach. Który rodzaj czyni je analogicznymi do tego, jak naprawdę są szacunki; Guessery Wild Ass.

— Warren P

1

Chodzi o to, że jeśli wiemy, że na przykład zadanie 1 punkt zajmie na przykład 7,5 godziny, to możemy powiedzieć, że historia użytkownika 5 punktów zajmie 30 godzin, a historia użytkownika 10 punktów zajmie 60 godzin. Na przykład możemy wybrać jedno z najmniejszych zadań, a szacowany czas można przypisać jako wartość pojedynczego punktu historii użytkownika. Następnie możemy wykorzystać tę historię użytkownika jako podstawę do oszacowania większych zadań. Jeśli uważamy, że kolejne zadanie potrwa dwa razy dłużej, przydzielilibyśmy 2 punkty historii użytkownika (15 godzin) i tak dalej.

— Ciaran Gallagher

1

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

— Joqus
źródło

1

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

— ptyx
źródło

0

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.

— Roopesh Shenoy
źródło

0

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:

Osoby wykonujące pracę powinny uczestniczyć w szacowaniu projektu
Przyprowadź ekspertów: ocena eksperta ma kluczowe znaczenie dla powodzenia projektu
Oszacuj duże sztuki jako zakres
Użyj techniki Delphi: jest to metoda, która pomaga zbierać opinie zespołu w przypadku konfliktu w szacowaniu projektu oprogramowania.
Pamiętaj o koszcie
Należy pamiętać o przydzielonych zasobach dostępnych do wykonania pracy

— Jusubow
źródło

Nigdy nie widziałem zespołu ani osoby, która oceniała, że rutynowo (ponad 50% czasu) okazało się, że są one dokładne w ciągu 10% faktycznie spędzonego czasu. Inni ludzie w innych miejscach twierdzą, że sukcesy wydaje mi się trudne do wyobrażenia sobie, że kiedykolwiek zdarzy się coś, co kiedykolwiek pracowałem.

— Warren P

„dokładność w ciągu 10% faktycznie spędzonego czasu” - to tak naprawdę bardzo słaby wynik. Weź również pod uwagę margines błędu, który zwiększa się o złożoność i zewnętrzne zależności projektu.

— Yusubov

Tak mówię. Ocena jest do kitu.

— Warren P

tak, to naprawdę duży cios, który „ma dokładność w granicach 10% faktycznie spędzonego czasu” ...

— Yusubov,