フレッド・ブルックスの「外科チーム」はバス要因を効果的に処理しますか？

私の4人の経験豊富な開発者のチームは、大規模なモジュール式のWindowsアプリケーション（約200 KLoC）に取り組んでいます。私はプロジェクトの開始時（3年前）からコアコードベースに焦点を当てており、チームマネージャーではありませんが、徐々にセミリードの開発者ポジションに移行しています。

私たちの現在のイテレーションは、コアコードベースへの約15の変更を含む、上級管理職から要求された優先度の高いUI更新です。マネージャーから尋ねられたとき、15の変更のそれぞれが完了するまでに 4時間未満、合計で7営業日未満であると推定しました。それから私はボランティアでその仕事をしました。代わりに、マネージャーは15のタスクすべてを4人の開発者全員に均等に分配することを決定しました。

仕事を始めてから3日間で、次の2つのことがわかりました。

1. 他の経験の浅いチームメンバーは、それぞれ約1つ以下のタスクを完了しました。

2. 実行中のブルックの法則：半分の時間を費やして支援を提供しました（コンポーネントを使用するよう指導することを試みました）。その結果、私は自分で2つだけタスクを完了しましたが、予想された5または6ではありませんでした。

私は遅刻しているのではないかと心配して上司に連絡し、残りのタスクを完了するよう再度提案しました。私の要求は親切に拒否されました。負荷を均等に分割する理由は2つあります。

1. トラック/バスの要素を制限-これらのスキルで他の開発者を強化し、将来、私だけでなく誰にでもどんな仕事でも与えることができるようにします。
2. 「ボトルネック」（私）を解消し、作業を迅速に行うため。

明確にするために、私は問題はありません：a）時間を教えることに投資する、b）私のコードに触れる人々、またはc）仕事の安全。実際、私は定期的にチームリーダーに、コアコードベースの特定の側面について他の開発者をトレーニングしてリスクを減らすように提案しています。

このイテレーションでは、優先度の高いバグ修正の大規模なコレクションも対象としているため、ワークロードが再分散されれば、より多くの進歩が見込めるようになります。

Mythical-Man-Monthでは、Brooksが提案する「外科チーム」では、すべてのチームがリード+サブリード（マネージャーと私）といくつかのマイナーな役割で構成されています。私たちは自然にこの組織に陥っているように感じますが、私のマネージャーはそれに反対しています。バスファクターはすでに処理されており（マネージャーはコアコードに精通している）、ボトルネックは実際には存在しない（開発者が増えると作業が速くならない）。この点で、外科チームは良いことだと思います。

これらは私の気持ちですが、私は経験豊富なマネージャーではありません。バス要因（木のノック）に対処する必要もありませんでした。ブルックスは正しかったですか？バス要因が関係する「外科チーム」で働いたことはありますか？専門知識の配布を管理するためのより良いテクニックはありますか？

同様の質問：

• バス係数を増やすと同時に専門化する方法は？
• /software/103718/always-keeping-2-people-expert-on-any-one-chunk-of-code

実際、あなたは「外科チーム」モデルに従っていると私は主張します。幸運な！

上記のモデルのポイントの一部は、下位のチームメンバーがアシスタントの役割を持っていることです。チームが心臓手術をしていないときは、ゆっくりと動いて、スキルを練習したり、責任をクロストレインしたりする機会を与えても問題ありません。

弱点を探して解決することによりチームを調査および管理すること、ならびにトップ開発者になることは、外科医の仕事です。非外科医（ビジネスマネージャー）がこれを行うことはできません。彼らが必要なスキルを理解していないためです。

したがって、マネージャーはこの機会を利用して、他の目的の1つに取り組みます。その過程でチームに欠陥が明らかになった場合、問題になる前に対処することができます。たとえば、別の開発者を雇ってください。

または、後輩は間違いをするかもしれません。彼らは肩越しに誰かを見守っているので、これは彼らにとってそうするのに最適な時期です。オスカーワイルドは言った

経験は、私たちが私たちに間違いを与える名前です。

これらの後輩がミスをする機会がない場合、彼らは決して改善されません。これは、経験豊富な将来の開発者のチームを奪うだけでなく、ある意味、彼らが持っていたはずの機会を奪ってしまいます。

私たちの会社はあなたが提案しているように働いていました。コードの重要な部分を理解しているのは2人だけでした。コードのその部分でタスクが発生した場合は常に、数週間かけて他のユーザーをスピードアップするのではなく、タスクは数日で完了するため、タスクに割り当てられます。これは実際にはしばらくの間かなりうまくいきました。

何が起こったかというと、最終的に彼らの皿がいっぱいになり、2日でタスクを完了することができたとしても、リストのトップに移動するのに数週間かかります。マネージャーは、そのタスクがより緊急であったことをめぐって激しい口頭の戦いをするでしょう。緊急の依存タスクは元に戻されます。

結局、マネージャーは待つことにうんざりして、自分のチームを訓練し始めました。はい、それはだったたくさんのしばらくの間、より遅いが、今私たちのスループットははるかに優れています。

作業を処理できる最初のフェーズに入っている可能性がありますが、次のフェーズにいつ移行するかを予測する方法はありません。ここにヒントがあります：それは常に可能な限り最も不便な時間に起こります。まだ余裕があるときは、マネージャーが攻撃を受けるのは当然です。

ええ、自分がもっと早く簡単にできることで誰かが苦労しているのを見るのはイライラします。いつか2歳の子育てをしてみてください。それは、チーム全体の改善に役立つためです。スケジュールを気にするのはマネージャーの仕事です。優先度の高いバグを取り消すことが心配な場合は、どれだけ早く修正できるかを自分で試してください。

今はボトルネックではないかもしれませんが、最終的には自分ですべての作業を続ければボトルネックになるでしょう。あなたのマネージャーは、あなたのプロジェクトが遅れるというリスクに委任することを学ぶことはあなたにとって十分重要であることを理解しています-彼を信頼してください。手放すことを学ぶと、後輩はあなたの指導の下ではるかに多くのことを学び、作り出すでしょう。

存在しない、または想定しているほど重要ではない制約を適用しています。具体的には、完成までの時間を心配しています。一方、あなたのマネージャーは、知覚される時間の制約を心配しているようには見えません。

質問から納期を短縮すると、そもそもなぜ質問をするのか疑問に思われるようになります。

それは時間が常に利用可能であると言っているわけではありません、そしてあなたはこれが上級管理職からの優先度の高い要求であることを述べました しかし、あなたはあなたの上司が彼らと行ったすべての会話に精通しているわけではありません。チームの他のメンバーのトレーニングにその時間を費やすようにするために、彼はもっと長い時間交渉したかもしれません。

バスの問題はすでに解決されているように感じますが、上司は、スター開発者の1人による7日間の作業に簡単に収まらない次の要求を待ち望んでいる可能性があります。リスクの客観的な大きさがはるかに小さい小さな反復でチームをトレーニングする方がはるかに安全です。

私は以前に重大なボトルネックになりました。正直なところ、それは快適な場所ではありません。私の場合、ITのVPと私は話し合い、問題を恒久的に修正する計画を思い付きました。痛いですが、私が運ばれたよりもずっと痛くないです。

できるだけ早くノックアウトする必要があるすべての考え方に入るのは簡単です。優れたマネージャーは、少しの遅延（クロストレーニング/教育のため）が後でかなりの配当を支払うことができるまれな機会を見つけます。