Dlaczego harmonogramy oprogramowania są tak trudne do zdefiniowania?

39

Z mojego doświadczenia wynika, że ​​nakłanianie nas inżynierów do dokładnego oszacowania i określenia zadań do wykonania jest jak wyciąganie zębów. Zamiast podawać szacunek SWAG na 2-3 tygodnie lub 3-6 miesięcy ... jaki jest najprostszy sposób na zdefiniowanie harmonogramów oprogramowania, aby nie były tak bolesne? Na przykład klient A chce funkcji do 02/01/2011. Jak zaplanować czas na wdrożenie tej funkcji, wiedząc, że po drodze mogą być potrzebne inne poprawki błędów i zajmuje to dodatkowy czas inżynierii?

Brian
źródło
33
Odkryłem naprawdę cudowny dowód, że niemożliwe jest dokładne oszacowanie wszystkich złożonych zadań programistycznych, ani perfekcyjne zaplanowanie tych zadań, ani ogólnie żadnego harmonogramu opartego na szacunkach. To pole komentarza jest zbyt małe, aby je pomieścić.
Dan McGrath
2
@Dan McGrath: Dlaczego nie opublikujesz linku zawierającego dowód? Zaraz, próbujesz być jak Fermat i jego ostatni dowód twierdzenia, którego nigdy nie znaleziono: |
Shamim Hafiz
9
Z tego samego powodu, że trudno jest zaplanować podróż, gdy nawigator nie jest pewien miejsca docelowego, kierowca nie zna dróg, a wszyscy pasażerowie chcą lodów.
Steven A. Lowe
1
Coś, co może Cię zainteresować, to planowanie oparte na dowodach.
Craige,
2
Nie są trudne do zdefiniowania. Po prostu niemożliwe do utrzymania.
Tony Hopkinson,

Odpowiedzi:

57

Jeśli realizujesz projekt prawie identyczny z innymi wykonanymi projektami, używając znanych narzędzi i znanego zespołu, a otrzymujesz twarde, pisemne wymagania, wtedy powinna istnieć możliwość dokładnego oszacowania.

Są to warunki, których regularnie doświadczają malarze, instalatorzy dywanów, architekci krajobrazu itp. Ale nie jest to dobre rozwiązanie dla wielu (lub większości) projektów oprogramowania.

Często jesteśmy proszeni o oszacowanie projektów, które wykorzystują nowe narzędzia, technologie, w których zmieniają się wymagania itp. Jest to bardziej ekstrapolacja w nieznane niż interpolacja w stosunku do naszych przeszłych doświadczeń. Jest więc naturalne, że oszacowanie będzie trudniejsze.

Rob Weir
źródło
20
Doskonałe punkty. To tak, jakby zapytać, ile czasu zajmie ci jazda samochodem w miejscu, w którym nigdy nie byłeś. Możesz podać oszacowanie na podstawie odległości, ale nie możesz uwzględnić natężenia ruchu w godzinach szczytu.
JeffO
2
@Jeff To bardzo dobre porównanie. Będę musiał pamiętać ten jeden
Dave McClelland
1
@Jeff ... ale wiesz, że jest godzina szczytu i dodaj ten fakt do swoich szacunków ... nadal możesz być nieobecny, ale nie aż tak bardzo
Pemdas
2
@Pemdas: W rzeczywistości nie masz wystarczającej wiedzy, aby dodać wszystkie fakty do swoich szacunków. Nie możesz wiedzieć, czy straż pożarna odpowiada na połączenie. Nie możesz wiedzieć, czy spadł drut elektryczny i blokuje drogę. Istnieje nieskończona liczba rzeczy, których nie możesz wiedzieć o przyszłości. To jest przyszłość. Trudno przewidzieć - z definicji.
S.Lott,
1
@Pemdas - im bardziej złożone zadanie, tym bardziej bogowie chaosu przeszkadzają. Oczywiście, że prawdopodobnie pasuje to bardziej do niektórych komentarzy - dzięki znanym zadaniom wiesz, jak zainteresowani są ci nieznośni bogowie.
Steve314,
35

Zgodnie z moim osobistym doświadczeniem jest to dokładnie odwrotność tego, co powiedział Pemdas : dzięki praktyce zrozumiałem, że całkowicie niemożliwe jest oszacowanie, ile czasu zajmie zadanie. Na początku mojej kariery w tworzeniu oprogramowania często podawałem prognozy takie jak „45 dni”, „pięć tygodni” itd., A potem bardzo ciężko próbowałem skończyć na czas. Kilka lat później zacząłem podawać mniej precyzyjne szacunki, takie jak „ok. Jeden miesiąc”, „od pięciu do siedmiu tygodni” itp. W rzeczywistości staram się nie podawać żadnych szacunków lub prosić klienta o podanie własnych oszacowań lub ostateczny termin albo podam możliwie jak najbardziej przybliżony szacunek.

Dlaczego tak trudno jest oszacować? Ponieważ prawie niemożliwe jest ustalenie, w jaki sposób zostanie napisany cały kod źródłowy przed jego faktycznym napisaniem, a ponieważ twoja praca zależy od przypadkowych rzeczy, takich jak praca innych ludzi, twojej motywacji itp. Oto bardziej szczegółowa lista możliwych przyczyn:

  1. Nie jest łatwo wiedzieć, co dokładnie jest wymagane, aby zrobić produkt, a zwłaszcza jak to zrobić . Bardzo często uruchamiałem niektóre części aplikacji, a po wielu dniach pracy zrozumiałem, że moje pierwsze podejście było błędne i że istnieje lepszy i mądrzejszy sposób robienia rzeczy.

  2. Pewne problemy mogą się pojawić . Na przykład, jeśli aby rozpocząć pracę, musisz zainstalować na swoim komputerze fantazyjny serwer SQL, a instalacja nie powiedzie się, a obsługa nie będzie dostępna, możesz poświęcić tygodnie na rozwiązanie tego problemu.

  3. Wymagania często nie są wystarczająco jasne , ale po przeczytaniu ich na początku wydaje ci się, że są. Czasami możesz zrozumieć, że oznacza to „A”, a po rozpoczęciu ich wdrażania zauważysz, że mogą one oznaczać „B”.

  4. Klienci lubią zmieniać swoje wymagania dokładnie po zakończeniu danej części , a oni naprawdę nie rozumieją, dlaczego żądasz jeszcze dwóch tygodni i 2000 USD na drobną zmianę, ponieważ nie widzą, że ta drobna zmiana wymaga zmienić inne rzeczy, które wymagają zmiany innych itp.

  5. Nie możesz oszacować swojej motywacji . Są dni, kiedy możesz pracować godzinami i odnosić sukcesy. Są tygodnie, kiedy po napisaniu dziesięciu wierszy kodu przełączasz się na programistów StackExchange i spędzasz godziny na czytaniu odpowiedzi na pytania.

  6. Rzeczy stają się naprawdę złe, gdy twoje oszacowanie zależy od innych ludzi . Na przykład w jednym 2-miesięcznym projekcie musiałem czekać, aż projektant wykona swoją pracę, aby ukończyć własną. Ten projektant potrzebował 3 miesięcy, zanim dostarczył kawałek bezużytecznego badziewia. Oczywiście projekt się spóźnił.

  7. Twój szacunek zależy również od klienta . Miałem klientów, którzy spędzili tygodnie przed odpowiedzią na swoją pocztę. Może to naprawdę wpłynąć na twój harmonogram, gdy musisz poczekać na odpowiedź (na przykład, jeśli poprosisz ich o sprecyzowanie wymagania).

Co możesz zrobić?

  1. Podaj większy harmonogram . Jeśli uważasz, że możesz wykonać pracę w ciągu dwóch tygodni, powiedz, że dostarczysz ją w ciągu miesiąca.

  2. Być jasne . Jeśli polegasz na projektantach, innych programistach itp., Powiedz to. Zamiast mówić „Dostarczę produkt za trzy miesiące”, powiedz „Dostarczę produkt za dwa miesiące po tym, jak projektant dostarczy mi pliki PSD”.

  3. Wyjaśnij, że jeśli wymagania zmieniają się każdego dnia, projekt nie zostanie dostarczony na czas.

  4. Pokrój swój harmonogram . Dostarczenie części dużego projektu na czas jest łatwiejsze.

  5. Nigdy nie podawaj wartości szacunkowych, gdy używasz produktu, którego nie znasz dobrze, a zwłaszcza, gdy będziesz pracować nad kodem źródłowym innej osoby: nigdy nie możesz przewidzieć, jak kiepski może być kod źródłowy i ile czasu spędzisz zrozumienie i skopiowanie go do The Daily WTF.

Arseni Mourzenko
źródło
1
@Jeff O: Nie wiem. Dla mnie termin dostawy oznacza termin. A termin oznacza, że ​​projekt nie może być dostarczony po nim. Ponadto psychologicznie klienci mogą być mniej źli, kiedy powiedzielibyście, że dostarczą coś za miesiąc, a dostarczycie to cztery dni później, niż jeśli 8 stycznia 2011 r. Powiecie, że dostarczycie to 8 lutego 2011 r., A wy dostarcz go 12 lutego.
Arseni Mourzenko
10
@Pemdas: to nie jest kwestia lenistwa. Możesz być w depresji lub mieć przejściowe trudności z koncentracją, mieć problemy osobiste / rodzinne lub być zbyt zestresowanym przez innych klientów lub cokolwiek innego.
Arseni Mourzenko
2
Dodając do punktów MainMa, jeśli pracujesz w zespole, zdarzają się sytuacje, gdy ktoś musi być na urlopie, z powodu radości lub choroby.
Shamim Hafiz
5
@Pemdas Zdarza się do pewnego stopnia u każdego programisty. Po prostu manifestuje się w sposób, który nie zawsze jest oczywisty. Tydzień pracy nad danym problemem może zająć 3 godziny, ponieważ jesteś bardzo bystry i „w strefie”, podczas gdy następny tydzień zajmuje 3 dni.
Matthew Frederick
7
@ 0A0D Jeśli podzielisz projekt na jego najbardziej szczegółowe podzadania i zorientujesz się dokładnie, jak każdy z nich będzie działał, przeanalizuj wszystko, aby upewnić się, że rozumiesz implikacje połączenia tych elementów i dokładnie przejrzyj wszystkie nowe lub nie-świeże- zaangażowane w twoje myśli technologie i usuń wszelkie nieznane im przeszkody, wtedy absolutnie możesz podać cholernie dokładne oszacowanie. Oczywiście wykonałeś prawie całe programowanie, pozostawiając tylko część kodującą i nie możesz z góry wiedzieć, jak długo zajmie to oszacowanie. ;)
Matthew Frederick
15

Bardzo podobne pytanie brzmi: „Ile czasu zajmie rozwiązanie tej krzyżówki?”

Nie możesz odpowiedzieć na to pytanie, dopóki nie spojrzysz na to, aby zobaczyć wiele rzeczy, takich jak:

  • Czy to w znanym języku? (Hiszpański kontra angielski kontra chiński)
  • Czy jest to jeden z rodzajów, które rozwiązaliśmy wcześniej? (Jeden z serii np. W magazynie)
  • Czy któryś z potencjalnych klientów wymaga dodatkowej wiedzy, zanim będziemy w stanie ją zrozumieć?
  • Czy w puzzlach jest coś, co według twojej wiedzy będzie wymagało dodatkowej pracy?

Ponieważ w projekcie jest zwykle kilka nowych rzeczy (inaczej nie byłby to projekt), nie można powiedzieć, ile czasu zajmie ich rozwiązanie, dopóki nie przyjrzysz się im bardzo uważnie. Być może nawet mniej lub bardziej rozwiązujesz je, a wtedy nadal nie masz pewności, że nie ma żadnej niespodzianki, jeśli nie pomyślałeś o nich.

Istnieje również silna presja, aby zrobić to tak tanio, jak to możliwe, dlatego tak szybko, jak to możliwe, a wina za zbyt niskie oszacowanie nie spoczywa na menedżerze projektu, ale naciska na dewelopera. Programiści nie muszą tego robić wiele iteracji i nauczyć się BARDZO zmęczony podawaniem liczb bezwzględnych.

Jim G.
źródło
11

Najbardziej oczywistym powodem, dla którego inżynierowie nie są w stanie podać dokładnych szacunków, jest to niemożliwe .

Oczywiście możesz oszacować, ile czasu + -2 minuty zajmie Twój dom do pracy. Wiesz, jak prowadzić samochód, możesz ocenić natężenie ruchu i inne czynniki zewnętrzne.

Powiedz mi, ile czasu zajmie Ci jazda samochodem z Londynu do Barcelony. Oczywiście bez zaawansowanych narzędzi do planowania GPS. Korzystając ze starej, dobrej metody, tak jak robimy to w szacowaniu oprogramowania. Empiryczne oszacowanie i prognozy .

W oprogramowaniu jest gorzej:

  1. Szacunki często stają się zobowiązaniem , więc nasz osąd jest modyfikowany.
  2. Pomiędzy oceną Boba i Karla dla tego samego zadania mogą występować ogromne różnice .
  3. Niepewności są bardzo częste, jak bardzo utknęliśmy w głupim błędzie lub awarii dysku twardego, niszcząc wszelkie pozornie dobre oszacowania.
  4. Zazwyczaj zapominamy o wszystkich innych zadaniach niż programowanie, w tym o spotkaniach, rozmowach telefonicznych, pomaganiu naszej koleżance itp.
  5. Ludzki mózg jest ograniczony . Nie został zaprojektowany do oszacowania długotrwałych zadań.

Dlatego nie można powiedzieć klientowi, co będzie można wysłać na 01.01.2011 z dobrą dokładnością, i zapomnieć o 01.01.2011.

Aby rozwiązać wszystkie te problemy, polecam zaawansowane techniki szacowania, takie jak Planning Poker (zrzeczenie się: to jedna z moich stron) i Iterative Development with Velocity .

  • Pierwsze dwa problemy rozwiązuje się za pomocą Planning Poker. Szacunki są zbiorowe, a zespół jest ich właścicielem, a nie pojedynczymi osobami.
  • Ostatnie trzecie problemy są rozwiązywane za pomocą Velocity i Iterative Development. Znając swoją prędkość (czynnik, który należy zastosować do szacunków na podstawie historii), możesz planować wydania z większą pewnością. Programowanie iteracyjne, jeśli jest dobrze wykonane, zapewnia najważniejsze funkcje na szczycie i pomaga wcześnie zapewnić użytkownikom wartość.

źródło
Więc jeśli ktoś poprosi o datę dostawy 02/01/2011 o funkcję, najlepiej postawić „powiedzieć, jak tylko nad tym pracuję, dam ci znać, jak długo to potrwa”? Jestem pewien, że wypadłoby to jak ołowiany balon;)
Brian
0A0D: zależy od sytuacji. Z zespołem, który się nie zna, nie postawiłbym na ŻADNY termin. Jeśli jednak znasz swoją średnią prędkość, korzystasz z szacunków zbiorowych i ćwiczysz iteracyjny rozwój, możesz wyznaczyć termin z większą pewnością.
@ 0A0D, w Europie 02/01/2011 oznacza 2 stycznia. Przynajmniej ułatwia odpowiedź, gdy zostanie zapytany 8 stycznia: D
6

Tworzenie oprogramowania jest - z definicji - odkryciem i wynalazkiem. Zawsze musi dotyczyć czegoś nieznanego.

Jedyny raz, kiedy wszystko związane z tworzeniem oprogramowania jest znane, to kiedy oprogramowanie jest kompletne.

Jedynym przypadkiem, gdy nie ma nieznanej technologii lub funkcji biznesowej, jest kompletne, gotowe do pobrania rozwiązanie.

Powodem, dla którego piszemy nowe oprogramowanie, jest to, że mamy nową funkcję lub nową technologię albo jedno i drugie. Nowy oznacza nowy - nieznany - nieprzewidywalny.

Ponieważ tworzenie oprogramowania musi obejmować nowość, nie można przewidzieć wysiłku programistycznego.

S.Lott
źródło
3

Szczerze mówiąc, myślę, że to wymaga jedynie praktyki. Jeśli w końcu napiszesz wystarczającą ilość kodu, powinieneś być „dość” dokładny. Mój pierwszy szef uważał, że ta umiejętność była na tyle ważna, że ​​poprosił, abym nieformalnie ćwiczył ją przy każdej funkcji / projekcie, który zrealizowałem. Po każdym projekcie sprawdziliśmy szacunki i próbowaliśmy dowiedzieć się, gdzie popełniłem błąd. W końcu zrozumiesz.

Pemda
źródło
Zgadzam się z recenzją, ale jestem naprawdę ciekawy: @Pemdas, czy masz tendencję do pracy nad tymi samymi problemami dla każdego projektu, z niewielkimi zmianami? Masz na myśli dość proste rzeczy, może jeszcze jedną usługę RESTful, która po prostu zwraca wiersze tabeli bazy danych lub coś takiego? Pracując z wieloma dziesiątkami programistów i zatrudniając dziesiątki, jeszcze nie znalazłem kogoś, kto byłby w stanie podać dokładne oszacowanie problemów pełnych niewiadomych.
Matthew Frederick
Pracuję nad tym samym produktem, ale zestawy problemów zmieniają się wraz z każdym wydaniem. Przyznam, że nigdy nie musiałem oszacować czegoś, co zajęło mi więcej niż 6-8 miesięcy.
Pemdas
Perndas, dla zabawy: Ile czasu zajmie przepisanie produktu w C # lub Javie? Aby uruchomić w chmurze Google? Czy chcesz wizualizować dane na żywo w OpenGL? Chcesz mieć klienta końcowego działającego na Wii?
Może nasza definicja szacunków jest błędna. Zdecydowanie potrzebny jest okres badań, zanim będzie można podać uzasadnioną ocenę, której zwykle nie uwzględniam czasu na oszacowanie dostawy. Nie potrafię rozsądnie odpowiedzieć na żadne z tych pytań bez uprzedniego przeprowadzenia badań. Nigdy nie zakładałbym, że będę w stanie podać oszacowanie bez zrozumienia technologii.
Pemdas,
2

To nigdy nie jest łatwe. Po prostu starasz się być w tym lepszy.

Jedną z zalet podziału kodu dostarczalnego na mniejsze części jest to, że klienci rozumieją, czego się spodziewać i kiedy się spodziewać. Teraz masz dla nich jakiś punkt odniesienia do wykorzystania jako odniesienie.

Jeśli mają ścisłą definicję funkcji, której potrzebują w określonym czasie, muszą wiedzieć, że na to żądanie należy przeznaczyć dodatkowe zasoby. Podejmują ryzyko związane z nasileniem pojawiających się błędów i tym, jak długo mogą trwać bez ich naprawy. Kiedy pojawia się coś ważnego, wracasz do klienta i zmuszasz go do podjęcia decyzji. Czy mogę naprawić błąd lub ustalić termin wprowadzenia nowej funkcji? Podaj im wystarczającą ilość informacji, aby podjąć świadomą decyzję.

Mamy nadzieję, że masz dość historii współpracy i osiągnąłeś wystarczający poziom zaufania. Nie możesz oczekiwać od nich pełnego zrozumienia procesu rozwoju, ale możesz sprawić, że poczują, że podejmują uczciwy wysiłek i nie wykorzystują ich braku wiedzy.

JeffO
źródło
Nawet nie myślałem o wydaniach przyrostowych. To świetne narzędzie, aby dać klientowi pewien postęp. Chociaż nie pracuję z klientami „zewnętrznymi”, zrób to samodzielnie, to świetny sposób na testowanie potokowe wraz z programowaniem.
Pemdas,
2

Ponieważ wykonujemy harmonogram zbyt wcześnie. Zobacz artykuł Construxa na temat wstępnego zgrubnego, a później lepszego. Również jeśli nie śledzisz swoich wcześniejszych szacunków, trudno jest polepszyć sytuację. FogBugz robi to [klient ich darmowy, żaden inny konflikt interesów].

Brian Carlton
źródło
2

Wiele się nauczyłem z tej książki:

Ocena oprogramowania: Demystifying the Black Art

W skrócie, aby uzyskać lepsze wyniki szacowania, robimy to:

  1. wszystkie zadania oprócz trywialnych są oceniane przez więcej niż jedną osobę (w naszym przypadku dwie)
  2. dzielimy zadanie na mniejsze. Im więcej masz zadań, tym bardziej prawdopodobne jest, że twoje oszacowanie będzie dobre - prawo wielkich liczb, jeśli dobrze pamiętam z boo
  3. oceniamy najgorszy, najlepszy i najbardziej prawdopodobny scenariusz. Czasami każdy z nas ocenia te scenariusze drzew zupełnie inaczej. Oznacza to, że musimy porozmawiać i zwykle okazuje się, że jedno z nas nie zrozumiało zadania. Gdyby jedna osoba oceniła samo zadanie, byłoby źle ocenione.
  4. kładziemy 3 liczby z powyższego punktu do równania i otrzymujemy oszacowanie (excell) k

Po zakończeniu zadania i błędnym oszacowaniu staramy się znaleźć przyczyny. I włączamy tę wiedzę do następnego procesu szacowania. Jak dotąd jest to najlepszy proces, który wykorzystałem do oszacowania większych zadań. Kiedy mówię zadanie, mam na myśli prace, które trwają od około 50-500 godzin.

Piotr Perak
źródło
1

Uwaga: tak naprawdę dotyczy to tylko projektów, w których rozliczasz się według godziny w stosunku do stawki stałej / zryczałtowanej.

Zwykle staram się tak zaplanować harmonogram, aby składał się on zasadniczo z kilku Sprintu SCRUM (czy to SCRUM, czy nie). Przy opracowywaniu harmonogramu określam, jaka będzie długość każdego sprintu i jakie będą cechy projektu. Zazwyczaj są pewne funkcje, które należy wykonać w pierwszej kolejności, dlatego staram się podać najlepsze oszacowanie (nie mylić z optymizmem) dla tych, a wszelkie cechy, które będą pod koniec projektu, będą miały ogólne oszacowania. Po zmapowaniu obiektów do sprintu staram się dodać 1 do 2 sprintów na końcu projektu, aby uwzględnić funkcje, które przesuwają się w prawo, oraz funkcje, które zostały pominięte podczas gromadzenia oryginalnych wymagań.

Kluczem do tego jest to, że robię to z góry przejrzyste dla klienta, aby rozumieli, dlaczego ostatnie dwa sprinty są puste lub słabo zaludnione. Przynajmniej do tego stopnia, z którymi współpracowali klienci, podobało się to, ponieważ wiedzą, że w harmonogramie / finansach istnieje pewna poduszka, ponieważ większość z nich zdaje sobie sprawę, że szacunki SW są zwykle mniej niż konkretne. Zdają sobie również sprawę, że jeśli nie potrzebujemy ostatniego sprintu, to są godziny, których nie rozliczamy. Dzięki przejrzystości budowania harmonogramu i regularnym informacjom o postępach w trakcie realizacji projektu każdy klient, z którym to zrobiłem, jest bardzo zadowolony.

Ken Henderson
źródło
1

Oprócz wszystkich wymienionych rzeczy widzę te dwie rzeczy jako jedne z największych problemów. Najpierw szacujesz ostateczną datę na podstawie dostępności każdego devloper przez pełne 8 godzin dziennie przez 5 dni w tygodniu. Jest to niepoprawne i praktycznie w 100% gwarantuje, że data zakończenia zostanie pominięta w przypadku każdego projektu, który nie jest trywialny. Ludzie biorą wolne, biorą udział w spotkaniach firmowych (lub nieopartych na projektach), walczą z działem kadr o roszczenia z tytułu ubezpieczenia zdrowotnego, robią przerwy itp. Nigdy nie zakładaj, że programista ma więcej niż 6 godzin dziennie.

Kolejni dewloniści notorycznie zapominają oszacować wszystkie zadania niezwiązane z programowaniem, takie jak spotkania i wiadomości e-mail dotyczące projektu, wdrożenia, wsparcia jakości, wsparcia UAT, pisania testów jednostkowych, badań, dokumentacji itp. Po dodaniu tego rodzaju zadań do arkusza kalkulacyjnego naszych ocen szacunki stały się znacznie lepsze.

HLGEM
źródło
Nie nazwałbym zadania pisania testów jednostkami non-development;) Nasi szefowie liczą nas przez 6 godzin dziennie. Jeśli powiem 60 godzin, powiedzą 10 dni.
Piotr Perak,
@Peri, przyznam, że ja też bym tego nie zrobił, ale wiele osób zapomina dodać czasu na pisanie testów i myśleć tylko o głównym problemie. Dobry dla twoich szefów, zadziwia mnie, ilu nie.
HLGEM,
1

Jeśli chodzi o szacowanie czasu dla zadań, które mogą trwać dłużej niż kilka godzin, staram się jak najlepiej wykorzystać te zasady:

  1. Nie zawsze starają się przewidzieć, kiedy inni ludzie zakończy swoją pracę, jeśli zdarzy ci się od niej zależne. Mów tylko za siebie.
  2. Najpierw przeanalizuj zadanie, a następnie oszacuj. Analizując, mam na myśli przynajmniej zapisanie (i nie próbowanie trzymania wszystkiego w głowie!) Listy podzadań z oszacowaniem dla każdego z nich.
  3. Jeśli zadanie jest wystarczająco złożone, oszacuj czas na taką analizę. Niech oszacowanie będzie odrębnym procesem. Możesz także upewnić się, że twój szef o tym wie.
  4. Nie szacuj pod presją. Wyjaśnij, że dokonanie rozsądnego oszacowania wymaga czasu i po prostu powiedz im coś w stylu: „jutro określę datę na 11:00, kiedy skończę analizować zadanie”. Wiem, że niektórzy klienci / menedżerowie mogą mocno naciskać, ale nie przejdą. Załóż swoją zajętą ​​twarz i odbierz swój czas!
  5. Poproś o trochę więcej czasu, niż myślisz, że będziesz potrzebować, ponieważ prawdopodobnie zapomniałeś dodać do swojej oceny czas przerwy na kawę (i inne zakłócenia).
  6. W przypadku dużych zadań zapytaj jeszcze więcej - prawdopodobnie będzie więcej niż jedna przerwa na kawę.
  7. Jeśli naprawdę nie możesz oszacować (zadanie jest zbyt trudne / nieznane) lub naprawdę nie masz pewności - poproś kogoś, kto może pomóc w analizie.

Prawdopodobnie jest więcej zasad, ale tak naprawdę nie mam plakatu z tymi zasadami na mojej ścianie. Właśnie je sformułowałem, ale pochodzą one z mojego doświadczenia (więc może nie działać dla ciebie).

Jedynym niezawodnym sposobem planowania rozwoju oprogramowania, o którym myślę (ale tak naprawdę go nie wypróbowałem), jest Planowanie oparte na dowodach, które jest w zasadzie metodą Monte Carlo stosowaną do zliczania prawdopodobieństwa daty wysyłki na podstawie historycznych zapisów dotyczących zadań, które „ osiągnęliśmy wcześniej. To przyjemne, ponieważ nie próbuje używać żadnych innych wskaźników niż szacowany i rzeczywisty czas. Wymaga to jednak dużego doświadczenia, aby wcześniej podzielić duże zadania na mniejsze i trzeba mieć duży zestaw danych historycznych, aby działał wystarczająco precyzyjnie.

scriptin
źródło
1

Istnieją „znane nieznane” i „nieznane nieznane”. :-)

  1. Szacunki często stają się terminami.

    • Nikt nie chce przekroczyć terminu i zostać nagłówkiem!
  2. Wymagania zmieniają się (często racjonalnie) i programista nie może tego zawetować.

  3. Programista nie ma / może mieć kontroli nad czynnikami takimi jak

    • Dostępność kodu, od którego jest zależna
    • Jakość kodu, od którego jest zależna
    • Ogólna architektura i projekt systemu
    • Interfejsy API umożliwiające dostęp do innych części systemu
Arun Saha
źródło