チームを通じて能力をどのように配分すべきですか?


9

これを読んだ後、さまざまな能力を持つ開発者のグループ(別名ほとんどすべてのチーム)内でアジャイルチームをどのように構成すべきかについて、多くの意見の相違があるように見えました。優秀な開発者全員を自分のチームに配置し、最も優先度の高い仕事を与えるべきですか?これにより、最も重要なタスクが確実に実行されます。同時に、優先度の低いタスクのみに関係する場合でも、技術的負債を抱える「完璧ではない」チームが残ります。一方、均等に分散されたチームは、遅れている開発者を少し良くする利点がありますが、最も重い打者をやる気にさせる可能性があります。また、一連の優れたデザインパターンとひどいアンチパターンを組み合わせると、最終的にはアンチパターンの束になる可能性があります。


これは、programmers.stackexchange.com / questions / 76890 /…のようです。
S.Lott

@Lott似ていますが、それは私が正しく覚えているかどうかを過度に支配的な開発者に確認しておくことを指します。
Morgan Herlocker、2011年

2
ほとんどのまともなキャラクターシステムでは、タレントポイントを定期的に再配分できます。
FrustratedWithFormsDesigner

1
最近、Mass Effect 2(および他のゲーム)が多すぎます。:P
FrustratedWithFormsDesigner

回答:


11

Aチームには既知のリスクがいくつかありますが、ダイナミクスが正しければ、そうだと思います。私は、最強の人々を、最も可能性のあるジュニア開発者と共に、最も重要なプロジェクトに参加させます。優先度の低いプロジェクトでは、可能な限り、プロジェクトが軌道から離れないようにするために、優れたチームリーダーが必要です。技術的負債は何があっても発生します。すべての技術的負債が等しいわけではありません。技術的負債のコスト/負債はそもそもプロジェクトのビジネス価値に比例するため、優先度の低いプロジェクトではいぼが多くなる可能性がありますが、それらのコストは、優先度の高いプロジェクトでの重大な問題よりもはるかに少ないでしょう。あります。


7

私が大学に行っていたときに、チームの構造についての逸話を語っている教授の1人だったときのことを覚えています(彼が今話している論文を探しましたが、見つけられないようです)。

基本的に、物語は次のように進んだ:

プログラマーのグループは、能力に基づいてグループに分割されました。最悪のxプログラマーはグループ化され、次のxプログラマーはグループ化され、さらに最高のものはグループ化されました。

彼ら全員に同じタスクが割り当てられ、それを完了するための設定された時間枠が与えられました。

期間の終わりに、主催者はタスクのソリューションを検討しましたが、驚いたことに、平均的な人々で構成されたチームが最高のパフォーマンスを発揮するソリューションであることを発見しました。対照的に、A *プログラマーで構成されたチームは、最悪のソリューションの1つを作成しました

物事を成し遂げるつもりのチームが必要な場合は、平均的な人と主導権を握る支配的な人の束を集めてください(私が正しく覚えていれば)研究の結論でした。出来上がり!


1
はい、これはAチームの主要な問題の1つですが、この調査に基づいてすべてのチームに普遍的に適用されると結論するのは誤りです。
ジェレミー

同意:全員が同じであるわけではなく、同等のグループが同じダイナミクスを持つこともありませんが、それでもそれは良い逸話です!
エドジェームス

1
まあ、一緒にそのすべての書き込みのみ経路探索アルゴリズムを開発者の束を入れて、これは...あなたが得るものです
スティーブン・エヴァース

笑-教授がその場でストーリーを作成したため、論文を見つけることができません。;-)
Steven A. Lowe

それは私を驚かせないでしょう:D
エド・ジェームス

3

経験の浅い開発者の大多数は、堅牢でエレガントなデザインを自分で思いつくことはできないかもしれませんが、デザインを見たときにそれを認識して理解することができます。それができない場合、彼らは通常、そもそも採用されるべき適性または準備のいずれかが欠けています。

また、非常に複雑なソフトウェア設計を理解できる経験豊富な開発者もいますが、単純なものがより良い場合を知る裁量がありません。

私の経験では、準備されていないメンバー、不必要に複雑なメンバー、またはその両方がチームに含まれている場合、通常、混合チームに永続的な問題が発生します。それ以外の場合、チームに問題がある場合、通常はより良いコミュニケーションまたは適切な役割の割り当てで修正できます。


私はあなたの最初の段落から、開発者の需要が供給を超える環境で働いていないことを想定することができます。私たちの多くはそうします。:-)
Carson63000

3

優秀な人々を単一のチームにグループ化することは、優れた短期的なソリューションのように見えますが、長期的な範囲では失敗であり、追加のコストがかかります。たとえば、私の会社では、トレーニングにお金を払うのではなく、よりスキルの高い同僚から学習することを好みます。あなたが最高の人を分離すると、彼らは知識の低い人に知識を移すことができなくなります。短期的には、最高のチームはうまく機能しますが、知識の移転が不足しているため、熟練したスタッフの数は増えません。初めはチームのパフォーマンスが低く、スキルが向上するにつれて、すべてのチームのパフォーマンスを向上させることをお勧めします。

さらに、熟練した人々が去ろうと決心したらどうなりますか?誰が彼らのプロジェクトをとりますか?

もう1つのポイントは、チームは異なるスキルセットを持つ人々で構成される必要があるということです。あなたは常に簡単なタスク(そして退屈なタスク)を抱えています。


3

教えることができないもの、すること...

考慮すべき要素は他にもあると思います。

チームのリーダーとして教えることができる人々を配布することにより、最大の価値を得ることができます。彼らはチームの他のメンバーに教え、彼らの仕事の質を高めるのを助けることができます。

すべての上級プログラマーが良いリードをするわけではありません。情報を伝達するその能力は、それ自体がスキルです。このスキルは、プログラミングの経験を通じて発達するものではありません。それは教育と説明を通して発達します。


私は同意しますが、同時に、他の開発者によって書かれたコードから学ぶことができます。上級開発者がチームの一員でない場合、この方法で彼らから学ぶことはできません。
Ladislav Mrnka

@Ladislav Mrnka:シニア開発者をさまざまなチームに分散すべきではないと言っているのではありません。コードから学ぶ能力は異なります。これは、開発者が多くの人がしないコードから学ぶのに時間がかかることも想定しています。
Dietbuddha

2

「A」チームの割り当てには、2つの重要な問題があります。最初は互換性です。チームが協力してうまく連携することは、その「能力」よりもはるかに重要です。現在、これは2人の「高」スキルプログラマ、2人の「低」スキルプログラマ、またはそれらの組み合わせです。彼らがうまく連携できるという事実は、彼らがより生産的になることを意味します。

第二の問題は成長についてです。2人の「低」スキルプログラマーは、悪い習慣を除いて、互いに多くを学ぶことはありません。同様に、2人の「高度な」熟練プログラマーは互いに多くを学ぶことはありません。ただし、「低」スキルレベルと「高」スキルレベルを混在させると、「低」スキルの能力が向上します。また、「高」スキルの能力も向上します。科目を教えると、短所がすぐにわかりますあなたがそれを他の誰かに教えることができるようになるまで、私は「マスターされた」スキルとは考えません。


1

コインの裏側からは、互いに「追いつく」ことができるチームを維持することは理にかなっていると思います。Aチームタイプのプログラマは、Bチームタイプの処理が完了するのを待ちたくありません。Bチームのタイプは、Aチームスタイルのワークフローに密接に関係している場合があります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.