「The Mythical Man-Month」の「Surgical Team」パターンはどうなりましたか？
何年か前に、The Mythical Man-Monthを読んだとき、他のソースからすでに知っていたものをたくさん見つけました。しかし、1975年の本であるにもかかわらず、そこにも新しいものがありました。そのうちの1つは次のとおりです。
ミルズは、大きな仕事の各セグメントはチームで取り組むことを提案しますが、チームは豚の屠殺チームではなく、外科チームのように編成することを提案します。つまり、各メンバーが問題を切り捨てるのではなく、1人が切り取りを行い、他のメンバーが彼の有効性と生産性を高めるすべてのサポートを提供します。
これは、ソフトウェア開発チームを編成するための非常に興味深いパターンですが、他のソフトウェアエンジニアリングの本に記載されていないため、どこにも言及されていません。
何故ですか？
- 「外科チーム」は当時も珍しいものでしたか？
- または、試されて失敗しましたか？
- もしそうなら、それはどのように失敗しましたか？
- そうでない場合、なぜそのパターンが今日のソフトウェアプロジェクトに実装されていないのでしょうか。
「神話男月」は、私が大学を始めた年に出て、現在の言葉を使うために、UUUGEでした！ :-)理解する必要があるのは、ソフトウェアの開発方法と今との違いです。バック・イン・ザ・デイ（tm）では、ほとんどすべてのコーディングが最初に紙で行われ、次に（ご想像のとおり）パンチされたカードにキーパンチされ、次に読み込まれ、コンパイルされ、リンクされ、実行され、結果が得られ、プロセスが繰り返されました。 CPU時間は高価であり、リソースが限られているため、無駄にしたくありませんでした。同上、同様にディスクスペース、テープドライブ時間など、なんとか。 （ショックとホラー！）エラーが発生したコンパイルで完全に良好なCPU時間を浪費することは、完全に良好なCPU時間の浪費でした。そして、これは1975年でした。フレッドブルックスが彼のアイデアを開発していたとき、それは1960年代の中頃から後半までのCPU時間はもっと高価でした、メモリ/ディスク/その他の制限など。外科チームの背後にある考え方は、One Super Great Rockstar開発者がデスクチェックコード、キーパンチ、提出などの日常的なタスクにHISの時間を費やす必要がないようにすることでした。ジョブ、結果を待っている（時には数時間）。 Rockstar Dude Developer Manはコードを書くことでした。グルーピー/書記/ジュニア開発者の彼の軍団は平凡なことをすることになっていた。
問題は、ブルックスの本が出版されてから2年以内に、The Surgical Teamの背後にある基本的なアイデアが壊れていたことでした。
CRTターミナルとディスクファイルは、キーパンチとカードデッキに置き換わり始めました。コンピュータ時間はより安価になり、複数のコンピュータが利用可能になり、ジョブのターンアラウンドタイムは劇的に減少しました。大学に入学したとき（マイアミ大学、オハイオ州オックスフォード、'79のクラス、質問ありがとう）良い仕事の所要時間は約1時間でした。決勝週-4時間、場合によっては6時間。 （私たちはCPU時間を競って多くの商業企業や大学と競争しました-そして商業ユーザーが最優先されました）。マイアミがその「共有コンピュータ」の配置から抜け出し、キャンパスに独自のIBM 370/145をインストールし、メインフレームをオンにすることができるRJEステーションとして機能する私が取り組んだ素敵なHPミニを持っている私の年の年の間に5分以内にジョブを実行します。コードをHPで実行し、HPからメインフレームに送信し、親指をいじったり煙草を吸ったりして、コードのデスクチェックを完了する前に出力を元に戻すことは価値のあることです。
外科チームは、基本的な前提として、あなた（または「管理」、神は私たち全員を助けてください）がロックスター外科開発者デュードを識別できるという考えを持っています。実際、それが可能かどうかは疑問です。そこにはarerockstar開発者がいます、誰もが知っています-研究は最高と最低の開発者の生産性に2000％もの違いがあることを示していますが、その人を特定しています長期間コードを書かせずに不可能である可能性が高いです。誰かがロックスターの開発者であるかどうかを知る唯一の方法は、実際にコードを開発させることです-しかし、彼らがロックスターの外科的開発者ではない場合、彼らは彼のコードのデスクチェック、カードへのキーパンチなどのエキサイティングなことをします。実際に機能する唯一の方法をコード化することを学ぶ代わりに、コードを書き、コードをデバッグして、ミスターロックスターサージカルデベロッパーデュードに戻せるように、パンチされたカードの箱をジョブエントリー部門に送り込み、結果を待っています。など。戻る日（tm）プログラミングコンテストがなかった、スタックオーバーフローがなかった、あなたが好きなときにいつでもコードを書くことができるPCがなかった、ばかアルゴリズムの本がなかった-本プログラミングを学ぶ唯一の方法は、学校に通い、少しプログラミングをする必要がある分野を専攻することでした。しかし、プログラミング自体は真剣に受け取られていませんでしたそれは人々がしたくないことだと想定されていました。私の最初のカレッジコース（SAN151-システム分析入門、トムシェーバー博士-ありがとう、トム:-)で、インストラクターから「...私たちは費やさなければならないという事実に直面しなければならなかったシステムアナリストになる前のプログラマーとしての数年間」 「二年？」と思った。 「私はこれを2年間だけ行うつもりですか？！？」。私はまじめにつまらなかった。ありがたいことに彼は間違っていて、それ以来私はコーディングをかなり続けてきました。 :-)
外科チームは、プログラマーは比較的まれなリソースであると想定しています。実際にはさらに数年かかりましたが、80年代の初めにPCが登場したことで、プログラミングはマニアなら誰でも参加できるものになりました。コンピュータの価格は下がり始め、開発ツールの価格も下がり始めました。ああターボパスカル-今日の基準ではそれほどではありませんでしたが、当時は完全なパスカルでしたIDE約40ドルで、これは絶対に大変なことでした！今なら誰でもプログラミングに入ることができます。コンピューターを買う余裕があり、IBMがPCjr（そう、私の最初のPCはIBMの最大の間違いの1つでしたが、これらの七面鳥を取り除くために約500ドルで販売した）を決定したとき、どこにでも現金を手にしたオタクは家賃の支払いをスキップしました1か月（「ええ、ええと、私は知っていますが、私は、ええと...ウブラを壊して手術を受けなければならなかった...ええと...来週、問題ありません、ありがとう、男...）火のセール価格でそれらを吸い込んだ。それから、それを使用可能にするために、アドオンにコンピューターの代金を払った以上の費用を費やした（「そうだね、来週、確かに...」:-)。
私が本当に悲しいのは、今日でも、「The Mythical Man-Month」を読んだことがあるか、またはその主要なレッスンを理解したかどうかを尋ねると（「後のプロジェクトにリソースを追加すると、後でそれができるようになります」）、空白になる凝視-そして、OS/360の開発中にすべての年前に行われたのとまったく同じエラーを作成します。古いものはすべて新しいものです...：-}
areが今日実装されることがあるその概念のいくつかの側面があり、避けられる他の側面があります。
チームを小さく保つことは、アジャイルメソッドの基本機能の1つですが、アジャイル以外でも実践されています。
部門を超えたチームもアジャイルの定番ですが、アジャイル以外でも一般的です。
プログラム書記の役割は、バージョン管理システム、ソフトウェア構成管理システム、変更管理システム、ドキュメント管理システム、Wiki、アーティファクトリポジトリを使用した継続的ビルドシステムなどのコンピュータ化されたシステムに大きく含まれています。つまり、フルタイムの従業員にソースコードを印刷し、手動でインデックスを作成してファイルを提出することを本当に想像できるでしょうか。
同様に、システム管理者の役割（MillsのSurgical Teamの一部ではなく、ここ数年の典型的な部門間チームの一部）は、DevOps（Sysadminの役割をSoftware Engineerの役割に吸収する）などの概念によって時代遅れになっています。 、Platform-as-a-Service、Infrastructure-as-a-Service、Utility Computing（Sysadminの役割を「誰か他の問題」にする）、またはInfrastructure-as-Code（システム管理をソフトウェアエンジニアリングに変える）。
今日避けようとしている側面の1つは、最大2人がシステムを理解していることです。外科医だけがシステムを完全に理解することが保証されています、副操縦士はそうかもしれませんし、そうでないかもしれません。これにより、1〜2のバス係数が得られます。外科医が病気になった場合、プロジェクトは死にます。限目。これに対するアジャイルの答えは、そのコードの正反対である集合コード所有権です：nobodyは、システムのすべての部分を単独で担当します。代わりに、everybodyがeverythingグループとして責任を負います。
最後に、その概念に組み込まれたいくつかの仮定が古くなっています。たとえば、明示的には述べられていませんが、チームは、チーム内の1人（外科医）だけが実際にコンピューターを持っているように設定されています。つまり、もちろん記事が書かれた時点で、チーム全体で1人のコンピュータはもちろん、チーム全体が1台のコンピュータを所有するという考えでさえ、一筋縄ではいきませんでした。 （1980年にSmalltalkがリリースされたときでも、失敗の原因の1つは、システムがすべての開発者とすべてのユーザーが自分のコンピュータを使用できるように設定されていたことでした。当時はまったく考えられませんでした）。
つまり、簡単に言うと、コンセプトは説明どおりに実装されていないと思いますが、そのいくつかの側面は確実に実装されていますare実装されており、いくつかの側面が見られます望ましくなく積極的に回避されるため、いくつかは時代遅れであり、いくつかはおそらくGood Ideas™ですが、誰もそれをしていません。
それはかつて、大学教育はユニークなものであり、エンジニアは選ばれた少数の一人でした。コンピューターは高価で、チームはビジネスRoIが定義されたプロジェクトに取り組みました。これらはあまり一般的ではありませんでした。
起こったことは、マイクロコンピューター、ユビキタスな学部教育、そして進歩するために大学の学位を必要としないコンピューターシステムでした。また、起こったのは経済の変化と労働コストの上昇でした。
8：2のサポート：エンジニア比率の経済性は、もはや意味がありません。エンジニアは彼ら自身のサポートでなければなりません。十分な教育とスキルを備えた、開発チームに所属する現代の人間は、高額すぎて、何らかの独自の開発を行うことができません。
（関連する経済学用語は「サービス部門のコスト病」です。）
このパターンは、Mobプログラミングのように私にはよく聞こえます。
グループ全体（QA、開発者、さらに必要に応じてプロダクトオーナーまで）が同じ問題で同時に作業しています。立ち上がっていない、高いコミュニケーション、直接ライブに展開。
から http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/
Mobプログラミングの基本的な概念は単純です。チーム全体が同時に1つのタスクでチームとして機能します。つまり、1つのチーム– 1つの（アクティブな）キーボード– 1つの画面（もちろん、プロジェクター）です。これは、チーム全体のペアプログラミングを行うのと同じです。
ここで実際に見てください： https://www.youtube.com/watch?v=dVqUcNKVbYg
このチームモデルについては、305ページの「Steve McConnellによるRapid Development-Taming Wild Software Schedules」で再度言及しています。そこでは、チーフプログラマチームと呼ばれています。
このモデルは、チームに天才があり、コンピューティングリソースが限られていたために発生しました。天才は稀であり、ユビキタスコンピュータと分散バージョン管理により、手術台に多くの手を置く余地があるので、それは支持から外れています。
その他の参考資料：
ベイカー、F。テリー。 「プロダクションプログラミングのチーフプログラマチームによる管理」、IBM Systems Journal、vol。 11、いいえ。 1、1972、56-73ページ。
ベイカー、F。テリー、ハーランD.ミルズ。 「チーフプログラマチーム」 Datamation、ボリューム19、ナンバー12（1973年12月）、58-61ページ。
私の推測では、ほとんどの小さな自己組織化チームは、とにかく事実上の手術チームモデルに落ち着く傾向があるでしょう。
私がこれまで行ってきた最後の2つのチームは、3人または4人で構成される傾向があります。今日ブルックスが言及している外科チームの役割のいくつかは、スクラムマスターとシステム管理者、またはクラウドプロバイダーが担当しています。当時、ソースコントロールはほとんど存在していなかったことに注意してください。gitのような強力なものは言うまでもありません。
ベゾスの2ピザのルールを考えてみてください。それがあなたの自己組織化外科チームです。
HPから同様のことを示唆する論文が出されました。
- 各ソフトウェアエンジニアには、複数のマネージャーと複数のサポート担当者が必要です。
- 各エンジニアにはテクニカルライター、テスター、ビルドマネージャー、ツールメーカーが必要です。
紙はウェブの前の時代で、時々面白いように取り上げられました。毎年それが取り上げられたとき、解説は「とてもばかげているそのおかしい」から「多分それをやるべきだ」に少し動いた。
実際のテストは設計が難しいことで悪名高いので、おそらく意見は残っています。プロジェクトとその完了率の調査が存在する場合があります。
インターネットの台頭により、外科チームの必要性がどれほど冗長になったのでしょうか 統合開発環境 および ソフトウェア開発キット 、フレッド・ブルックス氏が外科チームに帰属した機能の一部。
- 外科医：プログラマー
- 副操縦士： ペアプログラマー 、同僚、StackExchangeやIRCなどのオンラインコミュニティ
- 管理者：一般的にソフトウェアが担う役割 プロジェクトマネージャー
- エディター：JavadocやDoxygenなどのドキュメントジェネレーターを統合するIDE。ソフトウェア開発キットのドキュメント
- 秘書：電子メールクライアント、課題追跡やプルリクエストなどのプロジェクト管理ツール、会社のチャットルーム、メーリングリスト
- プログラム担当者：IDEコードをリファクタリングする機能が追加されたプロジェクト設計に関する情報の保存、ソフトウェア開発キットのドキュメントと例
- Toolsmith：オープンソースコミュニティ全体
- テスター：すぐに、テストスイートとテストライブラリ。ただし、当然、本番用コードには個別のQAプロセスが必要です。
- 言語弁護士：オンラインドキュメント、StackExchange
The Mythical Man Monthの前提を見直す必要があると思います。より多くのプログラマーを雇うことは、問題のある/期限切れのソフトウェアプロジェクトを悪化させるだけです。問題は、コミュニケーションと、新しく追加されたプログラマーがプロジェクト（既存の開発に時間がかかる）、テクノロジー、そして場合によってはドメイン自体に迅速に対応できるようにすることです。
十分にサポートされたプログラマー1人が、通信時間と調整の多くを排除します。テクノロジーXのコンサルタントを雇ったとしましょう。このコンサルタントをプロジェクトの速度を上げて、この個人がその領域ですべてのコーディングを実行できるようにするのではなく、既存の開発者を指導して、何かを構築できるようにします。いくつかの監督付き。
これがあまり見られない理由の1つは、ほとんどのソフトウェアがとにかく一人で書かれているためです。チームが作業を分割し、全員が行って作業を行います。ペアプログラミング、レビュー、マイクロマネージメントの匂いがするものはすべて嫌がられます。多くの人はプログラミングをチームスポーツとは考えていません。ある人は、全体的な制約を考慮して、与えられた問題を解決します。
DevOpsとBuild Masterの役割を頻繁に担当するプログラマーとして、私はしばしば外科チームになるという立場になってしまうと感じました。ビルドマスターとして、コード全体の概要があり、失敗したときの最初の行でした。多くの場合、自分で修正します。
私はしばしばこれらのメトリクスシステムを作成し、コードのホットポイント、より頻繁に失敗するパーツ、ほとんどのバグレポートなどを集めたものを測定しました。分析するチームに結果を公開しただけではありませんでしたそれらも、問題の原因となったねじれと、これに対処するために提案されたソリューションとアーキテクチャの変更を見つけます。
DevOpsとして、私は一連のプロセスとオーバーヘッドを自動化しました。私は、開発者、QAテスター、IT運用から管理まで、チーム全体、チーム全体での生活を楽にするテクノロジーとツールを研究します。私の役割はプロセスを理解することでした、はい。しかし、そのプロセスを使用して（苦しんでいる）チーム（実際の人間）に注意を向け続けることで、それを完全に透明にするポイントまでそれを詳細化し、その一方で客観的なビューを得るための有用なデータを取得することができました。とらえどころのない「全体像」。
これは恩知らずの立場であり、なぜそれがそんなに敬遠されるのでしょう。ビルドパイプラインについて誰も考えなかったときに、誰もそのプロセスに気づかなかったとき、私はうまく仕事をしたことを知っています。ですから、よく油を塗った機械はすぐに当たり前のことと見なされます。しかし、私は実際に測定したところ、この作業がチームの生産性に及ぼす可能性のある相乗的影響を知っており、投資する価値は十分にあります。
ですから、確かに、その役割は現在でも非常に活気に満ちていると思いますが、確かに、その役割は当時の状態から進化したものでした。
設計、実装、テスト、文書化、構築、展開、運用などを専門家が行う固有の役割に分離すればするほど、「外科チーム」の哲学に従っていると言えます（ただし、説明されているとおりではないかもしれません） ）。
私の経験では、すべての人がすべてのタスクを実行できるようにするというdevOpsの哲学は、豚を屠殺するモデルに戻ることです（悪いことではなく、ただ違う）。