Mityczny człowiek-miesiąc -The Mythical Man-Month
.jpg) Pierwsza edycja
| |
| Autor | Frederick Brooks |
|---|---|
| Podmiot | Zarządzanie projektami oprogramowania |
| Wydawca | Addison-Wesley |
Data publikacji |
1975 |
| Numer ISBN | 0-201-00650-2 (wyd. 1975), 0-201-83595-9 (wyd. 1995) |
| OCLC | 1201368 |
| 001.6/425 | |
| Klasa LC | QA76.6 .B75 |
| Śledzony przez | „ Nie ma srebrnej kuli ” |
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 roku, z kolejnymi wydaniami w 1982 i 1995. Jej głównym tematem jest to, że „dodanie siły roboczej do późnego projektu oprogramowania sprawia, że później." Ta idea jest znana jako prawo Brooksa i jest przedstawiana 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 projektu opóźnionego w harmonogramie, a decyzja, o której później stwierdził, wbrew intuicji, opóźniła projekt jeszcze bardziej. Popełnił również błąd, twierdząc, że jeden projekt – związany z napisaniem kompilatora ALGOL – wymagałby sześciu miesięcy, niezależnie od liczby zaangażowanych pracowników (wymagał więcej). Tendencja menedżerów do powtarzania takich błędów w rozwoju projektów sprawiła, że Brooks zażartował, że jego książka nosi tytuł „Biblia inżynierii oprogramowania”, ponieważ „każdy ją cytuje, niektórzy ją czytają, a kilka osób ją stosuje”.
Edycje
Praca została po raz pierwszy opublikowana w 1975 ( ISBN 0-201-00650-2 ), przedrukowana z poprawkami w 1982 i ponownie opublikowana w jubileuszowym wydaniu z czterema dodatkowymi rozdziałami w 1995 ( ISBN 0-201-83595-9 ), w tym przedruk eseju „ No Silver Bullet ” z komentarzem autora.
Przedstawione pomysły
Mityczny człowiek-miesiąc
Brooks omawia kilka przyczyn niepowodzeń planowania. Najtrwalsze jest jego omówienie prawa Brooksa : dodanie siły roboczej do spóźnionego projektu oprogramowania sprawia, że jest on późniejszy . Człowiek-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 stanowi centralny punkt książki.
Złożonych projektów programistycznych nie można idealnie podzielić na dyskretne zadania, nad którymi można pracować bez komunikacji między pracownikami i bez ustalenia zestawu złożonych wzajemnych relacji między zadaniami a wykonującymi je pracownikami.
Dlatego przydzielenie większej liczby programistów do opóźnionego projektu sprawi, że będzie to jeszcze później. Dzieje się tak, ponieważ czas potrzebny nowym programistom na zapoznanie się z projektem i zwiększone obciążenie komunikacyjne pochłaniają coraz większą ilość dostępnego czasu kalendarzowego. Gdy n osób musi komunikować się między sobą, gdy rośnie n , ich wydajność spada, a gdy staje się ujemna, projekt jest opóźniany o 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.
Brak srebrnej kuli
Brooks dodał „No Silver Bullet — Essence and Accidents of Software Engineering” — i dalsze refleksje na ten temat — „No Silver Bullet” Refired” — do jubileuszowego wydania The Mythical Man-Month .
Brooks twierdzi, że nie ma jednej srebrnej kuli – „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ęciokrotny] wzrost wydajności, niezawodności i prostoty w ciągu dekady. "
Argument opiera się na rozróżnieniu między przypadkową złożonością a zasadniczą złożonością, podobnie jak prawo Amdahla opiera się na rozróżnieniu między „ściśle seryjnym” a „równoległym”.
Efekt drugiego systemu
Efekt drugiego systemu sugeruje, że kiedy architekt projektuje drugi system, jest to najbardziej niebezpieczny system, jaki kiedykolwiek zaprojektuje, ponieważ będą mieli tendencję do włączania wszystkich dodatków, których pierwotnie nie dodali do pierwszego systemu ze względu na nieodłączny czas ograniczenia. Dlatego, rozpoczynając pracę z drugim systemem, inżynier powinien mieć na uwadze, że jest podatny na jego przeinżynierię.
Tendencja do nieredukowalnej liczby błędów
99 małych błędów w kodzie.
99 małych błędów.
Zdejmij jeden, załataj go.
127 małych błędów w kodzie...
Autor zauważa, że w odpowiednio złożonym systemie istnieje pewna nieredukowalna liczba błędów. Każda próba naprawienia zaobserwowanych błędów prowadzi do wprowadzenia innych błędów.
Śledzenie postępów
Brooks napisał "Pytanie: Jak duży projekt oprogramowania może się spóźnić o rok? Odpowiedź: Jeden dzień na raz!" Narastające poślizgi na wielu frontach w końcu kumulują się, tworząc duże ogólne opóźnienie. Na każdym poziomie zarządzania wymagana jest ciągła uwaga poświęcana realizacji małych, indywidualnych kamieni milowych.
Integralność koncepcyjna
Aby system był przyjazny dla użytkownika, system musi mieć integralność koncepcyjną, którą można osiągnąć jedynie poprzez oddzielenie architektury od implementacji. Pojedynczy główny architekt (lub niewielka liczba architektów), działający w imieniu użytkownika, decyduje o tym, co wchodzi do systemu, a co pozostaje poza systemem. Architekt lub zespół architektów powinien opracować pomysł na to, co system powinien zrobić i upewnić się, że ta wizja jest zrozumiana przez resztę zespołu. Nowatorski pomysł kogoś może nie zostać uwzględniony, jeśli nie pasuje idealnie do ogólnego projektu systemu. W rzeczywistości, aby zapewnić system przyjazny dla użytkownika, system może celowo dostarczać mniej funkcji, niż jest w stanie. Chodzi o to, że jeśli system jest zbyt skomplikowany w użyciu, wiele funkcji pozostanie niewykorzystanych, ponieważ nikt nie ma czasu się ich nauczyć.
Instrukcja
Główny architekt opracowuje podręcznik specyfikacji systemu. Powinna szczegółowo opisywać zewnętrzne specyfikacje 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
Przy projektowaniu nowego rodzaju systemu, zespół będzie zaprojektowanie systemu jednorazowe (czy zamierza lub nie). System ten działa jak „plan pilotażowy”, który ujawnia techniki, które następnie spowodują całkowite przeprojektowanie systemu. Ten drugi, mądrzejszy system powinien zostać dostarczony do klienta, ponieważ dostarczenie systemu pilotażowego spowodowałoby u klienta jedynie agonię i prawdopodobnie zrujnowałoby reputację systemu, a może nawet firmy.
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 je osiągnie, kiedy zostaną osiągnięte i ile będą kosztować. Dokumenty te mogą również ujawniać niespójności, które w inny sposób trudno byłoby dostrzec.
Wycena projektu
Szacując czas realizacji 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 faktycznie poświęcona sprawom technicznym, w przeciwieństwie do zadań administracyjnych lub innych nietechnicznych zadań, takich jak spotkania, a zwłaszcza spotkania „stand-up” lub „z udziałem wszystkich rąk”.
Komunikacja
Aby uniknąć katastrofy, wszystkie zespoły pracujące nad projektem powinny pozostawać w kontakcie ze sobą na jak najwięcej sposobów – e-mail, telefon, spotkania, notatki itp. Zamiast zakładać, realizatorzy powinni poprosić architekta(ów) o wyjaśnij swoje zamiary dotyczące wdrażanej funkcji, zanim przyjmą założenie, które może być całkowicie błędne. Architekt (architekci) są odpowiedzialni za sformułowanie grupowego obrazu projektu i przekazanie go innym.
Zespół chirurgiczny
Podczas gdy zespół chirurgiczny podczas operacji jest kierowany przez jednego chirurga wykonującego najbardziej krytyczną pracę, podczas gdy kieruje zespołem, aby asystował przy mniej krytycznych częściach, wydaje się rozsądne, aby „dobry” programista opracował krytyczne komponenty systemu, podczas gdy reszta zespołu zapewnia co jest potrzebne we właściwym czasie. Dodatkowo Brooks zastanawia się, że „dobrzy” programiści są zazwyczaj od pięciu do dziesięciu razy bardziej produktywni niż przeciętni.
Zamrożenie kodu i wersjonowanie systemu
Oprogramowanie jest niewidoczne. Dlatego wiele rzeczy staje się widocznych dopiero po wykonaniu pewnej ilości pracy w nowym systemie, co pozwala użytkownikowi doświadczyć tego. To doświadczenie przyniesie spostrzeżenia, które zmienią potrzeby użytkownika lub postrzeganie potrzeb użytkownika. System powinien zatem zostać zmieniony, aby spełnić 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 terminie nie należy dopuszczać do 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 każdego programisty, który ma swój własny, specjalny zestaw narzędzi, każdy zespół powinien mieć wyznaczonego producenta narzędzi, który może tworzyć narzędzia wysoce dostosowane do pracy, którą wykonuje zespół, np. narzędzie do generowania kodu, które tworzy kod w oparciu o specyfikację . 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:
- Realizatorzy mogą zostać zatrudnieni dopiero po ukończeniu architektury systemu (krok, który może zająć kilka miesięcy, podczas którego przedwcześnie zatrudnieni realizatorzy mogą nie mieć nic do roboty).
- Inną techniką, o której wspomina Brooks, nie jest wcale tworzenie oprogramowania, ale po prostu kupowanie go „ z półki ”, gdy tylko jest to możliwe.
Zobacz też
- Antywzór
- Refaktoryzacja kodu
- Oprogramowanie dla ludzi: produktywne projekty i zespoły
- Proces tworzenia oprogramowania
- Prawo Hofstadtera
Bibliografia
- — (1975). Mityczny człowiek-miesiąc . Addisona-Wesleya. Numer ISBN 0-201-00650-2.
- Brooks, Frederick P. Jr. (wrzesień 1983). „Mityczny człowiek-miesiąc” . Magazyn PC . 2 (4): 210–240.
- — (1995). „Rozdz. 17”.„Brak srebrnego naboju” wycofany . Miesiąc Mitycznego Człowieka (Edycja Rocznicowa z czterema nowymi rozdziałami wyd.). Addisona-Wesleya. Numer ISBN 0-201-83595-9.