Mythical Man Monthの影響を軽減する方法は何ですか？

ブルックスの法則： 後期ソフトウェアプロジェクトに人員を追加すると、後の作業になります。

彼の本「No Silver Bullet —ソフトウェアエンジニアリングの本質と事故」で、フレデリックブルックスは「神話の男月」の概念を定義しています。

ブルックスの仮定は、複雑なプログラミングプロジェクトを、作業者間のコミュニケーションがなく、タスクとそれを実行する作業者間の複雑な相互関係を確立せずに作業できる個別のタスクに完全に分割できないことです。

1982年以来、私たちは確かに前進し、この問題を緩和するためのさらなる経験を集めてきました。より多くの問題を作成せずにプロジェクトにリソースを追加するために、仕事で正常に適用したソリューションにはどのようなものがありますか。

MMMとは

まず、ブルックの法則の背景を説明します。1975年に彼が作成した理由は何ですか？

人月は、1か月に1人が行った作業を表す架空の作業単位です。ブルックスの法則によれば、有用な仕事を人月で測定することは不可能だという。

^{ソース：https : //en.wikipedia.org/wiki/The_Mythical_Man-Month}

かつては、複雑なプログラミングプロジェクトは大きなモノリスシステムを意味していました。そして、ブルックスは、これらを開発者間のコミュニケーションなしで、そしてタスクとそれを実行する人々との間の複雑な相互関係のセットを確立することなく作業できる個別のタスクに完全に分割できないと主張します。

これは、非常にまとまりのあるソフトウェアモノリスに非常に当てはまります。デカップリングがいくら行われても、大きなモノリスは、新しいプログラマがモノリスについて学ぶために必要な時間を要求します。また、通信オーバーヘッドが増加し、利用可能な時間がますます増えています。

しかし、本当にこのようにする必要がありますか？モノリスを作成し、開発者の人数に応じてコミュニケーションチャネルを維持する必要n(n − 1) / 2がnありますか？

数千人の開発者が大きなプロジェクトに取り組んでいる企業があることを知っています...そしてそれはうまくいきます。したがって、1975年以降に変更されたものがあるはずです。

MMMを緩和する可能性

2015年、PuppetLabsとIT Revolutionは2015 State of DevOps Reportの結果を公開しました。そのレポートでは、彼らは高パフォーマンスの組織と非高パフォーマンスの組織との違いに焦点を合わせました。

高パフォーマンスの組織は、いくつかの予期しない特性を示しています。たとえば、彼らは開発において最高のプロジェクト期日パフォーマンスを持っています。運用における最高の運用安定性と信頼性。また、最高のセキュリティとコンプライアンスの実績。

レポートで強調されている驚くべきことの1つは、1日あたりの展開数の指標です。しかし、1日あたりの展開だけでなく、展開/日/開発者、およびパフォーマンスの高い組織とパフォーマンスの低い組織で開発者を追加した場合の影響も測定しました。

これはそのレポートのグラフです-

成果の低い組織は、神話上の男月の仮定に沿っています。高性能な組織は、開発者の数に応じてデプロイ/日/開発の数を線形にスケーリングできます。

Gene KimによるDevOpsDays London 2016での優れたプレゼンテーションは、これらの調査結果について語っています。

どうやってするの

まず、どのように高性能な組織になるのですか？これについて説明している本がいくつかありますが、この回答には十分なスペースがありませんので、それらにリンクします。

• 良いから素晴らしい：なぜいくつかの企業が躍進するのか...そして他の企業はジム・コリンズではない
• 高速エッジ：市場のリーダーがいかにオペレーショナルエクセレンスを活用して競争に打ち勝つかスティーブンスピア
• W.エドワーズデミングによる産業、政府、教育のための新しい経済学

ソフトウェアおよびIT組織にとって、パフォーマンスの高い組織になるための重要な要素の1つは、品質と速度に焦点を当てることです。

例えば、ウォード・カニンガムは、私たちが未解決のままにしておいたすべてのものを技術的負債として説明しています。これは、時間があるときに修正されるという約束が常にあるため、経営陣に受け入れられています。

決して十分な時間はなく、技術的な負債はますます悪化しています。

技術的負債を増大させる原因は何ですか？

• レガシーコード
• 環境の手動構成
• 手動テスト
• 手動展開

レガシーコードマイケルフェザーズによる「レガシーコードを効果的に使用する」で定義されているように、自動テストがないコードがあります。

いつでもショートカットを使用してコードを実稼働に移行します。事業はこの借金を永久に維持する負担を負います。その後、展開のプロセスはますます長くなります。

ジーンはプレゼンテーションで、6週間の展開を行っている会社について話しています。数万の非常にエラーが発生しやすい退屈な手順を伴い、400人を拘束し、毎年4回これを行います。

DevOpsの原則の1つは、小規模な展開をより頻繁に行うことで信頼性が得られることです。

例

• Velocity 2011のJon Jenkins：Amazonは1日あたり1万5,000個のデプロイを行っています
• AWS Summit 2015のKen Exner：Amazonは1日あたり1万3,000のデプロイを行っています

これら2つのプレゼンテーションは、Amazonがコードを本番環境にデプロイするのにかかる時間を短縮するために行ったすべてのことを示しています。

Geneによれば、これらの高パフォーマンスの組織で時間とともに変化するのは、開発者の数だけです。したがって、Amazonの例から、4年でさらに人を追加するだけで展開が10倍になったと言えるでしょう。

これは、特定の条件下で、適切なアーキテクチャ、適切な技術的慣行、適切な文化的規範により、開発者の数が増えるにつれて開発者の生産性が拡大することを意味します。そして、DevOpsは間違いなくこれらすべての真っin中にあります。

私がやったこと（そしてこれは主観的なことです）は次のとおりです：

期日を考えているマネージャーが、必要な時間を削減するために私のチームに人を追加したいと思い、MMMの下にいるように見えるとき、私は最初に彼または彼女となぜこれが悪いのかについて話し合います。これに対する私のお気に入りの例えは、1人の女性が9か月で赤ちゃんを産むことができる場合、9人の女性は1か月で1人の赤ちゃんを産まないが、9か月で9人の赤ちゃんを産むことを思い出させることです。時間は短縮されず、並列処理の方が優れています。

チームに決定が強制されると、通常、いくつかのタスクをさらに分割しようとします。これが不可能な場合、通常はペアプログラミングに依存します .1人のプログラマが入力を担当し、もう1人がコードを決定します（そして定期的に切り替える）。

コードの作成自体は遅くなりますが、テスト中の入力ミスやリンティング、バグは少なくなります。これは、作成中に避けられないレビューが行われるためです。全体的なコード品質も少し改善されていると感じていますが、その主張を裏付ける指標はありません。

CIの観点からのみ言えば、プロジェクトで作業する開発者の数を増やすと、通常、同じブランチで作業する人が増えます。

従来のCIシステムには、この点でスケーラビリティの問題があります。破損/回帰/ブロックの確率が高くなり、統合速度が遅くなり、小さなチームが子ブランチに分岐して移動するように招きます（つまり、さらなる減速）。非常に大規模なプロジェクト/チーム向けに継続的インテグレーションを拡張するにはどうすればよいですか？を参照してください 。これは、Mythical Man Monthコンセプトに沿って正しく機能します。

その質問への私の答えで提案するソリューションは、非常にスケーラブルな CIシステムにより、真のCIへの移行を可能にします。

同じページの全員が、同じ自動化ツール/プロセスとCIシステム自体の内部で自動化されたQA検証の大部分を使用すると、役割を切り替えてチームメンバー間で集中することがはるかに簡単になります。開発プロセス全体がよりスムーズになり、より予測可能になり、よりリラックスしたものになります。

そのような環境で新しい人を乗せて、経験豊富なチームメンバーから難易度の低いタスクをオフロードするだけで生産性を高め、その後、より困難なタスクを引き受けることが容易になります。

これらはすべて、Mythical Man Monthコンセプトの効果をなだめるものとして見ることができます。