フレッド・ブルックスの「外科チーム」はバス要因を効果的に処理しますか？
私の4人の経験豊富な開発者のチームは、大規模なモジュール式のWindowsアプリケーション（約200 KLoC）に取り組んでいます。私はプロジェクトの開始時（3年前）からコアコードベースに焦点を当てており、チームマネージャーではありませんが、徐々にセミリードの開発者ポジションに移行しています。 私たちの現在のイテレーションは、コアコードベースへの約15の変更を含む、上級管理職から要求された優先度の高いUI更新です。マネージャーから尋ねられたとき、15の変更のそれぞれが完了するまでに 4時間未満、合計で7営業日未満であると推定しました。それから私はボランティアでその仕事をしました。代わりに、マネージャーは15のタスクすべてを4人の開発者全員に均等に分配することを決定しました。 仕事を始めてから3日間で、次の2つのことがわかりました。 他の経験の浅いチームメンバーは、それぞれ約1つ以下のタスクを完了しました。 実行中のブルックの法則：半分の時間を費やして支援を提供しました（コンポーネントを使用するよう指導することを試みました）。その結果、私は自分で2つだけタスクを完了しましたが、予想された5または6ではありませんでした。 私は遅刻しているのではないかと心配して上司に連絡し、残りのタスクを完了するよう再度提案しました。私の要求は親切に拒否されました。負荷を均等に分割する理由は2つあります。 トラック/バスの要素を制限-これらのスキルで他の開発者を強化し、将来、私だけでなく誰にでもどんな仕事でも与えることができるようにします。 「ボトルネック」（私）を解消し、作業を迅速に行うため。 明確にするために、私は問題はありません：a）時間を教えることに投資する、b）私のコードに触れる人々、またはc）仕事の安全。実際、私は定期的にチームリーダーに、コアコードベースの特定の側面について他の開発者をトレーニングしてリスクを減らすように提案しています。 このイテレーションでは、優先度の高いバグ修正の大規模なコレクションも対象としているため、ワークロードが再分散されれば、より多くの進歩が見込めるようになります。 Mythical-Man-Monthでは、Brooksが提案する「外科チーム」では、すべてのチームがリード+サブリード（マネージャーと私）といくつかのマイナーな役割で構成されています。私たちは自然にこの組織に陥っているように感じますが、私のマネージャーはそれに反対しています。バスファクターはすでに処理されており（マネージャーはコアコードに精通している）、ボトルネックは実際には存在しない（開発者が増えると作業が速くならない）。この点で、外科チームは良いことだと思います。 これらは私の気持ちですが、私は経験豊富なマネージャーではありません。バス要因（木のノック）に対処する必要もありませんでした。ブルックスは正しかったですか？バス要因が関係する「外科チーム」で働いたことはありますか？専門知識の配布を管理するためのより良いテクニックはありますか？ 同様の質問： バス係数を増やすと同時に専門化する方法は？ /software/103718/always-keeping-2-people-expert-on-any-one-chunk-of-code