Jak napięte terminy i presja harmonogramu wpływają na całkowity koszt posiadania i czas dostawy?

Ojciec przyjaciela, który jest menedżerem ds. Inżynierii oprogramowania, powiedział z naciskiem: „Najważniejszą przyczyną przekroczeń harmonogramu jest presja planowania”.

Gdzie znajdują się badania? Czy umiarkowana presja związana z planowaniem jest ożywcza, czy też menedżer, o którym wspomniałem, jest dobry, czy nie, czy też jest to kwestia „im więcej masz presji związanej z planowaniem, tym dłuższy jest czas dostawy i więcej TCO?” Czy to jedna z tych rzeczy, w których idealnie działałaby inżynieria oprogramowania bez presji planowania, ale praktycznie musimy pracować z ograniczeniami rzeczywistych sytuacji?

Doceniamy wszelkie linki do literatury inżynierii oprogramowania.

Główną przyczyną przekroczeń harmonogramu jest presja planowania.

Nie zgadzam się. Główną przyczyną przekroczenia harmonogramu jest harmonogram, który nie odzwierciedla rzeczywistości i jest zbyt optymistyczny. Natura ludzka dyktuje, że jakaś presja planowania jest absolutną koniecznością. Tylko kilka problemów, które powstają bez pewnej presji związanej z planowaniem, są interesującymi problemami i „najlepszy jest wróg wystarczająco dobry”. My, specjaliści techniczni, zdecydowanie wolelibyśmy pracować nad problemami, które nas interesują, niż nad problemem, który należy rozwiązać, aby wyciągnąć produkt z domu. Zabierz terminy (inaczej presję harmonogramu), a my zajmiemy się tymi interesującymi problemami, ze szkodą dla produktu.

Innym problemem jest to, że produkt musi być „wystarczająco dobry”. To nie musi być idealne. Inżynierowie i naukowcy dostrzegają upraszczające założenia, które nie są całkiem aktualne w niektórych szczególnych przypadkach. Projektanci graficzni widzą problemy z aliasingiem, które są niewidoczne dla wszystkich innych. Programiści widzą brodawki w swoich architekturach, które mają zerowy wpływ na zachowanie produktu. „Najlepszy jest wróg wystarczająco dobrego”, co oznacza, że ​​czasami musimy żyć z tymi problemami, które tak naprawdę nie są problemami.

Brak presji związanej z planowaniem doprowadzi do powstania produktu o bardzo wysokich kosztach posiadania. Przyczyną przekroczeń są złe harmonogramy. Może to przybierać różne formy. Niezbędne jest niedocenianie wysiłku, nieuwzględnianie zależności, dodawanie ludzi do już spóźnionego projektu. Żeby wymienić tylko kilka.

Czas, jakość, zasoby i liczba funkcji są ze sobą powiązane. Możesz naprawić dowolne trzy z nich, a ostatnią otrzymasz jako wynik procesu planowania.

Sposób sformułowania pytania oznacza, że ​​czas jest zmienną, a pozostałe trzy (jakość, zasoby i liczba funkcji) są ustalone. Pytanie może zyskać na nieznacznej zmianie perspektywy poprzez ustalenie czasu ^* i pozostawienie jakości.

Teraz twoje pytanie brzmi: „Czy ograniczenia czasowe negatywnie wpływają na jakość”? Odpowiedź na to pytanie brzmi: „Tak”: badania potwierdzają, że ludzie czują się gorzej pod presją problemów matematycznych ^** , których wcześniej nie ćwiczyli intensywnie (tj. Próbowali pięćdziesiąt lub więcej razy), więc ojciec twojego przyjaciela ma rację.

^** Istnieje tutaj dorozumiane założenie, że programowanie jest podobne do robienia matematyki; Myślę, że to założenie jest uczciwe.

im większa presja na planowanie, tym dłuższy czas dostawy i wyższy całkowity koszt posiadania?

Cóż, wszelkie harmonogramy wykonywane przez kierownika bez omawiania go z potencjalnym klientem są na to podatne. Jest bardzo oczywistą prawdą, że planowanie lub szacunki, które NIE są oparte na faktach, są podatne na niepowodzenia .

Ponadto menedżerowie, którzy unikają planowania opartego na dowodach, również zmierzają w kierunku kolejnego niepowodzenia swojego projektu. Istnieje wiele badań na ten temat, a planowanie oparte na metrykach jest właściwym sposobem postępowania.

Planowanie od prawej do lewej.

Ktoś z kierownictwa zawsze myśli, że to Steve Jobs ze swoją słynną strefą zniekształcania rzeczywistości. Dopóki ktoś z działu rozwoju produktu ich nie edukuje, menedżerowie nietechniczni często mogą mieć zdanie na temat planowania, które jest tak wyrafinowane, jak wczesny francuski film „Le voyage dans la lune” („Podróż na Księżyc”) był przeznaczony do nauki o rakietach.

Problem istnieje już od jakiegoś czasu. Fred Brooks opowiada o szacunkowej ocenie w Mythical Man-Month . Barry Boehm mówi o tym w swoich propozycjach teoretycznego podejścia do zarządzania. Niedawno Steve McConnell (autor Code Complete ) skupia się na koncepcji pryncypialnych kwestii negocjacyjnych w „How To Defend a Unpopular Schedule” .

Zwinne przesuwa zakres projektów w miejsce, w którym jest bardzo widoczny. Agile Manifesto wzywa do „współpracy z klientem ponad negocjowanie kontraktu”. Mam również nadzieję, że wzmocni to ludzi, którzy są pociągnięci do odpowiedzialności. W grze planistycznej unika się nietechnicznych interesariuszy zmuszających deweloperów do obietnic złożonych dawno temu, które zostały przekroczone przez zmiany wymagań lub nowe odkrycia.

Jeśli Twoja organizacja odrzuca zwinność, istnieją świetne metody związane z kalibracją szacunków w celu zmiany harmonogramu na podstawie uzyskanej wartości . Nie sądzę, aby wartość zarobiona świetnie sobie radziła z niektórymi prawdziwymi problemami z prognozowaniem, ale może pomóc w rozwiewaniu złudzeń co do szybkości projektów i oparcia się na szacunkach, które jakoś są faktami.

Jest takie powiedzenie, że im szybciej zaczniesz kodować, tym dłużej to zajmie. Nacisk na harmonogram może spowodować wymuszenie zmiany metodologii. Czasami jest to od wodospadu po „kod jak diabli”. Może to mieć negatywny wpływ na jakość, nie mówiąc już o morale, gdy pracownicy nie mogą dać z siebie wszystko, a ich rówieśnicy i przyszli opiekunowie widzą ich w najgorszym, a nie najlepszym. W środowisku takim jak ten pewien stopień chaosu można kontrolować za pomocą kontroli źródła, codziennej kompilacji i testów (lub ciągłej integracji i testów jednostkowych), przeglądów kodu, przy użyciu doświadczonego i wysoce wykwalifikowanego zespołu, opierając się pokusie dodania personelu do późna projekt i stary tryb gotowości, nadgodziny.

Innym razem zmiana metodologii może być z wodospadu na iteracyjny przyrostowy. Z mojego doświadczenia wynika, że ​​zarządzanie zwlekało z przyjęciem Agile. Ale po pewnym czasie pojawiło się nowe kierownictwo, które bardziej wspiera Agile. Boks czasowy może przypominać budżetowanie - może zmusić nas do myślenia o najlepszym wykorzystaniu ograniczonego zasobu. Scrum ma dwa przedziały czasowe - jedno dziennie na informacje zwrotne między członkami zespołu, drugie co miesiąc na sprint poprzez listę wypalenia.

Licencja Creative Commons - patrz http://en.wikipedia.org/wiki/File:Scrum_process.svg

Nie potrzebujesz literatury inżynierii oprogramowania. Koncepcyjne prawdopodobieństwo i statystyki z licencjata to wszystko czego potrzebujesz.

Szacunek jest po prostu szacunkiem. To nie jest dokładne, nie jest gwarantowane. Dla każdego oszacowania istnieje pewne prawdopodobieństwo, że go przejedziesz lub uderzysz go w nos, oraz pewne prawdopodobieństwo, że go przekroczysz.

Prawdopodobieństwo 101: p (niedokończenie lub trafienie dokładnie) + p (przekroczenie) = 100%.

Harmonogram oparty na oszacowaniu ma dokładnie te same cechy.

Nie można całkowicie wyeliminować niepewności. ZAWSZE będzie pewne prawdopodobieństwo przekroczenia. Może to być małe, prawdopodobieństwo, że Iran zniszczy Twój budynek biurowy, ale nadal tam jest. Najlepsze, co możesz zrobić, to spojrzeć na WSZYSTKO i zmniejszyć niepewność tak bardzo, jak tylko możesz. Gdy to zrobisz, jeśli będziesz miał szczęście, będziesz miał harmonogram z małą niepewnością i 50% prawdopodobieństwem z każdej strony.

Pomyśl o tym: jeśli wprowadzisz harmonogram, prawdopodobieństwo, że zostaniesz przekroczony lub dokładnie dotrzymasz harmonogramu, maleje. Suma wciąż musi sumować się do 100%. Dokąd zmierza to prawdopodobieństwo? Odpowiedź, wchodzi w prawdopodobieństwo przekroczenia.

General Dynamics / Fort Worth Division nauczył się tego na własnej skórze. Dokonali wstępnej oceny rozwoju F-16C / D i wysłali go do łańcucha pokarmowego. Ktoś wyżej arbitralnie wyciął z tego rok i wysłał to do Sił Powietrznych. W rezultacie GD / FW spóźniło się o rok z próbą w locie, a siły powietrzne NIE były zadowolone. (Należy pamiętać, że „opóźnienie o jeden rok” było zgodne ze zmienionym harmonogramem, co oznacza, że ​​pierwotny harmonogram był PRAWO NA CELU).

Myślę, że pewna presja w projekcie jest OK, ponieważ pomaga utrzymać koncentrację.

Jeśli jednak presja nie jest realistyczna lub jeśli komunikacja między kierownictwem a pracownikami technicznymi nie działa prawidłowo, tak, istnieje ryzyko, że planowanie presji spowoduje złą jakość i / lub opóźnione dostawy.

Doświadczony programista będzie wiedział, że nie oczekuje się, że stworzy idealne rozwiązanie, ale raczej takie rozwiązanie wystarczająco dobre . Tak więc szacunek podany przez takiego programistę będzie już odzwierciedlał ich zrozumienie tego, co jest wystarczająco dobre dla konkretnego projektu.

Istnieje wiele czynników, które wpływają na definicję wystarczająco dobrego.

Na przykład, ile miesięcy trwa projekt? Jeśli projekt trwa jeden rok, możesz napisać prototyp tego szczególnie trudnego modułu dość szybko na początku projektu, a następnie masz kilka miesięcy na przetestowanie i debugowanie go jako działania pobocznego do opracowania innych, bardziej rutynowych modułów. (Możesz pozwolić temu modułowi dojrzewać przez kilka miesięcy, aż będzie wystarczająco dobry więc nie musisz próbować go robić od samego początku.) Uważam tę strategię za bardzo skuteczną, ale potrzebujesz menedżera, który ci ufa i pozwoli ci utrzymuj projekt otwarty przez miesiące. Inny (nieufny) menedżer może zmusić cię do ukończenia tego modułu tak szybko, jak to możliwe (bez względu na to, czy będziesz musiał go naprawić później i czy takie podejście ostatecznie będzie kosztowało znacznie więcej czasu).

Kolejny przykład: projekt dotyczy produktu, który będzie miał tylko jedną wersję. Następnie możesz spróbować zrobić to szybko i polegać na szeroko zakrojonych testach, aby upewnić się, że produkt działa zgodnie z oczekiwaniami (szybki i brudny jest wystarczająco dobry ). Z drugiej strony, jeśli produkt będzie miał dwie lub trzy wersje, lepiej poświęć trochę czasu na jego zaprojektowanie, aby uniknąć obszernego przepisywania kodu dla późniejszych wersji. (W tym przypadku szybkie i brudne nie są wystarczająco dobre, ponieważ całkowity czas programowania w trzech wydaniach jest dłuższy.)

Podsumowując, uważam, że zła komunikacja między kierownictwem a pracownikami technicznymi oraz brak powszechnego zrozumienia tego, co jest wystarczająco dobre dla danego projektu, może prowadzić do nadmiernej presji planowania, co prowadzi do złej jakości / opóźnionej dostawy.

Nigdy nie ma wystarczająco dużo czasu, aby zrobić to poprawnie za pierwszym razem, ale zawsze jest wystarczająco dużo czasu, aby to naprawić później.