| Mytisk man-måned | |
|---|---|
| Den mytiske man-måned | |
| Forfatter | Frederic Brooks |
| Originalsprog | engelsk |
| Original udgivet | 1975 |
| Forlægger | Addison-Wesley |
| ISBN | ISBN 0201835959 |
| Næste | Der er ingen sølvkugle |
The Mythical Man-Month: Essays on Software Engineering er en bog om softwareprojektledelse af Frederick Brooks .
Faktisk er Brooks' bog en samling essays, der sekventielt diskuterer nøgleproblemerne ved at udvikle store softwareprojekter: at øge programmørernes produktivitet, organisere teamwork, planlægge og implementere en implementeringsplan. Et af bogens hovedtemaer var ideen, senere kaldet "Brooks' lov", om at indførelsen af nye kræfter i projektet på de senere udviklingsstadier kun udskyder deadline for projektet [1] .
Det engelsksprogede magasin PC World placerede Brooks' bog som nummer et på sin liste over " Top ti it-bøger, som aldrig skal indrømme, at du ikke har læst " [2] . Ifølge en undersøgelse blandt flere tusinde medlemmer af Stack Overflow -fællesskabet er bogen en af de ti mest indflydelsesrige programmeringsbøger nogensinde [3] . Brooks' bog er beskrevet på Association for Computing Machinery Librarys hjemmeside som følger: "Meget få bøger om softwareprojektledelse er blevet så indflydelsesrige og tidløse" [4] . Ifølge Java World klummeskribent Dustin Marks er The Mythical Man-Month en af de mest berømte bøger i hele softwareudviklingslitteraturen og sandsynligvis den mest berømte bog inden for softwareprojektledelse [5] . Ifølge magasinet Computerra om Brooks' bog, "har det længe været troet i USA, at uden at have læst den, vil ingen softwareudviklingschef være i stand til at handle effektivt" [6] .
Så måske før man går i gang med et nyt softwareprojekt, giver det stadig mening at læse Frederic Brooks?
PC uge [1] .Brooks' observationer er baseret på hans erfaring hos IBM , mens han styrede OS/360 -operativsystemprojektet . For at fremskynde udviklingen gjorde han et mislykket forsøg på at tiltrække flere arbejdere til projektet, hvis deadlines allerede var overskredet. Da Brooks lagde mærke til ledernes evne til at gentage sådanne fejl, kaldte Brooks hånligt sin bog "bibelen for softwareudvikling": "alle har læst den, men ingen følger den!"
Brooks hævdede også, at det ville tage seks måneder at skrive en Algol -sprogkompiler , uanset antallet af personer involveret i projektet.
Bogen udkom første gang i 1975 , i 1979 blev den udgivet på russisk. Jubilæumsudgaven af 1995 (på russisk - 2000 ) indeholder yderligere kapitler: essayet " Der er ingen sølvkugle ", udgivet i 1986 (kapitel 16), en revision af, hvad der blev sagt i dette essay 10 år senere (kapitel 17) og forfatterens kommentarer til sin bog 20 år efter dens første udgave (kapitel 18 og 19).
program og softwareprodukt. Et softwareprodukt er forskelligt fra et program:
Et softwareprodukt kræver 3 gange mere tid end et program (kapitel 1).
Mytisk man-måned. Projektets ledetid er ikke omvendt proportional med antallet af programmører af mindst 2 grunde.
Hvis der er N programmører, så er antallet af par af programmører lig med N ( N - 1) / 2, det vil sige med en stigning i antallet af programmører vokser tiden brugt på interaktion kvadratisk. Derfor, startende fra nogle N, bremser en stigning i antallet af programmører projektet.
Hvis deadlines overskrides, bremser ansættelse af nye programmører projektet af en anden grund: nytilkomne har brug for tid til at lære. Bogen formulerer "Brooks' Law": "Hvis et projekt ikke følger tidsplanen, vil tilføjelse af arbejdskraft forsinke det endnu mere."
Med et meget stort antal programmører bliver projektet måske aldrig færdigt: På grund af generel forvirring genererer forsøg på at rette eksisterende fejl i softwaren nye fejl, så systemet ikke forbedres (kapitel 2).
kirurgiske teams. Det giver mening for udviklingsteamet at have én "god" programmør, der implementerer de mest kritiske dele af systemet, og flere andre, der hjælper ham eller implementerer de mindre kritiske dele. Sådan foregår operationer. Derudover arbejder de bedste programmører ifølge Brooks 5-10 gange hurtigere end resten (kapitel 3).
konceptuel integritet. For at sikre systemets konceptuelle integritet er det nødvendigt at adskille arkitekturen fra implementeringen. Én ledende arkitekt (eller en lille gruppe), der handler i brugerens bedste interesse, beslutter, hvad der skal og ikke skal ind i systemet. En "meget cool" idé kan blive afvist, hvis den foreslåede funktion ikke passer ind i systemets overordnede design. Enkelhed er meget vigtig; det kan være nyttigt kun at implementere en delmængde af de muligheder, som systemet er i stand til, for hvis systemet er for komplekst, vil nogle af dets muligheder forblive ubrugte.
Chefarkitekten bør formulere sine beslutninger i form af en brugervejledning (kapitel 4).
Effekt af det andet system. En programmør, der udvikler sit andet system, har en tendens til at tilføje alle de funktioner, som han ikke kunne tilføje til sit første system (på grund af mangel på tid). Derfor viser det andet system sig ofte at være overbelastet med kapaciteter (kapitel 5).
formelle dokumenter. Hver projektleder bør oprette et lille sæt formelle dokumenter, der beskriver projektets mål, hvordan, af hvem og hvornår de vil blive implementeret, og hvor meget de vil koste. Disse dokumenter kan afsløre uoverensstemmelser, som ellers ville være svære at bemærke.
Hvert udviklingsteam modtager et sæt krav til deres del af systemet, herunder en præcis beskrivelse af dets funktionalitet og maksimale krav til processortid, hukommelse, diskplads mv.
Interaktion. For at afværge katastrofe skal udviklingsteams interagere med hinanden på alle mulige måder. I stedet for at lave antagelser om den funktion, de implementerer, bør bygherren stille arkitekten afklarende spørgsmål, da antagelserne kan vise sig at være helt forkerte. "Antagelse er moderen til fiasko."
pilotsystem. Før et endeligt system kan udvikles, skal der udvikles et pilotsystem. Pilotsystemet vil afsløre designfejl, hvorefter det skal laves helt om (kapitel 11). Brooks afviser denne idé 20 år senere i kapitel 19, da tilgangen til at skabe programmer har ændret sig på 20 år - den iterative udviklingsmodel , der blev vedtaget i 60'erne og 70'erne , har erstattet vandfaldsudviklingsmodellen .
Versionering og frysning af systemet. Efterhånden som systemet bygges, kan brugerens krav til det ændre sig baseret på deres erfaring med det ufærdige system. Disse ønsker fra brugeren bør tages i betragtning, men kun op til et vist punkt, ellers vil arbejdet på systemet aldrig blive afsluttet. Derefter fastfryses specifikationerne, og alle efterfølgende ændringsanmodninger udskydes, indtil arbejdet påbegyndes med den næste version (kapitel 11).
Specialiserede hjælpeprogrammer. I stedet for at hver programmør skriver deres egne hjælpeprogrammer, bør hvert udviklingsteam have en programmør, der er ansvarlig for at skrive hjælpeprogrammer til deres team (for eksempel en kodegenerator, der genererer kode i henhold til en eller anden specifikation). Der bør også være en gruppe, der opretter hjælpeprogrammer til alle, der arbejder på et givet system (kapitel 12).
Reducerede udviklingsomkostninger. Brooks lister 2 måder at reducere omkostningerne ved softwareudvikling på: