神話のman-monthEdit

Brooksは、スケジューリングの失敗のいくつかの原因について説明します。 最も永続的なのは、Brooksの法則についての彼の議論です。 ブルックスの法則は、人月で有用な仕事を測定する可能性は神話であり、したがって本の目玉であると述べています。

複雑なプログラミングプロジェクトは、ワーカー間の通信なしで、タスクとそれらを実行するワーカー間の複雑な相互関係のセットを確立することなく、

したがって、スケジュールの遅れて実行されているプロジェクトに多くのプログラマを割 これは、新しいプログラマがプロジェクトについて学ぶのに必要な時間と、通信オーバーヘッドの増加が、利用可能なカレンダー時間の増加量を消費するた N人が自分たちの間で通信する必要がある場合、nが増加するにつれて、その出力が減少し、それが負になると、プロジェクトはすべての人が追加され

• グループ相互通信式：n（n−1）/2
• 例：50人の開発者が与える50 · (50 – 1) / 2 = 1225 通信のチャネル。

いいえ銀の弾丸edit

Brooksは、”No Silver Bullet—Essence and Accidents of Software Engineering”を追加し、それについてのさらなる反省、”No Silver Bullet’Refired”を神話のMan—Monthの記念日版に追加しました。

ブルックスは、誰も銀の弾丸がないことを主張している-“技術や管理技術のいずれかで、単一の開発はありません。”

この議論は、アムダールの法則が”厳密に直列”と”並列化可能”の区別に依存する方法と同様に、偶発的な複雑さと本質的な複雑さの区別に依存しています。

the second-system effectEdit

second-system effectは、アーキテクトが第二のシステムを設計するとき、それは彼らが設計する最も危険なシステムであると提案しています。 したがって、第二のシステムに着手するとき、エンジニアは、彼らがそれをオーバーエンジニアリングの影響を受けやすいことに留意す

エラーの既約数への傾向edit

著者は、適切に複雑なシステムでは、特定の既約数のエラーがあるという観察を行います。 観測されたエラーを修正しようとすると、他のエラーが発生する傾向があります。

Progress trackingEdit

Brooksは”質問：大規模なソフトウェアプロジェクトはどのように一年遅れになるのですか？ 答え：一度に一日！”多くの面での増分滑りは、最終的には大きな全体的な遅延を生成するために蓄積します。 管理の各レベルでは、小さな個々のマイルストーンを満たすことに継続的な注意が必要です。

Conceptual integrityEdit

ユーザーフレンドリーなシステムを作るためには、システムは実装からアーキテクチャを分離することによってのみ達成できる概念的な整合性 ユーザーに代わって行動する単一のチーフアーキテクト（または少数のアーキテクト）が、システムに何が入るのか、何が出ないのかを決定します。 アーキテクトまたはアーキテクトのチームは、システムが何をすべきかのアイデアを開発し、このビジョンがチームの残りの部分によって理解されているこ それはシステム全体の設計とシームレスに適合しない場合、誰かが新しいアイデアが含まれていない可能性があります。 実際には、ユーザーフレンドリーなシステムを確保するために、システムは意図的にそれが可能であるよりも少ない機能を提供することができます。 ポイントは、システムが使用するにはあまりにも複雑である場合、誰もそれらを学ぶ時間がないので、多くの機能が未使用になります。

マニュアル編集

チーフアーキテクトは、システム仕様のマニュアルを作成します。 システムの外部仕様、つまりユーザーが見ているすべてのものを詳細に記述する必要があります。 このマニュアルは、実装チームとユーザーからのフィードバックに応じて変更する必要があります。

パイロットsystemEdit

新しい種類のシステムを設計するとき、チームはスローアウェイシステムを設計します（意図するかどうかにかかわらず）。 このシステムは、その後、システムの完全な再設計を引き起こす技術を明らかにする”パイロット計画”として機能します。 この第二に、よりスマートなシステムは、パイロットシステムの配信は、顧客に何も苦痛を引き起こさないだろうし、おそらくシステムの評判、多分会社を台無しにするので、顧客に配信されるものでなければなりません。

Formal documentsEdit

すべてのプロジェクトマネージャーは、プロジェクトの目標、達成方法、誰が達成しようとしているのか、いつ達成しようとしているのか、どれだけの費用がかかるのかを定義する小さなコアセットの正式な文書を作成する必要があります。 これらの文書は、そうでなければ見るのが難しい矛盾を明らかにするかもしれません。

Project estimationEdit

プロジェクト時間を見積もるとき、プログラミング製品（有料の顧客に販売できる）とプログラミングシステムは、単純な独立した社内プログ 会議などの管理やその他の非技術的なタスク、特に”スタンドアップ”や”オールハンド”の会議とは対照的に、作業週のどれだけが実際に技術的な問題に費や

CommunicationEdit

災害を避けるために、プロジェクトに取り組んでいるすべてのチームは、電子メール、電話、会議、メモなど、できるだけ多くの方法で互いに連絡 何かを仮定するのではなく、実装者は、完全に間違っている可能性のある仮定を進める前に、実装している機能に関する意図を明確にするようにアーキテ 建築家（複数可）は、プロジェクトのグループ画像を策定し、他の人にそれを通信するための責任があります。

the surgical teamEdit

手術中の外科チームは、最も重要な作業を行う外科医によって導かれているのと同じように、チームの残りの部分が適切なタイミングで必要なものを提供しながら、”良い”プログラマに重要なシステムコンポーネントを開発させるのは合理的だと思われます。 さらに、Brooksは、「良い」プログラマは、一般的に平凡なプログラマの5〜10倍の生産性があると考えています。

コードフリーズとシステムのバージョン管理編集

ソフトウェアは表示されません。 したがって、多くのことは、新しいシステムで一定量の作業が行われた後にのみ明らかになり、ユーザーがそれを体験できるようになります。 この経験は、ユーザーのニーズやユーザーのニーズの認識を変更する洞察をもたらすでしょう。 したがって、システムは、ユーザーの変更された要件を満たすように変更する必要があります。 これは特定の時点までのみ発生する可能性があり、そうでない場合はシステムが完了しない可能性があります。 特定の日付では、システムにこれ以上の変更を許可せず、コードを凍結する必要があります。 すべての変更要求は、システムの次のバージョンまで遅延する必要があります。

Specialized toolsEdit

すべてのプログラマが独自の特別なツールセットを持つのではなく、各チームには、チームがやっている仕事のために高度にカスタマイズされたツールを作成することができる指定されたツールメーカーが必要です。 さらに、システム全体のツールは、プロジェクトマネージャーが監督する共通のツールチームによって構築される必要があります。

ソフトウェア開発コストの削減編集

Brooksが書いているソフトウェア開発コストを削減するための二つのテクニックがあります。

• 実装者は、システムのアーキテクチャが完了した後にのみ雇用される可能性があります(数ヶ月かかることがありますが、その間に早期に雇用された実装者は何の関係もない可能性があります)。
• ブルックスが言及しているもう一つの技術は、ソフトウェアをまったく開発するのではなく、可能であれば単に”既製”で購入することです。