書評:人月の神話:ソフトウェア工学に関するエッセイ、記念日版

Frederick P. Brooks、Jr。のThe Mythical Man-Month(MM-M)は、すべてのソフトウェア開発文献の中で最も有名な本の1つであり、おそらくソフトウェア開発管理に関する最も有名な本です。このクラスのレビューはすでに無数にありますが、このクラスを読んでおらず、何が好きかについての簡単な概要が必要なソフトウェア開発者のために、この投稿でもう一度レビューします。結局のところ、それはあなたが読んだことがないことを決して認めないトップ10のIT本のリストの中でPCWorldのナンバーワンのタイトルです。この投稿でレビューしているエディションの完全なタイトルは、The Mythical Man-Month:Essays on Software Engineering、AnniversaryEditionです。

The Mythical Man-Month(1995年発行)の「Anniversary Edition」は、1975年の元の版で発行されたものに加えて重要なコンテンツを追加します。「AnniversaryEdition」には、元の形式の元の本が含まれています(含まれていますが) 1982年の再版で追加された修正の数)そして4つの新しい章を追加します。アニバーサリーエディションの最初の15章は、元の本の章です。追加された章には、ブルックスの別の、しかし同様に有名なIFIPS(1986)/ IEEE Computer Magazine(1987)の論文No Silver Bullet:Essence and Accidents of Software Engineeringと、No Silver BulletReFiredと呼ばれるフォローアップが含まれます。アニバーサリーエディションの第18章と第19章は、ブルックスが1975年に書いたものに対する1995年の自己視点に焦点を当てています。ブルックスは、彼が何を間違えたのか、何が正しかったのかを指摘しています(前者よりも後者の方がはるかに多い)。

この本からのトピックと引用の徹底的な報道を含むTheMythical Man-Monthの多数のレビューがあります(Wikipediaの記事、Bernard I.NgのTheMythical Man-Monthの要約、第11章から始まるThe Mythical ManMonthからのいくつかの洞察たとえば、人月の神話–抜粋I、人月の神話–人月の神話の抜粋II、人月の神話の講義、および人月の神話のレビュー/要約)。この投稿では、本の内容全体の概要を繰り返すのではなく、いくつかの重要なポイントに焦点を当て、現代のソフトウェアのベストプラクティスとイデオロギーに照らして説明します。

第19章( "の命題人月の神話:「AnniversaryEdition」の「Trueor False?」)は、本全体を読むのが待ち遠しい、または時間がないが、ブルックスの主張の全体像を把握したい読者に特にアピールします。ブルックスはこの章を使用して提示するためです。 「概要形式」の「1975年の本の本質」、彼の元の本からのブルックスの主張(「経験からの事実と親指のルールタイプの一般化」)は「完全な形式」(約20ページ)で提示されます。 「アニバーサリーエディション」にこの章が存在することも、この本を章ごとに分類しないもう1つの理由です。この章では、元の本の主張を要約するだけでなく、ブルックスの一部も含まれています。■1995年のコメントは、さらに20年間の観察と後知恵の恩恵に基づいています。

マーク・ニーダムは、彼の投稿「人月の神話:書評」で、この本のレビューを次のように締めくくっています。「この本を読んで、より現代的な方法論の多くのアイデアが1980年代にすでに知られているのを見るのは本当に楽しかったです。本質的に新しいアイデアではありません。」私はこの声明に心から同意しますが、それの真実はおそらくもっと驚異的です:これらは1960年代半ばのOS / 360開発に取り組んだブルックスの経験とその後の会話に基づいて1975年出版された本の観察でした1960年代後半s。言い換えれば、今日私たちが「新しい」または「トレンディ」と考えるかもしれないもののいくつかは、45年以上前から存在していて知られています!ちなみに、これは、2006年後半にDenver Java Users Groupに行ったAlanM。Davisのプレゼンテーション(「ソフトウェア開発の新しい方法についての新機能」)を思い出させます。彼は、「新しい」方法論と今日の戦術には、過去数年で非常に類似した前任者がいて、何十年にもわたってそれらの間を循環しているように見えます。

ブルックスの次の点は、この本が1960年代半ばから後半の経験に基づいて1975年に出版されたという考えを心に留めているときに特に興味深いものです(これらの引用は第19章の要約からのものですが1975年版のテキストに基づいています):

  • 「非常に優れたプロのプログラマーは、貧しいプログラマーの10倍の生産性があります...」[職人技]
  • 「小さな鋭いチームが最善です-できるだけ少ない心。」[アジャイル]
  • 「欠陥を修正すると、別の欠陥が発生する可能性がかなり高くなります(20〜50%)。修正するたびに、システムに対して以前に実行したテストケースのバンク全体を実行して、システムが不明瞭な方法で損傷していないことを確認する必要があります。」[回帰試験]
  • 「デバッグ用のスキャフォールディングとテストコードをたくさん作成することは価値があります。おそらく、デバッグ対象の製品の50%にもなります。」[ユニットテスト]
  • 「ドキュメントを維持するには、個別のドキュメントとして保持するのではなく、ソースプログラムに組み込むことが重要です...高級言語の構文でさえ、目的をまったく伝えていません。」【DRY原理】

The Mythical Man-Monthには、ブルックスや当時の他の開発者が、今日私たちが理解している(そして時には再び「発見」する)ソフトウェア開発の同じ基本の多くを理解したことを示す、さらに多くの観察結果があります。これらの多くはよりよく知られており、他のレビューで呼び出されているため、これらの必須の引用を除いて、ここではリストしません。

  • 「他のすべての原因を合わせた場合よりも、カレンダーの時間が不足しているために、より多くのソフトウェアプロジェクトが失敗しました。」
  • ブルックスの法則:「後期のソフトウェアプロジェクトに人員を追加すると、後でそれが可能になります。」
  • 「したがって、仕事の規模を測定するための単位としての人月は、危険で欺瞞的な神話です。」

私が特にタイムリーに見つけたセクションの1つ(特に2011年の1975年の本)は、ソフトウェアアーキテクトが実装にどのように影響を与えることができるかについてのブルックスの報道でした。これは、アーキテクトのビジョンがアーキテクトが望む方法で開発者によって実装されていない場合に特に敏感になる可能性があります。ブルックスのヒントは非常に実用的なようです。彼は、アーキテクトは、コードを実装する人がその実装に対して「創造的な責任」を持っているという事実に同意しなければならないと述べています。彼はさらに、アーキテクトは常に自分の設計のいずれかを実装するという考えを持っている必要がありますが、同時に、コードを実装する人によって提案された同様に優れた代替アプローチを喜んで受け入れる必要があるとアドバイスします。ブルックスはさらに、アーキテクトが実装に関するすべての提案を行うことを推奨しています。静かにそして個人的に」、「信用を放棄する準備ができている」、そして実装者の「アーキテクチャ改善のための提案」に耳を傾ける。これは、この関係の両側での私の経験に基づく私にとって健全なアドバイスのようです。

頻繁に引用される2005年の記事で、ブルックスは次のように述べています。

この本は、テクノロジーよりも管理に関するものです。テクノロジーは大きく変化したため、古い章のいくつかは完全に同期していません。一方で、人はあまり変わっていません。だからこそ、ホメロスとシェイクスピアと聖書は、すべて人間の本性を扱っているので、依然として関連性があります。それがこの本の説明の一部だと思います。人々がデザインする媒体と彼らが使用するツールはありますが、チームで人々を管理する問題は変わっていません。この本を「ソフトウェア工学の聖書」と呼ぶ人もいます。私はある点でそれに同意します。つまり、誰もがそれを引用し、何人かの人々がそれを読み、そして何人かの人々がそれを通ります。

この引用に含まれている概念は、人月の神話のレビューで伝えるための最も重要なことかもしれません。この本の魅力は、人々の管理をカバーし、それに焦点を当てていることです。それは時代を超え、何十年にもわたって変わっていません。テクノロジーは間違いなく大きく変化しており、それがこの本の最大の欠点かもしれません。 1975年の特定の製品、ツール、および言語に基づくBrooksの例は、一般的な読者にとって今日よりも確かに説明的でした。たとえば、彼の1975年の本では、PL / Iを「今日のシステムプログラミングの唯一の合理的な候補」と呼んでいます。ブルックスが言及している製品を直接経験していないため、読書の一部が少し難しい場合があります。しかし、ほとんどの場合、人間の要素が本の焦点であり、これは今でもほとんど変わっていないため、これは最終的にはそれほど大きな障害にはなりません。アニバーサリーエディションの第19章では、ブルックスは彼の本の継続的な人気を振り返り、次のように述べています。MM-Mは人とチームに関するものであり、陳腐化は遅いはずです。」

人月の神話は、非常に大規模なエンタープライズソフトウェア開発プロジェクトについて実際にあります。これは、小さなプロジェクトで作業している人には明白に見えるかもしれないことを読むときに覚えておくことが重要です。上記の引用の最後の部分は有名です:「何人かの人々は本を「ソフトウェア工学の聖書」と呼びました。私はある点でそれに同意します。つまり、誰もがそれを引用し、何人かの人々がそれを読み、そして何人かの人々がそれを通ります。」ブルックスの本は聖書の参考文献でいっぱいで、彼は明らかに聖書に精通しています。悲しいことに、ブルックスの「誰もがそれを引用し、何人かの人々がそれを読み、そして何人かの人々がそれを通り過ぎる」という引用は今日ではあまりにも真実です。私たちはそれを読み続けますが、大規模なソフトウェア開発プロジェクトで物事を変えるためにもっと多くのことをするのは素晴らしいことです。

人月の神話だと感じる人もいます敗北者であり、憂うつですらあります。読んでも同じ気持ちにはなりません。むしろ、特定の行動が有害で機能不全であることを思い出させてくれると思います。また、「次の大きなもの」を待つのではなく、できる限り技術を向上させ続ける必要があることも思い出させてくれます。多くの実用的なヒントと提案が提供されています。ブルックスは明らかにソフトウェア開発の分野にいるのが大好きで、これは彼の本に何度も示されています。ブルックスは本の「エピローグ:不思議、興奮、喜びの50年」を締めくくり、以前は「すべてのジャーナルと会議の議事録を読む」ことができたが、最終的には特定の興味を1つずつあきらめなければならなかった。知識が爆発した。彼は次のように結論づけています。「興味が多すぎて、学ぶための刺激的な機会が多すぎます。研究、そして思考。なんて素晴らしい苦境でしょう。終わりが見えないだけでなく、ペースも緩んでいません。私たちには多くの将来の喜びがあります。」私は間違いなく同意します。

//marxsoftware.blogspot.com/で利用可能な元の投稿(実際のイベントに触発された)

この物語、「書評:人月の神話:ソフトウェア工学に関するエッセイ、記念版」は、もともとJavaWorldによって発行されました。