A mitikus emberhónap

Brooks az ütemezési hibák több okát tárgyalja. A legmaradandóbb Brooks törvényének megvitatása:a munkaerő hozzáadása egy késői szoftverprojekthez később teszi. Az emberhónap egy hipotetikus munkaegység, amely azt a munkát képviseli, amelyet egy ember egy hónap alatt végez; Brooks törvénye szerint a hasznos munka emberhónapokban történő mérésének lehetősége mítosz, ezért a könyv középpontja.

a komplex programozási projekteket nem lehet tökéletesen felosztani olyan különálló feladatokra, amelyeken a munkavállalók közötti kommunikáció és a feladatok és az azokat végző munkavállalók közötti összetett kapcsolatok létrehozása nélkül lehet dolgozni.

ezért ha több programozót rendelünk egy ütemterv mögött futó projekthez, az még később is megtörténik. Ennek az az oka, hogy az új programozóknak a projekt megismeréséhez szükséges idő és a megnövekedett kommunikációs költségek a rendelkezésre álló naptári idő egyre növekvő mennyiségét fogyasztják el. Amikor n embernek egymás között kell kommunikálnia, ahogy n növekszik, a kimenetük csökken, és amikor negatívvá válik, a projekt tovább késik minden hozzáadott személlyel.

• Csoportos kommunikációs képlet: n (n-1) / 2
• példa: 50 Fejlesztő AD 50 · (50 – 1) / 2 = 1225 kommunikációs csatornák.

nincs ezüst golyószerkesztés

Brooks hozzáadta a “Nincs ezüst golyó—a szoftverfejlesztés lényege és balesetei “—és további reflexiók,”nincs ezüst golyó” -a mitikus Emberhónap jubileumi kiadásához.

Brooks ragaszkodik ahhoz, hogy nincs egyetlen ezüst golyó – “nincs egyetlen fejlesztés sem a technológiában, sem a menedzsment technikában, amely önmagában akár egy nagyságrenddel is javulást ígér egy évtizeden belül a termelékenységben, a megbízhatóságban, az egyszerűségben.”

az érvelés a véletlen összetettség és az alapvető összetettség megkülönböztetésére támaszkodik, hasonlóan ahhoz, ahogyan Amdahl törvénye a “szigorúan soros” és a “párhuzamosítható”megkülönböztetésére támaszkodik.

the second-system effectEdit

a second-system effect azt javasolja, hogy amikor egy építész tervez egy második rendszert, ez a legveszélyesebb rendszer, amit valaha is terveznek, mert hajlamosak lesznek beépíteni az összes kiegészítést, amelyet eredetileg nem adtak hozzá az első rendszerhez a benne rejlő időbeli korlátok miatt. Így, amikor elindulna egy második rendszer, egy mérnök kell szem előtt tartani, hogy hajlamosak a túlzott mérnöki azt.

A hibák irreducibilis számának tendenciájaszerkesztés

a szerző azt a megfigyelést teszi, hogy egy megfelelően összetett rendszerben bizonyos számú hiba van. A megfigyelt hibák kijavítására tett kísérletek általában más hibák bevezetését eredményezik.

Progress trackingEdit

Brooks azt írta: “kérdés: Hogyan lehet egy nagy szoftverprojekt egy évvel késni? Válasz: egy nap egy időben!”Az inkrementális csúszások sok fronton végül felhalmozódnak, hogy nagy általános késést eredményezzenek. A vezetés minden szintjén folyamatos figyelmet kell fordítani a kis egyedi mérföldkövek teljesítésére.

fogalmi integrityEdit

a felhasználóbarát rendszer létrehozásához a rendszernek fogalmi integritással kell rendelkeznie, amelyet csak az architektúra és a megvalósítás elválasztásával lehet elérni. Egyetlen főépítész (vagy néhány építész), aki a felhasználó nevében jár el, eldönti, hogy mi kerül a rendszerbe, és mi marad ki. Az építésznek vagy építészcsapatnak ki kell dolgoznia egy ötletet arról, hogy mit kell tennie a rendszernek, és gondoskodnia kell arról, hogy ezt a jövőképet a csapat többi tagja megértse. Lehet, hogy valaki nem tartalmaz újszerű ötletet, ha az nem illeszkedik zökkenőmentesen a teljes rendszertervhez. Valójában a felhasználóbarát rendszer biztosítása érdekében a rendszer szándékosan kevesebb funkciót nyújthat, mint amennyire képes. A lényeg az, hogy ha egy rendszer túl bonyolult a használatához, sok funkció kihasználatlan marad, mert senkinek nincs ideje megtanulni őket.

a kézikönyvszerkesztés

a főépítész elkészíti a rendszer specifikációinak kézikönyvét. Részletesen le kell írnia a rendszer külső specifikációit, azaz mindent, amit a felhasználó lát. A kézikönyvet módosítani kell, mivel az implementációs csapatok és a felhasználók visszajelzései érkeznek.

A kísérleti rendszerSzerkesztés

egy új típusú rendszer tervezésekor a csapat egy eldobási rendszert tervez (akár szándékozik, akár nem). Ez a rendszer “kísérleti tervként” működik, amely olyan technikákat tár fel, amelyek később a rendszer teljes átalakítását eredményezik. Ezt a második, okosabb rendszert kell az ügyfélnek eljuttatni, mivel a kísérleti rendszer átadása csak gyötrelmet okozna az ügyfélnek, és esetleg tönkretenné a rendszer hírnevét, sőt talán még a vállalatot is.

Formal documentsEdit

minden projektmenedzsernek létre kell hoznia egy kis alapdokumentumot, amely meghatározza a projekt céljait, hogyan kell elérni őket, ki fogja elérni őket, mikor fogják elérni őket, és mennyibe kerülnek. Ezek a dokumentumok olyan következetlenségeket is feltárhatnak, amelyeket egyébként nehéz észrevenni.

Project estimationEdit

a projektidők becslésekor nem szabad megfeledkezni arról, hogy a programozási termékeket (amelyeket fizető ügyfeleknek lehet eladni) és a programozási rendszereket háromszor olyan nehéz megírni, mint az egyszerű, független házon belüli programokat. Nem szabad megfeledkezni arról, hogy a Munkahét mekkora részét fordítják ténylegesen technikai kérdésekre, szemben az adminisztratív vagy egyéb nem technikai feladatokkal, például az ülésekkel, különösen a “stand-up” vagy a “minden kéz” találkozókkal.

CommunicationEdit

a katasztrófa elkerülése érdekében a projekten dolgozó összes csapatnak a lehető legtöbb módon kapcsolatban kell maradnia egymással—e-mail, telefon, találkozók, emlékeztetők stb. Ahelyett, hogy feltételez valamit, a megvalósítóknak meg kell kérniük az építész(EK) t, hogy tisztázzák szándékukat egy általuk megvalósított jellemzővel kapcsolatban, mielőtt folytatnának egy olyan feltételezést, amely nagyon is teljesen helytelen lehet. Az építész(ek) feladata a projekt csoportképének kialakítása és másokkal való kommunikálása.

a sebészeti csapatszerkesztés

mivel a sebészeti csapatot a műtét során egy sebész vezeti, aki a legkritikusabb munkát végzi, miközben a csapatot kevésbé kritikus részekkel segíti, ésszerűnek tűnik, hogy egy “jó” programozó fejlessze a kritikus rendszerelemeket, míg a csapat többi tagja biztosítja, amire szükség van a megfelelő időben. Ezenkívül Brooks azt állítja, hogy a “jó” programozók általában ötször-tízszer olyan produktívak, mint a középszerűek.

Kódfagyasztás és rendszerverziószerkesztés

a szoftver láthatatlan. Ezért sok dolog csak akkor válik nyilvánvalóvá, ha bizonyos mennyiségű munkát végeztek egy új rendszeren, lehetővé téve a felhasználó számára, hogy megtapasztalja azt. Ez a tapasztalat betekintést nyújt, amely megváltoztatja a felhasználó igényeit vagy a felhasználó igényeinek észlelését. A rendszert ezért meg kell változtatni, hogy megfeleljen a felhasználó megváltozott követelményeinek. Ez csak egy bizonyos pontig fordulhat elő, különben a rendszer soha nem fejezhető be. Egy bizonyos időpontban nem szabad több változtatást engedélyezni a rendszerben, és a kódot be kell fagyasztani. Minden változtatási kérelmet el kell halasztani a rendszer következő verziójáig.

Specialized toolsEdit

ahelyett, hogy minden programozónak saját speciális eszközkészlete lenne, minden csapatnak rendelkeznie kell egy kijelölt szerszámkészítővel, aki olyan eszközöket hozhat létre, amelyek nagymértékben testreszabhatók a csapat által végzett munkához, például egy kódgenerátor eszköz, amely egy specifikáció alapján kódot hoz létre. Ezenkívül a rendszerszintű eszközöket egy közös eszközcsapatnak kell felépítenie, amelyet a projektmenedzser felügyel.

a szoftverfejlesztési költségek Csökkentéseszerkesztés

két módszer létezik a szoftverfejlesztési költségek csökkentésére, amelyekről Brooks ír:

• a Megvalósítókat csak a rendszer architektúrájának befejezése után lehet felvenni (ez a lépés több hónapot is igénybe vehet, amely idő alatt az idő előtt felvett implementátoroknak nincs mit tenniük).
• egy másik technika, amelyet Brooks említ, egyáltalán nem szoftver fejlesztése, hanem egyszerűen csak “polcról” vásárolni, ha lehetséges.