| Mytisk man-månad | |
|---|---|
| Den mytiska man-månaden | |
| Författare | Frederic Brooks |
| Originalspråk | engelsk |
| Original publicerat | 1975 |
| Utgivare | Addison-Wesley |
| ISBN | ISBN 0201835959 |
| Nästa | Det finns ingen silverkula |
The Mythical Man-Month: Essays on Software Engineering är en bok om projektledning av programvara av Frederick Brooks .
Faktum är att Brooks bok är en samling essäer som sekventiellt diskuterar nyckelproblemen med att utveckla stora programvaruprojekt: öka produktiviteten hos programmerare, organisera lagarbete, planera och implementera ett implementeringsschema. Ett av bokens huvudteman var tanken, som senare kallades "Brooks' lag", att införandet av nya krafter i projektet vid senare utvecklingsstadier endast skjuter upp deadline för projektet [1] .
Den engelskspråkiga tidskriften PC World placerade Brooks bok som nummer ett på sin lista över " Tio it-böcker som aldrig medger att du inte har läst " [2] . Enligt en undersökning av flera tusen medlemmar av Stack Overflow -gemenskapen är boken en av de tio mest inflytelserika programmeringsböckerna genom tiderna [3] . Brooks bok beskrivs på Association for Computing Machinery Librarys webbplats enligt följande: "Väldigt få böcker om programvaruprojektledning har blivit lika inflytelserika och tidlösa" [4] . Enligt Java World- krönikören Dustin Marks är The Mythical Man-Month en av de mest kända böckerna i hela mjukvaruutvecklingslitteraturen, och förmodligen den mest kända boken inom mjukvaruprojektledning [5] . Enligt tidskriften Computerra om Brooks bok, "har man länge trott i USA att utan att läsa den kommer ingen programvaruutvecklingschef att kunna agera effektivt" [6] .
Så kanske innan man påbörjar ett nytt programvaruprojekt, är det fortfarande vettigt att läsa Frederick Brooks?
PC-vecka [1] .Brooks observationer är baserade på hans erfarenhet på IBM när han skötte operativsystemet OS/360 -projektet . För att påskynda utvecklingen gjorde han ett misslyckat försök att locka fler arbetare till projektet, vars deadlines redan hade missats. Brooks lade märke till förmågan hos chefer att upprepa sådana misstag och kallade hånfullt sin bok "bibeln för mjukvaruteknik": "alla har läst den, men ingen följer den!"
Brooks hävdade också att det skulle ta sex månader att skriva en Algol- språkkompilator , oavsett antalet personer som är involverade i projektet.
Boken publicerades första gången 1975 , 1979 gavs den ut på ryska. Jubileumsutgåvan 1995 (på ryska - 2000 ) innehåller ytterligare kapitel: uppsatsen " Det finns ingen silverkula ", publicerad 1986 (kapitel 16), en revidering av vad som sades i denna uppsats 10 år senare (kapitel 17) och författarens kommentarer till sin bok 20 år efter dess första upplaga (kapitel 18 och 19).
program och mjukvaruprodukt. En mjukvaruprodukt skiljer sig från ett program:
En mjukvaruprodukt kräver 3 gånger mer tid än ett program (kapitel 1).
Mytisk man-månad. Projektledtiden är inte omvänt proportionell mot antalet programmerare av minst två anledningar.
Om det finns N programmerare är antalet par av programmerare lika med N ( N - 1) / 2, det vill säga med en ökning av antalet programmerare växer tiden som spenderas på interaktion kvadratiskt. Därför, med start från något N, saktar en ökning av antalet programmerare ner projektet.
Om deadlines missas, bromsar anställning av nya programmerare projektet av en annan anledning: nykomlingar behöver tid att lära sig. Boken formulerar "Brooks' Law": "Om ett projekt inte följer schemat, kommer att lägga till arbetskraft försena det ytterligare."
Med ett mycket stort antal programmerare kan projektet aldrig bli färdigt alls: på grund av allmän förvirring genererar försök att fixa befintliga buggar i programvaran nya buggar, så att systemet inte förbättras (kapitel 2).
kirurgiska team. Det är vettigt för utvecklingsteamet att ha en "bra" programmerare som implementerar de mest kritiska delarna av systemet, och flera andra som hjälper honom eller implementerar de mindre kritiska delarna. Det är så operationer görs. Dessutom, enligt Brooks, arbetar de bästa programmerarna 5-10 gånger snabbare än resten (kapitel 3).
konceptuell integritet. För att säkerställa systemets konceptuella integritet är det nödvändigt att separera arkitekturen från implementeringen. En ledande arkitekt (eller en liten grupp), som agerar i användarens bästa, bestämmer vad som ska och inte ska gå in i systemet. En "mycket cool" idé kan förkastas om den föreslagna funktionen inte passar in i systemets övergripande design. Enkelhet är mycket viktigt; det kan vara användbart att implementera endast en delmängd av de funktioner som systemet kan, för om systemet är för komplext kommer en del av dess funktioner att förbli oanvända.
Chefsarkitekten bör formulera sina beslut i form av en bruksanvisning (kapitel 4).
Effekten av det andra systemet. En programmerare som utvecklar sitt andra system tenderar att lägga till alla funktioner som han inte kunde lägga till i sitt första system (på grund av tidsbrist). Därför visar sig det andra systemet ofta vara överbelastat med kapacitet (kapitel 5).
formella dokument. Varje projektledare bör skapa en liten uppsättning formella dokument som beskriver målen för projektet, hur, av vem och när de kommer att genomföras och hur mycket de kommer att kosta. Dessa dokument kan avslöja inkonsekvenser som annars skulle vara svåra att upptäcka.
Varje utvecklingsteam får en uppsättning krav för sin del av systemet, inklusive en exakt beskrivning av dess funktionalitet och maximala krav på processortid, minne, diskutrymme etc.
Samspel. För att undvika katastrofer måste utvecklingsteam interagera med varandra på alla möjliga sätt. Istället för att göra antaganden om vilken funktion de implementerar bör utvecklaren ställa klargörande frågor till arkitekten, eftersom antagandena kan visa sig vara helt felaktiga. "Antagande är misslyckandets moder."
pilotsystem. Innan ett slutgiltigt system kan utvecklas måste ett pilotsystem utvecklas. Pilotsystemet kommer att avslöja konstruktionsfel, varefter det måste göras om helt (kapitel 11). Brooks avvisar denna idé 20 år senare i kapitel 19, eftersom inställningen till att skapa program har förändrats på 20 år - den iterativa utvecklingsmodellen som antogs på 60- och 70-talen har ersatt modellen för vattenfallsutveckling .
Versionering och frysning av systemet. Allt eftersom systemet byggs kan användarens krav på det ändras baserat på deras erfarenhet av det ofärdiga systemet. Dessa önskemål från användaren bör beaktas, men bara upp till en viss punkt, annars kommer arbetet med systemet aldrig att slutföras. Därefter fryses specifikationerna och alla efterföljande ändringsförfrågningar skjuts upp tills arbetet påbörjas med nästa version (kapitel 11).
Specialiserade verktyg. Istället för att varje programmerare skriver sina egna verktyg, bör varje utvecklingsteam ha en programmerare som ansvarar för att skriva verktyg för sitt team (till exempel en kodgenerator som genererar kod enligt någon specifikation). Det bör också finnas en grupp som skapar verktyg för alla som arbetar på ett givet system (kapitel 12).
Minskad utvecklingskostnad. Brooks listar två sätt att minska kostnaderna för mjukvaruutveckling: