「The Mythical Man-Month」の「外科チーム」パターンはどうなりましたか？

何年も前に、The Mythical Man-Monthを読んだとき、他の情報源からすでに知っているものをたくさん見つけました。しかし、1975年からの本にもかかわらず、そこには新しいものもありました。そのうちの1つは次のとおりです。

外科チーム

ミルズは、大規模な仕事の各セグメントはチームに取り組むことを提案しますが、チームは豚の屠殺チームではなく外科チームのように組織されることを提案します。つまり、各メンバーが問題を切り捨てる代わりに、1人がカットを行い、他のメンバーが彼の有効性と生産性を高めるすべてのサポートを提供します。

これは、ソフトウェア開発チームを編成するための非常に興味深いパターンですが、他のソフトウェアエンジニアリングの本では説明されておらず、どこにも記載されていません。

何故ですか？

• 「手術チーム」は当時も珍しかったですか？
• または、試行されて失敗しましたか？
  • もしそうなら、どのように失敗しましたか？
  • そうでない場合、今日のソフトウェアプロジェクトでそのパターンが実装されていないのはなぜですか。

「The Mythical Man-Month」は大学を始めた年に出てきたもので、現在の専門用語であるUUUGEを使用していました。:-)理解する必要があるのは、ソフトウェアの開発方法と現在の開発方法の違いです。Back In The Day（tm）ほぼすべてのコーディングが最初に紙で行われ、次にパンチカードにキーパンチ（推測）され、次に読み込まれ、コンパイルされ、リンクされ、実行され、結果が得られ、プロセスが繰り返されました。CPU時間は高価でしたリソースが限られているので、無駄にしたくありませんでした。同様にディスクスペース、テープドライブ時間など、なんとか。（ショックと恐怖！）エラーをもたらすコンパイルで完全に良いCPU時間を浪費することは...まあ、完全に良いCPU時間の無駄です。そして、これは半ばから1960年代後半のCPU時間もあったフレッド・ブルックスは、彼のアイデアを開発していた時、で1975年にあったよりThe Surgical Teamの背後にあるアイデアは、One Super Great Rockstar Developerが、コードのチェック、キーパンチなどのありふれたタスクにHIS時間を浪費する必要がないようにすることでした。ジョブを送信し、結果を待ちます（場合によっては数時間）。Rockstar Dude Developer Manはコードを書くことになっていた。彼の大勢のグルーピー/店員/ジュニア開発者は、ありふれた仕事をすることになっていた。

問題は、Brooksの本が出版されてから2年以内に、The Surgical Teamの背後にある基本的なアイデアが崩壊することでした。

1. CRT端末とディスクファイルは、キーパンチとカードデッキに取って代わり始めました。コンピューター時間がより安価になり、複数のコンピューターが使用可能になり、ジョブの所要時間が劇的に短縮されました。私は大学になった（マイアミ大学、オックスフォード大学、オハイオ州、'79のクラス、尋ねるためのおかげで）良いです仕事の所要時間は約1時間でした。決勝戦の週-4時間、場合によっては6時間。（私たちは多くの商業企業や大学とCPU時間を競い合いました-そして商業ユーザーが最優先されました）。マイアミが「共有コンピューター」配置から抜け出し、自分のIBM 370/145をキャンパスにインストールし、RJEステーションとして機能する素敵なHP miniをメインフレームに変えることができた4年生仕事は5分以内で完了します。コードをHPにバングインし、HPからメインフレームに送信し、親指をたたいて/タバコを吸って、コードのデスクチェックを完了する前に出力を取り戻すことは価値がありました。

2. 外科チームは、その基本的な前提として、あなた（または「管理」、神が私たちすべてを助ける）が、ロックスター外科開発者デュードを特定できるという考えを持っています。実際、それが可能だとは思わない。ありますロックスターの開発者は、誰もがそれを知っている-研究は限り2000など％の最高と最悪の開発者間の生産性の違いを示している-しかし、その人を識別し、それらが長期間にわたってコードを書くことなく、ほとんど不可能です。誰かがロックスター開発者であるかどうかを知る唯一の方法は、実際にコードを開発させることです-しかし、彼らがRockstar Surgical Developer Dudeでない場合、彼らはコードのデスクチェック、カードへのキーパンチ、パンチカードの箱をジョブエントリ部門に運び、結果を待って、実際に動作する唯一の方法をコーディングすることを学ぶのではなく、ロックスター外科開発者の氏に戻せるようにします。 Back In The Day（tm）プログラミングコンテストはありませんでした。スタックオーバーフローはありませんでした。あなたが好きなときにコードを書くことができるPCを持っていなかったので、Algorithms For Idiotsの本はありませんでした。プログラミングを学ぶ唯一の方法は、学校に行って、少しプログラミングをすることを専攻することでした。しかし、プログラミングそれ自体は真剣に受け止められておらず、人々がしたくないことであると想定されていました。私の最初の大学のコース（SAN151-システム分析入門、トムシェーバー博士-ありがとう、トム:-)インストラクターから、「...私たちはただ過ごす必要があるという事実に直面しなければならなかった」と言われました。私たちがシステムアナリストになる前にプログラマーとして数年を過ごしました」。「2年？」と思った。「私はこれを2年だけやろうとしていますか？！？」。私はひどく腹を立てました。ありがたいことに彼は間違っていて、それ以来ずっとコーディングを続けてきました。:-)

3. 外科チームは、プログラマーは比較的まれなリソースであると想定しています。実際にはさらに数年かかりましたが、80年代前半のプログラミングのPCの出現により、あらゆるオタクが関与できるようになりました。コンピューターの価格が下がり始め、開発ツールの価格が下がり始め、それがすべてでしたTurbo Pascalを称えましょう-今日の基準ではそれほどではありませんでしたが、当時は約40ドルの完全なPascal IDEでした。今なら誰でもプログラミングに入ることができます-コンピューターを買う余裕があり、IBMがPCjr（そう、私の最初のPCはIBMの最大の間違いの1つでした:-)を販売するために約500ドルでそれらの七面鳥、現金を取り除きます-あらゆる場所に閉じ込められたオタクは、家賃の支払いを1か月間スキップしました（「ええ、ええと、わかっていますが、私は...口蓋垂を壊して手術をしなければなりませんでした。。ええと...ええ、来週、問題ありません、ありがとう、男...）、そして火の販売価格でそれらを吸い上げました。その後、コンピューターを使用可能にするためにアドオンに支払った以上の費用がかかりました。（「ええ、男、来週、確かに、おそらく...」:-)。

本当に悲しいのは、今日でも「The Mythical Man-Month」を読んだことがあるかどうか、またはその主要なレッスンを理解したかどうかを尋ねると（「後のプロジェクトにリソースを追加すると後でそれが」）、空白になることです凝視-そして、OS / 360の開発中にすべてのそれらの年前に行われたのとまったく同じエラーを犯します。古いものはすべて新しくなりました...：-}

その概念のいくつかの側面がありますされ、時には、今日実装は、されている他の側面がある回避は。

チームを小さく保つことは、アジャイルメソッドの基本的な機能の1つですが、アジャイル以外でも実践されています。

機能横断型チームもアジャイルの定番ですが、アジャイル以外でも一般的です。

Program Clerkの役割は、バージョン管理システム、ソフトウェア構成管理システム、変更管理システム、ドキュメント管理システム、Wiki、アーティファクトリポジトリーを備えた継続的ビルドシステムなどのコンピューター化されたシステムに大きく含まれています。つまり、フルタイムの従業員にソースコードを印刷し、手動でインデックスを作成してファイルするために支払うことを本当に想像できますか？

同様に、システム管理者（Millsの外科チームの一部ではなく、過去数年間の典型的な部門横断チームの一部）の役割は、DevOps（Sysadminの役割をソフトウェアエンジニアの役割に吸収）などの概念によって廃止されています、Platform-as-a-Service、Infrastructure-as-a-Service、およびユーティリティコンピューティング（Sysadminの役割を「他の人の問題」にする）、またはInfrastructure-as-Code（システム管理をソフトウェアエンジニアリングに変える）。

今日回避しようとする側面の1つは、多くても2人がシステムを理解していることです。外科医だけがシステムを完全に理解することが保証されていますが、副操縦士はそうでないかもしれません。これにより、バスファクターは1〜2になります。外科医が病気になった場合、プロジェクトは終了します。期間。それにアジャイル答えはある集団のコードの所有権であり、正反対、そのモデルの：誰がために単独で責任がない任意の部分システムの。代わりに、すべての人がグループとして責任を負います 。

最後に、その概念に組み込まれたいくつかの仮定がありますが、それらは時代遅れです。たとえば、明示的に述べられていなくても、チームはチーム内の1人の人間（外科医）だけが実際にコンピューターを持っているようにセットアップされます。それは、もちろん、記事が書かれた時点では、チーム全体がチーム用に1台のコンピューターはもちろん、チーム用に1台のコンピューターを所有するという考えでさえ、一気に広まったためです。（Smalltalkがリリースされた1980年でさえ、その失敗の原因の1つは、すべての開発者とすべてのユーザーが独自のコンピューターを持つようにシステムがセットアップされていたことでした。

つまり、説明したとおりにコンセプトが実装されたとは思いませんが、その一部は確実に実装され、一部は望ましくなく積極的に回避されていると見なされ、一部は廃止され、一部はProbably Good Ideas™です。しかし、誰もそれをしません。

以前は、大学教育はユニークなものであり、エンジニアは選ばれた数人の中にいました。コンピューターは高価であり、チームは定義されたビジネスRoIでプロジェクトに取り組みました。これらはあまり一般的ではありませんでした。

起こったことは、マイクロコンピューター、ユビキタスな学部教育、そして進歩するために大学の学位さえ必要としないコンピューターシステムでした。また、起こったのは経済学のシフトと労働コストの上昇でした。

8：2のsupport：engineer比率の経済性はもはや意味をなしません。エンジニアは自分でサポートする必要があります。開発チームに効果的に参加するのに十分な教育とスキルを備えた現代の人間は、費用がかかりすぎて、何らかの独自の開発を行わないのです。

（関連する経済学用語は「サービス部門のコスト病」です。）

このパターンは、Mobプログラミングのように私にはたくさん聞こえます：

グループ全体（QA、開発者、および必要に応じてプロダクトオーナーも）が同じ問題に同時に取り組んでいます。スタンドアップなし、高度なコミュニケーション、ライブへの直接展開。

http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/から

mobプログラミングの基本的な概念は単純です。チーム全体が、一度に1つのタスクでチームとして一緒に動作します。つまり、1つのチーム– 1つの（アクティブな）キーボード– 1つのスクリーン（もちろんプロジェクター）。これは、チーム全体でペアプログラミングを行うようなものです。

こちらで実際にご覧ください：https : //www.youtube.com/watch?v=dVqUcNKVbYg

このチームモデルについては、スティーブマッコネルの305ページの「Rapid Development-Taming Wild Software Schedules」で再度説明しています。そこではチーフプログラマーチームと呼ばれています。

チームに天才があり、コンピューティングリソースが限られていたため、このモデルが生まれました。天才はまれであり、ユビキタスコンピューターと分散バージョン管理のおかげで、手術台に多くの人が入る余地があります。

その他の参照：

ベイカー、F。テリー。「プロダクションプログラミングのチーフプログラマーチーム管理」、IBM Systems Journal、vol。11、いいえ。1、1972、pp。56-73。

ベイカー、F。テリー、ハーランD.ミルズ。「チーフプログラマーチーム」。Datamation、Volume 19、Number 12（1973年12月）、pp。58-61。

私の推測では、ほとんどの小規模な自己組織化チームは、とにかく事実上の手術チームモデルに落ち着く傾向があります。

私が参加した最後の2つのチームは、通常1人のシニア（外科医）、中級者（副操縦士）、および数人のジュニア/スペシャリストの3人または4人で構成される傾向がありました。最近ブルックスが言及した手術チームの役割の一部は、スクラムマスターとシステム管理者またはクラウドプロバイダーによって満たされています。gitほど強力なものは言うまでもなく、ソース管理は当時ほとんど存在していなかったことを思い出してください。

Bezosの2つのピザのルールを考えてください。それがあなたの自己組織化外科チームです。

同様のことを示唆するHPからの論文がありました。

• 各ソフトウェアエンジニアには、複数のマネージャーと複数のサポート要員が必要です。
• 各エンジニアには、テクニカルライター、テスター、ビルドマネージャー、ツールメーカーが必要です。

この論文はウェブ前の時代で、時々面白いものとして育てられました。毎年、それが育てられたので、この解説は「ばかげているのがおかしい」から「多分私たちはそれをするべきだ」に少しずつ移動しました。

実際のテストは設計が難しいことで有名なので、おそらく意見が残っています。プロジェクトとその完了率の調査が存在する場合があります。

私はどのくらいの手術チームの必要性があるため、インターネットの台頭で冗長になってきただろう、統合開発環境とソフトウェア開発キットフレッド・ブルックスは、外科チームに起因する多くの機能を取ることができる、を含みます：

• 外科医：プログラマー
• 副操縦士：プログラマー、同僚、StackExchangeやIRCなどのオンラインコミュニティのペア
• 管理者：ソフトウェアプロジェクトマネージャーが通常担当する役割
• エディター：JavadocやDoxygenなどのドキュメントジェネレーターを統合するIDE。ソフトウェア開発キットのドキュメント
• 秘書：電子メールクライアント、課題追跡やプルリクエストなどのプロジェクト管理ツール、会社のチャットルーム、メーリングリスト
• プログラムクラーク：プロジェクトデザインに関する情報を保存するIDE。コードをリファクタリングする機能が追加されています。ソフトウェア開発キットのドキュメントと例
• Toolsmith：オープンソースコミュニティ全体
• テスター：すぐに、テストスイートとテストライブラリ。しかし、もちろん、量産コードには別のQAプロセスが必要です。
• 言語弁護士：オンラインドキュメント、StackExchange

神話上の男の月の前提を見る必要があると思います。より多くのプログラマーを雇用しても、問題のある/期限切れのソフトウェアプロジェクトが悪化するだけです。問題はコミュニケーションであり、新しく追加されたプログラマーをプロジェクト（既存の開発から時間がかかります）、テクノロジー、そして時にはドメイン自体のスピードを上げることです。

よくサポートされているプログラマーが、通信時間と調整の多くを排除します。テクノロジーXのコンサルタントを雇ったとしましょう。このコンサルタントがプロジェクトのスピードを上げて、この分野のすべてのコーディングを行えるようになるのではなく、既存の開発者に何かを構築できるように指導します。監督下で。

これがあまり見られない理由の1つは、とにかくほとんどのソフトウェアが1人で書かれているためです。チームが作業を分割し、誰もが自分のことをやります。ペアのプログラミング、レビュー、およびマイクロマネジメントの匂いがするものはすべて眉をひそめます。多くの人は、プログラミングをチームスポーツとは見なしていません。ある人は、全体的な制約をある程度考慮して、与えられた問題を解決します。

設計、実装、テスト、文書化、構築、展開、運用などを専門家によって行われる独自の役割に分離すればするほど、「外科チーム」の哲学に従っていると主張します）。

私の経験では、すべての人がすべてのタスクに対応できるようにするというdevOpsの哲学は、豚肉屋モデルへの回帰です（悪いと言っているのではなく、まったく違う）。

よくDevOpsとBuild Masterの役割を果たしたプログラマーとして、私はしばしば外科チームになるという立場になってしまうと感じました。ビルドマスターとして、コード全体の概要を把握し、失敗した最初の行でした。多くの場合、自分で修正するだけです。
多くの場合、これらのメトリックシステムを作成し、コード内のホットポイント、より頻繁に失敗するパーツ、最も多くのバグレポートなどを集めたホットポイントを測定する人でした。結果をチームに公開するだけでなく、分析します。問題を引き起こしたキンク、これに対処するための提案されたソリューションとアーキテクチャの変更。

DevOpsとして、プロセスとオーバーヘッドの膨大な範囲を自動化します。チーム、チーム全体、開発者、QAテスター、IT運用から管理まで、すべての作業を楽にするテクノロジーとツールを研究したいと思います。私の役割はプロセスを理解することでした。しかし、そのプロセスを使用して（苦しんでいる）チーム（実際の人間）に目を固定することで、有用なデータのスワースを取得しながら、そのプロセスを客観的に見ることができるようになりました。これまでとらえどころのない「全体像」。

それは恩知らずの地位であり、なぜそんなに敬遠されるのでしょう。誰もそのプロセスに気づかなかったとき、ビルドパイプラインについて誰も考えなかったとき、私は自分の仕事をうまくやったことを知っています。そのため、油が十分に塗られた機械は当然のことと見なされます。しかし、実際に測定したところ、この作業がチームの生産性に与える相乗効果はわかっていて、投資する価値は十分にあります。

そうです、確かにその役割は当時のものから進化したものの、その役割は今日でも非常に生き続けていると思います。