プロジェクトに割り当てられた人数と欠陥の数の間には本当に関係がありますか？
SLIMとソフトウェアの見積もりに関する作業中のトレーニングマニュアルからの引用は次のとおりです。
また、EffortとDefectsの間には相関関係があります。つまり、特定のサイズのプロジェクトに割り当てられる人数が多いほど、欠陥が多くなります。
作業量は、プロジェクトの個人時間（個人年、個人月）です。欠陥は、ライフサイクルの任意の時点で検出された欠陥の数です。サイズは、プロジェクトを構成するユースケース、機能ポイント、またはSLOCとして定義されます。
優れたプロセスと有能なエンジニアを想定すると、これは直感に反するようです。たとえば、人が増えるということは、すべてのアーティファクト（要件の仕様、設計、コード、テスト）に目を向けることを意味します。私の直感は、より多くの目を持っていることを除けば、適切な品質の技術を利用するプロジェクトでは、努力と欠陥の間にほとんど関係がないことを示唆しています。
パトナムモデル（SLIMで使用されている）に関するものを除いて、欠陥と努力、または欠陥とプロジェクトの人数との間の既知の関係を示唆する文書を見つけることができませんでした。これは既知の関係ですか？「より多くの人々=より多くの欠陥」という主張は有効ですか？
私の直感は次のようになります。
特定のサイズのプロジェクトに割り当てられる人が多いほど、通信のオーバーヘッドが大きくなります
=>誤解やあらゆる種類のコミュニケーション問題の可能性が高い
=>結果として生じる欠陥の数が多いほど。
そして
良い開発者は平凡な/悪い開発者よりもまれであり、したがって見つけて雇うのが難しい
=> 特定のサイズのプロジェクトに割り当てられる人が多いほど、彼らの平均的な能力レベルは低くなります
=>結果として生じる欠陥の数が多いほど。
しかし、これらは私の推論に過ぎないかもしれません。私には裏付けとなる証拠がありません。
ちなみに、以下で強調されているあなたの仮定は、私たちの職業の状態を考慮に入れて、IMHO（悲しいことに）かなり強いです：
これは直感に反しているように見えます優れたプロセスと有能なエンジニアを前提としています。 [...]私の直感は、適切な品質技術を使用するプロジェクトの努力と欠陥の間にほとんど関係がないことを示唆しています。
それは単なる相関関係かもしれません。管理は、彼らがより複雑であると考えるプロジェクト、または多くの非永続的なバグのために遅れているプロジェクト、またはさまざまなコンポーネント間の多くの結合を必要とするプロジェクトを支援するためにより多くの人々を割り当てる傾向があります。もしあなたが管理の決定をミックスから取り除くことができたなら、私は逆ではないとしても、相関関係は少なくとも減少すると思う。
サイズと労力の最近更新された定義を考えると、おそらく結果は、労力（総工数）が実際にはソースが使用している測定値よりも実際のプロジェクトサイズのより良い推定量であるという事実によるものであることを示唆します（労力はすべてのチームとチームのリソースが同等である場合の完璧な尺度）。
したがって、実際に起こっていることは、大規模なプロジェクトにはより多くの欠陥があるということです。これはまったく驚くべきことではありません。
優れたプロセスと有能なエンジニアを想定すると、これは直感に反するようです。
どちらも現実の世界では想定できないと思います。プロジェクトに参加する人が多ければ多いほど、追いつけない悪いリンゴができて、最高の開発者のペースが遅くなる可能性が高くなります。あなたが仮定に従えば、あなたが人々の数を増やすにつれてプロジェクトを遅くし、より多くの欠陥を引き起こす他のいくつかのことがあります：
- 通信オーバーヘッド
- コード読み取りのオーバーヘッド（つまり、最高の開発者でさえ、自分のコードよりも他の人のコードの読み取りと使用に時間がかかることを意味します）
- テストはより綿密である必要があります（私たちはすべて100％のテストカバレッジを目指しますが、現実の世界ではめったに起こりません。プロジェクトに参加する人が増えるほど、変更を期待しているだけなので、徹底的な自動テストを行わなければ、恐ろしいリファクタリングが実現します副作用はありません。すべてのテストを合理的な方法で自動化できるわけではなく、さらに時間がかかります。）
私の経験では、プロジェクトが非常にモジュール化されていて、層ごとに1人か2人しかいない場合、開発者がロードされたプロジェクトの悪影響は大幅に減少します。たまたま使用しているバージョン管理システムは関係ありません。4人の開発者全員が一度に同じファイルにチェックインを自動マージするのはおそらく悪い考えです。
相関関係と因果関係には違いがあります。引用は、より多くのエンジニアが割り当てられているプロジェクトでは、欠陥の総数が多くなる傾向があると言っているようです。これは私には完全に理にかなっています。MSWindowsには、私が作成したアプリケーションよりも多くの欠陥があると確信していますが、それは私のアプリケーションが優れた品質であることを意味するわけではありません。
別のより抽象的な例を挙げると、国ごとの総死亡数を取り、それを国内の医師の総数と相関させると、「医師の数が多い国ほど死亡数が多い」と言えるでしょう。これは、医師が死を引き起こしたからではなく、医師の数が多いことから、人口が多いことを示しています。
人数についての主張はさておきましょう。
欠陥の数とソフトウェアのサイズの間には強い相関関係があるため、努力の関数として欠陥の数を見る注入されたは、努力の増加には必然的にサイズの増加が必要であると想定する限り、理にかなっています。
したがって、プロジェクトに多くの労力をかけると、より多くのコード行が書き込まれると想定すると、おそらく、努力をサイズのプロキシとして使用して、欠陥の数を予測できます。サイズ（LOCなど）と欠陥の数との相関関係は、Watts Humphrey、CapersJonesなどの研究で何度も示されています。
人数が多いということは、努力が必要なことを除けば、人数がどのように収まるのかわかりません。
補足として、因果関係との相関関係を混同しないでください。サイズと注入された欠陥の数の間には相関関係がありますが、サイズは原因ではありません。あなたが指摘したように、原因は通常、人とプロセスの問題から生じます。とはいえ、サイズの関数としての欠陥は、問題があるかどうかを理解し、変更の効果を測定するための優れた指標です。
これはコアプログラミングチームのメンバーに限定されており、UI、UX、DBAなどのスペシャリストがいる状況ではないと思います。
うまく管理する必要があると思いますが、それは簡単ではありません。質の高い開発者で構成される小さなチームは、自分で管理できます。コードの大部分が才能の少ない人を作成することを避ける可能性が高くなります。
チームメンバーが増えると、職務の分割が容易になります。より良いまたはより経験豊富な開発者を困難な領域に置きます。ありふれたタスクやプログラミング以外のタスクの一部を優れた開発者から遠ざけ、後輩の開発者に中断を処理させます。これにはより多くの計画と思考が必要になりますが、あなたの才能を活用する機会を提供します。
新しいスキルを習得する必要がある優れた開発者が、すでにそれを知っている平均以下の開発者よりも優れているという考えがあります。時間があれば、これは素晴らしいことです。おそらく、より多くの開発者がプロジェクトに割り当てられている理由は、必要な作業量と時間制限のためです。あなたは特定の分野に集中し、より熟練することができる誰かを持っているかもしれません。その包括的な知識を持っていることは素晴らしいことですが、時には少しの指示があれば、より少ない開発者がいくつかの指示を受けてそれを実行することができます。
現実には、成功したプロジェクトで大規模なチームを管理したことのある人はそれほど多くありません。彼ら全員が才能があるとしても、大規模なチームが自己管理することは困難です。エゴは邪魔になりますか？