Mytický man-monthEdit

Brooks pojednává o několika příčinách selhání plánování. Nejtrvalejší je jeho diskuse o Brooksově zákonu:přidání pracovní síly do pozdního softwarového projektu to udělá později. Muž-měsíc je hypotetická jednotka práce představuje práci jednoho člověka na jeden měsíc; Brooksův zákon říká, že možnost měření užitečné práce v man-měsíců-to je mýtus, a je tudíž středobodem knihy.

Komplexní programové projekty nemohou být dokonale rozdělen do jednotlivých úkolů, které mohou být pracoval na, bez komunikace mezi pracovníky a bez založení nastavit komplexní vzájemné vztahy mezi úkoly a pracovníci jejich provedení.

proto přiřazení více programátorů k projektu, který běží za plánem, bude ještě později. Je to proto, že čas potřebný k tomu, aby se noví programátoři dozvěděli o projektu, a zvýšená režie komunikace spotřebují stále rostoucí množství dostupného kalendářního času. Když n lidí komunikovat mezi sebou, jak se n zvětšuje, jejich produkce klesá a když se stane negativní projektu je odloženo s každou osobu, dodal.

• Skupina spojovacích vzorce: n(n − 1) / 2
• Příklad: 50 vývojáři dát 50 · (50 – 1) / 2 = 1225 komunikační kanály.

No silver bulleteditovat

Brooks dodal: „Žádná Stříbrná Kulka — Podstata a Nehod Softwarového Inženýrství“—a dále úvahy o tom, „‚No Silver Bullet‘ opět obnoven“—k výročí vydání Mytický Člověk Měsíc.

Brooks trvá na tom, že není nikdo, stříbrná kulka … „neexistuje jediný vývoj, v obou technologie nebo techniky řízení, které samo o sobě slibuje ještě o jeden řád zlepšení během deseti let v produktivitě, spolehlivosti, jednoduchosti.“

tento argument se opírá o rozlišení mezi náhodné složitosti a esenciální složitost, podobně jako Amdahlův zákon se opírá o rozlišení mezi „přísně sériové“ a „parallelizable“.

druhá-systém effectEdit

druhý-efekt systému navrhuje, že když architekt navrhuje druhý systém, to je nejvíce nebezpečné systému, že bude někdy design, protože budou mít tendenci začlenit všechny dodatky, že původně neměl přidat k první systém, vzhledem k vlastní časové omezení. Při nástupu do druhého systému by tedy inženýr měl mít na paměti, že jsou náchylní k přepracování it.

tendence k neredukovatelné počet errorsEdit

autor poznamenává, že v vhodně složitém systému existuje určitý neredukovatelný počet chyb. Jakýkoli pokus o opravu pozorovaných chyb má tendenci vést k zavedení dalších chyb.

Progress trackingEdit

Brooks napsal “ otázka: jak se velký softwarový projekt dostane o rok později? Odpověď: jeden den po druhém!“Přírůstkové skluzy na mnoha frontách se nakonec hromadí, aby vytvořily velké celkové zpoždění. Na každé úrovni řízení je nutná trvalá pozornost věnovaná plnění malých individuálních milníků.

konceptuální integrityEdit

aby byl systém uživatelsky přívětivý, musí mít systém koncepční integritu, čehož lze dosáhnout pouze oddělením architektury od implementace. Jediný hlavní architekt (nebo malý počet architektů), jednající jménem uživatele, rozhoduje o tom, co se v systému děje a co zůstává venku. Architekt nebo tým architektů by měl vytvořit představu o tom, co by měl systém dělat, a ujistit se, že tuto vizi chápe zbytek týmu. Nový nápad někoho nemusí být zahrnut, pokud se nehodí hladce s celkovým designem systému. Pro zajištění uživatelsky přívětivého systému může systém záměrně poskytovat méně funkcí, než je schopen. Jde o to, že pokud je systém příliš komplikovaný, mnoho funkcí se nevyužije, protože nikdo nemá čas se je naučit.

manualEdit

hlavní architekt vytváří manuál specifikací systému. Měl by podrobně popsat externí specifikace systému, tj. vše, co uživatel vidí. Manuál by měl být změněn, protože zpětná vazba přichází od implementačních týmů a uživatelů.

pilotní systémEditovat

při navrhování nového druhu systému, tým navrhne odhazovací systém (ať už má v úmyslu nebo ne). Tento systém funguje jako „pilotní plán“, který odhaluje techniky, které následně způsobí kompletní redesign systému. Tento druhý, chytřejší systém by měl být ten, dodáno k zákazníkovi, od dodání pilotní systém by způsobit nic, ale utrpení k zákazníkovi, a možná i zničit pověst systému a možná i společnosti.

Formální documentsEdit

Každý projektový manažer by měl vytvořit malý základní soubor formálních dokumentů definování cílů projektu, jak mají být dosaženy, kdo se chystá dosáhnout je, když se chystáte být dosaženo, a kolik budou stát. Tyto dokumenty mohou také odhalit nesrovnalosti, které jsou jinak těžko vidět.

Projekt estimationEdit

Při odhadu projektu krát, je třeba připomenout, že programové produkty (které mohou být prodávány na platící zákazníky) a programování systémů jsou oba třikrát tak těžké napsat tak jednoduché, nezávislé in-house programů. Je třeba mít na paměti, kolik pracovního týdne bude skutečně vynaloženo na technické otázky, na rozdíl od administrativních nebo jiných netechnických úkolů, jako jsou schůzky, a zejména schůzky „stand-up“ nebo „all-hands“.

CommunicationEdit

aby se předešlo katastrofě, měly by všechny týmy pracující na projektu zůstat ve vzájemném kontaktu co nejvíce způsoby—e-mailem, telefonem, schůzkami, poznámkami atd. Místo toho, za předpokladu, něco, realizátoři měli zeptat architekt(s) objasnit svůj záměr na funkce, které provádějí, před pokračováním s předpokladem, že by mohla velmi dobře být zcela nesprávné. Architekt (architekti) jsou zodpovědní za formulaci skupinového obrazu projektu a jeho komunikaci s ostatními.

chirurgické teamEdit

Stejně jako chirurgický tým při operaci je veden jeden chirurg provádí nejvíce kritické práce, zatímco řídí tým, aby pomohl s méně kritické části, se zdá rozumné, aby měl „dobré“ programátor rozvíjet kritické komponenty systému, zatímco zbytek týmu poskytuje to, co je potřeba ve správný čas. Brooks navíc uvažuje, že“ dobří “ programátoři jsou obecně pětkrát až desetkrát produktivnější než průměrní.

zmrazení kódu a systémová verzeedit

Software je neviditelný. Mnoho věcí se proto projeví až poté, co bylo na novém systému provedeno určité množství práce, což uživateli umožní zažít to. Tato zkušenost přinese poznatky, které změní potřeby uživatele nebo vnímání potřeb uživatele. Systém by proto měl být změněn tak, aby splňoval změněné požadavky uživatele. K tomu může dojít pouze do určitého bodu, jinak nemusí být systém nikdy dokončen. K určitému datu by v systému neměly být povoleny žádné další změny a kód by měl být zmrazen. Všechny žádosti o změny by měly být zpožděny až do další verze systému.

Specializované toolsEdit

Místo toho, každý programátor má své vlastní speciální sadu nástrojů, každý tým by měl mít určený nástroj-maker, který může vytvářet nástroje, které jsou vysoce přizpůsobené pro práci, kterou tým dělá, např. generátor kódu nástroj, který vytváří kód založený na specifikaci. Kromě toho by Systémové nástroje měly být vytvářeny společným týmem nástrojů, na který dohlíží projektový manažer.

Snížení software development zavedeníeditovat

Existují dvě techniky pro snížení náklady na vývoj softwaru, který Brooks píše o tom:

• Realizátory mohou být zařazeni pouze po architekturu systému byla dokončena (krok, který může trvat několik měsíců, během nichž předčasně najal realizátoři nemusí mít nic společného).
• další technikou, kterou Brooks zmiňuje, není vůbec vyvíjet software, ale jednoduše jej koupit“ z police“, pokud je to možné.