新しい方法論（オリジナル）

設計と構築の分離

方法論の通常のインスピレーションは、土木工学や機械工学などの工学分野です。このような分野では、構築する前に計画を立てることに重点が置かれています。そのようなエンジニアは、構築する必要があるものと、それらをどのように組み合わせる必要があるかを正確に示す一連の図面に取り組みます。橋の荷重への対処方法など、多くの設計上の決定は、図面が作成されるときに行われます。その後、図面は別のグループ（多くの場合、別の会社）に渡されて、構築されます。構築プロセスは図面に従うと想定されています。実際には、コンストラクターはいくつかの問題に遭遇しますが、これらは通常は小さいものです。

図面はピースとその組み立て方法を指定しているため、詳細な構築計画の基礎となります。このような計画では、実行する必要があるタスクと、これらのタスク間に存在する依存関係を把握できます。これにより、かなり予測可能なスケジュールと構築予算が可能になります。また、建設作業を行う人々がどのように作業を行うべきかを詳細に示しています。これにより、建設は知的スキルが低くても済みますが、多くの場合、手動で非常に熟練しています。

そのため、ここでは根本的に異なる2つのアクティビティが見られます。予測が難しく、高価で創造的な人材を必要とする*設計*と、予測が容易な*構築*です。設計ができれば、構築を計画できます。構築の計画ができれば、はるかに予測可能な方法で構築に対処できます。土木工学では、建設は設計と計画よりもコストと時間の両方ではるかに大きくなっています。

そのため、多くの方法論のアプローチは次のようになります。スキルが低い人材を使用できる予測可能なスケジュールが必要です。これを行うには、設計と構築を分離する必要があります。したがって、計画が完了したら構築を簡単に行えるように、ソフトウェアの設計方法を理解する必要があります。

では、この計画はどのような形をとるのでしょうか？多くの人にとって、これはUMLなどの設計表記の役割です。UMLを使用してすべての重要な決定を行うことができれば、構築計画を作成し、これらの設計をコーダーに構築活動として引き渡すことができます。

しかし、ここに重要な質問があります。コーディングを構築活動に変えることができる設計を得ることができますか？もしそうなら、このアプローチを worthwhile にするのに十分なコストと時間で構築は十分に大きいですか？

これらすべてがいくつかの疑問を思い起こさせます。1つ目は、UMLのような設計をプログラマーに引き渡せる状態にするのがどれほど難しいかということです。UMLのような設計の問題点は、紙の上では非常によく見えても、実際にプログラムしなければならないときは深刻な欠陥がある可能性があることです。土木技師が使用するモデルは、エンジニアリングコードに enshrined されている長年の実践に基づいています。さらに、設計における力の働き方など、重要な問題は数学的分析に適しています。UMLのような図でできる唯一のチェックはピアレビューです。これは役に立ちますが、コーディングとテスト中にのみ明らかになる設計上のエラーにつながります。私自身も熟練した設計者であると考えていますが、そのような設計をソフトウェアに変換すると、しばしば驚かされます。

もう1つの問題は、比較コストの問題です。橋を建設する場合、設計作業のコストは作業全体の約10％であり、残りは建設です。ソフトウェアでは、コーディングに費やされる時間ははるかに少なくなります（マコネルは、大規模プロジェクトの場合、プロジェクトの15％だけがコードと単体テストであり、橋の建設比率とほぼ完全に逆転していると示唆しています。すべてのテストを建設の一部に含めたとしても、設計は依然として作業の50％です。）これは、ソフトウェアにおける設計の性質と、他のエンジニアリング分野におけるその役割について重要な疑問を提起します。

これらの種類の質問により、ジャック・リーブスはソースコードは設計ドキュメントであり、構築フェーズは実際にはコンパイラとリンカの使用であると示唆しました。実際、構築として扱うことができるものはすべて自動化する必要があります。

この考え方は、いくつかの重要な結論につながります

• ソフトウェアでは、構築は無料であるほど安価です
• ソフトウェアでは、すべての努力は設計であり、創造的で才能のある人材が必要です
• 創造的なプロセスは簡単に計画できるものではなく、予測可能性は不可能な目標である可能性があります
• ソフトウェアを構築するための従来のエンジニアリングのメタファーには非常に注意する必要があります。これは異なる種類のアクティビティであり、異なるプロセスが必要です

要件の予測不可能性

私が遭遇したすべての問題プロジェクトで聞いた言葉があります。開発者は私のところにやって来て、「このプロジェクトの問題は、要件が常に変化することです」と言います。この状況で私が驚くべきことは、誰もがそれに驚いているということです。ビジネスソフトウェアを構築する際には、要件の変更は当たり前であり、問題はそれについてどうするかです。

変化する要件への対処法の一つは、それを要件エンジニアリングの失敗の結果とみなすことです。要件エンジニアリングの背後にある考え方は、ソフトウェアの構築を開始する前に要件を完全に理解し、顧客からこれらの要件の承認を得て、承認後に要件の変更を制限する手順を確立することです。

この方法の問題点の一つは、要件の選択肢を理解すること自体が難しいということです。さらに、開発組織が通常、要件に関するコスト情報を提供しないため、事態はより困難になります。あなたは、車にサンルーフをつけたいと思っているかもしれませんが、営業担当者がサンルーフのコストが10ドルなのか10,000ドルなのか教えてくれない状況に陥るのです。コストがわからなければ、サンルーフに費用を払うべきかどうかを判断できるでしょうか？

見積もりは多くの理由で困難です。その理由の一つは、ソフトウェア開発は設計作業であり、計画とコストの見積もりが難しいことです。また、基本的な素材が急速に変化し続けることも理由の一つです。さらに、どの個人が関与するかによって大きく左右されるという点も重要です。個人は予測や定量化が難しいからです。

ソフトウェアの無形性も問題を複雑にします。ソフトウェアの機能がどのような価値を持つのかは、実際に使用してみないとわかりません。ソフトウェアの初期バージョンを使用してみて初めて、どの機能が価値があり、どの部分がそうでないかを本当に理解し始めるのです。

これは、人々が要件は変更可能であるべきだと期待するという皮肉な点につながります。結局のところ、ソフトウェアは「ソフト」であるべきです。そのため、要件は変更可能であるだけでなく、変更可能であるべきなのです。ソフトウェアの顧客に要件を確定させるには、多くのエネルギーが必要です。顧客がソフトウェア開発に少しでも携わったことがある場合はさらに厄介です。なぜなら、彼らはソフトウェアが簡単に変更できることを「知っている」からです。

しかし、たとえこれらすべてを解決し、本当に正確で安定した要件セットを得ることができたとしても、おそらくまだあなたは失敗する運命にあります。今日の経済では、根本的なビジネスの力はソフトウェア機能の価値を急速に変えています。現在良い要件セットであっても、6か月後には良いセットではなくなる可能性があります。顧客が要件を固定できたとしても、ビジネスの世界は彼らを待ってはくれません。そして、ビジネスの世界の変化の多くは完全に予測不可能です。そうでないと言う人は、嘘をついているか、株式市場の取引で10億ドルを稼いだかのどちらかです。

ソフトウェア開発における他のすべては、要件に依存します。安定した要件が得られなければ、予測可能な計画を立てることはできません。

予測可能性は不可能か？

一般的には、予測可能なソフトウェア開発は不可能です。しかし、予測可能性が可能なソフトウェア開発も存在します。NASAのスペースシャトルソフトウェアグループなどの組織は、ソフトウェア開発が予測可能であることの代表的な例です。それは、多くの儀式、十分な時間、大規模なチーム、そして安定した要件を必要とします。スペースシャトルのようなプロジェクトは存在します。しかし、多くのビジネスソフトウェアがそのカテゴリーに当てはまるとは思いません。そのためには、異なる種類プロセスが必要です。

大きな危険の一つは、予測不可能なプロセスに従うことができると偽ることです。方法論に取り組んでいる人々は、境界条件、つまり方法論が適切なものから不適切なものに移行する場所を特定するのがあまり得意ではありません。ほとんどの方法論者は、すべての人が自分の方法論を使用できるようにしたいと考えているため、境界条件を理解したり、公表したりしません。これは、予測不可能な状況で予測可能な方法論を使用するなど、間違った状況で方法論を使用することにつながります。

そうしたいという強い誘惑があります。予測可能性は非常に望ましい特性です。しかし、できないときに予測できると信じていると、初期段階で計画を立て、計画が崩壊した状況に適切に対処しないという状況につながります。計画と現実が徐々に乖離していくのを見ることになります。長い間、計画はまだ有効であると偽ることができます。しかし、ある時点でずれが大きくなりすぎて、計画は崩壊します。通常、その崩壊は苦痛を伴います。

したがって、予測不可能な状況では、予測的な方法論を使用することはできません。これは大きな打撃です。プロジェクトを管理するための多くのモデル、顧客関係全体の多くのモデルが、もはや真実ではないことを意味します。予測可能性の利点は非常に大きいため、手放すのは難しいです。多くの問題と同様に、最も難しい部分は、問題が存在することを単に認識することです。

しかし、予測可能性を手放すということは、制御できない混沌に逆戻りする必要があるという意味ではありません。代わりに、予測不可能性を制御できるプロセスが必要です。それが適応性です。

予測不可能なプロセスの制御

では、予測不可能な世界でどのように自分自身を制御するのでしょうか？最も重要で、依然として難しい部分は、自分がどこにいるのかを正確に知ることです。頻繁な間隔で状況を正確に教えてくれる、正直なフィードバックメカニズムが必要です。

このフィードバックの鍵は、反復開発です。これは新しいアイデアではありません。反復開発は、インクリメンタル、エボリューショナル、ステージド、スパイラルなど、多くの名前でしばらくの間存在していました。反復開発の鍵は、必要な機能のサブセットを持つ最終システムの動作バージョンを頻繁に作成することです。これらの動作するシステムは機能が不足していますが、それ以外の点では最終システムの要求に忠実である必要があります。それらは完全に統合され、最終的な納品物と同様に慎重にテストされるべきです。

重要なのは、テスト済みで統合されたシステムほど、あらゆるプロジェクトに現実を突きつけるものはないということです。ドキュメントはあらゆる種類の欠陥を隠すことができます。テストされていないコードは多くの欠陥を隠すことができます。しかし、人々が実際にシステムの前に座って作業すると、バグと誤解された要件の両方の点で、欠陥が本当に明らかになります。

反復開発は、予測可能なプロセスでも理にかなっています。しかし、適応プロセスでは、必要な機能の変更に対処できる必要があるため、不可欠です。これは、長期計画が非常に流動的で、安定した計画は単一の反復に対して作成された短期計画のみであるというスタイルの計画につながります。反復開発は、各反復において、後で計画の基盤とすることができる確固とした基盤を提供します。

このための重要な質問は、反復の長さです。人によって答えは異なります。XPは1〜3週間の反復を提案しています。SCRUMは1か月を提案しています。クリスタルはさらに長くなります。しかし、傾向としては、各反復を可能な限り短くすることです。これにより、より頻繁なフィードバックが得られるため、自分がどこにいるのかをより頻繁に知ることができます。

適応性のある顧客

この種の適応プロセスでは、特に開発が別の会社によって行われる場合、顧客との関係が、しばしば考えられるものとは異なる種類のものになります。別の会社にソフトウェア開発を依頼する場合、ほとんどの顧客は固定価格契約を好みます。開発者に必要なものを伝え、入札を求め、入札を受け入れると、ソフトウェアを構築する責任は開発組織にあります。

固定価格契約には、安定した要件と、それに伴う予測可能なプロセスが必要です。適応プロセスと不安定な要件は、通常の固定価格の概念ではうまくいかないことを意味します。適応プロセスに固定価格モデルを適用しようとすると、非常に苦痛な爆発が起こります。この爆発の厄介な部分は、顧客がソフトウェア開発会社と同じくらい傷つくということです。結局のところ、顧客はビジネスで必要でなければソフトウェアを求めていないでしょう。ソフトウェアを入手できなければ、ビジネスは苦しみます。そのため、開発会社に何も支払わなくても、彼らは損をします。実際、彼らはソフトウェアに支払うよりも多くの損失を被ります（ソフトウェアのビジネス価値がそれよりも低ければ、なぜソフトウェアに支払うのでしょうか？）。

そのため、予測プロセスを使用できない状況で固定価格契約に署名すると、両方の側にとって危険があります。これは、顧客が異なる方法で作業する必要があることを意味します。

適応プロセスでは、顧客はソフトウェア開発プロセスをよりきめ細かく制御できます。すべての反復で、彼らは進捗状況を確認し、ソフトウェア開発の方向性を変えることができます。これは、ソフトウェア開発者とのより緊密な関係、真のビジネスパートナーシップにつながります。このレベルのエンゲージメントは、すべての顧客組織、あるいはすべてのソフトウェア開発者にとって適切なわけではありませんが、適応プロセスを適切に機能させるためには不可欠です。

顧客にとっての主な利点は、はるかに応答性の高いソフトウェア開発です。最小限ではありますが、使用可能なシステムを早期に本番稼働させることができます。その後、顧客はビジネスの変化に応じて、また現実のシステムの使用方法から学んだことに基づいて、機能を変更できます。

プラグ互換プログラミングユニット

従来の方法論の目的の一つは、関係する人々が交換可能な部品であるプロセスを開発することです。このようなプロセスでは、人々をさまざまなタイプで利用可能なリソースとして扱うことができます。アナリスト、コーダー、テスター、マネージャーがいます。個人はそれほど重要ではなく、役割のみが重要です。そうすれば、プロジェクトを計画する場合、どのアナリストとどのテスターを取得するかは問題ではなく、何人いるかを知っていれば、リソースの数が計画にどのように影響するかを知ることができます。

しかし、これは重要な疑問を提起します。ソフトウェア開発に関わる人々は交換可能な部品なのでしょうか？軽量メソッドの重要な特徴の一つは、この仮定を拒否することです。

おそらく、人々をリソースとみなすことを最も明確に拒否しているのは、Alistair Cockburnです。彼の論文「Characterizing People as Non-Linear, First-Order Components in Software Development」の中で、彼は予測可能なプロセスには予測可能な方法で動作するコンポーネントが必要であると述べています。しかし、人々は予測可能なコンポーネントではありません。さらに、ソフトウェアプロジェクトに関する彼の研究により、人々はソフトウェア開発において最も重要な要素であると結論付けました。

タイトル[彼の記事の]では、私は人々を「コンポーネント」と呼んでいます。これは、プロセス/方法論の設計文献で人々がどのように扱われているかです。このアプローチの間違いは、「人々」は非常に多様で非線形であり、独自の成功と失敗のモードを持っているということです。これらの要因は一次であり、無視できるものではありません。プロセスと方法論の設計者がそれらを考慮に入れなかったことが、私たちがしばしば目にする計画外のプロジェクトの軌跡の一因となっています。

-- [cockburn-non-linear]

Cockburnはソフトウェア開発における人間中心の考え方を最も明確に示していますが、人間を第一に考えるという概念は、ソフトウェアにおける多くの思想家にとって共通のテーマです。問題は、方法論がプロジェクトの成功における一次的な要因としての人間の概念に反対してきたことです。

これは強い正のフィードバック効果を生み出します。すべての開発者がプラグ互換のプログラミングユニットであることを期待している場合、個人として扱うことはしません。これは士気（と生産性）を低下させます。優秀な人材はより良い場所を探し、あなたは自分の望むものを手に入れることになります。プラグ互換のプログラミングユニットです。

人を第一に考えるというのは、大きな決断であり、それをやり遂げるには強い決意が必要です。人材を資源とみなす考え方は、ビジネス思考に深く根付いており、その起源は、フレデリック・テイラーの科学的管理法の影響にまで遡ります。工場の運営においては、このテイラー主義的なアプローチは理にかなっています。しかし、ソフトウェア開発は非常に創造的で専門的な仕事であり、私はそう信じていますが、このアプローチは当てはまりません。（実際、現代の製造業もテイラー主義モデルから脱却しつつあります。）

プログラマーは責任ある専門家である

テイラー主義の重要な考え方のひとつは、実際に作業を行う人々は、その作業を最も効率的に行う方法を理解しているわけではない、というものです。工場では、これはいくつかの理由で真実かもしれません。ひとつには、多くの工場労働者が最も知的または創造的な人々ではないということがあり、また、経営陣と労働者の間には、労働者の賃金が低いほど経営陣の利益が増えるという緊張関係があるためでもあります。

近年の歴史は、ソフトウェア開発においてこれがいかに真実でないかをますます示しています。ソフトウェア開発には、その華やかさと潜在的な高収入の両方に惹かれて、ますます優秀で有能な人材が集まっています。（私も、これらの魅力に惹かれて電子工学から転身しました。）ストックオプションのような制度は、プログラマーの利益と企業の利益をますます一致させています。

（ここには世代効果があるかもしれません。いくつかの事例証拠から、過去10年ほどでより優秀な人材がソフトウェアエンジニアリングに参入してきたのではないかと考えさせられます。もしそうであれば、コンピュータ業界に若者崇拝の風潮がある理由の説明がつくかもしれません。ほとんどのカルトと同様に、そこには真実の欠片が必要なのです。）

優秀な人材を採用し、維持したいのであれば、彼らが有能な専門家であることを認識しなければなりません。そのため、彼らは技術的な作業をどのように行うかを決定するのに最適な人材です。作業方法を決定する別個の計画部門というテイラー主義的な考え方は、計画担当者が作業を行う人々よりも作業方法を理解している場合にのみ有効です。優秀で意欲的な人材が作業を行っているのであれば、これは当てはまりません。

人中心のプロセスの管理

軽量プロセスでは、人材重視はさまざまな形で現れます。それはさまざまな効果をもたらし、必ずしもすべてが一致するわけではありません。

重要な要素のひとつは、プロセスの押し付けではなく、プロセスの受け入れです。ソフトウェアプロセスは、しばしば経営陣によって押し付けられます。そのため、特に経営陣が実際の開発から長期間離れている場合、抵抗を受けることがよくあります。プロセスを受け入れるにはコミットメントが必要であり、そのためにはチーム全員の積極的な参加が必要です。

これは、開発者自身だけが適応型プロセスに従うことを選択できるという興味深い結果をもたらします。これは、実行に多くの規律を必要とするXPに特に当てはまります。Crystalは、最小限の規律を目標としているため、効果的な補完策となります。

もうひとつのポイントは、開発者が*すべて*の技術的な決定を下せる必要があるということです。XPは、その計画プロセスにおいて、開発者のみが作業にどれくらいの時間がかかるかを推定できると規定している点で、この核心に触れています。

このような技術的なリーダーシップは、多くの管理職にとって大きな変化です。このようなアプローチでは、開発者と経営陣がプロジェクトのリーダーシップにおいて対等な立場を持つ、責任の分担が必要です。*対等*と言っていることに注意してください。経営陣は依然として役割を果たしますが、開発者の専門知識を認識します。

この重要な理由は、私たちの業界における技術の変化の速さです。数年後には、技術的な知識は時代遅れになります。この技術スキルの半減期は、他のどの業界にも例を見ません。技術者でさえ、管理職に就くということは、技術スキルが急速に衰えることを認識しなければなりません。元開発者は、自分の技術スキルが急速に失われていくことを認識し、現在の開発者を信頼し、頼りにする必要があります。

ビジネスリーダーシップの役割

しかし、技術者だけでプロセス全体を行うことはできません。ビジネスニーズに関するガイダンスが必要です。これは、適応型プロセスのもうひとつの重要な側面につながります。それは、ビジネスの専門知識との非常に緊密な連携が必要であるということです。

これは、ほとんどのプロジェクトにおけるビジネスロールの関与を超えています。軽量チームは、時折のコミュニケーションだけでは存在できません。ビジネスの専門知識に継続的にアクセスできる必要があります。さらに、このアクセスは管理レベルで処理されるものではなく、すべての開発者が利用できるものです。開発者は、それぞれの分野の有能な専門家であるため、他の分野の専門家と対等に協力できる必要があります。

もちろん、これは適応型開発の性質によるものです。適応型開発の前提は、物事が急速に変化することであるため、変化を全員に知らせるために常に連絡を取り合う必要があります。

開発者にとって、自分の努力が無駄になるほど frustratinge なことはありません。そのため、開発者が利用でき、かつ開発者が信頼できる質の高いビジネスの専門知識があることを確認することが重要です。

XP（エクストリームプログラミング）

すべての軽量方法論の中で、これは最も注目を集めているものです。これは partly に、XPのリーダー、特にケント・ベックの注目を集める remarkable な能力によるものです。また、ケント・ベックが人々をこのアプローチに惹きつけ、主導的な役割を果たす能力によるものでもあります。しかし、ある意味では、XPの人気が問題となっており、他の方法論とその貴重なアイデアを締め出してしまっています。

XPのルーツは、Smalltalkコミュニティ、特に1980年代後半のケント・ベックとウォード・カニンガムの緊密な協力関係にあります。2人とも、1990年代初頭に多くのプロジェクトで実践を積み重ね、適応性と人間中心の両方を備えたソフトウェア開発アプローチのアイデアを拡張しました。

非公式な実践から方法論への決定的なステップは、1996年の春に起こりました。ケントは、クライスラーの給与計算プロジェクトの進捗状況をレビューするように依頼されました。プロジェクトは請負会社によってSmalltalkで実施されており、問題を抱えていました。コードベースの品質が低いため、ケントはコードベース全体を破棄し、彼のリーダーシップの下で最初からやり直すことを推奨しました。その結果が、クライスラーC3プロジェクト（Chrysler Comprehensive Compensation）であり、XPの初期のflagshipであり、トレーニングの場となりました。

C3の最初のフェーズは、1997年初頭に稼働しました。プロジェクトはその後も継続され、後に困難に遭遇し、1999年にさらなる開発が中止されました。これを書いている時点では、まだ最初の10,000人の従業員に給与を支払っています。

XPは、コミュニケーション、フィードバック、シンプルさ、勇気という4つの価値観から始まります。そして、XPプロジェクトが従うべき12のプラクティスを構築します。これらのプラクティスの多くは、古くから試行錯誤されてきた技術ですが、多くの計画プロセスを含め、多くの人々に忘れられています。XPは、これらの技術を復活させるだけでなく、それぞれが互いに強化し合う相乗効果のある全体に織り込みます。

最も印象的で、私にとって initially 魅力的だったことの1つは、テストを重視していることです。すべてのプロセスでテストについて言及されていますが、ほとんどのプロセスではあまり重視されていません。しかし、XPはテストを開発の基盤に置いており、すべてのプログラマーは本番コードを書くのと同時にテストを書いています。テストは、継続的な統合とビルドプロセスに統合され、将来の開発のための非常に安定したプラットフォームを提供します。

このプラットフォーム上で、XPは、反復ごとにシンプルなベースシステムをリファクタリングすることに依存する進化型設計プロセスを構築します。すべての設計は、将来のニーズを予想した設計を行うことなく、現在の反復を中心に展開されます。その結果、規律がありながらも驚くべき設計プロセスが実現し、規律と適応性を arguably がすべての適応型方法論の中で最もよく開発された方法で組み合わせています。

XPは幅広いリーダーシップを発揮しており、その多くは重要なC3プロジェクトから生まれています。そのため、より多くの情報源があります。現時点での最良の概要は、外部のジム・ハイスミスによって書かれており、彼自身 methodology については後述します。ケント・ベックは、XPの主要なマニフェストである* Extreme Programming Explained* を執筆し、方法論の背後にある理論的根拠と、人々がさらに追求することに興味があるかどうかを判断できるだけの説明を提供しています。

さらに2冊の本が執筆中です。C3プロジェクトの3人のメンバー、ロン・ジェフリーズ、アン・アンダーソン、チェット・ヘンドリクソンは、C3の経験に基づいたXPの説明である* Extreme Programming Installed* を執筆しています。ケント・ベックと私は、この適応型方法でどのように計画を行うかについて説明した* Planning Extreme Programming* を執筆しています。

書籍だけでなく、かなりの数のウェブ・リソースもあります。XPのアイデアの初期の提唱と開発の多くは、Ward Cunninghamのwikiウェブ共同執筆環境で行われました。このwikiは、そのとりとめのない性質があなたを吸い込んでしまうことになりますが、発見するには魅力的な場所です。XPへのより体系的なアプローチを見つけるには、C3の卒業生であるRon JeffriesのxProgramming.comとDon WellsのextremeProgramming.orgの2つのサイトから始めるのが最善です。Bill WakeのxPlorationsには、多くの有用な論文が掲載されています。C++とOO設計で有名な著者であるRobert MartinもXPのプロモーターのリストに加わりました。彼の会社であるObjectMentorは、ウェブサイトに多くの論文を掲載しています。また、XPディスカッションegroupも後援しています。

Cockburnのクリスタルファミリー

Alistair Cockburnは、90年代初頭にIBMから方法論について書くことを依頼されて以来、方法論に取り組んできました。しかし、彼のアプローチはほとんどの方法論者とは異なります。彼は、物事を行うべき方法の理論を構築するために個人的な経験のみに頼るのではなく、プロジェクトにインタビューしてどのように機能するかを確認するために積極的に努力することで、彼の直接的な経験を補完しています。さらに、彼は自分の発見に基づいて自分の見解を変えることを恐れていません。これらすべてが、彼を私のお気に入りの方法論者にしています。

彼の著書、オブジェクト指向プロジェクトを生き延びるは、プロジェクトの実行に関する彼の最初のアドバイスであり、反復型プロジェクトの実行に関する私の一番のお勧めの本です。

その著書以来、彼は軽量級方法論をさらに探求し、Crystal方法論ファミリーを考案しました。それはファミリーと呼ばれるのは、彼が異なる種類のプロジェクトには異なる種類Methodologyが必要だと考えているからです。彼は、プロジェクトの人数とエラーの結果という2つの軸に沿って、このバリエーションを調べています。それぞれの方法論はグリッドの異なる部分に適合するため、裁量資金を失う可能性のある40人のプロジェクトと、6人の人命に関わるプロジェクトでは、異なる方法論が用いられます。

CrystalはXPと同様に人間中心ですが、この人間中心主義は異なる方法で行われます。Alistairは、人々が規律あるプロセスに従うのは難しいと考えているため、XPの高い規律に従うのではなく、Alistairは成功する可能性のある最も規律の低い方法論を探求し、生産性を意識的に犠牲にして実行の容易さを実現しています。したがって、彼は、CrystalはXPよりも生産性は低いものの、より多くの人がCrystalに従うことができると考えています。

Alistairはまた、反復の終わりに行われるレビューに大きな重点を置いており、プロセスの自己改善を促進しています。彼の主張は、反復型開発は問題を早期に発見し、人々がそれを修正できるようにするためにあるということです。これは、人々が自分のプロセスを監視し、開発中に調整することに重点を置いています。

オープンソース

この見出しに驚くかもしれません。結局のところ、オープンソースはソフトウェアのスタイルであり、プロセスではありません。しかし、オープンソースコミュニティには、明確なやり方があり、そのアプローチの多くは、クローズドソースプロジェクトにもオープンソースプロジェクトにも同様に適用できます。特に、彼らのプロセスは物理的に分散したチームを対象としており、これは、ほとんどの適応型プロセスが共同配置されたチームを重視しているため重要です。

ほとんどのオープンソースプロジェクトには、1人以上のメンテナーがいます。メンテナーは、ソースコードリポジトリに変更をコミットすることを許可されている唯一の人物です。ただし、メンテナー以外の人がコードベースに変更を加えることは可能です。重要な違いは、他の人は変更をメンテナーに送信する必要があることです。メンテナーは変更をレビューし、コードベースに適用します。通常、これらの変更はパッチファイルの形式で行われ、このプロセスが容易になります。したがって、メンテナーはパッチの調整とソフトウェアの設計の一貫性の維持を担当します。

プロジェクトによって、メンテナーロールの処理方法は異なります。プロジェクト全体で1人のメンテナーを持つもの、モジュールに分割してモジュールごとにメンテナーを持つもの、メンテナーをローテーションするもの、同じコードに複数のメンテナーを持つもの、これらのアイデアを組み合わせたものなどがあります。ほとんどのオープンソース関係者はパートタイムであるため、このようなチームがフルタイムのプロジェクトでどの程度うまく連携できるかという問題があります。

オープンソース開発の特別な特徴は、デバッグが高度に並列化できることです。そのため、多くの人がデバッグに関与できます。バグを見つけたら、パッチをメンテナーに送信できます。これは、ほとんどの時間がバグの発見に費やされるため、メンテナー以外の人にとって適した役割です。また、優れた設計スキルを持たない人にも適しています。

オープンソースのプロセスはまだ十分に文書化されていません。最も有名な論文は、Eric Raymondの伽藍とバザールです。これは優れた説明ですが、かなり簡潔でもあります。Klaus FogelのCVSコードリポジトリに関する書籍にも、オープンソースプロセスに関する優れた章がいくつか含まれており、cvs updateをしたくない人にとっても興味深いでしょう。

Highsmithの適応型ソフトウェア開発

Jim Highsmithは、予測型方法論に長年取り組んできました。彼はそれらを開発し、導入し、教え、そしてそれらが根本的に欠陥があると結論付けました。特に現代のビジネスにとっては。

彼の最近の著書は、新しい方法論の適応性、特に複雑適応系（一般にカオス理論と呼ばれる）の世界で生まれたアイデアの適用に焦点を当てています。XPのように詳細なプラクティスを提供するわけではありませんが、適応型開発がなぜ重要なのか、そして組織と管理のより深いレベルでの結果について、基本的な土台を提供しています。

スクラム

SCRUMはオブジェクト指向の世界ではしばらく前から存在していましたが、正直に言って、私はその歴史や発展にあまり詳しくありません。繰り返しますが、定義された反復可能なプロセスは、定義された反復可能な人と定義された反復可能な環境で、定義された反復可能な問題に取り組む場合にのみ機能するという事実に焦点を当てています。

SCRUMは、プロジェクトを30日間の反復（スプリントと呼ぶ）に分割します。スプリントを開始する前に、そのスプリントに必要な機能を定義し、チームにそれを提供させます。重要なのは、スプリント中に要件を安定させることです。

しかし、経営陣はスプリント中に責任を放棄するわけではありません。チームは毎日、スクラムと呼ばれる短い（15分）会議を開催し、チームは次の日に何をするかを検討します。特に、彼らは経営陣が解決する必要がある進捗を妨げている障害を明らかにします。また、何が完了したかを報告するため、経営陣はプロジェクトの進捗状況を毎日把握できます。

SCRUMの文献は、主に反復的な計画と追跡プロセスに焦点を当てています。多くの点で他の軽量級方法論に非常に近く、XPのコーディングプラクティスとうまく連携するはずです。

現時点ではSCRUMに関する書籍はありませんが、多くのウェブリソースがあります。Ken Schwaberは、SCRUMの最も優れた概要であるcontrolChaos.comをホストしています。Jeff Sutherlandは、オブジェクトテクノロジーの問題に関するアクティブなウェブサイトを常に運営しており、SCRUMに関するセクションが含まれています。PLoPD 4の本には、SCRUMプラクティスの優れた概要もあります。

Coadのフィーチャ駆動開発

フィーチャ駆動開発（FDD）は、長年のOOの第一人者であるPeter Coadによって開発されました。他の適応型方法論と同様に、具体的な機能を提供する短い反復に焦点を当てています。FDDの場合、反復は2週間です。

FDDには5つのプロセスがあります。最初の3つはプロジェクトの開始時に行われます。

• 全体モデルの開発
• フィーチャリストの作成
• フィーチャごとの計画

最後の2つは、各反復内で行われます。

• フィーチャごとの設計
• フィーチャごとの構築

各プロセスはタスクに分割され、検証基準が与えられます

開発者は、クラスオーナーとチーフプログラマーの2種類に分けられます。チーフプログラマーは、最も経験豊富な開発者です。彼らには、構築するフィーチャが割り当てられます。ただし、彼らはそれを単独で構築するわけではありません。代わりに、チーフプログラマーは、フィーチャの実装に関与するクラスを特定し、そのクラスオーナーを集めて、そのフィーチャを開発するためのフィーチャチームを結成します。チーフプログラマーは、コーディネーター、リードデザイナー、メンターとして行動し、クラスオーナーはフィーチャのコーディングの多くを行います。

FDDの主な説明は、Peter CoadらのUML in Colorの本にあります。彼の会社であるTogetherSoftも、FDDに関するコンサルティングとトレーニングを行っています。

その他の情報源

軽量級方法論のこのテーマについては、他にも多くの論文や議論があります。これらは完全な方法論ではないかもしれませんが、この成長分野への洞察を提供しています。

プログラミングのpatterns言語カンファレンスでは、パターンに興味を持っている人の多くは、より適応的で人間的な方法にも興味を持っているため、この主題に触れた資料がよく含まれています。初期の主要な論文は、PLoP1でのJim Copleinの論文でした。Ward CunninghamのEpisodesパターン言語は、PLoP2に登場しました。Jim Copleinは現在、組織パターンのパターンを収集するwikiであるOrgPatternsサイトをホストしています。

Dirk RiehleはXP2000に、XPと適応型ソフトウェア開発の価値体系を比較する論文を送りました。Coadレターの7月号では、XPとFDDを比較しています。IEEE Softwareの7月号には、「プロセスの多様性」に関するいくつかの記事が含まれており、これらの方法論に触れています。

どの適応型プロセスを選ぶべきか？

これらのプロセスはすべて新しく、私はいくつかの直接的な経験からしかガイダンスを提供できません。私の選択では、問題はチームの規模と、彼らがどれだけの規律を守ることができるかにあります。

試してみることに前向きな12人以下の開発者であれば、私は間違いなくXPを推奨します。少なくとも最初は、チームがXPプロセスに全力を注がないかもしれませんが、部分的なXPアプローチでも多くのメリットが得られます。私にとって、このプロセスをうまく使用するための重要なテストは、自動化された単体テストです。チームがそれを行う準備ができているなら、技術的な基盤は整います。彼らがそれができない場合、私は彼らが残りを処理できるとは思いません。

規律がなかったり、チームが大きすぎる場合は、Crystalのアドバイスに従う傾向があります。それは確かに最も軽量な手法であり、Cockburnは特に開発の教訓に適応しています。これらの場合でも、XP計画プロセスを使用します。

しかしながら、私は多くのXPプラクティスを成功裏に試み、完全なXPに非常に近い40人のチームと協力しています。そのため、決意と献身的なチームがあれば、少なくともこれらの境界の一部を超えてプロセスを適応させることができます。

そして、それが本当に重要なメッセージです。どのプロセスから始めても、それが本当にうまくいくプロセスになるとは限りません。あなたは自分のプロセスを管理し、監視し、状況に合わせて適応させる必要があります。最終的には、それはあなた自身のプロセスになる必要があり、他のラベルは二次的なものです。