プロジェクトで開発者を交代させるのは良い考えですか、悪い考えですか？

私は小さなチームで働いており、別の小さなチームと一緒に大規模な新しいプロジェクトに取り組み始めます。他のチームは現在、長年取り組んでいるレガシーシステムで作業しています。

マネージャーは、私のチームの開発者が、レガシーシステムで作業している開発者を置き換えるために、数か月ごとに交代することを決定しました。そうすれば、他のチームは新しいプロジェクトに取り組み、新しいシステムをよりよく理解できるようになります。

2〜3か月ごとにプロジェクトから開発者を交代することの利点と欠点（ある場合）を知りたい。

これは「主任開発者を交代させるのは良い考えなのか悪い考えなのか」と似た質問であることを知っています。、しかしその質問は主任開発者に焦点を当てています。この質問は、プロジェクト全体でチーム全体をローテーションすることに関するものです（新しいプロジェクトの技術リーダーはローテーションされる場合とされない場合があります。まだわかりません）。

誰もがこれがとても良いことだと思っていることに驚いています。Peopleware（IMOは、実際に読む価値のある貴重な数少ないソフトウェアプロジェクト管理書籍の1つです）の著者は、強く反対しています。本のパートIVのほぼ全体がこの問題に専念しています。

ソフトウェアチームは非常に重要な機能単位です。チームは、本当に生産的になるために大声で話す必要があります。それは時間（とり多くの習慣や癖や強みと弱みお互い学ぶために、敬意をお互いを獲得するために、チームメンバーのための時間のを）。

確かに、個人的な経験から、私は特定の人々と1年間働いた後、私を苦しめた特定のことを笑い飛ばすことを学んだ、チームリーダーとしての私の推定ははるかに優れており、それはそれほど難しくないすべての人が幸せになるように作業を配布します。最初はそうではなかった。

「ああ、でも私たちはチーム全体を分割するのではなく、ほんの数人を動かすだけです」と言うかもしれません。ただし、（a）代替品が最初にどれだけ盲目的に非生産的になるか、および（b）自分や他のチームが「Xが本当に好きだった」または「これは持っているだろう」 「Yがまだ残っている」ことで簡単になりました」、新しいメンバーを微妙かつ無意識に怒らせ、既存のチーム内で分裂を引き起こし、「古い」メンバー間で不満を植え付けさえしました。

もちろん、意図的にこれを行うわけではありませんが、それはほぼ毎回発生します。人々は考えずにそれをします。そして、彼らがそうしないように強制した場合、彼らは最終的に問題にさらに集中し、強制的な沈黙に失望します。チームやサブチームでさえ、相乗効果を発揮します。相乗効果は、構造に手を加えたときに失われます。ピープルの著者は、「teamicide」の形と呼んでいます。

ことでは回転していても、言ったチームメンバーが回転し、恐ろしい練習で自身がチーム完全に罰金です。よく運営されているソフトウェア会社には製品の所有権という概念がありますが、チームが実際に古いプロジェクトを終了するか、少なくともプロジェクトに持ち込む限り、チーム全体を別のプロジェクトに移動するのはチームにとってそれほど混乱しません彼らが満足しているレベル。

開発者スティントの代わりにチームスティントを持つことにより、ユニットとして各チームに悪影響を与えることなく、回転する開発者に期待されるのと同じ利点（ドキュメント、「他家受粉」など）をすべて得ることができます。本当に管理を理解していない人にとっては、生産性が低いように見えるかもしれませんが、チームを分割することで失われる生産性は、そのチームを別のプロジェクトに移動することで失われる生産性を完全にdします。

PSあなたの脚注で、あなたはローテーションしない唯一の人が技術リードであるかもしれないと述べています。これは、両方のチームを台無しにすることがほとんど保証されています。技術リーダーはマネージャーではなくリーダーであり、チームの尊敬を得る必要があり、より高いレベルの経営陣から単純に権限が付与されるわけではありません。チーム全体を一緒に仕事したことのない新しいリードの指揮下に置き、アーキテクチャ、ユーザビリティ、コード編成、見積りなどについてさまざまなアイデアを持っている可能性が非常に高いです...まあ、それは地獄のようにストレスになります信頼性を構築しようとしているリードと、古いリードがないために結束力を失い始めるチームメンバーにとって非常に非生産的です。時には企業が持っているこれを行うには、つまり、リードが終了したり昇格したりする場合でも、選択によってそれを行うと異常に聞こえます。

私自身、ここには多くの欠点はありません。回転はあなたを取得します：

• 制度的知識の相互受粉-少なくとも理論的には、誰もがレガシープロジェクトと新しいプロジェクトを知っているでしょう。
• クロストレーニング-プロジェクトごとに異なるものが必要になることがよくあります。きれいできれいなグリーンフィールドプロジェクトよりも、legacyいレガシープロジェクトで作業する開発者として、はるかに成長します。
• 根本的に優れたプロジェクト-ドキュメントを完成させ、一緒に住みたいが公然と認めないprocessesいプロセスを終わらせるために新しいチームがやってくるようなものはありません。
• より良いコード-ほとんどの場合、ヘッドが多いほど良いです。
• おそらく士気の​​向上-多様性は人生のスパイスです。そして、レガシープロジェクトのバグ修正/ダクトテーピングモードに永久に立ち往生したい人。また、ある時点で「新しい」プロジェクトがレガシーになることを忘れないでください。永遠にそこにとどまりたいですか？

おそらく唯一の欠点は、場所を切り替えることで得られる生産性の低下ですが、それは最初のラウンドで悪い結果をもたらすだけです。その後、両方の側で両方の場所にいくらかの座席時間があり、ハンドオフのい部分がおそらくよりよく理解され、おそらく解決されるでしょう。

興味深いことに、私の経験では、多くの場合、この非常に意図してプロジェクトを開始しました。将来的には、新しいプロジェクトに対する制約と、クロストレーニングが高すぎるという考えのために、この意図に基づいて行動することができませんでした。

長期的には、チーム、会社、クライアント、ソフトウェアなど、すべての関係者にとって有益であると信じているので、私たちは常にそれを管理したかったのです。2/3か月は、深刻な負の影響のリスクが限られているため、十分な期間のように聞こえます。開発者が代替プロジェクトに専念できる時点を除いて、関係する開発者のコ​​ンテキスト切り替えはありません。

言及されていないいくつかの可能な利点：

• より良いプロジェクト管理。両方のプロジェクトのプロジェクトマネージャーが参加している場合、移行期間がどちらのプロジェクトにとっても苦痛にならないように一生懸命働くことが彼らの最善の利益です。これは（設定に応じて）変わり、PMと開発チームの間のより緊密なコラボレーションをもたらす可能性があります。
• より良い（プロアクティブな）ドキュメント。あなたがプロジェクトに出入りすることを知っているなら、それはプロジェクトの最高の利益、企業の最高の利益、一般的なベストプラクティスだけでなく、今ではバウンスしながら人生を楽にするために各開発者の最高の関心を持っています周り。
• 開発者がレガシプロジェクトにこだわるのに十分でない場合、士気は大したことです。そして、彼らはあなたが望む開発者ではないかもしれません！持っている場合、それらを切り替えて、他の開発者に作業をしてもらうことで、あなたの会社への愛情を感じることができます。レガシーシステムは、しばしば彼らの不利益につながるセカンドクラスのプロジェクトと見なされることが多く、このようにあなたがその認識を変える助けになるかもしれません。

ローテーションは会社にとって良いことであり、開発者にとっても良いことです。

多くの正当な理由があり、ワイアットは彼の答えでそれらの多くを言及しました。

とはいえ、あなたの状況では、これを紹介するときに、新しいプロジェクトからレガシープロジェクトに移行する開発者は満足していない可能性がありますので、これがなぜ起こっているのか、どのくらいの期間それが起こっているのかを非常に明確に伝える必要がありますであり、今後の計画です。

チームを大々的に交換して最初から1つまたは2つの開発者を交代させないことを考えるのは良いことかもしれませんが、降格のために人々を孤立させるように見えるかもしれません（一部の人々はそれを見るかもしれません）。

どれだけ多くの人がマイナス面を見ていないかを見るのは非常に奇妙なAaronaughtに同意します。あなたは非常に迅速に指摘できると思う人はほとんどいません-コードには所有者がなく、誰もがすべてに責任がある場合は品質が良くありません。開発者はリソースではなく（マネージャーからそのように呼ばれることもあります）、彼らは人であり、チームがお互いを知ることは非常に重要であり、ローテーションはそこで混乱をもたらします。あるプロジェクトでより長い時間働いた場合、専門家（ドメインだけでなく、そのプロジェクトの専門家）になります。ほとんどのトラブルはどこから来たのか、誰が最良の答えを得るか、またはより具体的なドメインの知識などを得るでしょう。あなたが新しい場合、あなたはこのすべてを考える必要がありますので、進歩が遅くなります。しかし、もちろん、組織内の他の慣行を知ることも良いことです。他のチームがどのように構築および編成するか。プロジェクトが何らかの形で関連している場合、たとえば、あるプロジェクトが別のプロジェクトに直接入力されている場合（直接必要ではない場合）、特に全体像をよりよく理解できます。そしてもちろん、専門知識を広めることは良いことです（もしあなたがこれらの知識を得るための時間を得るなら）。

Aaronaughtのトップの答えに同意し、いくつか追加します。

• 人々は押しのけられたくない。
• 階層的なビジネス設定では、人々に責任が割り当てられることがありますが、その責任は後で取り消されます。これは単なる仕事の一部かもしれません。ただし、これが頻繁に発生するほど、これらの人々は自分に割り当てられたものに対して責任を感じる可能性が低くなります。
• 前者は、人々自身が作成しなかったものの保守作業にも当てはまります。他の人の混乱をクリーンアップする（またはより中立に策定された：未完成の作業）ことは、ほとんどの個人を作成するために特に動機付けられません。
• 「プログラマーはプログラマーであり、プログラマーであり、必要に応じてプロジェクトに挿入される匿名プラグインである」という哲学は、どのプログラマーも彼に割り当てられたタスクを高く評価したり気にしたりしません。

誰かを再配置する絶好のタイミングは、彼らがやっていることに飽き始めたときです。これ以上得るものはありません。すべてが制御され、仕事は完了です。これらの場合、彼らは通常、前に出て、自分で他の機会を求めます。

もちろん、現実は頑固であり、多くの場合選択の余地がありません。何らかの理由で誰かが他の場所で必要になるかもしれません。これは必ずしも悪いことではありません。また、人を重要に感じさせる可能性があり、その人が何らかの大きな問題を解決する場合、その人に信用があります。

知識を広めるために人々をシャッフルするだけで、離職率が上がる可能性があります。そのようにして知識は広まりますが、それはおそらく意図ではない会社の外に広まります。

TL; DR 1つのチームにして、2つのプロジェクトをサポートする1​​つのチームにします。

@Aaronaughtをエコーするには、チームのミキシングは新しいプラクティスやプロセスなどに順応するのに時間がかかる可能性があるため、問題になる可能性があると思います。これは、より多くの質問、混乱、およびそのアイデンティティを補おうとするのに費やされた時間につながります。

一方、2つのチームを1つのチームに参加させて、1つのチームが2つのプロジェクトをサポートするように努力している場合、チームが大きすぎない限り、うまくいくと思います。私は複数のプロジェクトをサポートする多数のチームの一員です。2つのプロジェクトの技術が近いほど、移行が容易になります。私の経験では、あるプロジェクトから別のプロジェクトへの移行にかかるコストは、言語、クライアント/サーバー（特にGUI）、業界（医療、Web、ゲーム）、またはその他の類似のラインを横断するときに発生します。秘Theは、さまざまな人々がプロジェクトを頻繁に作業して利益を得ることができるようにすることですが、移行コストが利益を超えるほど頻繁ではありません。

そして、プロジェクトでより多くの人を獲得することのメリットは、コストと同様にかなりよく知られています。

プログラマーのローテーションは、会社の観点と開発者の観点からは良いことです。

会社の観点から

1. 管理者は、特定の開発者がマルチタスクを処理できるかどうか、および変更に適応できるかどうかを知ることができます。
2. 何らかの理由で開発者が退職した場合、会社はすでに将来のバックアップを準備しています。
3. 多くの人がプロジェクトに取り組むので、プロジェクトのパフォーマンスが向上し、同じことがより多くの開発者によってテストされます。（リソースの無駄を最小限に抑えるテスト）
4. すべてのチームメンバーはチームで作業し、プロジェクトのパフォーマンスを向上させ、将来の経営陣は、困難なモジュールまたはタスクを実装する際にどのようなチームを作成する必要があるかを把握します。

開発者の観点から

1. 開発者の自信が高まるにつれて、開発者はよりポジティブになります。
2. 開発者は他のチームメイトコードからより良いアイデアを得て、将来の開発でそれらのテクニックを使用できます。
3. 他のチームメンバーからのより良いアイデアや提案から、開発者の生産性が向上します。

主なものは1つだけです。

プログラマーのローテーションはあまり頻繁に起こるべきではありません。60％から70％の開発が完了した後は、シフトのみが有益です。