チームを通じて能力をどのように分配する必要がありますか？
this を読んだ後、さまざまな能力を持つ開発者のグループ（別名ほぼすべてのチーム）内でアジャイルチームをどのように構成するかについて多くの意見の相違があるように思われることがわかりました。すべての最高の開発者を自分のチームに配置し、最優先の作業を与える必要がありますか？これにより、最も重要なタスクが確実に実行されます。同時に、優先度の低いタスクのみを行っている場合でも、他の場所で「完璧とは言えない」チームが技術的負債を抱えていることになります。一方、均等に分散されたチームは、遅れている開発者を少し良くするという利点がありますが、最も重い打者をやる気にさせる可能性があります。また、優れたデザインパターンの束とひどいアンチパターンの束を混ぜ合わせると、アンチパターンの束になる可能性のあるものになってしまう可能性があります。すべてのチームには強力なコーダーとそれほど強力ではないコーダーがいますが、これはどのように対処する必要がありますか？
A-Teamにはいくつかの既知のリスクがありますが、ダイナミクスが正しければ、私は最強の人々を最も重要なプロジェクトに、最も可能性のあるジュニア開発者と一緒に配置します。優先度の低いプロジェクトでは、可能であれば、Railsから遠く離れないようにするための優れたチームリーダーが必要です。技術的負債は何があっても起こりそうです。すべての技術的負債が等しいわけではありません。技術的負債のコスト/責任は、そもそもプロジェクトのビジネス価値に比例するため、優先度の低いプロジェクトにはいぼが多い可能性がありますが、優先度の高いプロジェクトの重大な問題よりもはるかに少ない可能性があります。あります。
私が大学にいたとき、私たちの教授の1人がチーム構造についての逸話を教えてくれたのを覚えています（彼が今話している論文を探しましたが、見つからないようです）。
基本的に、ストーリーは次のようになりました。
プログラマーのグループは、能力に基づいてグループに分けられ、最悪のxプログラマーがグループ化され、次のxプログラマーがグループ化され、最高のプログラマーがグループ化されました。
それらはすべて同じタスクを割り当てられ、それを完了するための設定された時間枠が与えられました。
時間枠の終わりに、主催者はタスクの解決策を検討しましたが、驚いたことに、最高のパフォーマンスを発揮する解決策は平均的な人々で構成されるチームからのものであることがわかりました。対照的に、A *プログラマーで構成されたチームは、最悪の解決策の1つを作成しました彼らはすべての時間を最善の解決策について議論するために費やしたため。
あなたが物事を成し遂げるチームが必要な場合は、平均的な男とリードできる支配的な男をたくさん手に入れてください（私が正しく覚えていれば）、そうでなければ、より支配的なメンバーは得るよりも戦いに多くの時間を費やしますやった！
教えることができない人は...
考慮すべき要素は他にもあると思います。
チームリーダーとして教えることができるものを配布することで、最大の価値を得ることができます。彼らはチームの他のメンバーに教え、彼らの仕事の質を高めるのを助けることができます。
すべての上級プログラマーが良いリードをするわけではありません。情報を伝達するその能力は、それ自体がスキルです。このスキルは、プログラミングの経験を通じて発達するものではありません。それは教え、説明することを通して発展します。
経験の浅い開発者の大多数は、堅牢でエレガントなデザインを自分で思いつくことはできないかもしれませんが、それを見るとそれを認識して理解することができます。できない場合は、通常、そもそも採用されるための適性や準備が不足しています。
非常に複雑なソフトウェア設計を理解できるが、より単純なものがいつより良いかを知る裁量を欠いている、より経験豊富な開発者もいます。
私の経験では、通常、混合チームに永続的な問題があるのは、準備の整っていないメンバー、不必要に複雑なメンバー、またはその両方が含まれている場合のみです。それ以外の場合、チームに問題がある場合は、通常、より良いコミュニケーションまたは適切な役割の割り当てで修正できます。
最高の人材を単一のチームにグループ化することは、優れた短期的な解決策のように見えますが、長期的な範囲では失敗であり、追加のコストがかかります。たとえば、私の会社は、人々がトレーニングにお金を払うよりも、より熟練した同僚から学ぶことを好みます。最高の人を分離すると、スキルの低い人に知識を伝えることができなくなります。短期的にはあなたの最高のチームはうまく機能することができますが、知識の伝達が不足しているため、熟練した人々の数は増えません。最初はパフォーマンスの低いチームを用意し、スキルが上がるにつれてすべてのチームのパフォーマンスを向上させることをお勧めします。
さらに、熟練した人々が去ることを決定した場合はどうなりますか？誰が彼らのプロジェクトを引き受けますか？
もう1つのポイントは、チームはさまざまなスキルセットを持つ人々で構成される必要があるということです。あなたは常に簡単なタスク（そして退屈なタスク）を抱えていますが、それは最も上級の開発者が行うには費用がかかりすぎます。
「A」チームの割り当てには、2つの重要な問題があります。 1つ目は互換性です。仲良くして一緒にうまく働くチームを持つことは、彼らの「能力」よりもはるかに重要です。これは、2人の「高」スキルプログラマー、2人の「低」スキルプログラマー、またはそれらの組み合わせである可能性があります。彼らが一緒にうまく働くことができるという事実は、彼らがより生産的になることを意味します。
2番目の問題は成長を扱っています。 2人の「低い」スキルのプログラマーは、悪い習慣を除いて、お互いから多くを学ぶことはありません。同様に、2人の「高度な」熟練したプログラマーはお互いから多くを学ぶことはありません。ただし、「低」と「高」のスキルレベルを組み合わせると、「低」スキルの能力が向上し、「高」スキルの能力も向上します。どのように？科目を教えようとすると、その弱点がすぐに見つかります。主題。他の誰かに教えることができるまで、私はスキルを「習得した」とは見なしません。
コインの反対側からは、お互いに「追いつく」ことができるチームを維持することは理にかなっていると思います。 A-Teamタイプのプログラマーは、B-Teamタイプがビットを完成させるのを待ちたくありません。 Bチームのタイプは、Aチームスタイルのワークフローによって促進される可能性があります。