8

神話上の人月は今や古典的ですが、「外科チーム」の方法論は依然として興味深いものです。どの方法論がそれに最もよく似ているか、または同じ本質を持っていますか?

外科チームのアナロジーを要約すると: 外科医は問題/ビジネス領域を理解し、専門家です。彼らは、チーム内で疑問や対立があるときの権限です。外科医は、設計などの問題が発生した場合、専門家の小規模な緊密なチームとして機能し、互いに協力します。つまり、本質的に彼らはドメインの知識を持っており、正しいと思うことを任せられ、実際のコーディングを行うのでしょうか? チームの残りの部分は、サポート、テスト、文書化に重点を置いており、プロジェクト計画は委任されたタスクです。したがって、外科医は最も熟練した/訓練されたリソースでもあります。

答えは、プロジェクト、プログラミング、設計方法論である可能性があります。これは、主要な方法論ドメイン全体に影響を与えるように思われるためです。アジャイル、MDA、エクストリーム、ソーシング開発? この質問は、複雑なビジネス ドメインで大規模なソフトウェアの場合にも、より意味があります。COTS 開発者や一般的なユーティリティではなく、航空管制を考えてみてください。

4

4 に答える 4

6

アジャイル ソフトウェア開発の組織パターンで言及されているパターンの 1 つは、「役割ごとに 3 人から 7 人のヘルパー」というタイトルです。すべての役割に注意を払うという点で外科チームとは異なります。たとえば、ヘルパーまたは関係を持つのは外科医の「役割」だけではありません。すべての役割にはいくつかの関係があります。

「アーキテクトも実装する」という名前の同じソースからの別のパターンは、特にアーキテクトが（おそらく）高度なスキルを持っているという点で「外科チーム」に類似している可能性があります。

于 2009-05-22T18:16:13.077 に答える
3

外科医の場合、主要なアクターはドメインの専門家と実装者の両方です。

つまり、彼はソフトウェア プログラム マネージャー (アーキテクト) であり、開発者でもあります。

この種の方法論は、特定の短期的な状況に適している場合があります。たとえば、サーバーのライブ移行やソフトウェアのアップグレードなどの複雑な操作です。

ただし、一般的な開発では、このような「ヒーロー」の方法論にはいくつかの問題があります。

  • 問題のドメインを十分に理解している主要な開発者はほとんどおらず、ドメインの専門家に頼らなければなりません。これは単に専門分野の機能にすぎません。弁護士、医師、会計士、またはソフトウェアがモデリングしている分野の専門家でもある、気の利いたプログラマーを見つけるのは困難です。

  • スケーラビリティは、利用可能な「外科医」の数によって制限されます。

  • 集中力の高い「実行者」がチームを管理しているため、他のスタッフが指示を待っている間、多くのダウンタイムがあります。OR では問題ありません。"バグゼロ" の義務と "ライブ ソフトウェア" を扱っているからです。しかし、この経済状況では、チーム メンバー間の同期の問題がときどき発生する場合でも、より分散されたワークロードがより効率的です。

于 2009-05-22T18:34:33.437 に答える
1

開発者が実際にどのようにソフトウェアを開発するかということではなく、開発者に優先順位を付け、すべてを彼らのニーズに合わせることの問題であるため、どの方法論も実際にそれに対処しているとは確信していません。

これを妨げる何らかの方法論を探しているなら、これは悪いニュースかもしれません。これは、ほとんどすべてのソフトウェア開発手法でこのアプローチを使用できるという意味で、良いニュースだと思います。

私は、そのように実行された1 つのプロジェクトに取り組んできました。「仕事」と呼ぶのがもったいないくらい楽しかったです。私たち 4 人の開発者 (時折追加のジュニア コード モンキーを含む追加のサポート担当者を含む) は、わずか 9 か月で本当に膨大な量のコードを作成し、適切に実行することができました。私が行ったことのある他の場所では、20 人のチームではこれほど多くのことはできませんでした。

于 2009-05-22T18:20:16.863 に答える
0

テキストから、次のことがわかります。

アジャイルのように:

  • 特定の問題の解決に焦点を当てた小さなチーム
  • 外科医間のコラボレーション

非アジャイルのようなもの:

  • 外科医は権威であり、計画を推進し、設計を決定し、サポートタスクを割り当て (彼らをコーディングに従属していると見なして)、コーディングを行います。これらはすべて、アプローチにおいて非常にコマンドアンドコントロールであり、自己管理型のチームとは対照的です (対管理型のチーム)。
  • ビジネス パートナーとのコラボレーションがないように見える (ビジネス パートナーとの頻繁なコラボレーションは言うまでもなく)
  • 優先順位の付けられた製品のバックログがないように見えるため、外科医はビジネス パートナーではなく重要なものを選択します。
  • 増分配信はないようです (タイトなフィードバック ループ)

ウォーターフォール プロジェクトの場合、専門家 (外科医) のチームを使用して、計画、設計、コーディングなどを行い、「サポート」スタッフにタスクを割り当てることを提案しています。アジャイル チームでは、テストはサポートとしてではなく、デリバリーの不可欠な部分として扱われます。

提唱されている方法論を確実に言うことはできません。ただし、言語 (プロジェクト計画、タスク) を使用しているように見え、ウォーターフォール アプローチ (計画に基づく設計、コーディング、テストなどのフェーズ) に従っていることを前提としています。どのような方法論が使用されているにせよ、それは少数者が多数者の仕事を決定するものです。

于 2009-05-22T18:35:23.170 に答える