Ewaluacja kosztorysów oprogramowania: pewne oznaki nierealistycznych liczb?

Nikt tego nie powiedział, Więc ja to zrobię. Oczywistą odpowiedzią jest to, że jeśli masz szacunki harmonogramu oprogramowania, to jest to pewny znak nierealistycznych liczb. Tak, istnieje wiele metod szacowania oprogramowania, ale żadna z nich nie jest dokładna w żaden sposób, kształt lub forma. Co zwykle dzieje się, że terminy są ustalane. Jeśli zadanie jest nadmiernie szacowane, dodatkowy czas spędzany jest na poprawianiu wyniku. Jeśli zadanie jest niedoszacowane, to coś poświęca się, aby spełnić zadanie (np. Testowanie i funkcje).

Wiem, że ta odpowiedź nie jest tym, w co ludzie chcą wierzyć, ale szacowanie jest zawsze domysłem. Najczęściej programista nie może nawet przewidzieć, ile osiągnie do końca dnia. Spodziewasz się, że odgadną rzeczy miesiące/lata w dół drogi na coś, że nie są nawet pewni, co jest naprawdę zaangażowane jeszcze.

Jedyną praktyczną odpowiedzią na twoje pytanie, które nie jest podatne na dawanie nierealistycznych wyników, byłoby użycie arkusza, który pojawia się z domysły oparte na wcześniejszej historii w Twojej firmie. Niestety, nie będzie to uwzględniało zadań, które Estymator przegapił. Przynajmniej to może dać numery boiska.

Jeśli nie rozwiniecie w kółko tego samego systemu, to każdy, kto myśli, że to rozgryzł, oszukuje siebie. Jest zbyt wiele zmiennych.

Istnieją dwa rodzaje szacunków: szacunki Zadań i szacunki projektów . Możesz je zobaczyć jako duże i małe zdjęcia.

Szacunki projektu są koniecznie na wysokim poziomie (ziarnistość nie mniejsza niż zazwyczaj dni) i muszą zawierać takie rzeczy jak:

• Architektura wysokiego poziomu;
• Czas na testowanie;
• Ramp up times;
• procesy defektów;
• Czas na dokumentację;
• istotne szkolenie;
• założenia;
• zależności (np. drużyna A nie może zrobić tego, co musi, dopóki drużyna B nie dostarczy fazy 1);
• ścieżka krytyczna( które elementy mogą określić, czy projekt się poślizgnął i o ile); oraz
Ryzyko.

Im więcej tych rzeczy, których brakuje, tym bardziej nierealistyczne (lub ryzykowne) szacunki.

Drugi rodzaj oszacowania zadania, który jest zazwyczaj znacznie niższym poziomem. Dla tego rodzaju kosztorysu powinno być to po prostu zadanie podział (bez zadania większego niż powiedzmy 5 dni).

Nie odnoszą się one do powyższych pozycji, ale niektóre z nich mogą być istotne, takie jak założenia dotyczące decyzji jeszcze nie podjętych (np. sprzęt produkcyjny). Warto również określić, kto może, a nie może wykonywać zadań ze względu na odpowiednie doświadczenie, wiedzę lub umiejętności (ponieważ ta osoba lub te osoby mogą skończyć się nadmiernie).

Inne posty wspominały, że czas testowania powinien być równy lub dłuższy niż czas dev. Zdecydowanie się z tym nie zgadzam. Widziałem, jak 8 godzinne zadania deweloperskie skutkują ponad 100 godzinami testów, a 80 godzinne zadania deweloperskie skutkują mniej niż 2 godzinami testów. W obu przypadkach czas testowania był całkowicie rozsądny. Nie ma bezwzględnej korelacji między nimi. W najlepszym razie jest luźna więź.

• jest oszacowaniem, jakie kierownictwo chcesz wiedzieć?
• Czy kosztorys ładnie pasuje do planowany termin wysyłki na następny uwolnić?
• czy zarząd wynagradza ludzie, którzy dają dobrą nowinę więcej niż ludzie dają złe wieści?
• był kosztorys przygotowany przed poznaniem, kto będzie pracować nad projektem?
• Did ktoś, kto chciał ten kawałek funkcjonalnie zaimplementowane przygotowanie oszacowanie?
• Czy istnieje historia oprogramowanie spóźniłeś się?
• Czy to normalne dla deweloperzy do przeniesienia na inne zadania partway choć projekt?
• mieć niektórzy lub wszyscy deweloperzy zrezygnowali z komentowanie złych szacunków jako strata czasu?

Policz liczbę pytań, na które otrzymasz odpowiedź "Tak" lub "może".…

Jeśli otrzymujesz głównie odpowiedzi " nie " na powyższe pytania, to może warto przyjrzeć się oszacowaniu szczegółowo, aby zobaczyć, czy zawiera zadania, które inne osoby wymienione w tym wątku.

Wow... Bardzo podoba mi się odpowiedź toolkita.

I zgadzam się, że wszelkie szacunki są wadliwe, ponieważ zakłada, że Estymator ma o wiele więcej wskazówek, jak rozwiązać problem, niż jakikolwiek Estymator faktycznie robi, gdy projekt jest szacowany. Myślę jednak, że zanim zaczniesz, musisz przynajmniej oszacować wielkość góry. Niektórzy myśleli, czy warto próbować to zrobić, powinni poprzedzić wszelkie starania i na tym powinna polegać istota oszacowania be.

Wymyśliłem jeszcze kilka wskaźników niebezpiecznego oszacowania:

• Brak odsyłacza - jeśli oszacowanie nie może być zweryfikowane na co najmniej dwa różne sposoby, prawdopodobnie będzie niewiarygodne. Na przykład, ostatnie szacunki, które zrobiłem, udało mi się rozbić pracę na małe części funkcji i rozważyć, jak długo zajęło naszemu zespołowi wykonanie podobnych funkcji. Wtedy byłem w stanie spojrzeć na sumę tych kosztów i zobaczyć, jak duży zakres był względny do innych projektów, nad którymi pracowałem. To dwa sposoby na potwierdzenie.
• tło estymatora - jeśli jest to Estymator oprogramowania wykonany przez faceta od sprzętu, który nigdy nie napisał kodu - bardzo się bój. Bardziej subtelne-im bliżej tła estymatora do dziedziny technologii i problemu projektu, tym lepiej.
• detal - Jak już powiedziałem na kilka różnych sposobów w kilku różnych postach - lubię widzieć detale zarówno dla poszczególnych funkcji, jak i zadań potrzebne do ukończenia każdej funkcji. Większość szacunków, które widzę, nie pokazuje szczegółów w formalnej prezentacji, ale jeśli zapytasz osobę, która zrobiła oszacowanie, powinna mieć gdzieś plik. Mam nadzieję, że to nie jest tył papierowej serwetki poplamionej piwem i ketchupem. :)
• udokumentowane założenia - każdy Estymator będzie musiał sporządzić jakiś zestaw założeń dotyczących zadania. Powinny one być gdzieś udokumentowane, doskonale w formalnych dokumentach. Zawsze się trochę martwię. kiedy widzę krótką propozycję z niezbyt wieloma udokumentowanymi założeniami. Albo zostały przemyślane i nie przekazane Klientowi, albo nie zostały przemyślane. Nie wiem, który jest gorszy. Oczywiste jest, że założenia powinny być również rozsądne.
• zrównoważony cykl życia - jakkolwiek zadanie jest podzielone, jaki jest stosunek projektu, kodu i testu? A co z dokumentacją, integracją z systemami zewnętrznymi i obsługą post release? Jak o tych dodatkowych rzeczach, które są tak istotne (administratorzy systemu, Guru CM, wysiłek zarządzania)?
• Slack - jestem pewien, że korporacyjne demony taniości przyjdą i mnie obedrą, ale harmonogram i koszt powinny mieć trochę luzu. Jeśli oszacowanie wygląda ambitnie i agresywnie dla doświadczonego oka, prawdopodobnie będzie zbyt niskie. Szacunki prawie nigdy nie są zbyt wysokie.

Jedną z dobrych heurystyk jest sprawdzenie, czy czas testu jest mniej więcej taki sam jak czas rozwoju. To dobry znak dla oszacowania.

Jeśli nie mogą dać ci podziału oszacowania, to jest to zła rzecz. Zazwyczaj jest to znak wielu małych rzeczy, które mogły zostać zapomniane. Nie muszą podawać kompletnego oryginalnego podziału, tylko taki podział jak:

• wymagania
• rozwój
• testowanie
• opakowania i deployment
• itd.

Powinni używać standardowego szablonu do obliczania swoich szacunków. Nie potrzebują liczby w każdej kolumnie, ale robią szablon, aby wyświetlić listę wszystkich możliwych zadań. W ten sposób szablon może być używany do odświeżania umysłów ludzi podczas pracy nad oszacowaniem.

Jeśli oszacowanie jest zbyt precyzyjne, np. 0.25 godzin przyrostów, to dla mnie jest to nieprzyjemny zapach.

Jeśli brakuje takich rzeczy jak przechwytywanie wymagań, testowanie, wdrażanie i przekazanie do jakiejś grupy operacyjnej? Jeśli któraś z nich zaginęła, to coś, co wróci i cię ugryzie.

Edit: Jeszcze jedna rzecz, na którą warto uważać, to stare zadania " wiecznie ukończone w 90%". Otrzymasz aktualizację postępu po aktualizacji postępu, wymieniając zadanie jako " ukończone w 90%". Niedobrze!

HTH

Cheers

• Jest kompilatorem kosztorys dostępny i chętny do omów to z innymi starszymi projektami członków? Jeśli nie, to często troska.

• Czy kosztorys został wysłany do klienta przed doświadczeniem i umiejętności kadry rozwojowej to znane. Dwa szacunki punktowe mogą pomóc ale tylko do pewnego stopnia.

• zanim jeszcze przejrzysz oszacowanie, zostaniesz poinformowany, że jesteś zaangażowany w dostarczanie wszystkich funkcji opisany konkretną datą.

Jeśli widzisz jeden lub więcej z nich, możesz mieć złe oszacowanie:

• szacunki jednopunktowe: oszacowanie powinno być związane z zakresem możliwych dat lub wartością ufności
• niewystarczająca ziarnistość zadań: duże wiadro zadań zwykle wskazuje, że funkcjonalność nie jest dobrze zrozumiana (co jest szczególnie problemem, ponieważ słabo zrozumiane problemy są zwykle niedoszacowane)
• Brak wyrażania założeń i / lub ryzyka
• nieodpowiedni wysiłek przydzielane do często pomijanych lub niedocenianych elementów (np. skryptów kompilacyjnych, dokumentacji, wdrożeń itp.)

Zgadzam się z sateesh, bardzo podoba mi się Software Estimation: Demystifying The Black Art Steve ' a McConnella. Ma kilka list kontrolnych, które są przydatne podczas przeglądania i / lub przygotowywania szacunków.

Całkowicie zgadzam się z Dunk, pierwszą oznaką złych szacunków {[2] } jest sama obecność dużego szczegółowego harmonogramu z góry. Szacunki są dokładnie tym, przybliżeniem, inaczej nazwalibyśmy je dokładnymi imitami. Dlatego nigdy nie powinny być używane samodzielnie w zarządzaniu projektem.

Najważniejszym punktem do rozważenia nie jest dokładność szacunków, ale spójność . Jeśli strona trzecia wykonywała dla Ciebie szacunki, poproś o wyświetlenie historii o ich sukcesach lub porażkach, porozmawiaj ze swoimi poprzednimi klientami i określ ich wiarygodność.

Że wszystko jest powiedziane, z punktu widzenia zwinnego, niektóre ze sposobów, które staramy się uzyskać bardziej spójne szacunki podczas projektu są; {]}

• używaj względnego standardu rozmiaru (S, M, L,XL) zamiast opartego na czasie (idealne dni).
• skoncentruj się na złożoności, a nie na czasie
• Zawsze używaj szacunków grupowych, a nie szacunków pojedynczych osób
• Zbieraj szacunki często w całym projekt, zwykle na początku każdego sprintu
Wykorzystaj informacje zwrotne z poprzednich sprintów do określenia złożoności fabuły]}
• prędkość ścieżki, aby nadać znaczenie względnemu rozmiarowi
• częsta i wczesna retrospekcja historii, aby zbadać/zrozumieć każde uderzenie

Jeśli masz do czynienia z firmami, które używają tych metod szacowania następnie, są szanse masz zamiar uzyskać spójne i tym samym lepsze wyniki.

Szacunki postaci 3, 6 lub 12 miesięcy (w zasadzie dowolne okrągłe liczby) cuchną zgadywaniem. Zazwyczaj, gdy zgadujesz, wybierasz jakąś okrągłą liczbę większą, niż myślisz, że to zajmie -- ćwierćdolarówki, pół roku itp. -- to zwykli podejrzani. Zdecydowanie wolę szacunki pod względem rzeczywistych iteracji rozwoju (niezależnie od ich wielkości).

Jakie są oczywiste, a nie tak oczywiste oznaki słabego oprogramowania szacunki, które można zauważyć bez dużo szczegółowej wiedzy o zadaniach na ręka?

Szacunki, które są podawane bez bardzo szczegółowej wiedzy o zadaniu pod ręką, nie są na ogół dobre.

Być może ogólnym podejściem, które mógłbyś podjąć, jest sprawdzenie, czy pozycje w wymaganiach odpowiadają tym w oszacowaniu. Jeśli chcesz być bardzo szybki sprawdź względne rozmiary, jeśli istnieje słowo 100 szacunki podane do 100,000 słowo krótki nie ma szans na rację.

Również (jak powiedzieli inni) sprawdź, czy wspomniane są Analizy, kodowanie, debugowanie, testowanie, integracja, awaryjność itp. To pokazuje, że jakaś myśl weszła w to.

W jaki sposób osoba dająca kosztorys jest powiązana z osobami wykonującymi pracę?

Często widziałem szacunki, w których istnieje ogólna osoba wykonująca pracę, mimo że zespół składa się z osób o bardzo różnym pochodzeniu. Najprawdopodobniej zadania i specjalności nie pasują idealnie i dostajesz programistę C++, który robi albo gui, albo bazę danych... Czasami kierownik zespołu nie docenia zespołu mocne strony członka, więc jeśli został poproszony o opracowanie oszacowania na własną rękę, ponieważ jego zespół jest zajęty poprzednim projektem, przekonasz się, że praca, o której mowa, jest naprawdę odpowiednia tylko dla części zespołu (nie motywująca, Brak umiejętności itp.)]}

Innym pomocnym sposobem oceny szacunków jest porównanie go z rzeczywistym wysiłkiem, który został wydany w poprzednich projektach podobnego rodzaju. Najlepsze dane do porównania byłyby dane wysiłku z poprzednich projektów, które organizacja wykonała. Jeśli nie ma organizacyjnych danych historycznych, możesz spróbować porównać szacunki z branżowymi benchmarkami.

Powiedziałbym też, że jeśli oszacowanie jest przedstawione jako pojedyncza liczba bezwzględna (powiedzmy 180 dni), to nie jest to dobry znak. Pojedyncza liczba bezwzględna wskazywałaby, że oszacowanie polega na tym, że zadanie zostanie zakończone ze 100% prawdopodobieństwem na podanych danych. Szacunki przedstawione w zakresie (powiedzmy 130 do 180 dni) wskazywałyby, że zakres, w którym zadanie może być wykonane.

Wiele z tego co napisałem powyżej przypisuję do książki:

Szacowanie oprogramowania: Demystifying The Black Art autor: Steve McConnell

Sprawdzam szacunki względem siły człowieka. Chociaż nie jest to bardzo dokładna heurystyka, jasne jest, czy jakaś masywna praca ma tylko jednego lub dwóch programistów przypisanych do niej, że zadanie nie zostało poprawnie oszacowane

Dobry kosztorys będzie miał dobry podział, obejmujący wszystkie fazy projektu.

Prawie na pewno nie skończy się w dogodnym dla firmy terminie.

Będzie zawierać różnego rodzaju zagrożenia.

Będzie on prezentowany w przedziałach ufności, w domyśle (10-12 miesięcy) lub przy użyciu dużych jednostek (około czterech kwartałów).

Zrobi to ktoś odpowiedzialny za wykonanie projektu, najlepiej więcej niż jeden taki osób.

Jeśli wystąpią opóźnienia na początku, będą opóźnienia na końcu (wyrażone jako 10-12 miesięcy od początku lub około 1Q2010, jeśli zaczniemy teraz, a nie coś takiego jak styczeń 2010, kiedy projekt jeszcze się nie rozpoczął).

Założenia i zależności będą jasno i wyraźnie wymienione.

Edit: część tego zależy od etapu, na którym znajduje się projekt. Wczesne, ale dokładne oszacowanie jest znakiem ostrzegawczym, zwłaszcza jeśli nie ma przedziału ufności przypisany. To cuchnie Procrustean oszacowania.

Uważaj także na inne metody rozwoju. Projekt timeboxed może mieć sztywny i dowolny harmonogram, ale zestaw funkcji będzie elastyczny.

Dowolny z poniższych:

• jest to jeden duży projekt i nie ma krótkiej strategii wysokiego poziomu opisanej
• nie ma jasnej, krótkiej i zwięzłej wizji tego, co chce osiągnąć projekt
• projekt nie jest zorganizowany wokół wartości biznesowej dostarczanej stopniowo
• zespół stara się podać "dokładne" szacunki dla dużego projektu, przechodząc (lub został wykonany) długą fazę analizy? (zmiany nadejdą i będą miały zazwyczaj wpływ na te szacunki w sposób, którego nie można łatwo określić ilościowo bez jeszcze większych wysiłków)
• istnieją" szczegółowe " szacunki dla całego projektu (związane z poprzednim)
• nie ma szczegółowych szacunków dla pierwszej fazy, lub jest coś nie tak w nich.

"cztery do sześciu tygodni" , gdy nie towarzyszy im podział na krótsze zadania...