トピック

ホワイト ペーパー:


概論ページの先頭へ

RUP (Rational Unified Process) は、小規模から大規模までの—すべてのタイプのソフトウェア プロジェクトに幅広く使用されてきた Rational™ Software が長年にわたって洗練を重ねたプロセス フレームワークです。最近では、—XP (eXtreme Programming)、SCRUM、FDD (Feature-Driven Development)、Crystal Clear Methodology など—増加している「アジャイルな」プロセスが、小規模システムを構築するための効果的な方法として重要視されつつあります。(アジャイルな連携について詳しくは、「www.agilealliance.org」を参照してください。)

以下の各セクションは、プロジェクト チームが、これらの方法のいずれかで発見される一部の「アジャイルな」実践原則を評価して、RUP で定義されたより完全なソフトウェア開発プロセスによってそれらがどのように処理されるかを確かめるのを支援することを目的とします。

概要ページの先頭へ

アジャイルなコミュニティは、小規模な同一の場所に配置されたプロジェクト チームに特に適用できる多数の「最善の実践原則」を総合的に扱っています。RUP はどんな規模のプロジェクト チームも対象にしていますが、小規模なプロジェクトのほうがうまく適用できます。一般に、RUP とアジャイルなコミュニティのプロセスは、高品質のソフトウェアを開発するために必要な主要な最善の実践原則の視点が類似しています。—たとえば、反復的開発を適用し、エンド ユーザーを重視することなど。

以下の各セクションでは、アジャイルなコミュニティで特定された「最善の実践原則」を、RUP に基づくプロジェクトに適用する方法を説明します。この場合、正確には焦点は XP (eXtreme Programming) 方法論によって提示されるその実践原則にあります。(XP について詳しくは、Web サイト: http://www.extremeprogramming.orgを参照してください。)

XP の実践原則ページの先頭へ

XP には 4 つの基本的な「作業」(コーディング、テスト、リスニング、設計) が含まれます。これらの作業は実際には RUP の作業分野とより緊密に連携します。これらの XP の作業は、追加の作業の性能が必要である実践原則セットを使用して実行されて、RUP の一部の他の作業分野にマッピングします。『Extreme Progamming Explained』によれば XP の実践原則は、以下のものになります。

  • 計画ゲーム: ビジネス優先度と技術的見積もりを組み合わせて、次のリリースの範囲を迅速に決定します。現実が計画を上回ると、計画を更新します。
  • 短期リリース: シンプルなシステムを素早く稼動させて、新しいバージョンを非常に短いサイクルでリリースします。
  • メタファ: システム全体の機能の仕方についての単純な共有ストーリーによりすべての開発を誘導します。
  • シンプルな設計: システムは、いつなんどきでもできるだけ簡単に設計される必要があります。余分な複雑さは、発見されたら直ちに除去されます。
  • テスト: プログラマは頻繁に単体テストを記述して、完璧に開発が継続できるように実行する必要があります。顧客は、機能が完成したことを実証するテストを記述します。
  • リファクタリング: プログラマは、複製を削除したり、コミュニケーションを向上させたり、簡略化したり、柔軟性を追加するために振る舞いを変更せずにシステムを再構成します。
  • ペア プログラミング: すべての生産コードは、1 台のコンピュータで 2 人のプログラマによって記述されます。
  • 共同所有権: 誰でも、いつでもシステム内のどこにあるどんなコードでも変更できます。
  • 継続的な統合: タスクが完成するたびに、1 日に何度もシステムを統合、構築します。
  • 週 40 時間労働: 原則として、1 週間の労働時間が 40 時間を超えないようにします。2 週間続けて時間外労働をしないようにします。
  • オンサイト顧客: 質問に対して常時答えられる、チームの実際の生のユーザーを含みます。
  • コーディング標準: プログラマは、コードを通じてコミュニケーションを強調するルールに従ってすべてのコードを記述します。

たとえば、「計画ゲーム」の実践原則の結果として実行される作業は、主として RUP のプロジェクト管理の作業分野にマッピングします。ただし、ビジネス モデリング、リリースされたソフトウェアの導入など一部の RUP のトピックは、XP の範囲外になります。顧客が要求を定義し提供するので、要求の導出は主として XP の範囲外になります。対処するのがより簡単な開発プロジェクトのため、RUP が構成と変更管理の作業分野、環境の作業分野で詳細にカバーする問題を XP は非常に容易に処理することができます。

RUP と互換性のある XP の実践原則ページの先頭へ

XP と RUP で重複する作業分野では、XP で説明した以下の実践原則が、RUP で採用されます—すでに採用されている場合もあります—。

  • 計画ゲーム: 非常に小規模なプロジェクトのために RUP のプロジェクト管理の作業分野で示された多数の目的を達成するために、XP の計画ガイダンスを使用することができます。これは、公式の中間のプロジェクト管理成果物を生成する必要のない格式度の低いプロジェクトに特に役立ちます。
  • テスト先行設計とリファクタリング: RUP の導入の作業分野で適用することができる優れた技術です。テスト先行設計が要求される XP のテストの実践原則は、特に詳細なレベルで要求を明確にする優れた方法です。次のセクションで説明するように、リファクタリングは大規模システムに十分に対応することはできません。
  • 継続的な統合: RUP では、(反復の中で) サブシステムとシステム レベルのビルドを通じてこの実践原則をサポートしています。単体テストしたコンポーネントは、出現するシステム コンテキストで統合され、テストされます。
  • オンサイト顧客: RUP の多数の作業は、オンサイトの顧客をチーム メンバーとすることから多大な恩恵を受け、それによって、特に文書など、必要である中間の納品可能物の数を減少させることができます。— 顧客と開発者間のコミュニケーションの最適な媒体として、XP では会話を重んじますが、成功するために継続性と親密性に依存します。ただし、システムを—小規模なものであっても—移行する場合は、会話以外のものが必要になります。XP では、プロジェクトの終わりの設計文書のようなもので、ある種の結果論としてこれを考慮します。XP では、文書または他の成果物の生成を禁止してはいませんが、本当に必要なものだけを生成すべきであると言及しています。RUP も賛同していますが、継続性と親密性が最適となりえない場合に必要になる可能性のあるものについて説明します。
  • コーディング標準: RUP には、ほとんどの場合に必須とみなされる成果物—プログラミング ガイドライン—があります。(カスタマイズの主要ドライバであるほとんどのプロジェクト リスク プロフィールで、そうなります。)
  • 週 40 時間労働: XP の場合と同様に、RUP では超過勤務が慢性的になってはならないとしています。XP では 40 時間という制限は示唆しておらず、労働時間に関する異なる許容範囲を認めています。ソフトウェア エンジニアは、特別な報酬なしで—完成したものを見て満足するぐらい—長時間働くことで有名ですが、管理者は必ずしもそれを止めさせなければならいというわけではありません。管理者が決してするべきないことは、この実践原則を利用したり、強要することです。管理者は、報酬を付けないとしても、実際の労働時間に関するメトリクスを常に収集する必要があります。誰かの労働時間に関する記録が、長期間にわたって並外れている場合は、これを調査する必要があります。ただし、これらの問題は、それが発生した環境で、チームの他のメンバーの状況もよく認識したうえで、管理者と個人の間で解決すべきことです。40 時間というのは指針にすぎませんが、—強力な指針です。
  • ペア プログラミング: ペア プログラミングはコードの品質に有益であるので、このスキルを獲得すれば、一層享受できるようになると XP では主張しています。RUP ではそのようなきめ細かなレベルでのコード生成の仕組みについては説明していませんが、RUP に基づくプロセスでペア プログラミングを使用することは確かにできます。ペア プログラミングに関する一部の情報—テスト先行設計とリファクタリングも—が、現在ホワイト ペーパーの形式で RUP と共に提供されています。明らかに、RUP でこれらの実践原則のいずれかを使用するというのは必要条件ではありませんが、オープン コミュニケーションというカルチャーを持つチーム環境では、(ライフサイクルの合計コストへの影響という観点で) ペア プログラミングの利点は見分けづらいと推測します。うまく機能しているチームであれば、強要しなくても自然に人々が協力して問題について話し合い解決すると予想されます。

優れたプロセスは「ミクロ」レベルで実施される必要があるという意見は、受け入れがたい場合もあり、一部の企業文化に合わないこともあります。したがって、RUP では厳格な施行を提唱してはいません。ただし、状況によっては、ペアでの作業—と XP が提唱するチームに基づく他の実践原則の一部—は、以下のような場合に、各チーム メンバーが他方を助けることができるので、明らかに好都合です。

  • 人々が知り合いになりつつあるような、チームが形成されて間もない頃
  • 一部の新しい技術についての知識がないチームの場合
  • 経験を積んだスタッフと初心者が混在するチームの場合

大規模への対応が不十分な XP の実践原則ページの先頭へ

以下の XP の実践原則は、大規模なシステムには十分に対応していません (XP でもその点については明言していません)。したがって、RUP ではこの但し書きを条件として XP の実践原則を利用します。

  • メタファ: 大規模で複雑なシステムの場合、メタファとしてのアーキテクチャは単に不十分です。RUP は、—『Extreme Programming Explained』で説明されているように—単に「大きなボックスと接続」にとどまらないアーキテクチャのための豊富な説明フレームワークを提供します。XP コミュニティでも、メタファは最近になって異を唱えられています。XP ではメタファはもはや実践原則の 1 つではなくなっています (うまく説明する方法が見つかるまでは—メタファの助けを借りる可能性があります)。
  • 共同所有権: 小規模なシステムまたはサブシステムを担当するチームのメンバーが、そのシステムのすべてのコードに精通している場合に役立ちます。ただし、すべてのチーム メンバーに平等に、どこにでも変更を行える権限を与える必要があるかどうかは、コードの複雑さによって異なります。通常は、関連するコード セグメントで現在作業している個人 (またはペア) によって修正が行われるようにすると、より迅速 (かつより安全) になります。最適なコード作成に精通していても、特にアルゴリズム的に複雑な場合は、時間の経過に伴い急速にその意義が薄れてしまいます。
  • リファクタリング: 大規模なシステムでは、リファクタリングの頻度を多くしても、アーキテクチャの不足を補うことはできません。『Extreme Programming Explained』では次のように述べています。「XP の設計戦略は、山登りのアルゴリズムに似ています。シンプルな設計を取得したら、それを少し複雑にし、少し簡素化し、また少し複雑にするといったことを繰り返します。山登りのアルゴリズムに関する問題は、局地的最適点に達しているので、小規模な変更では状況を改善することはできませんが、大規模な変更なら可能であることです。」 RUP では、アーキテクチャが「大きな山」へのビューとアクセスを提供して、大規模で複雑なシステムを扱いやすくします。
  • 短期リリース: 顧客が新しいリリースを受け入れ、導入できる速度は、通常ビジネスへの影響と関連づけられているシステムのサイズを含め、多数の要因によって左右されます。2 ヵ月サイクルでは、一部のタイプのシステムには短すぎることもあります。導入の物流によって、それが禁じられる場合もあります。

注意を要する XP の実践原則ページの先頭へ

最終的に、一見したところでは RUP で使用できそうに思える XP の実践原則—シンプルな設計—でも、一般的に適用される場合は多少の推敲と注意が必要です。

  • シンプルな設計
    XP は非常に機能駆動型です。つまり、ユーザー ストーリーを選択し、タスクに分解して、実装します。『Extreme Programming Explained』によれば、常にソフトウェアに適した設計とは、すべてのテストを実行し、重複するロジックがなく、プログラムにとって重要な意図をすべて述べ、できるだけ最小限のクラスとメソッドを使用するものです。XP では、顧客にビジネス価値を提供するために必要ではないものを追加することの価値を認めません。

    ここに、RUP で「機能外」要求と呼ぶものを処理するうえで、局地的最適化の問題と同様の問題があります。これらの要求は、顧客にビジネス価値を提供しますが、それらはストーリーとして表現するのがより困難です。XP で制約と呼ぶものの一部が、このカテゴリに入ります。RUP では、どんな種類の理論的方法でも必要である以上の設計を支持しませんが、モデルが機能外要求を満たすために重要なものの 1 つであるという考え方からアーキテクチャ モデルを使用して設計するのを支持します。

    したがって、RUP は、「シンプルな設計」にすべてのテストの実行を含める必要があるという点では XP と合致しますが、ソフトウェアが機能外要求を満たすことを実証するテストを含めるという追加条項があります。一方、これは、システム サイズと複雑さが増すにつれ、またはアーキテクチャが前例のないものであるか、機能外要求が厄介な場合に、重要な問題として浮上するだけです。たとえば、(異種分散環境で操作するために) データを整列させる必要性は、コードを過度に複雑にするように思われますが、それはまだプログラム全体にわたって必要です。

小規模プロジェクトの成果物のマッピングページの先頭へ

小規模プロジェクトのために RUP をカスタマイズし、それに応じて成果物要求を減らす場合、XP プロジェクトの成果物に相当するものとの対比はどのようになるでしょうか。RUP の「../../../examples/devcase_sp/dc_index.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません小規模プロジェクトの開発個別定義書の例」を見ると、サンプルの RUP 構成が (表 1 に示されているように) より少ない成果物を生成するように構成されていることがわかります。

XP の成果物
ストーリー
会話からの追加の文書
開発構想
用語集
ユース ケース モデル
制約 補足仕様書
受け入れテストと単体テスト
テスト データとテスト結果

../../../process/artifact/ar_tstpl.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテスト計画
../../../process/artifact/ar_tstcs.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテスト ケース../../../process/artifact/ar_tstste.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません
テスト セット
(../../../process/artifact/ar_tstsc.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテスト スクリプト../../../process/artifact/ar_tstdta.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテスト データを含む)
../../../process/artifact/ar_tstlog.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテスト ログ
テスト評価のまとめ

ソフトウェア (コード) 実装モデル
リリース ../../../process/artifact/ar_prdct.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません製品 (導入ユニット)
../../../process/artifact/ar_rlsnt.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんリリース ノート
メタファ ソフトウェア アーキテクチャ説明書
設計 (CRC、UML スケッチ)
技術的タスクとそのほかのタスク
最後に生成される設計文書
サポート文書
設計モデル
コーディング標準 ../../../process/artifact/ar_projspecgls.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんプロジェクト固有ガイドライン
ワークスペース
テストのフレームワークとツール
../../../process/artifact/ar_devcs.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません開発個別定義書
../../../process/artifact/ar_tstenv.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテスト環境構成
リリース計画書
反復計画書
ストーリー見積もりとタスク見積もり
ソフトウェア開発計画書
反復計画書
全体的な計画と予算 開発企画書
リスク リスト
進捗に関するレポート
タスク作業に関する時間記録
メトリクス データ (リソース、範囲、品質、時間を含む)
結果の追跡
会合に関するレポートと注記
ステータス評価
反復評価
レビュー記録
障害 (と関連データ) 変更依頼
コード管理ツール プロジェクト リポジトリ
../../../process/artifact/ar_wkspc.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんワークスペース
スパイク (ソリューション)

プロトタイプ
ユーザー インターフェイスのプロトタイプ
アーキテクチャ上の概念の検証

XP 自体 (推奨かつガイダンス)

../../../process/artifact/ar_tstidslst.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテスト構想リスト
../../../process/artifact/ar_projspecgls.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんプロジェクト固有ガイドライン

[XP には含まれていない]

データ モデル
../../../process/artifact/ar_eusm.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんエンドユーザー サポート文書

表 1: 小規模プロジェクトの成果物の XP から RUP へのマッピング

成果物の粒度は両サイドで異なりますが、一般に小規模プロジェクトの RUP の成果物 (XP が十分に対応できるタイプ) は、XP プロジェクトの成果物に問題なくマッピングします。

../../../examples/devcase_sp/dc_index.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません小規模プロジェクトの開発個別定義書の例には、XP でカバーされていないが、多数のプロジェクトで必要である成果物も含まれていることに注意してください。その中には、データ モデルと、../../../process/artifact/ar_eusm.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんエンドユーザー サポート文書などの導入に関連する成果物も含まれます。

作業ページの先頭へ

RUP では役割によって実行される作業として作業を定義します—入力成果物を使用し変換するにせよ、新規 / 変更した出力成果物を生成するにせよ。次にこれらの作業を列挙し、それらを RUP の作業分野に応じて分類します。それらの作業分野には、(特に) ビジネス モデリング、要求、分析と設計、導入、プロジェクト管理などがあります。

作業は、それらが生成し、消費する成果物を通じて時間に関連しています。成果物は論理的に、その入力が利用可能で (かつ適切な成熟状態に) あるときに始めることができます。つまり、成果物状態が許可するなら、生産者-消費者の作業ペアが時を違えず重複することができます。それらは厳格に順序付けられる必要はありません。作業は、成果物の生成方法についての強力なガイダンスを提供するよう意図されており、プロジェクト管理者の計画を支援するために使用されることもあります。

ライフサイクル、成果物、作業の観点から説明されているように RUP を通じて組み入れられるのが「最善の実践原則」です。つまり、予測できるスケジュールと予算に合わせて構築される高品質のソフトウェアを生み出すことが立証されたソフトウェア エンジニアリング原則。RUP はその作業 (と関連している成果物) を通じて、これらの最善の実践原則をサポートし実現します-それらは RUP を貫くテーマです。XP では「実践原則」の概念も使用しますが、RUP の最善の実践原則の概念と正確に一致しているわけではないことに注意してください。

XP では、4 つの基本的な作業—コーディング、テスト、リスニング、設計—を行うときにソフトウェア開発の魅力的なシンプルなビューを提供します。(「第 9 章 Extreme Programming Explained」で説明されているように) 一部のサポートしている実践原則に従って 4 つの作業を有効にし、構成することができます。実際には、前に示したように、XP の作業は RUP の作業よりも RUP の作業分野の範囲に密接しており、(4 つの基本的な作業のほかに) XP プロジェクトで発生するものの多くは、その実践原則の推敲と適用によってもたらされるものです。

したがって、XP には RUP の作業と同等のものがありますが、XP の「作業」はそういうものとして正式に特定または説明されません。たとえば、『Extreme Programming Installed』の「第 4 章 User Storie」を見ると、「Define requirements with stories, written on cards」という見出しがあり、第 4 章全体にわたって、ユーザー ストーリーが何であり、どのように (誰が) それらを生成するかについてのガイダンスとプロセスの記述があります。そのほかにも、(成果物と作業関連のものが混在する見出しの下の) XP booksのさまざまなセクションに、「生成されるもの」と「行うこと」の両方が、さまざまな度合いの規範と詳細にわたって説明されています。

RUP の明らかに高度な規範は、作業とその入力 / 出力の処理における完成度と格式度の高さに起因します。XP は規範が欠如してはいませんが、軽量のまま残そうとする試みでは、格式度と詳細が単に省略される可能性があります。特異性の欠如は利点でも弱点でもありませんが、XP における詳細情報の欠如を簡素さと混同しないようにしてください。詳細がないことは、経験を積んだ開発者にとって良い場合もありますが、多くの場合、詳細が多いことは、新しいチーム メンバーと、チームのソフトウェア開発のアプローチに追いつこうとしているチーム メンバーにとって非常に役に立ちます。

成果物と同様に作業に関しても、達成しようとしていることに焦点をあわせ続けることは重要です。やみくもに作業を実行することは、良いやり方ではありません。作業と関連ガイドラインは、目的を達成するためにそれらが必要な場合に見るように存在しますが、何を達成しようとしているのかをはっきりさせる必要がないことの口実として使用すべきではありません。この精神は XP で十分に明確に示されており、RUP のすべてのユーザーがそれを適用する必要があると確信しています。

役割ページの先頭へ

RUP では、作業役割 (またはもっと正確には役割を果たす個人かグループ) によって実行されると言われています。役割には、特定の成果物に対する責務があります。責任ある役割が、通常、成果物を作成し、(多少なりと認められている場合) 他の役割によって行われた変更が成果物を破壊しないようにします。一個人またはグループが、1 つだけの役割を実行することも、複数の役割を実行することもできます。役割を、組織内の 1 つだけの役職または「地位」にマッピングする必要はありません。

Extreme Programming Explained』では、XP に適用できる役割—プログラマ、顧客、テスト担当者、トラッカ、コーチ、コンサルタント、ビッグ ボス—を特定し、それらを実行する人に必須の責務と能力について説明しています。そのほかの一部のXP booksでも、これらの役割について言及しています。XP と RUP の役割の数の違いは、以下のように簡単に説明できます。

  • XP は RUP のすべての作業分野をカバーしてはいません。
  • XP の役割は、RUP の役割よりも (場合によっては多数の責務がある) 組織内の役職に相当します。たとえば、XP のプログラマは実際には、わずかに異なる能力が必要である多数の RUP の役割—実装担当者、コード レビュー担当者、統合担当者—を実行します。

小規模プロジェクトにおける XP と RUP の役割ページの先頭へ

RUP の役割を小規模プロジェクトにマッピングするとき、それらが相当する XP のような役割の数は、役職または肩書きの数が 5 というように、かなり減少されます。(RUP をもとに作成された) 表 3 に、このマッピングと、対応する XP の役割を示します。

XP の役割 RUP の小規模プロジェクトのチーム メンバーの例 RUP の役割
コーチ
コンサルタント
ビッグ ボス
サリー スラローム、上級管理者 プロジェクト管理者
../../../process/workers/wk_depm.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません導入管理者
技術的レビュー担当者
構成管理者
変更管理責任者
顧客 利害関係者 (開発構想に文書化されているとおり)
管理レビュー担当者
技術的レビュー担当者 (要求)
顧客
ビッグ ボス
トラッカ
トム テレマーク、上級ソフトウェア エンジニア システム分析者
ユース ケース定義者
ユーザー インターフェイス設計者
ソフトウェア アーキテクト
技術的レビュー担当者
テスト管理者
../../../process/workers/wk_tstanl.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテスト分析者

ほかにも開発者の役割があります。

プログラマ
テスト担当者

スーザン スノー、ソフトウェア エンジニア

ヘンリー ハーフパイプ、初級ソフトウェア エンジニア

設計者
実装担当者
技術的レビュー担当者
統合担当者
../../../process/workers/wk_tstds.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテスト設計者
../../../process/workers/wk_tstr.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテスト担当者
../../../process/workers/wk_tchwr.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテクニカル ライター
トラッカ パトリック パウダー、管理アシスタント プロジェクト Web サイトの保守、作業の計画とスケジュールの作成におけるプロジェクト管理者の補助、成果物の変更管理における変更管理責任者の補助を担当します。必要に応じて、そのほかの役割の補助も行うことがあります。

表 3: 小規模プロジェクトにおける XP 役割の RUP 役割へのマッピング

RUP と互換性のある XP の実践原則の使用ページの先頭へ

RUP は、特定のプロセスを構成してインスタンス化することができるプロセス フレームワークです。RUP を構成する必要があります—これは RUP 自体で定義される必須手順です。厳密に言うと、そのとき、XP と RUP のカスタマイズされたバージョンを比較する必要があります—つまり、XP が明示的に構築するプロジェクトの特性 (と推論できるもの) に合わせて RUP はカスタマイズされます。そのようなカスタマイズされた RUP プロセスは、多数の XP の実践原則 (ペア プログラミング、テスト先行設計、リファクタリングなど) に適応することができましたが、アーキテクチャ、抽象化 (モデリングでの)、リスク、時間 (フェーズと反復) で異なる構造などの重要性に RUP は重きを置いているので、まだ XP と同一ではありません。

XP は意図的に、小規模プロジェクトの軽量プロセスを実装することに方向づけられます。そうする際に、完全に詳細化されてはいない (少なくとも本の) 説明も含まれます。XP の実装では、進行中に発見、考案、または定義する必要があるものが常にあります。RUP は、規模と種類の点で XP の範囲内と範囲外の双方のプロジェクトに適応します。このロードマップが示すように、RUP は実際には XP の反復で記述されるほとんどの実践原則と互換性があります。

XP の本質は、組織、人、カルチャーを重視していることに留意してください。このことはすべてのプロジェクトで重要であり、RUP を使用しているプロジェクトにも当てはまります。小規模プロジェクトは、これらの実践原則を一緒に使用することで大きな利益を得ることができます。

アジャイルなプロセス参照ページの先頭へ

  • XP (eXtreme Programming) (詳しくは、「http://www.extremeprogramming.org/more.html」を参照してください。)
    • Extreme Programming Explained: Embrace Change』 Kent Beck 氏が、極端なプログラミングの背後の概念と考え方について説明しています。この本では、方法ではなく、何と理由を教えます。
    • Refactoring Improving the Design of Existing Code』 Martin Fowler 氏が執筆したリファクタリングに関する権威ある第一巻です。パターンとして紹介されています。Java の多数の例が掲載されています。この本は、リファクタリングの方法と理由を教えます。
    • Extreme Programming Installed』 Ron Jeffries 氏、Chet Hendrickson 氏、Ann Anderson 氏の共著。この本は、『Expreme Programming Explained』よりも詳細に特定の XP の実践原則について論じています。この本は、XP スタイルのプログラミング方法を教えます。
    • Planning Extreme Programming』 Kent Beck 氏と Martin Fowler 氏の共著。この本では、迅速な納品環境におけるソフトウェアの計画方法に関する最新の見解を紹介します。この本は、XP プロジェクトの実行方法を教えます。
    • Extreme Programming Examined』 Giancarlo Succi 氏と Michele Marchesi 氏の共著。XP2000 で紹介された論文。十分に成熟した一連の論文では、ほとんどのトピックについて論じています。
    • Extreme Programming in Practice』 Robert C. Martin 氏と James W. Newkirk 氏の共著。XP を使用した真のプロジェクトについて、詳しく説明しています。
    • Extreme Programming Explored』 William C. Wake 氏の著書。人気の高い XPlorations の Web サイトに基づいています。特定の主題について詳しく検討しています。
    • Extreme Programming Applied: Playing to Win』 Ken Auer 氏と Roy Miller 氏の共著。XP の適用の先駆者による経験から得た知識。9 月に出版される予定。
  • アジャイルな連携のそのほかのメンバーについて詳しくは、「http://www.agilealliance.org/home」を参照してください。



Rational Unified Process   2003.06.15