Jak wytłumaczyć, że trudno jest oszacować czas potrzebny na większy projekt oprogramowania?

37

Jestem młodszym programistą i trudno mi oszacować, ile czasu zajmuje ukończenie większego projektu oprogramowania. Wiem, jak ogólnie zbudować architekturę, ale trudno mi wiedzieć, jakie szczegóły muszę zrobić i jakie problemy muszę rozwiązać. Trudno więc oszacować, ile czasu zajmie ukończenie większego projektu, ponieważ nie wiem, jakie problemy muszę rozwiązać i jak długo trzeba je rozwiązać.

Jak wytłumaczyć to osobie, która nie jest programistą ?

Jonas
źródło
5
Ciekawe: dlaczego Twoim zadaniem jako młodszego programisty jest wyjaśnianie tego innym programistom? Czy w Twojej grupie roboczej lub w łańcuchu zarządzania jest ktoś, kto może pomóc Ci w procesie przekonywania każdego, kogo potrzebujesz przekonać?
Alex Feinman
@Alex: Nie, to nie jest osoba w tej samej firmie. Tylko osoba z pomysłami na uruchomienie. Jestem jedynym programistą, z którym ma kontakt.
Jonas

Odpowiedzi:

48

Możesz poprosić go o oszacowanie, ile czasu zajmie jej dotarcie do jakiejś odległej lokalizacji w niezamieszkanym zakątku świata. Jako skrajny przykład wybierzmy mniej znany szczyt w Himalajach, na który wspinało się bardzo niewiele (jeśli w ogóle) ludzi. Potrzebowałaby strasznie dużo przygotowań i ćwiczeń przed rozpoczęciem podróży, a także szeregu zezwoleń, z których każde może opóźnić podróż o miesiące lub lata ... i dobrego zespołu wsparcia ... a potem raz na wzgórzu na zboczu, musiała poczekać i modlić się o dobrą pogodę, aby zacząć wspinać się na szczyt ... itd. itd. Większość z nich jest trudna do oszacowania, nawet przy wcześniejszym doświadczeniu.

I chodzi o to, że każdy projekt oprogramowania przypomina wspinanie się na nową górę, gdzie nikt wcześniej nie był, więc nikt nie ma bezpośredniego doświadczenia. Doświadczeni programiści mogli gromadzić doświadczenie przy mniej lub bardziej podobnych projektach, ale zawsze pojawią się nowe elementy i niespodzianki - w przeciwnym razie, jeśli projekt oprogramowania byłby dokładnie taki , jak poprzedni, absolutnie nie ma sensu tego robić .

Péter Török
źródło
Więcej niewiadomych oznacza większą niepewność.
surfasb
9
Zapomnij daleko. Poproś ich, aby oszacowali - do minuty - kiedy wrócą wieczorem z pracy do domu. Co jeśli ruch jest inny, co jeśli zacznie padać deszcz, co jeśli otrzymasz telefon podczas jazdy itp. Jeśli coś tak przyziemnego i wykonywanego tak często, jak jazda samochodem do domu, nie może być zmierzone z jakimkolwiek stopniem dokładności - to jak czy możemy spodziewać się lepszego oszacowania czasu potrzebnego na wdrożenie złożonego oprogramowania, które ma niezliczoną liczbę znaczących zmiennych w większym stopniu niż nędzny powrót do domu z pracy.
quentin-starin
8
@qes, korzystam z transportu publicznego, więc mogę powiedzieć z około 10% dokładnością, kiedy wrócę do domu - myślę, że większość kierowników projektów SW byłaby zadowolona z tego poziomu dokładności ;-)
Péter Török
1
Zmieniają się też cele projektu oprogramowania, więc po oszacowaniu czasu, w którym będą potrzebować, OP może zapytać, czy nadal zdąży na czas, po tym, jak ktoś powie im, aby zmieniali szczyty, gdy byli w połowie drogi do pierwszego.
Paul
18

Czy wyjaśniłeś to osobie? Jesteś profesjonalnym inżynierem oprogramowania, więc osoba, dla której budujesz oprogramowanie, powinna wziąć pod uwagę Twoją wiedzę i opinie dotyczące projektowania i wdrażania systemów oprogramowania.

Cone niepewności jest chyba dobry punkt wyjścia. Projekty oprogramowania są trudne do oszacowania, dopóki nie poznamy więcej szczegółów, co dzieje się później w projekcie. Ponadto zmieniające się wymagania również zmienią szacunki. Twoje wstępne szacunki na początku projektu będą miały dużą zmienność.

Być może zainteresują Cię także inne techniki szacowania. Wspomniałeś, że jesteś tylko młodszym programistą. Ogólnie rzecz biorąc, bardziej doświadczeni programiści mają lepszą zdolność do oszacowania, ponieważ widzieli więcej problemów, rozwiązali je i (miejmy nadzieję) śledzili oszacowanie w stosunku do rzeczywistego czasu. Możesz to wykorzystać, korzystając z technik szacowania, takich jak szerokopasmowe delphi lub planowanie pokera .

Jako młodszy programista zacznij śledzić prognozy i aktualny czas. Być może zainteresuje Cię lektura dotycząca procesu tworzenia oprogramowania osobistego opracowanego w Software Engineering Institute. Najważniejsze książki o PSP to Dyscyplina inżynierii oprogramowania , PSP: Proces samodoskonalenia dla inżynierów oprogramowania oraz Wprowadzenie do osobistego procesu oprogramowania . Uważam, że wprowadzenie do procesu tworzenia oprogramowania osobistego obejmowałoby tematy, które byłyby dla Ciebie najbardziej pomocne. Myślę, że dla większości programistów jest to nadmierna umiejętność, ale ma kilka dobrych pomysłów i dobrych praktyk, które można wyciągnąć i zastosować w celu poprawy osobistej produktywności i doskonalenia różnych umiejętności (w tym szacowania), które będziesz stale wykorzystywać w trakcie swojej kariery.

Jeśli będziecie wykonywać znacznie więcej pracy w zakresie szacowania, gorąco polecam dwie książki Steve'a McConnella: Szacowanie oprogramowania: Demystifying the Black Art (koncentruje się na szacowaniu jako sztuce i nauce) i Rapid Development: Taming Wild Software Schedules (ogólne oprogramowanie procesy inżynieryjne i zarządzanie projektami).

Thomas Owens
źródło
7

Zobacz literaturę. Istnieje ogromny stos złożonych i często sprzecznych materiałów, które, jak udowodniono w praktyce (eksperymenty), nie działają zgodnie z oczekiwaniami. Przynajmniej akademików kołysze stos książek.

Musisz przeczytać: http://en.wikipedia.org/wiki/The_Mythical_Man-Month

The Mythical Man-Month: Essays on Software Engineering to książka o inżynierii oprogramowania i zarządzaniu projektami autorstwa Freda Brooksa, której tematem przewodnim jest to, że „dodanie siły roboczej do późnego projektu oprogramowania czyni go później”. Pomysł ten jest znany jako prawo Brooksa i jest prezentowany wraz z efektem drugiego systemu i poparciem prototypowania.

Obserwacje Brooksa oparte są na jego doświadczeniach w IBM podczas zarządzania rozwojem OS / 360. Dodał więcej programistów do projektu, który nie nadąża za harmonogramem, co później, przeciw intuicyjnie, uzna, że ​​opóźnił projekt jeszcze bardziej. Popełnił także błąd, twierdząc, że jeden projekt - napisanie kompilatora ALGOL - wymagałby sześciu miesięcy, niezależnie od liczby zaangażowanych pracowników (wymagało to dłużej). Tendencja kierowników do powtarzania takich błędów w rozwoju projektu skłoniła Brooksa do stwierdzenia, że ​​jego książka nazywa się „Biblią inżynierii oprogramowania”, ponieważ „wszyscy ją cytują, niektórzy ją czytają, a niektórzy ją przechodzą”. Książka jest powszechnie uważana za klasyk na temat ludzkich elementów inżynierii oprogramowania ...

Jürgen Strobel
źródło
2

Dowiedz się, co planują zrobić z tym oszacowaniem. Ich zdaniem chcą wiedzieć, czy zajmie to miesiące, czy lata, a ty starasz się znaleźć dokładne godziny (typowy inżynier).

Sprawdź, czy możesz popracować nad projektem, a następnie w razie potrzeby przygotuj lepsze oszacowanie.

Jeśli nadal będą naciskać, będziesz zmuszony wyszczególnić jak najwięcej zadań, jak możesz zastosować ramy czasowe. Powiedz im, że poinformujesz ich, gdy tylko zobaczysz coś, co może wpłynąć na oszacowanie i dokona korekt. Ludzie zwykle starają się unikać niespodzianek.

JeffO
źródło
1

Spotkałem ludzi, którzy twierdzą, że potrafią oszacować oprogramowanie, ale nie wiem, jak to robią. Żadne z nich nie było w stanie wyjaśnić, jak to robią.

Jako konsultanci moi klienci często wymagają ode mnie pracy na podstawie stałej oferty. Dlatego muszę oszacować, aby przygotować realistyczną ofertę. Nigdy temu mi się nie udało. Można by pomyśleć, że licytowałbym tak często, jak underbid, ale nigdy tak nie jest. Powoduje to, że często tracę dużo pieniędzy na moich umowach i w końcu zarabiam o wiele mniej, niż gdybym pracował dla firmy jako stały pracownik.

Przez wiele lat szukałem książki, która nauczyłaby mnie szacowania oprogramowania, ale jeszcze go nie znalazłem.

Co do wyjaśnienia tego komuś, kto nie jest programistą. Można zauważyć, że nikt w branży nie jest w stanie sprostać ich szacunkom. Dzieje się tak przez cały czas, gdy nowe produkty oprogramowania są zapowiadane, ale wysyłane są miesiące lub lata po pierwotnie ogłoszonym terminie.

Jeśli duża firma, taka jak Microsoft, nie jest w stanie dowiedzieć się, jak oszacować czas poświęcony na produkcję własnych produktów, jak mogę to zrobić?

Bez względu na to, czy otrzymuję wynagrodzenie za godzinę, czy za pracę, moi klienci zawsze oczekują ode mnie tych szacunków. Nie wiem, jak oczekują ode mnie, że takie oszacowanie nigdzie się nie uczy i nie mam racjonalnych podstaw do tych szacunków.

Mike Crawford
źródło
1
Książka Steve McConnell Software Estimation: Demystifying the Black Art naprawdę dobrze wyjaśnia, jak oceniają inżynierowie oprogramowania. Możesz nauczyć się technik i narzędzi, ale jedynym sposobem, aby stać się dobrym w szacowaniu, jest ciągłe szacowanie, wyciąganie wniosków z oszacowań i powtarzanie. Ponieważ nikt nie jest w stanie sprostać szacunkom, istnieją organizacje, które konsekwentnie osiągają kilka punktów procentowych w swoich szacunkach - książka McConnella mówi o organizacjach (często CMMI Poziom 4 lub 5, z ciągłą poprawą i szczegółowym śledzeniem), które to osiągają konsekwentnie.
Thomas Owens
Jeśli chodzi o twój problem ze złymi szacunkami. Czy śledzisz swoje szacunki w porównaniu z faktycznym czasem do ukończenia? Jeśli tak, określ, jakiego czynnika nie doceniasz, i pomnóż wszystkie swoje szacunki przez tę liczbę.
kubi
0

Szacowanie czasu całego projektu jest zwykle wykonywane przez kierownika projektu, a nie programistę.

Możesz zbudować argument na podstawie faktu, że kierownik projektu ma pełną listę wymaganych zadań. Bez tej listy wszelkie oszacowania byłyby „złym” przypuszczeniem.

Czas zależy również od wielu czynników, takich jak liczba dostępnych osób i zakres wymagań, o których nie mówiłeś, że masz. Sama architektura nie wystarczy.

Bez szans
źródło
W zależności od metodologii zarządzania projektem szef może nie mieć nawet pełnej listy zadań. W czymś takim jak zarządzanie projektami typu „wave wave” często występuje mglisty przedział opisujący bardzo wysoki poziom zadania, który jest na ogół zbyt duży, aby można go było oszacować przy jakimkolwiek przyzwoitym poziomie ufności. Ponieważ poprzednie zadania zostały zakończone, część zadań z tego segmentu jest lepiej zdefiniowana i można ją oszacować. W metodach zwinnych zadania są często dodawane, usuwane lub zmieniane według priorytetów w różnych punktach, co jeszcze bardziej utrudnia oszacowanie długoterminowych kamieni milowych poza kilkoma iteracjami.
Thomas Owens
0

Inną kwestią, którą możesz powiedzieć, jest to, że inżynieria oprogramowania jest wciąż w powijakach w porównaniu do innych dziedzin inżynierii i nie jest wystarczająco dojrzała, aby pojawiły się szacunkowe techniki programistyczne.

Inżynieria oprogramowania również podlega ciągłym zmianom. Do czasu, gdy technologia jest na tyle duża, że ​​można ją uznać za dojrzałą, często jest porzucana na rzecz jakiejś nowej technologii. Uniemożliwia to zdobycie wystarczającego doświadczenia w zakresie dowolnej technologii, aby móc uzyskać wiarygodne szacunki.

Porównaj to z oszacowaniem budowy. To bardzo dobrze rozumiany problem, nie tylko dlatego, że kontrakty są przyznawane na podstawie ofert, ale także dlatego, że ludzkość buduje rzeczy od zarania cywilizacji.

Mike Crawford
źródło
1
Inżynieria oprogramowania jest wciąż (zdecydowanie) młodsza niż większość innych dziedzin inżynierii w wieku 42 lat. Istnieje jednak wiele dojrzałych technik i narzędzi oceny. Wideband delphi (opracowany w latach 70., popularny przez Barry Boehm's Software Engineering Economics w 1981 r.), Punkty funkcyjne (1979 r.), SEER-SEM (korzenie w latach 60. XX wieku), oszacowanie oparte na proxy (używane w PSP, opracowane w 1994 r. W SEI) oraz COCOMO (1981) i COCOMO II (1997). W dziedzinie, która trwa tylko 42 lata, szacuje się projekty na prawie 40 lat.
Thomas Owens