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

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ą ?

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

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

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

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.

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.

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.

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.