プロジェクトで開発者を交代させることは良い考えですか、悪い考えですか？
私は別の小さなチームと一緒に大きな新しいプロジェクトに取り組み始める小さなチームに取り組んでいます。他のチームは現在、長年取り組んできたレガシーシステムに取り組んでいます。
マネージャーは、私のチームの開発者がレガシーシステムで作業している開発者を置き換えるために数か月ごとにローテーションすることを決定しました。そうすれば、他のチームが新しいプロジェクトに取り組み、新しいシステムをよりよく理解できるようになります。
2〜3か月ごとにプロジェクトから開発者をローテーションするメリットとデメリットがあれば知りたいです
これは "リード開発者をローテーションすることは良いアイデアか悪いアイデアか？" と同様の質問であることは知っていますが、その質問はリード開発者に焦点を当てています。この質問は、チーム全体をプロジェクトのオン/オフにローテーションすることに関するものです（新しいプロジェクトの技術リーダーはローテーションされる場合とされない場合があります-まだわかりません）。
これはとても良いことだと誰もが思っていることに驚きます。 Peopleware の著者（これはIMOであり、実際に読む価値のある貴重なソフトウェアプロジェクト管理の本の1つです）は強く反対します。本のパートIVのほぼ全体がこのまさにこの問題に捧げられています。
ソフトウェアteamは、非常に重要な機能単位です。チームは本当に生産的になるために叫ぶ必要があります。チームメンバーがお互いの尊敬を獲得し、お互いの習慣や癖、長所と短所を学ぶには時間がかかります（時間はlot）。
確かに、個人的な経験から、特定の人々と1年間働いた後、私を怒らせるのに使用されていた特定のことを笑い飛ばすことを学んだ、チームのリーダーとしての私の見積もりははるかに優れており、それほど難しいことではありません。作品を配布して、みんなを幸せにする。最初はそうではなかった。
さて、「ああ、でも私たちはチーム全体を解体するのではなく、数人を動かすだけです」と言うかもしれません。ただし、（a）最初からどれほど盲目的に非生産的であるかreplacementsが発生するか、（b）自分や他のチームが何も考えずに言っていることが何回あるか"私はXが本当に好きだった]または"これはYがいれば簡単だったでしょう "、微妙かつ無意識に新しいメンバーを怒らせ、既存のチーム内で分裂を引き起こし、さらに"古い」メンバー。
人々はこれをしません意図的にもちろん、それはほとんど毎回起こります。人々は考えずにそれをします。そして、彼らが自分自身に強制しないと、彼らは問題にさらに焦点を合わせてしまい、強制された沈黙に苛立ちます。チームやサブチームでさえ、相乗効果が生まれ、構造物をねじ込むと失われます。 Peoplewareの作者はこれを「殺人」の形と呼んでいます。
そうは言っても、回転チームメンバーは恐ろしい慣行ですが、回転チーム自体は完全に問題ありません。適切に運営されているソフトウェア会社は製品の所有権の概念を持っている必要がありますが、チームが実際に古いプロジェクトを完了したり、少なくともプロジェクトに参加したりする限り、チーム全体を別のプロジェクトに移動することは、チームにとってそれほど混乱を招きません。彼らが満足しているレベルです。
developer stintsの代わりにteam stintsを使用することで、ローテーションする開発者に期待されるすべての同じ利点（ドキュメント、「他家受粉」など）なしで得ることができますユニットとしての各チームへの厄介な副作用。管理を本当に理解していない人にとっては、生産性は低く見えるかもしれませんが、チームを分割することによって失われる生産性は、そのチームを別のプロジェクトに移動することによって失われる生産性を完全に小さくします。
PS脚注で、技術リーダーはonly person notである可能性があると述べています回転。これは、混乱を招くことがほぼ保証されていますbothチーム。技術リーダーはマネージャーではなくリーダーであり、チームの尊敬を得る必要があり、より高いレベルの管理者から権限を付与されるだけではありません。チーム全体を、これまで一緒に作業したことがなく、アーキテクチャ、使いやすさ、コード編成、見積もりなどについてさまざまなアイデアを持っている可能性が高い新しいリードのもとに置くことは、地獄のようにストレスになるでしょう古いリードがないと結束を失い始めるチームメンバーにとって信頼性を構築しようとするリードと非常に非生産的です。場合によっては、企業がhaveこれを行う場合があります。つまり、リードが終了したり昇格したりしますが、choiceでそれを行うと、非常識に聞こえる場合があります。
私自身、ここには多くの欠点は見られません。回転はあなたを取得します：
- 制度的知識の相互受粉-少なくとも理論的には、誰もが古いプロジェクトと新しいプロジェクトを知っています。
- クロストレーニング-プロジェクトが異なれば、必要なことも異なります。開発者は、すてきでクリーンなグリーンフィールドプロジェクトよりも、醜いレガシープロジェクトで作業する方がはるかに成長します。
- 根本的に優れたプロジェクト-ドキュメントを完成させて、公然とは認めないが、喜んで生きる醜いプロセスをクリーンアップするために、新しいチームがやって来るようなものは何もありません。
- 優れたコード-ほとんどの場合、ヘッドが多いほど優れています。
- おそらく士気の向上-多様性は人生のスパイスです。そして、誰がレガシープロジェクトのバグ修正/ダクトテーピングモードで永久に動かされたくないのか。また、「新しい」プロジェクトがいつかレガシーになることに注意してください。そこに永久にとどまりたいですか？
おそらく唯一の欠点は、場所を切り替えることによる生産性の低下ですが、それは最初のラウンドに悪影響を与えるだけです。その後、両サイドで両方の場所にいくらかの座席時間が確保され、ハンドオフの醜い部分がおそらくよりよく理解され、おそらく解決されるでしょう。
興味深いことに、私の経験では、この目的でプロジェクトを開始することがよくありました。将来的には、新しいプロジェクトに対する制約と、クロストレーニングは高すぎるとの考えから、この意図に基づいて行動することができませんでした。
私は常にそれを管理できればいいのにと思っていますが、長期的には、それがすべての関係者（チーム、会社、クライアント、ソフトウェア）にとって有益であると信じています。 2/3か月は、深刻な負の影響のリスクが限られているのに十分な長さのように聞こえます。開発者が代替プロジェクトに専念できる切り替え点を除いて、関係する開発者にとってコンテキストの切り替えは行われません。
言及されていないいくつかの利点：
- より良いプロジェクト管理。両方のプロジェクトのプロジェクトマネージャーが参加している場合、移行期間がどちらのプロジェクトでも苦痛にならないように懸命に取り組むことが最善の利益です。今度は（セットアップに応じて）PMと開発チームの間でより緊密なコラボレーションを実現できます。
- より良い（予防的）文書。プロジェクトに切り替えたり、プロジェクトから切り替えたりしていることがわかっている場合、それはプロジェクトの最善の利益、企業の最善の利益、一般的なベストプラクティスだけでなく、各開発者にとって、跳ねている間の人生を楽にするための最善の利益を持っています。周り。
- 士気は大したことです。もしあなたの開発者がレガシープロジェクトに行き詰まるのに十分ならなかったら、彼らはあなたが望む開発者ではないかもしれません！彼らがいる場合、それらを切り替えて他の開発者に取り組んでもらうと、彼らはあなたの会社への愛情を感じるようになります。彼らは、誰も見たことがないと思っていたコードを片付けるだけかもしれません。レガシーシステムは、多くの場合、彼らに不利益をもたらすセカンドクラスのプロジェクトと見なされています。
ローテーションは会社にとって良いことであり、開発者にとっても良いことです。
多くの正当な理由があり、ワイアットは彼の答えでそれらの多くを述べました。
そうは言っても、あなたの状況では、これを導入するときに、新しいプロジェクトからレガシープロジェクトに移行する開発者が満足できない可能性があるため、これが発生している理由とその期間を明確に伝える必要があります。のためであり、今後の計画です。
チームの卸売りを入れ替えて開始したり、最初に1人または2人の開発者を入れ替えたりしないことを検討するのはよいかもしれませんが、これは、降格のために人を選別するように見えるかもしれません（一部の人はそれを見るかもしれません）。
アーロノートのトップアンサーに同意し、いくつか追加があります。
- 人々は押し付けられることを好まない。
- 階層的なビジネス環境では、人々に責任が割り当てられ、後で再び彼らから奪われる可能性があります。これは単に仕事の一部かもしれません。ただし、これが頻繁に発生するほど、これらの人々が割り当てられたものに対して責任を感じる可能性は低くなります。
- 前者のポイントは、人々自身が作成しなかったもののメンテナンス作業にも当てはまります。他の人々の混乱（またはより中立的に定式化された：未完成の作業）をクリーンアップすることは、ほとんどの作成者に特にやる気を起こさせません。
- 「プログラマーはプログラマーであり、プログラマーはプログラマーであり、必要に応じてプロジェクトに挿入される匿名のプラグインである」という哲学は、プログラマーに感謝したり、割り当てられたタスクを気にかけたりすることはありません。
誰かを再割り当てするのに最適な時期は、彼らがやっていることに飽き始めたときです。これ以上得ることは何もありません、すべてが制御下にあり、仕事は完了しています。これらの場合、彼らは通常前進し、他の機会を自ら求めます。
もちろん、現実は頑固であり、選択の余地はほとんどありません。理由は何であれ、誰かが他の場所で必要になるかもしれません。これは必ずしも悪いことではありません。また、人を重要な気持ちにさせることもあり、その人が大きな問題を解決しようとする場合、その人の信用があります。
知識を広めるために人々をシャッフルするだけで売上高が増える可能性があります。そうすれば知識は広まるでしょうが、それはおそらく意図しない社外に広がっていくでしょう。
マイナス面が見られない人が何人いるのかを知るのは非常に奇妙であるAaronaughtに同意します。コードに所有者がいないため、すべての人がすべての責任を負っている場合、品質はそれほど良くありません。 。開発者はリソースではありません（マネージャーからそのように呼ばれることも多くあります）。彼らは人間であり、チームがお互いを知ることが非常に重要であるため、ローテーションは少し混乱します。あるプロジェクトで長時間働いた場合、（ドメインだけでなくそのプロジェクトの）エキスパートになります。ほとんどのトラブルがどこから発生したのか、誰が最良の回答を得るのか、あるいはより具体的なドメインの知識などを知ることができます。あなたが新しい場合は、この考えをすべて学ぶ必要があるので、進歩が遅くなります。しかしもちろん、組織内の他のプラクティス、他のチームがどのように構築および編成するかを知ることも良いことです。プロジェクトが何らかの方法で関連している場合、たとえば、あるプロジェクトが別のプロジェクトに入力されている場合（直接必要ではない）は特に優れているため、全体像をよりよく理解できます。そしてもちろん、専門知識を広めることは良いことです（これらの知識を得るための時間が得られる場合）。
プログラマーのローテーションは、会社の観点と開発者の観点からは良いことです。
会社の観点から
- 管理者は、特定の開発者がマルチタスクを処理できるかどうか、および変更に適応できるかどうかの長所と短所を知るようになります。
- なんらかの理由で開発者が退職した場合、その企業はすでに将来に備えたバックアップを用意しています。
- 多くの人々がそれに取り組むように、それはプロジェクトのパフォーマンスを向上させ、同じことがますます多くの開発者によってテストされます。 （テストリソースの無駄を最小限に抑える）
- すべてのチームメンバーがチームで作業することで、プロジェクトのパフォーマンスが向上し、将来の管理では、難しいモジュールやタスクを実装するときにどのようなチームを作る必要があるかを知ることができます。
開発者の観点から
- 自信が高まるにつれて、開発者はよりポジティブになります。
- 開発者は他のチームメイトのコードからますます優れたアイデアを得て、将来の開発でそれらのテクニックを使用できます。
- より良いアイデアや他のチームメンバーからの提案により、開発者の生産性が向上します。
1つの主要な事柄、それを覚えておく必要があります
プログラマーの交代はそれほど頻繁に行われるべきではありません。 60％-70％の開発が完了したら、シフトのみが有益になります。
TL; DR1つのチームにすると、2つのプロジェクトをサポートする1つのチームになります。
@Aaronaughtをエコーするには、新しいプラクティスやプロセスなどに慣れるのに時間がかかる可能性があるため、チームのミキシングには問題が生じる可能性があると思います。これは、そのアイデンティティを埋め合わせるために費やされる多くの質問、混乱、時間につながります。
一方、2つのチームを1つのチームに参加させ、1つのチームが2つのプロジェクトをサポートするための協調的な取り組みがある場合、チームが大きすぎない限り、それはうまく機能すると思います。私は複数のプロジェクトをサポートする数多くのチームの一員でした。 2つのプロジェクトが技術的に近いほど、移行が容易になります。私の経験では、あるプロジェクトから別のプロジェクトへの移行にかかるコストは、言語、クライアント/サーバー（特にGUI）、業界（医療、Web、ゲーム）、またはその他の類似のラインを横断するときに発生します。秘訣は、さまざまな人々にプロジェクトに取り組み、メリットを得るのに十分な頻度で働きますが、移行コストがメリットを超えるほどではありません。
次に、プロジェクトにより多くの人を参加させることのメリットは、コストと同様に、よく知られています。