フレッド・ブルックスの「外科チーム」はバス要因を効果的に処理しますか？
私の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は " Surgical Team "を提案し、すべてのチームはリード+サブで構成されます-リード（マネージャーと私）、およびいくつかのマイナーな役割。私たちは自然にこの組織に陥っているように感じますが、私のマネージャーはそれに反対しています。バスファクターは既に処理されており（マネージャーはコアコードに精通している）、ボトルネックは実際には存在しない（開発者が増えると作業が速くならない）。この点で、外科チームは良いことだと思います。
これらは私の気持ちですが、私は経験豊富なマネージャーではなく、バス要因（木のノック）に対処する必要もありませんでした。 ブルックスは正しかったですか？バス要因が関係する「外科チーム」で働いたことはありますか？専門知識の配布を管理するためのより良いテクニックはありますか？
同様の質問：
実際、あなたは「外科チーム」モデルに従っていると私は主張します。幸運な！
上記のモデルのポイントの一部は、下位のチームメンバーがアシスタントの役割を持っていることです。チームが心臓手術をしていないときは、ゆっくりと動いて、スキルを練習したり、責任をクロストレインしたりできるようにしてください。
弱点を探して解決することでチームを調査および管理することと、トップ開発者になることは、外科医の仕事です。外科医以外の人（ビジネスマネージャー）がこれを行うことはできません。彼らが必要なスキルを理解していないためです。
したがって、マネージャーはこの機会を利用して、他の目的の1つに取り組みます。その過程でチームに何らかの欠陥が明らかになった場合、問題になる前に対処することができます。たとえば、別の開発者を雇ってください。
または、後輩は間違いをするかもしれません。彼らは肩越しに誰かを見守っているので、これは彼らにとってそうするのに最適な時期です。オスカーワイルドは言った
経験とは、私たちが間違いを犯したときの名前です。
これらの後輩が機会を決して持っていない場合to間違いを犯すと、彼らは決して改善されません。これは、経験豊富な将来の開発者のチームを奪うだけでなく、ある意味、彼らが持っていたはずの機会を奪ってしまいます。
私たちの会社はあなたが提案しているように働いていました。コードの重要な部分を理解しているのは2人だけでした。コードのその部分でタスクが発生した場合は常に、数週間かけて他のユーザーをスピードアップするのではなく、数日で完了するため、タスクが割り当てられます。これは実際にはかなりうまくいきました。
何が起こったかというと、最終的に彼らの皿がいっぱいになり、2日でタスクを完了することができたとしても、リストのトップに移動するのに数週間かかります。マネージャーは、そのタスクがより緊急であったことをめぐって激しい口頭の戦いをするでしょう。緊急の依存タスクは元に戻されます。
結局、マネージャーは待つことにうんざりして、自分のチームを訓練し始めました。はい、しばらくはかなり遅くなりましたが、今ではスループットが大幅に向上しています。
作業を処理できる最初のフェーズになっている可能性がありますが、次のフェーズにいつ移行するかを予測する方法はありません。ここにヒントがあります：それは常に可能な限り最も不便な時間に起こります。まだ余裕があるときは、マネージャーが攻撃を受けるのは当然です。
はい、自分でもっとすばやく簡単にできることで誰かが苦労しているのを見るのはイライラします。いつか2歳の子育てをしてみてください。それは、チーム全体の改善に役立つためです。スケジュールを気にするのはマネージャーの仕事です。優先度の高い未解決のバグが心配な場合は、どれだけ早く修正できるかを自分で試してください。
今はボトルネックではないかもしれませんが、最終的には自分ですべての作業を続ければボトルネックになります。あなたのマネージャーは、あなたのプロジェクトが遅れるというリスクに委任することを学ぶことはあなたにとって十分重要であることを理解しています-彼を信頼してください。あなたが手放すことを学ぶと、あなたの後輩はあなたの指導の下ではるかに多くを学び、作り出すでしょう。
存在しない、または想定しているほど重要ではない制約を適用しています。具体的には、完成までの時間を心配しています。一方、あなたのマネージャーは、知覚される時間の制約を心配しているようには見えません。
質問から納期を短縮すると、そもそもなぜ質問をするのかとすぐに疑問に思うようになります。
それは時間が常に利用可能であると言っているわけではありません、そしてあなたはこれが上級管理職からの優先度の高い要求であると述べました。しかし、あなたはあなたの上司が彼らと行ったすべての会話に精通しているわけではありません。チームの他のメンバーのトレーニングにその時間を費やすために、彼はもっと長い時間交渉したかもしれません。
そして、バスの要因はすでに解決されていると感じている一方で、上司は次の要求に目を向けているかもしれませんそうではない彼のスター開発者の1人による7日間の作業に簡単に適合します。リスクの客観的な大きさがはるかに小さい小さな反復でチームをトレーニングする方がはるかに安全です。
以前、私は重大なボトルネックになりました。正直なところ、それは快適な場所ではありません。私の場合、ITのVPと私は話し合い、問題を恒久的に修正する計画を思い付きました。痛かったが、私が運ばれたよりもずっと痛くない。
できるだけ早くノックアウトする必要があるすべての考え方に入るのは簡単です。優れたマネージャーは、少しの遅れ（クロストレーニング/教育のため）が後でかなりの配当を支払うことができるまれな機会を見つけます。