CodeZine(コードジン)

特集ページ一覧

7つのアジャイル開発手法の実践ガイド(第2回)

AUP、クリスタル、DSDMの紹介と各アジャイル手法の比較

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2007/02/21 00:00

アジャイル開発手法を採用すべきだということはわかっていても、いろいろある開発手法をすべて検討しようとすれば、調査だけでかなりの時間がかかってしまいます。組織にとってどの方法論が適しているかを知るにはどうしたらよいでしょうか。この2回シリーズでは、7つの人気の高い開発手法の表と裏をすべて紹介し、組織に最適な開発手法を選ぶためのヒントを示します。第2回では、AUP、クリスタル、DSDMについて説明します。

目次

はじめに

 本稿は、さまざまなアジャイル開発手法を紹介する2回シリーズの記事の第2回です。本シリーズでは、7つの人気の高い開発手法の表と裏をすべて学習し、組織に最適な開発手法の組み合わせを選べるようになることを目的としています。第1回では、アジャイルの概要を説明し、エクストリームプログラミング(Extreme Programming:XP)、スクラム、リーン、機能駆動型開発(Feature Driven Development:FDD)について説明しました。第2回では、アジャイルユニファイドプロセス(Agile Unified Process:AUP)、クリスタル、動的システム開発手法(Dynamic Systems Development Method:DSDM)について説明し、それから7つの手法を比較検討します(第1回を読んでいない方は、以下の記事を先にお読みください)。

過去の記事

アジャイルユニファイドプロセス

 ユニファイドプロセス(UP)は、漸増反復的なソフトウェア開発プロセスフレームワークです。UPはしばしば「儀式度が高い」と見なされますが、それはソフトウェアプロジェクトに関係する多数のアクティビティと成果物を指定するからです。UPを発展させたプロセスフレームワークはいくつかありますが、最も人気が高いのはIBMによるラショナルユニファイドプロセス(Rational Unified Process:RUP)です。アジャイルユニファイドプロセス(AUP)はUPのアジャイル版であり、Scott Amblerによって整理され、Craig Larmanらによって文書化されました。AmblerはAUPを「大きな単位では連続的、小さな単位では反復的な性質を持ち、時間の経過と共に漸増的なリリースを引き渡す」と要約しています。

 AUPプロジェクトでは、リスク管理が重要な役割を果たします。AUPでは、危険性の高い要素を開発の早い段階で処理することを重視します。そのための手段として、通常はリスクリストを早期に作成し、開発プロセス全体を通して保守します。AUPでは、実行可能なアーキテクチャのベースラインを早期に開発することも重視します。つまり、このアーキテクチャコアを推敲(Elaboration)フェーズで開発することで、重要な要件と仮定の妥当性を検証し、技術的なリスクに対処します。

 Amblerは、AUPを「大きな単位では連続的」と表現した際に、開始(Inception)、推敲(Elaboration)、構築(Construction)、移行(Transition)という、UPプロジェクトの4つの主要なフェーズに言及しています。これらのフェーズは連続的に発生し、各フェーズは指定されたマイルストーンが達成されたときに終了します。

  • 開始 ― 開始フェーズでは、新しいシステムの適用範囲に関して共通の理解を育み、候補となるアーキテクチャを明確にします。
  • 推敲 ― 推敲フェーズでは、システム要件に対するチームの理解を広げ、候補となるアーキテクチャの妥当性を検証します。
  • 構築 ― 構築フェーズでは、システムの開発を行います。
  • 移行 ― 移行フェーズでは、システムテストを行い、システムをプロダクション環境に配備します。

 AUPは、各フェーズが1つ以上のイテレーションに分割されるという点で、「小さな単位では反復的」です。AUPの規律はUPの規律のサブセットであり、モデル、実装、テスト、デプロイメント、コンフィグレーション管理、プロジェクト管理、環境を含んでいます。大部分のイテレーションでは、AUPの7つの規律のすべてが並列的に生じます(図1を参照)それぞれの規律は、プロジェクトをそのビジョンの達成に近づけるアクティビティを表します。

図1 ユニファイドプロセスのフェーズと規律(イメージはIBM提供)
図1 ユニファイドプロセスのフェーズと規律(イメージはIBM提供)
※編集部注
 本文では「規律は7つ」と述べているが、上図では10個の規律があるように見える。これは図がIBM提供のものであり、本文の内容を明確に図示したものではないためである。上図では「モデル」にあたる規律をさらに細分化しており、「Business Modeling」(ビジネスモデル)、「Requirements」(要件)、「Analysis&Design」(分析・設計)の3つを項目に挙げている。

  • LINEで送る
  • このエントリーをはてなブックマークに追加

あなたにオススメ

著者プロフィール

  • japan.internet.com(ジャパンインターネットコム)

    japan.internet.com は、1999年9月にオープンした、日本初のネットビジネス専門ニュースサイト。月間2億以上のページビューを誇る米国 Jupitermedia Corporation (Nasdaq: JUPM) のニュースサイト internet.com や EarthWeb.c...

  • Rod Coffin(Rod Coffin)

    最新の開発プロセスおよびテクノロジの大規模導入のコンサルテーションを行うValtech Skill Developmentの上級顧問。主にエンタープライズJava開発およびアジャイル手法を行うチームを指導している。アスペクト指向プログラミングからEJB 3.0に至るまで各種の話題について数本の記事を...

  • Derek Lane(Derek Lane)

    Countrywide Financial Corp. のエンタープライズアーキテクト。メンター、コーチ、アーキテクト、マネージャ、開発者、トレーナー、開発方法論者、オープンソース信者など、さまざまな肩書を持つ。著者、プレゼンター、技術校閲者としてさまざまなプロジェクトに携わり、まもなく共著『EJB...

バックナンバー

連載:japan.internet.com翻訳記事

もっと読む

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5