Jaki jest dopuszczalny margines błędu przy szacowaniu czasu trwania projektu?

Firma, w której pracuję, dąży do osiągnięcia maksymalnego marginesu błędu wynoszącego 10%. Oczekuje, że analitycy nie przegapią szacunku o więcej niż 10%.

Nie wiem, co o tym myśleć, ponieważ nie mam nic do porównania.

Co może być dobrym punktem odniesienia do zmierzenia, jeśli oceniamy zbyt błędnie, mniej więcej? Ile (w%) Jak myślisz, jest w porządku , aby do panienko?

O ile nie oceniasz czegoś bardzo podobnego do tego, co zrobiliście ty i twoi współpracownicy, +/- 10% jest absurdalnie optymistyczny. Twoje zarządzanie albo nie ma dużego doświadczenia z oprogramowaniem, albo nie są świadome dużych ograniczeń szacowania oprogramowania . Ten papier zawiera dodatkowe materiały pomocnicze i można znaleźć wiele drobiazgów .

Przeanalizujmy znacznie prostszy system niż typowy projekt oprogramowania: Kostka Rubika. Możesz rozwiązać dowolną pozycję w 20 ruchach , max. Ale ponieważ szacujesz, możesz spojrzeć na daną kostkę tylko przez kilka minut, zanim podasz rozwiązanie. Czy możesz podać dobry kosztorys? Nie, czasami oszacowanie procesu trwa dłużej niż jego wykonanie.

Kolejny prosty system: Pinokio. Drewniany automat, jego nos rośnie, kiedy wypowiada kłamstwo. Co dzieje się, gdy Pinokio odpoczywa, a następnie mówi „Mój nos rośnie”? Niektóre systemy nie podlegają przewidywaniu, są nierozstrzygalne.

Te dwa problemy są wbudowane w większość systemów oprogramowania. Z tego powodu nigdy nie otrzymasz prognoz zbliżonych do +/- 10%.

Moja rada to podać mocno oszacowaną wartość, pracować jak niewolnik, aby wykonać projekt tak szybko, jak to możliwe, a następnie wyglądać na zajętego, dopóki nie osiągniesz 10% poniżej lub powyżej. W tym momencie ogłosić spektakularny sukces.

Bardzo wahałbym się przed jakimkolwiek „marginesem błędu docelowego”, ponieważ tak naprawdę zależy to od projektu. Jeśli próbujesz oszacować, ile czasu zajmie instalacja, konfiguracja i dostosowanie nowego systemu CRM, w którym nikt nie jest pewien, jakiego rodzaju dostosowania będą potrzebne i jakie zmiany procesów biznesowych będą potrzebne i firma nie ma historii podobnych dużych projektów, twój margines błędu powinien być dość duży (tzn. możesz się domyślać, że zajmie to 18 miesięcy +/- 50% i podasz 9-27 miesięcy). W miarę postępów projektu specyfikacje stają się jaśniejsze, podejmowane są decyzje dotyczące procesów biznesowych, programiści stają się bardziej komfortowi itp. Marginesy błędów powinny się zwiększać. Jeśli próbujesz oszacować, jak długo będzie budować 101. podstawową witrynę e-commerce, gdy „ Mając dobrą historię od pierwszych 100, można oczekiwać, że będziesz w stanie podać znacznie dokładniejsze oszacowanie. Jednak większość projektów spadnie gdzieś pośrodku.

Teraz, jeśli cytujesz pojedynczą liczbę, a nie zakres, odpowiedzią jest prawdopodobnie rozpoczęcie cytowania zakresu, aby osoba dokonująca oszacowania mogła określić, jak dokładne są jej oszacowania.

Dobry bazowa będzie jeden oparty na rzeczywistych danych zostały zebrane.

Pierwszym krokiem do tego jest zapisanie wszystkich szacunków . Drugim krokiem jest rejestrowanie rzeczywistych wyników . Bądź szczery, nie kusz się „samoregulowaniem” rzeczywistości. Zbierz wystarczającą ilość tych informacji, aby uzyskać dane statystyczne na temat tego, jak dobre są twoje szacunki. Zauważ, że to może / będzie się bardzo różnić w zależności od tego, kto dokonał oszacowania i kto wykonał pracę. Tylko w ten sposób można oczekiwać, że da się „margines błędu”, który jest czymś innym czystym śmieciem.

Na tym też się nie kończy; analiza przyczyn, dla których prognozy są wyłączone, może pomóc w poprawieniu dokładności przyszłych prognoz. Uwaga: Nadal pozostają szacunkami i jako takie są jedynie szacunkami .

Szacowanie również nie kończy się po pierwszym oszacowaniu; jest to coś, co można dostosować w miarę postępów projektu w miarę zdobywania wiedzy, co zmniejsza ewentualny margines błędu w miarę postępów. Im bardziej jesteś otwarty na komunikację, tym dyskutowane są wcześniejsze niespodzianki - co sprawia, że ​​ludzie są mniej zaskoczeni i dają więcej czasu na dostosowanie projektu lub oczekiwań klientów.

Po drugie, być może lepszym sposobem radzenia sobie z marginesem błędu jest „ wewnętrzne zaufanie ”, a nie tylko% marginesów błędu. Szacujesz datę dostawy na podstawie przedziału ufności, a nie pojedynczej daty.

PERT jest jednym z przykładów ram do szacowania na podstawie wnioskowania statystycznego. Na przykład:

„W oparciu o to, co teraz wiem, mamy 90% poziom zaufania, który możemy zapewnić w 8 miesięcy. 95% zaufania w 10 miesięcy, 99% zaufania w 2 lata itp.”

Uwaga tutaj: im bardziej będą cię pewni, tym większy będzie szacunek. W zależności od złożoności (czyli jak dokładny możesz być), może to być niewielka różnica między 80% a 90%, lub może być ogromna!

Wreszcie - powodzenia;) Jeśli kiedykolwiek rozwiążesz „maksymalny margines błędu” w szacowaniu oprogramowania, dzięki czemu możesz określić coś w rodzaju „wszystkie nasze szacunki będą wynosić +/- 10%”, koniecznie zamów film kasowy na resztę nas w branży oprogramowania. Myślę o czymś w rodzaju skrzyżowania Office Space i The Matrix: D

W rzeczywistości zależy to od wielkości i złożoności projektu.

Jeśli szacujesz, że twój projekt to 1 tydzień - 10% jest uzasadnione. Oznacza to +/- 1/2 dnia.
Jeśli to 1 miesiąc, 10% drży - z mojego doświadczenia nie można przewidzieć, co odkryjesz za 1 miesiąc.

Ponad miesiąc - wszystkie zakłady są wyłączone :).

Są one na jednego programistę - więc dla 4 zespołów programistycznych 1 tydzień == 1 miesiąc.

W przypadku 4-programistów zespół dobrze jest wymyślić listę funkcji, które można wykonać w ciągu 1 miesiąca, i nie przekraczać 10% tych funkcji. Następnie ponownie oszacuj na następny miesiąc.

Podjąłem tu naiwne założenia

1. Wszyscy programiści mogą pracować równolegle.
2. Nie uważałem testera - powinni mieć trochę czasu na przetestowanie
3. Wszyscy programiści są równi - Frontend, Backend, Designers itp.

Trzeba wziąć to pod uwagę ... ale to jest ogólny pomysł.

Istnieje wiele zmiennych:

1. Jak długo trwa projekt?

2. Jak będzie zarządzany projekt? Wodospad? Zwinny? SCRUM?

Zakładam, że z pytania Wodospad. W takim przypadku oczekuje się, że nie powiedzie się jakiś procent, biorąc pod uwagę prośbę o margines.

Jeśli odpowiedzią jest metodologia zwinna, zwłaszcza coś takiego jak SCRUM. Tak naprawdę nie ma znaczenia, jaki procent marży. 50% margines błędu w 2-tygodniowym sprincie wynosi 1 tydzień, w 1-tygodniowym sprincie - 2,5 dnia, oba skrajnie najgorsze scenariusze. Wynika to z faktu, że data dostawy jest ponownie szacowana przy każdym sprincie i z czasem będzie coraz dokładniejsza, a nie coraz mniejsza.

Z Waterfall 50% marginesu błędu również nie jest słyszalny, ale w ciągu 12-miesięcznego projektu, który trwa 6 miesięcy, i tak naprawdę nie zostaje wykryty / przyznany, że jest tak źle, aż do 10 miesięcy przed 12.

Kiedyś kierowałem zespołami programistycznymi, mniej więcej wokół granicy kredy / trzeciorzędu, faktycznie zbliżyliśmy się do osiągnięcia +/- 10% szacunków. To było około +/- 15%, jeśli moja bardzo niejasna pamięć służy. Ale to dlatego, że szacowaliśmy na rzeczy, które już zrobiliśmy : stosunkowo proste oprogramowanie komunikacyjne w czasie rzeczywistym, które pobierało bajty z A i przenosiło je do B, używając znanego nam języka, w zaprojektowanym przez nas środowisku czasu rzeczywistego , rozmawiamy ze sprzętem zaprojektowanym wewnętrznie przez facetów w kilku biurach. Wiele drobnych wariantów na powyższy temat, dosłownie lat .

Oczekiwanie na osiągnięcie takiego poziomu błędu w normalnym szacowaniu projektu oprogramowania jest, szczerze mówiąc, śmieszne . Kiedy widzisz, że to najwyraźniej zostało osiągnięte, dzieje się tak dlatego, że albo ludzie przeszacowali i wyszarpali (robiąc dodatkowe rzeczy i projekty zwierząt domowych, aby wykorzystać budżet), albo nie docenili i pracowali jak psy wieczorem i w weekendy, aby nadrobić czas.

Prawdopodobnie słyszałeś o 300%, prawda?

Właściwie to używam. W pełni oparty na tym, co widziałem od lat. Kiedy słyszę na dzień lub dwa, to tydzień lub więcej, aby być naprawdę zrobić . I przetestowane. We wszystkich środowiskach. Dokumentacja zaktualizowana. Testowana użyteczność. Testowana wydajność. Testowane obciążenie. Kilka godzin to naprawdę bardziej dzień.

Myślę, że naprawdę źle oceniamy z powodu:

• Pomaganie innym
• Przeszkadzać
• Szkolenie nowych ludzi
• Nadchodzą inne rzeczy
• Choroba lub złe samopoczucie
• Obejmujące osoby, które odchodzą
• Potrzebuje urlopu lub urlopu
• Rozpraszanie przez innych
• Trzymane przez inne grupy
• Nadmiernie optymistyczny niż realistyczny
• Nieprzydzielanie czasu na pracę nad przerywanymi błędami testu
• Łatwo wykluczając czas na testowanie, zwłaszcza pisanie testów automatycznych

Tak więc na najwyższym poziomie, z ludźmi biznesu, którzy potrzebują więcej niż 300% szacunków, to, co ostatecznie robimy, to dążenie do względnie dobrych szacunków, ale za cenę wyższego poziomu i bardziej ogólnego. „Będziemy mieć funkcję edycji użytkownika”, nawet jeśli wersja 1 oznacza tylko 1 grupę użytkowników do zmiany 1 pola.

Jeśli chodzi o „Jaki jest dopuszczalny margines błędu przy szacowaniu czasu trwania projektu?” Uważam, że takie podejście stosowane w wielu środowiskach zwinnych pomaga zmienić pytanie na minimalną funkcjonalność, aby uruchomić wersję alfa lub beta na żywo, a następnie iterować.