Mityczny miesiąc osobowy

Mityczny miesiąc osobowy
	Pierwsza edycja
Autor	Freda Brooksa
Kraj	Stany Zjednoczone
Język	język angielski
Temat	Zarządzanie projektami oprogramowania
Wydawca	Addison-Wesley
Data publikacji	1975
ISBN	978-0-201-00650-6 (wyd. 1975), 978-0-201-83595-3 (wyd. 1995)
Ułamek dziesiętny Deweya	001.6/425
Klasa LC	QA76.6 .B75

The Mythical Man-Month: Essays on Software Engineering to książka Freda Brooksa o inżynierii oprogramowania i zarządzaniu projektami , opublikowana po raz pierwszy w 1975 r., A kolejne wydania w 1982 i 1995 r. Jej głównym tematem jest dodanie siły roboczej do opóźnionego projektu oprogramowania opóźnia to jeszcze dłużej. Pomysł ten jest znany jako prawo Brooksa i jest przedstawiony wraz z efektem drugiego systemu i poparciem prototypowania .

Obserwacje Brooksa opierają się na jego doświadczeniach w IBM podczas zarządzania rozwojem OS/360 . Dodał więcej programistów do opóźniającego się projektu, a decyzja, którą później podjął, wbrew intuicji jeszcze bardziej opóźniła projekt. Popełnił również błąd, twierdząc, że jeden projekt dotyczył napisania kompilatora ALGOL — wymagałoby sześciu miesięcy, niezależnie od liczby zaangażowanych pracowników (wymagało to dłużej). Skłonność menedżerów do powtarzania takich błędów podczas opracowywania projektów skłoniła Brooksa do zażartowania, że jego książka nosi tytuł „Biblia inżynierii oprogramowania”, ponieważ „wszyscy ją cytują, niektórzy ją czytają, a kilka osób się nią kieruje”.

Wydania

Praca została po raz pierwszy opublikowana w 1975 r. ( ISBN 0-201-00650-2 ), przedrukowana z poprawkami w 1982 r. I ponownie opublikowana w rocznicowym wydaniu z czterema dodatkowymi rozdziałami w 1995 r. ( ISBN 0-201-83595-9 ), w tym przedruk eseju „ No Silver Bullet ” z komentarzem autora.

Przedstawione pomysły

Mityczny ludzki miesiąc

Brooks omawia kilka przyczyn niepowodzeń w planowaniu. Najtrwalsze jest jego omówienie prawa Brooksa : dodanie siły roboczej do późnego projektu oprogramowania sprawia, że jest on późniejszy . Osobo-miesiąc to hipotetyczna jednostka pracy reprezentująca pracę wykonaną przez jedną osobę w ciągu jednego miesiąca; Prawo Brooksa mówi, że możliwość mierzenia użytecznej pracy w osobo-miesiącach jest mitem i dlatego jest centralnym punktem książki.

Złożonych projektów programistycznych nie można idealnie podzielić na oddzielne zadania, nad którymi można pracować bez komunikacji między pracownikami i bez ustanowienia zestawu złożonych wzajemnych relacji między zadaniami a pracownikami je wykonującymi.

Dlatego przypisanie większej liczby programistów do opóźniającego się projektu sprawi, że będzie on jeszcze późniejszy. Dzieje się tak dlatego, że czas potrzebny nowym programistom na zapoznanie się z projektem i zwiększone koszty komunikacji pochłaniają coraz większą ilość dostępnego czasu kalendarzowego. Kiedy n osób musi się ze sobą komunikować, wraz ze wzrostem n ich wydajność maleje, a kiedy staje się ujemna, projekt jest dalej opóźniany z każdą dodaną osobą.

Formuła komunikacji grupowej: n ( n - 1)/2.
Przykład: 50 programistów daje 50 × (50 – 1)/2 = 1225 kanałów komunikacji.

Żadna srebrna kula

Brooks dodał rozdział „No Silver Bullet — Essence and Accidents in Software Engineering” oraz dalsze refleksje na ten temat w rozdziale „No Silver Bullet' Refired” do jubileuszowego wydania The Mythical Man-Month .

Brooks podkreśla, że nie ma jednego złotego środka : „nie ma jednego rozwoju, ani w technologii, ani w technice zarządzania, który sam w sobie obiecuje nawet jeden rząd wielkości [dziesięciokrotnej] poprawy w ciągu dekady pod względem produktywności, niezawodności, prostoty”.

Argument opiera się na rozróżnieniu między przypadkową złożonością a istotną złożonością, podobnie jak prawo Amdahla opiera się na rozróżnieniu między „paralelizowalnymi” a „ściśle szeregowymi”.

Efekt drugiego systemu

Efekt drugiego systemu sugeruje, że kiedy architekt projektuje drugi system, jest to najbardziej niebezpieczny system, jaki kiedykolwiek zaprojektuje, ponieważ będzie miał tendencję do włączania wszystkich dodatków, których pierwotnie nie dodał do pierwszego systemu ze względu na nieodłączny czas ograniczenia. Tak więc, rozpoczynając pracę nad drugim systemem, inżynier powinien pamiętać, że jest podatny na przeinżynierowanie go.

Tendencja do nieredukowalnej liczby błędów

Autor zauważa, że w odpowiednio złożonym systemie występuje pewna nieredukowalna liczba błędów. Każda próba naprawienia zaobserwowanych błędów zwykle skutkuje wprowadzeniem innych błędów.

Śledzenie postępów

Brooks napisał: „Pytanie: W jaki sposób duży projekt oprogramowania spóźnia się o rok? Odpowiedź: Jeden dzień na raz!” Stopniowe poślizgi na wielu frontach ostatecznie kumulują się, powodując duże ogólne opóźnienie. Na każdym poziomie zarządzania wymagane jest ciągłe zwracanie uwagi na osiąganie małych, indywidualnych kamieni milowych.

Integralność koncepcyjna

Aby system był przyjazny dla użytkownika, system musi mieć integralność koncepcyjną, co można osiągnąć jedynie poprzez oddzielenie architektury od implementacji. Pojedynczy główny architekt (lub niewielka liczba architektów), działając w imieniu użytkownika, decyduje, co ma wejść do systemu, a co nie. Architekt lub zespół architektów powinien opracować pomysł, co system powinien robić i upewnić się, że ta wizja jest zrozumiała dla reszty zespołu. Nowatorski pomysł kogoś może nie zostać uwzględniony, jeśli nie pasuje bezproblemowo do ogólnego projektu systemu. W rzeczywistości, aby zapewnić system przyjazny dla użytkownika, system może celowo udostępniać mniej funkcje, niż jest w stanie. Chodzi o to, że jeśli system jest zbyt skomplikowany w użyciu, wiele funkcji nie będzie używanych, ponieważ nikt nie ma czasu, aby się ich nauczyć.

Instrukcja

Główny architekt tworzy podręcznik specyfikacji systemu. Powinien szczegółowo opisywać zewnętrzną specyfikację systemu, czyli wszystko, co widzi użytkownik. Podręcznik powinien być zmieniany w miarę napływania informacji zwrotnych od zespołów wdrożeniowych i użytkowników.

System pilotażowy

Projektując nowy rodzaj systemu, zespół zaprojektuje system do wyrzucenia (niezależnie od tego, czy zamierza, czy nie). Ten system działa jak „plan pilotażowy”, który ujawnia techniki, które następnie spowodują całkowite przeprojektowanie systemu. Ten drugi, inteligentniejszy system powinien być dostarczony klientowi, ponieważ dostarczenie systemu pilotażowego spowodowałoby u klienta jedynie udrękę i prawdopodobnie zrujnowałoby reputację systemu, a może nawet firmę.

Dokumenty formalne

Każdy kierownik projektu powinien stworzyć mały podstawowy zestaw formalnych dokumentów określających cele projektu, sposób ich osiągnięcia, kto ma je osiągnąć, kiedy mają zostać osiągnięte i ile będą kosztować. Dokumenty te mogą również ujawniać niespójności, które w innym przypadku są trudne do zauważenia.

Szacowanie projektu

Szacując czas trwania projektu, należy pamiętać, że zarówno produkty programistyczne (które można sprzedać płacącym klientom), jak i systemy programistyczne są trzy razy trudniejsze do napisania niż proste, niezależne programy wewnętrzne. Należy pamiętać, jaka część tygodnia pracy będzie rzeczywiście poświęcona sprawom technicznym, w przeciwieństwie do zadań administracyjnych lub innych zadań nietechnicznych, takich jak spotkania, a zwłaszcza spotkania „na stojąco” lub „wszystkoręczne”.

Komunikacja

Aby uniknąć katastrofy, wszystkie zespoły pracujące nad projektem powinny pozostawać ze sobą w kontakcie na jak najwięcej sposobów (e-mail, telefon, spotkania, notatki itp.). Zamiast zakładać coś, osoby wdrażające powinny poprosić architekta (architektów) o wyjaśnienie ich zamiarów dotyczących implementowanej funkcji, zanim przystąpią do założenia, które równie dobrze może być całkowicie błędne. Architekci są odpowiedzialni za sformułowanie grupowego obrazu projektu i przekazanie go innym.

Zespół chirurgiczny

Ponieważ zespół chirurgów podczas operacji jest kierowany przez jednego chirurga wykonującego najbardziej krytyczną pracę, kierując zespół do pomocy przy mniej krytycznych częściach, wydaje się rozsądne, aby „dobry” programista opracowuje krytyczne komponenty systemu, podczas gdy reszta zespołu zapewnia co jest potrzebne we właściwym czasie. Ponadto Brooks zastanawia się, że „dobrzy” programiści są na ogół od pięciu do dziesięciu razy bardziej produktywni niż ci przeciętni.

Zamrożenie kodu i wersjonowanie systemu

Oprogramowanie jest niewidoczne. Dlatego wiele rzeczy staje się oczywistych dopiero po wykonaniu określonej pracy nad nowym systemem, co pozwala użytkownikowi tego doświadczyć. To doświadczenie przyniesie wgląd, który zmieni potrzeby użytkownika lub postrzeganie potrzeb użytkownika. Należy zatem zmienić system tak, aby spełniał zmienione wymagania użytkownika. Może to nastąpić tylko do pewnego momentu, w przeciwnym razie system może nigdy nie zostać ukończony. W określonym dniu nie należy zezwalać na więcej zmian w systemie, a kod powinien zostać zamrożony. Wszelkie prośby o zmiany należy odłożyć do następnej wersji systemu.

Narzędzia specjalistyczne

Zamiast posiadania przez każdego programistę własnego specjalnego zestawu narzędzi, każdy zespół powinien mieć wyznaczonego twórcę narzędzi, który może tworzyć narzędzia wysoce dostosowane do pracy wykonywanej przez zespół (np. narzędzie do generowania kodu, które tworzy kod na podstawie specyfikacji) . Ponadto narzędzia ogólnosystemowe powinny być budowane przez wspólny zespół narzędziowy, nadzorowany przez kierownika projektu.

Obniżenie kosztów tworzenia oprogramowania

Istnieją dwie techniki obniżania kosztów tworzenia oprogramowania, o których pisze Brooks:

Wdrożeniowców można zatrudnić dopiero po ukończeniu architektury systemu (co może zająć kilka miesięcy, w czasie których przedwcześnie zatrudnieni wdrożeniowcy mogą nie mieć nic do roboty).
Inną techniką, o której wspomina Brooks, nie jest w ogóle tworzenie oprogramowania, ale po prostu kupowanie go „ z półki ”, jeśli to możliwe.

Zobacz też

Bibliografia

Brooks, Frederick P. (1975). Mityczny miesiąc osobowy . Addison-Wesley. ISBN 0-201-00650-2 .
Brooks, Frederick P. (1983). „Mityczny miesiąc osobowy” . Magazyn PC . 2 (4): 210–240.
Brooks, Frederick P. (1995). „Rozdział 17.„ Bez srebrnej kuli ”odnowiony” . The Mythical Man-Month (wyd. Rocznicowa). Addison-Wesley. ISBN 0-201-83595-9 .

Linki zewnętrzne