Dlaczego harmonogramy oprogramowania są tak trudne do zdefiniowania?

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?

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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