ウォーターフォールモデルとの比較 アジャイルソフトウェア開発は、ウォーターフォールモデルによる開発との共通点は少ない。 一部の人々は、ウォーターフォール開発はもはや信頼を失っていると考えるが、2005年前後の時点では、ウォーターフォール開発手法は未だ広く行われている ("The Demise of the Waterfall Model Is Imminent" and Other Urban Myths) 。 ウォーターフォール開発手法は、数あるソフトウェア開発手法の中でも、最も計画重視であると位置づけられる。 要件定義、分析、設計、実装、テストの各工程を、厳格に、予め計画された順序に従って行う。 プロジェクトの進捗は、一般的には、次のような納品可能な成果物をもとに計測される。 要求仕様 設計文書 テスト計画 コードレビュー など ウォーターフォールモデルは、一連の工程の大規模な統合であり、数か月から数年の長い期間単位を採用し、その期間単位の終了に向けてテストが行われる。 この統合とテストの規模が大きくまた困難であることは、ウォーターフォールモデル開発のプロジェクトが失敗する際に、その原因の一つとなっていることが多い。 アジャイルソフトウェア開発手法では、対照的に、1週間から数週間もしくは数か月という短い期間単位ごとに、完全に開発されたテスト済みの機能をリリースする (ここでの機能とはシステム全体のごく小さなサブセットである) 。 アジャイル開発手法では、雑ではあるが利用可能なシステムを早期に構築し、継続的に改良を行ってゆくことを強調する。 一部のアジャイル開発チームでは、小規模なウォーターフォールモデルを採用する。 この場合、反復ごとに完全なウォーターフォールのサイクルを繰り返す。 また一部のアジャイル開発チーム (特にエクストリーム・プログラミングで開発するチーム) では、ウォーターフォールモデルの各工程を、同時並行して行う。 カウボーイコーディングはアジャイル開発とは異なる カウボーイコーディングとして呼ばれる「手法」がある。カウボーイコーディングには、明確な手法が欠如している。カウボーイコーディングで開発を行うチームのメンバーは、自分たちがそれぞれ正しいと感じた作業を行う。アジャイルソフトウェア開発には、計画の頻繁な再評価、直接顔を合わせた意思疎通の重視、比較的少ない文書化などの特徴がある。こうしたアジャイル開発の特徴のため、一部の人々はアジャイル開発とカウボーイコーディングを混同してしまうことがある。しかしこうした混同は正確ではない。アジャイル開発チームは明確なプロセスに従って作業する。そしてこのプロセスは、非常に統制され厳格である場合が少なくない。この点でアジャイル開発とカウボーイコーディングは異なっている。 アジャイルソフトウェア開発手法をいつ使うか アジャイルソフトウェア開発は、10人以下の小規模なチームが1か所で作業を行うプロジェクトの場合に有効であると、説明されることが多い。 またアジャイルソフトウェア開発は、特に、予測困難な要件や頻繁に変更される要件に直面するチームにとって、有効な手法であると指摘される。 以上に述べた状況以外においても、アジャイル開発を採用して成功したチームの体験報告がいくつか存在する。 しかし2005年4月の時点では、企業においてアジャイル開発を採用した報告は少ない。 アジャイルソフトウェア開発の次に列記する状況における適用可能性については、議論の対象となっている。 20人以上の大規模なチームでの開発 (開発規模に対する戦略については Supersize Meを参照) 開発者が地理的に分散した状況での開発 ミッションクリティカルなシステムや人命に関わるシステムの開発 「指示と管理」を社風とする企業 ベームとターナによるリスクベースの指針 バリー・ベームとリチャード・ターナ [1] は、適応的 (アジャイル) な開発手法と計画重視の開発手法のどちらを選択すべきかという問題に対する指針として、リスク分析手法を提案した。 ベームとターナは、適応的開発にも計画重視開発にもそれぞれ得意分野があると、述べている。 アジャイル開発の得意とする状況 クリティカルではないシステム (顧客の業務に重大な支障をきたす可能性がなく、人命に関わらないシステム) 熟練した開発者が参加する場合 開発中に頻繁に要件が変わる場合 開発者が少ない場合 混沌とした状況に意欲をもって取り組む組織的文化 計画重視開発の得意とする状況 クリティカルなシステム (顧客の業務に重大な支障をきたす可能性がある、もしくは人命に関わるシステム) 経験の少ない開発者が多い場合 開発中に要件がほとんど変わらない場合 開発者が多い場合 秩序を重視する組織的文化 ベームとターナの主張では、このようなそれぞれの得意分野の指針に照らして、これから取り組むプロジェクトを分析することで、アジャイル開発か計画重視開発かを選択する検討材料とすることができるとする。 歴史 近年のアジャイルソフトウェア開発の定義は、1990年代半ばに、「重量ソフトウェア開発手法」への反対運動の一部から発展して形成されてきた。 重量開発手法の特徴は、ウォーターフォール開発モデルを適用した場合に多くみられる、厳格な規律と統制、管理不足などである。 ウォーターフォールモデルのこのような適用に端を発する重量開発手法は、官僚的で、もたもたしていて (slow) 、衰退的 (demeaning) で、そのためソフトウェア技術者が効果的に作業を進めるという観点と矛盾していた。 アジャイルで反復的な開発手法の実践例は、ソフトウェア開発の歴史の初期に見出すことができる (Iterative and Incremental Development: A Brief History (PDF)) 。 今日で言うアジャイルソフトウェア開発手法は、以前は「軽量ソフトウェア開発手法」と呼ばれていた。 先述したとおり、2001年に軽量開発手法において名声のある人々がスノーバードに会し、「アジャイルソフトウェア開発手法」と呼称を変えた。 その後、スノーバードに会した人々の一部は、非営利組織 Agile Alliance を設立し、アジャイル開発を推進する活動を行っている。 2000年以前に開発された比較的歴史の長いアジャイル開発手法には次のようなものがある。 スクラム (1986) Crystal Clear エクストリーム・プログラミング (XP) (1996) Adaptive Software Development ユーザ機能駆動開発 (FDD; Feature Driven Development) Dynamic Systems Development Method (DSDM) (1995) エクストリーム・プログラミング (XP) は、最初のアジャイル開発手法ではなかったようだが、数あるアジャイル開発手法の中で抜きん出た評判を確立した。 エクストリーム・プログラミングは、ケント・ベックが1996年に開発し、米クライスラー社で苦境にあった Chrysler Comprehensive Compensation (C3) プロジェクトを立て直す際に、実践した。 そのプロジェクトは最終的には中止となったが、ケント・ベックの開発手法は、Ron Jeffries による長期の指導と、ウォード・カニンガムの Portland Pattern Repository wiki での公開議論と、ケント・ベックのさらなる改訂を経て、1999年に書籍として出版された [2] 。 エクストリーム・プログラミングの構成要素は、別のアジャイル開発手法 Scrum と、ウォード・カニンガムの Episodes pattern language を、基にしているようである。 Dynamic Systems Development Method (DSDM) はヨーロッパで最初に確立されたアジャイル開発手法であると考えられている。 アジャイルソフトウェア開発は、カウボーイコーディング (先述) であるとして、批判されることがある。 エクストリーム・プログラミング (XP) の初期の風評、およびそのペアプログラミングや継続的設計 (進化的設計) のような賛否両論のある実践原則は、特に批判の対象となった (McBreen [9]、Boehm and Turner [1]) 。 一方でこうした批判の多くは、アジャイルソフトウェア開発に対する理解不足に基づいていると、指摘されることがある (The Threat of the New) 。 Matt Stephens は、エクストリーム・プログラミングを再検討し批評して、再構成した (Extreme Programming Refactored) 。 アジャイルソフトウェア開発に対しては、構造的な批判と文書化に関する批判がある。 何人かの熟練した開発者が開発に参加する必要がある ソフトウェア設計工程が不十分である アジャイル開発に適応するには組織の文化を大きく変える必要がある アジャイル開発手法の一つ Agile Modeling は、不十分な設計や少ない文書という批判に対して、解決するべく取り組んでいる。 こうしたアジャイル開発に対する批判への解決は、Agile Modeling だけでなく、他のアジャイル開発手法 (エクストリーム・プログラミングなど) においても行われてゆくとみられる。