Den mytiske man-monthEdit

Brooks diskuterer flere årsaker til planlegging feil. Den mest varige er hans diskusjon Av Brooks ‘ s law: Å Legge arbeidskraft til et sent programvareprosjekt gjør det senere. Man-month er en hypotetisk enhet for arbeid som representerer arbeidet utført av en person i en måned; Brooks ‘ lov sier at muligheten for å måle nyttig arbeid i man-måneder er en myte, og er dermed midtpunktet i boken.Komplekse programmeringsprosjekter kan ikke deles perfekt i diskrete oppgaver som kan bearbeides uten kommunikasjon mellom arbeiderne og uten å etablere et sett av komplekse sammenhenger mellom oppgaver og arbeiderne som utfører dem.

derfor tilordne flere programmerere til et prosjekt som kjører etter planen vil gjøre det enda senere. Dette er fordi tiden som kreves for de nye programmerere å lære om prosjektet og økt kommunikasjon overhead vil forbruke en stadig økende mengde av kalenderen tid tilgjengelig. Når n mennesker må kommunisere seg imellom, når n øker, reduseres produksjonen, og når det blir negativt, blir prosjektet forsinket ytterligere med hver person lagt til.

• Gruppe intercommunication formel: n(n − 1)/2
• Eksempel: 50 utviklere gi 50 · (50 – 1) / 2 = 1225 kommunikasjonskanaler.

ingen sølv bulletEdit

Brooks la til «No Silver Bullet-Essence and Accidents Of Software Engineering»—og ytterligere refleksjoner om Det, «No Silver Bullet» Refired—- til jubileumsutgaven Av Den Mytiske Man-Month.Brooks insisterer på at det ikke er noen silver bullet – «det er ingen enkelt utvikling, i teknologi eller ledelsesteknikk, som i seg selv lover enda en størrelsesorden forbedring innen et tiår i produktivitet, pålitelighet, enkelhet.argumentet bygger på skillet mellom tilfeldig kompleksitet og essensiell kompleksitet, på samme måte Som amdahls lov baserer seg på skillet mellom «strengt serielt» og «parallelliserbart».

den andre-system effektendit

den andre-system effekt foreslår at når en arkitekt designer et andre system, det er det farligste systemet de noensinne vil designe, fordi de vil tendere til å innlemme alle tilleggene de opprinnelig ikke legge til det første systemet på grunn av iboende tidsbegrensninger. Derfor, når du tar fatt på et andre system, bør en ingeniør være oppmerksom på at de er utsatt for over-engineering it.

tendensen mot irreducible antall feilrediger

forfatteren gjør observasjonen at i et passende komplekst system er det et visst irreducible antall feil. Ethvert forsøk på å fikse observerte feil har en tendens til å resultere i innføring av andre feil.

Progress trackingEdit

Brooks skrev «Spørsmål: Hvordan kan et stort programvareprosjekt bli ett år forsinket? Svar: En dag av gangen!»Inkrementelle glidning på mange fronter akkumuleres til slutt for å produsere en stor total forsinkelse. Fortsatt oppmerksomhet til å møte små individuelle milepæler er nødvendig på hvert nivå av ledelse.

Konseptuell integritetredit

for å lage et brukervennlig system må systemet ha konseptuell integritet, som bare kan oppnås ved å skille arkitektur fra implementering. En enkelt sjefsarkitekt (eller et lite antall arkitekter), som handler på brukerens vegne, bestemmer hva som går i systemet og hva som forblir ute. Arkitekten eller teamet av arkitekter bør utvikle en ide om hva systemet skal gjøre og sørge for at denne visjonen forstås av resten av teamet. En ny ide av noen kan ikke inkluderes hvis den ikke passer sømløst med den generelle systemdesignen. Faktisk, for å sikre et brukervennlig system, kan et system bevisst gi færre funksjoner enn det er i stand til. Poenget er, hvis et system er for komplisert å bruke, mange funksjoner vil gå ubrukt fordi ingen har tid til å lære dem.

manualEdit

sjefsarkitekten produserer en manual med systemspesifikasjoner. Det skal beskrive de eksterne spesifikasjonene til systemet i detalj, dvs. alt som brukeren ser. Håndboken bør endres ettersom tilbakemeldinger kommer inn fra implementeringsteamene og brukerne.

pilotsystemetrediger

når du designer en ny type system, vil et lag designe et kastesystem (enten det har til hensikt eller ikke). Dette systemet fungerer som en «pilotplan» som avslører teknikker som senere vil føre til et komplett redesign av systemet. Dette andre, smartere systemet bør være det som leveres til kunden, siden levering av pilotsystemet ikke ville føre til noe annet enn smerte for kunden, og muligens ødelegge systemets omdømme og kanskje til og med selskapet.

Formelle documentsEdit

hver prosjektleder bør lage et lite kjernesett med formelle dokumenter som definerer prosjektmålene, hvordan de skal oppnås, hvem som skal oppnå dem, når de skal oppnås, og hvor mye de skal koste. Disse dokumentene kan også avsløre uoverensstemmelser som ellers er vanskelig å se.

Project estimationEdit

når man estimerer prosjekttider, bør man huske at programmeringsprodukter (som kan selges til betalende kunder) og programmeringssystemer begge er tre ganger så vanskelig å skrive som enkle uavhengige interne programmer. Det bør holdes oppmerksom på hvor mye av arbeidsugen faktisk vil bli brukt på tekniske problemer, i motsetning til administrative eller andre ikke-tekniske oppgaver, for eksempel møter, og spesielt «stand-up» eller «all-hands» møter.

CommunicationEdit

for å unngå katastrofe, bør alle team som arbeider på et prosjekt være i kontakt med hverandre på så mange måter som mulig-e – post, telefon, møter, notater etc. I stedet for å anta noe, bør implementatørene spørre arkitekten (e) om å klargjøre deres hensikt med en funksjon de implementerer, før de fortsetter med en antagelse som godt kan være helt feil. Arkitekten(e) er ansvarlig for å formulere et gruppebilde av prosjektet og formidle det til andre.

det kirurgiske teamet [Rediger / rediger kilde] Mye som et kirurgisk team under operasjonen ledes av en kirurg som utfører det mest kritiske arbeidet, mens teamet ledes til å bistå med mindre kritiske deler, virker det rimelig å ha en «god» programmerer utvikle kritiske systemkomponenter mens resten av et lag gir det som trengs til rett tid. I Tillegg muses Brooks at «gode» programmerere generelt er fem til ti ganger så produktive som middelmådige.

kodefrysing og systemversjonendit

Programvaren er usynlig. Derfor blir mange ting bare tydelige når en viss mengde arbeid er gjort på et nytt system, slik at en bruker kan oppleve det. Denne erfaringen vil gi innsikt, som vil endre brukerens behov eller oppfatningen av brukerens behov. Systemet bør derfor endres for å oppfylle de endrede kravene til brukeren. Dette kan bare skje opp til et bestemt punkt, ellers kan systemet aldri bli fullført. På en bestemt dato bør det ikke tillates flere endringer i systemet, og koden skal fryses. Alle forespørsler om endringer bør forsinkes til neste versjon av systemet.

Specialized toolsEdit

I Stedet for at hver programmerer har sitt eget spesielle sett med verktøy, bør hvert lag ha en utpekt verktøymaker som kan lage verktøy som er svært tilpasset for jobben som laget gjør, for eksempel et kodegeneratorverktøy som lager kode basert på en spesifikasjon. I tillegg bør system-wide verktøy bygges av et felles verktøy team, overvåket av prosjektlederen.

Senking software development costsEdit

Det er to teknikker for å senke programvareutviklingskostnader Som Brooks skriver om:

• Implementatorer kan kun ansettes etter at arkitekturen i systemet er fullført(et trinn som kan ta flere måneder, i løpet av hvilken tid for tidlig innleide implementerere kan ikke ha noe å gjøre).En annen Teknikk Brooks nevner er ikke å utvikle programvare i det hele tatt, men bare å kjøpe den» hyllevare » når det er mulig.