開発チームを作成するための基本的な法律

EDISONには 、従業員をチームに追加したいエンジニアから頻繁に連絡があります。 十数人の追加開発者を活用して、「パズルをすばやくリベット」したいです。 このアプローチは機能しますか？ 残念ながら、常にではありません。 物理学のように、プログラミングには法律があります。





インテリジェントなチームを編成することは本物の芸術です

ブルックス法

この原則に言及しない限り、開発チームの議論は行われません。

「人材を追加することにより、ソフトウェアプロジェクトの終了を遅らせています」（Brooks、1975）。

無数の開発チームが仮説を確認しています。 ブルックスとコンウェイの法律が基盤となっています。



新しい人に参加するとき、チームは物事の紹介、使用されるトリックとデバイスの説明に努力します。 参加者は、新人との情報交換と同期、チームワークの学習、知識の伝達に時間を費やします。 作業が遅くなっています。



新鮮なスタッフは、最初の週だけでなく助けを必要とします。 一部の著者（たとえば、KoplienやHarrison）は、初心者から生産性を得るまでに1年の間隔を想定しています。 さまざまな要因の影響により、声明をあまり重要にしないでください。 一部の従業員は最初の3か月間は助けなしで行動すると想定するのは理にかなっています。



チームは、新しい人が到着するずっと前に物事を遅くすることができます。 従業員はただ起こるだけではありません。 人事マネージャーは、私的利益のために行動し、より多くのリソースを要求することがあります。 職務内容の記述、確認、公開、人事部門へのリダイレクト、人材紹介会社への送信が必要です。 プロセスの承認には時間がかかります。



履歴書を検討し、拒否または面接の要請のいずれかを書かなければなりません。 候補者が承認されると、契約が作成され、チームへの入場の提案が送信されます。



手順は、人がコード行を書く権利を取得するまで通過します。 人事部門がほとんどのプロセスをリードしていても、チームリーダーや一般のメンバーは気を散らされます。 実際の作業と開発の時間が短縮されます。



ブルックスの法律は、チームの拡大を完全に拒否することを意味するものではありません。 しかし、統一の成長はめったに起こりません。 チームが拡張することを決定した場合、パフォーマンスの一部がキャパシティの構築に使用されます。



リチャード・シェリダンは大胆な声明を発表しました。

ブルックスの法律に違反する可能性があることを報告できてうれしいです。 私たちの活動はすべて、声明を破ることに集中しています。 人々をペアに分割し、ペア間を移動し、テスト自動化、コード管理、ヒーロー以外の採用、進行中の交渉、オープンな作業環境、目に見えるアーティファクトはすべて、ブルックスの声明に反論するものです（Sheridan、2013）。

この本では、著者はほとんどの開発者と管理者にとって実際の環境とは異なるソフトウェア開発環境を紹介しています。 メンロは、独自の文化とコミュニティの構築、参加、強化を軽視していません。 企業が実際にアプローチを試みるまで、研究するのに十分な例がなく、シェリダンのサンプルをコピーする価値があるかどうかを判断するのは困難です。



著者が説明した方法は信頼できます。 さて、ブルックスの法律に違反した場合。

コンウェイ法

システムを設計する組織...これらの組織で開発された通信構造をコピーしてシステムを作成し、

-コンウェイ、1968

人とその組織は、開発者が採用するソフトウェアアーキテクチャを決定する上で重要な役割を果たします。



政府による新しい社会保障制度の創設を想像してください。 データベース、インターフェイス、ビジネスロジックが必要です。 開発者とテスター、費用のかかる管理、要件の設定などが必要になります。



その結果、結果は目に見える形になります。ユーザーロール、ワークフロー、データフォーム、レポートが定義されます。 この時点で、あなたは同意しなければなりません、より小さいか根本的に異なるシステムの作成はすでに不可能です。



10年間の運用後のシステムをご覧ください。 コンウェイの逆の法則が守られています：

ソフトウェアシステムを使用する企業は、このシステムを複製する通信構造に限定されます。

Conwayの法律は、インターフェース、つまりレイヤー、APL、モジュール、またはその他の場所での企業問題のコピーの可能性について報告しています。



チームとソフトウェアシステムを編成するときは、Conwayの法律を考慮する必要があります。 故意または無知で原則を破ろうとすると、プロジェクトに反対する勢力が生まれます。 木材を繊維に分割したいようです。 コンウェイの法律を尊重して使用する方が賢明です。

ダンバー番号。 自然のランドマーク

「サルの中の人々の外挿は、社会的集団の規模のアイデアを与えます。 約150人-人間の社会的関係の限界。 番号には「ダンバー番号」という名前が与えられ、

-ダンバー、2010

開発グループからの一般的な質問は、「チームの大きさはどれくらいか？」です。人類学者のロビンダンバーの研究は、質問に答えようとするときに興味深いアイデアを提供します。



著者は、150が人々の組織の上限であるという説得力のある議論を提供しています。 ダンバーは、古代ローマ以降、新石器時代の入植地、アーミッシュのコミュニティ、そして現代の研究グループでの軍隊の数に注目しました。



150を超えるメンバーのコミュニティは凝集性が低く、動作と階層の制御を強化する必要があります。 研究と分析は、グループの形成における主要なポイントを強調しています。 パラメータを「ダンバー番号」と呼ぶ方が良いです。 特性は、大規模なフォーメーションに含まれるさまざまなグループに適用されます。 小規模なチームはより強力であり、仮定により、係数3の数値に依存しています。

論文に続いて、ほとんどの人には3人から5人の親しい友人がいます。 10人から13〜15人までの次のレベルの友人（多少の努力が必要）。 次のグループには30から50が含まれます-典型的な戦闘小隊です。 人口150人は、軍事会社で最小の独立したブロックを表し、企業で個別のグループを作成するポイントです。



Dunbarは、500と1,500のフォーメーションの存在を示唆しています。著者は、プラトンが5300ユニットの民主主義の理想的なサイズを決定することを支持しています。 軍事ユニットの規模の間に興味深い類似点を描くことができます。

組織	大きさ
消防隊	4人以下
セクション/分隊	8-12人の参加者（いくつかの消防隊）
小隊	15〜30人の従業員（2チーム）
会社	80〜250人の兵士（複数の小隊）
大隊	300〜800人の戦闘機

リストは有限ではありません。 国間の違いを忘れないでください。 ある軍事組織の側面の特性についてもです。 しかし、広義では、ブロックサイズはダンバーの調査結果に従います。

ミラーズマジックセブン（ミラーズウォレット）

7人のチーム（±2）の規模の賢明な選択であると考えられています。 声明には実用的な意味はありません。 5〜9人の最適なチームメンバー数に関する論文の証拠はありません。



サイズの支持者は、Millerの有名な1956年の記事、The Magic Number SevenとMinus Two：情報処理能力の制限に訴えます。 実際には、引用文献のほとんどは読まれていません。



この記事で、Millerは、人間の脳の処理能力の能力を説明するための7は重要な数字であると主張しています。 選択された図は、思考センターによる同時処理のための情報の「断片」の最大数を決定します。 著者は、数7の頻繁な繰り返しの解釈があいまいであるという結論に達します。

「現時点では、明確な判断を控えることをお勧めします。 おそらくこれらの七つの深みには、発見する必要のある重要な何かがあります。 しかし、私はすべてが悲惨なピタゴラスの偶然であることが判明するだろうと思います。」

7つの魔法の重要性は疑わしい。



結論として、著者は次のように述べています。「私の話はすでにおもしろくなっているので、ここでやめるべきだと思います。」 Millerの記事が公開されてから50年以上が経過しました。 すべてのアカウントで、変更を管理するには5〜9人のチーム範囲で十分です。 間隔の底から、専門家チームのテストと要件を満たす必要性が正当化されます。 範囲の上限では、システムを完全に制御することは困難です。 したがって、5〜9人の従業員の数は理にかなっています。



記載されている量は、状況に応じて、より大きなチームの存在を妨げるものではありません。

スクラム方法論におけるチームサイズ

人間の脳による情報処理の量に関するミラーの記事は、ソフトウェア開発チームの規模の決定にどのように適用されますか？ スクラムの方法論を見てみましょう。 教科書には、「スクラムのチームは7人のプラスまたはマイナス2人でなければならない」（Dimer et al。、2008）。 同時に、2011年のスクラムガイドには次のように記載されています。「9人を超えるメンバーのチームは、調整の問題が多すぎます。 大規模な開発チームは、プロセス全体を大幅に複雑化します」（Sutherland and Schwaber、2013）。



スタディガイドには次のように記載されています。

プロダクトオーナーとスクラムチームの責任者の役割は、次のスプリントのバックログを削減する作業に含まれていない限り、計算に含まれません。

-サザーランドとシュヴァーバー、2013

同時に、スクラムチームリーダーの紹介は、製品所有者がチームの外にいることを示唆しています。



他の情報源は、グループメンバーを特定し、「参加するだけ」のさまざまな推奨事項を提供しています。



4〜8人の範囲のチームがどこにでも見えます。 Millerの記事は、グループサイズの選択を7±2から合理的に実証しています。経験により、最適な数の制限が確認されています。 この量は、スクラムのソースに記載されている量を超える場合があります。

パーキンソンの法則とホフスタッターの法則

作業は、その実装に割り当てられたすべての時間を埋め、

-パーキンソンの法則

ホフスタッターの法則を知っていたとしても、予想以上に時間がかかります。

-1980年ホフスタッター法

質問に答えてみましょう。「大学で勉強したことを覚えていますか？ タスクはどの時点で行われましたか？」ほとんどの読者は、締め切りの数日前に作業を行いました。 一部は降伏の前夜にプロジェクトに従事していました。



そして、大多数は締め切りに収まります。



科学者は、人々が仕事を完了するのに必要な期間を見積もるのはうまくいかないことを確認しますが、明確に合意された日付までに問題を解決することに成功します（例えば、Buehler、Griffin and Peetz、2010）。



プロジェクトに時間がかかりすぎる場合、請負業者による作業範囲の過剰な拡大が発生します。



ソフトウェアの開発は、パーキンソンおよびホフスタッターの法律の影響を受けます。 締め切り日を選択すると、必然的に必要な時間が過小評価されます。 その結果、作業の条件と範囲が増加します。 ある研究（Buhler、Griffin and Pitz、2010）は、タスクが完了した日付について楽観的に見れば、悲観的な時間枠の推定よりも早く作業を実行できることを示唆しています。 しかし、楽観主義者によるプロジェクト全体のリードタイムは、悲観主義者よりも長くなります。 締め切りは、推定プロジェクト完了時間よりも重要かもしれません（Arily and Wertenbroch、2002）。

ゴルの法則。 パルナッソスとアレクサンダー

複雑な作業システムは、常に単純な作業システムから派生します。 ゼロから設計された洗練されたシステムは決して機能しません。 また、改善しても機能しません。 シンプルな作業システムから始めてください。

-1986年ゴルの法則

法律は、デイビッド・パルナソスの言葉を反映しています。



「原則として、ソフトウェアシステムは、「戦闘」条件で使用されるまで、また複数回使用されるまではうまく機能しません。



著者は、クリストファー・アレクサンダーによって「有機的成長」と呼ばれる現象のさまざまな側面を強調しています。



「ウォーキングスケルトン」と呼ばれる手法を使用してソフトウェアを作成するときは、シンプルで基本的なコードを作成することをお勧めします。 スケルトンは、ある程度のリスクはありますが、システムを前進させています。 ベースを作成した後、チームは機能のレイヤーである「肉」を追加します。



この原則は、グループ、ソフトウェアに適用できます。



「効果的で複雑なチームは、常に生産性の高い単純なチームから生まれます。 ゼロから組み立てられた複雑なチームは効果的に機能できません。 また、変更しても機能しません。 すでにワークアウトされたチームから始める価値があります。」



複雑なチームと大規模なチームの間に類似点を描くことができます。 法律は、大規模なグループを作成する方法、関連付けをスケーリングするための柔軟な方法論を示唆しています。



コンウェイの法則との関係は明らかです。「ウォーキングスケルトン」の構築は、チームのバックボーンに基づいています。 大きく複雑なフォーメーションを作成するには、同等のスケルトンスケルトンが使用されます。



最初に大規模な構造を構築する場合、Conway Lawは大きく複雑なアーキテクチャを予測します。 ゴルの法則は、動作不能システムの出現について述べており、期限に間に合わせるために少ない時間で開始するようチームに助言しています。

ケリーの法則

記事の著者からの有用な仮説をいくつか追加する必要があります。

ソフトウェアの規模は、利用可能なリソースに比例して常に増加しますが、

-ケリーの第一法則

各大規模開発プロジェクト内には、メインタスクの外側に小さなサイドプロジェクトがあります。

-ケリーの第二法則

独自の規模を正当化する特大チームは、より多くの労力、面倒なソリューション、および洗練されたアーキテクチャを提供します。 グループメンバーの意思に反して削除するよりも追加する方が簡単です。



初期段階でもチームの規模を小さく保つことで、シンプルで簡潔なソリューションを見つけることができます。 大規模なチームから始めると、面倒な実装が保証されます。

おわりに

ダンバー番号は、効果的なチームのサイズ制限を決定します。 コンウェイの法則に基づいて、システムの潜在的な制限について話すことができます。 公理を回避する唯一の方法は、大規模なシステムをコンパクトなグループに分割することです。 チームは完全に形成され、効果的ではありません。 コンウェイの法則は、ゴルの論文と連携して機能します。 グループは徐々に成長する必要があります。 ブルックスの仮定は、チームがあまりにも早く拡大できないことを意味します。 パーキンソンの法則は、自分たちの存在を維持する非常に大きなチームの雇用を意味します。



ケリーの2番目の仮説は解決策を示唆しています。大きなものを避け、小さなものに焦点を合わせます。



法律に反対するのではなく、アプローチを見つけて条項を使用する方がよいでしょう。 法律に対処する方法を見つけようとする試みは、少なくとも上位の当局に対して下された決定を正当化するためにそれらを使用する場合、商業的に利益を得ることができます。



この記事は、アラン・ケリーの新しい本「Xanpan Book 2：A Tool of Production」からの抜粋です。 2015年末に利用可能になります。