ユーザー機能駆動開発
feature は小さいので、feature を1つ完成させるのは小さな作業である。ソフトウェア開発プロジェクトとしての進捗状況を監視して報告するには、それぞれの feature の進捗状況を全て把握する必要がある。そこで、FDD では feature ごとに6つのマイルストーンを定義し、それらが順次完了していく状況を監視する。最初の3つのマイルストーンはfeature 毎の設計活動のもので、残る3つはfeature 毎の構築活動のものである。進捗を把握する補助として、各マイルストーンに進捗率が設定されている。次の表にそれらマイルストーン(と進捗率)を示す。これによると、コード作成中の feature の進捗率は 44%(ドメイン・ウォークスルーが 1%、設計が 40%、設計インスペクションが 3% で、合計で 44%)である。
FDD では、ソフトウェア開発工程を構成する5つの基本活動が存在する。最初の3つの逐次的な活動によって、全体モデルの形が決まる。その後の2つの活動は feature 毎に反復的に実施される。
ユーザー機能駆動開発は、ソフトウェア工学に基づいたベストプラクティスを中心として構築されている。それらプラクティスは、顧客にとっての機能価値(feature)の観点で駆動される。FDD が注目されるのは、それらプラクティスと技法の結合にある。FDD を構成するベストプラクティスを以下に簡単に列挙する。
ドメイン・オブジェクト・モデリング - 解決すべき問題の領域を探査し、説明する。結果として、機能を追加していく全体フレームワークが生じる。
feature 毎の開発 - 2週間以内に実装できない機能はより小さな部分機能に分割され、最終的に feature と呼ばれる小さな機能単位になる。これによりバグの少ない実装が可能となり、システムの拡張や改善も容易になる。
クラス毎のオーナーシップ - オーナーは、クラスの一貫性、性能、概念的完全性に責任を持つ。
feature チーム - 小規模で動的に結成されるチーム。個人あるいは固定的なチームで陥り易い独善を防ぐ。
インスペクション - インスペクションは、主にバグを検出することで設計やコードの品質を保証する。
構成管理 - 全 feature のソースコードについて、進捗を管理し、feature チームによる改変の履歴を保守する。
定期ビルド - 常に顧客に対してデモンストレーション可能な最新システムを構築しておくと共に、ソースコード結合時のエラーを早期に発見する。
目に見える進捗と成果 - プロジェクト内外に頻繁で適切で正確な進捗報告をすることで、マネージャがプロジェクトを適切に運営する補助となる。
FDDは、ジェフ デ・ルーカが1997年、シンガポールの大きな銀行向けのソフトウェア開発プロジェクト(50人で15か月)での必要性に応じて生み出したものであった。ジェフ デ・ルーカは、開発をカバーする5つのプロセスを設定した。それらは、全体モデルの開発と、機能のリストアップ、計画、設計、構築である。最初のプロセスは、ピーター・コードのオブジェクトモデル技法に大きな影響を受けている。2番目のプロセスは、機能的要求仕様と開発作業を管理するためのピーター・コード の機能リストの考え方を取り入れている。他のプロセスと全体としてのプロセスの統一性は、ジェフ デ・ルーカの経験に基づいている。シンガポールでのプロジェクトが成功して以来、FDDはいくつかのプロジェクトで使用されている。
FDDが世界的に知られるようになったのは、ピーター・コード、エリック・レイフェイブル、ジェフ デ・ルーカの1999年の著書Java Modeling in Color with UML(日本語訳『Javaエンタープライズ・コンポーネント—カラーUMLによるJavaモデリング』) の第6章で紹介されたのが最初である。スティーブン・パルマーとマック・フェルシングの2002年の著書 A Practical Guide to Feature-Driven Development (日本語訳『アジャイル開発手法FDD—ユーザ機能駆動によるアジャイル開発』) では、さらに詳しく Java とは切り離した手法として FDD が解説されている。
オリジナルと最近のFDDプロセスについては、ジェフ デ・ルーカ のウェブサイトの Article 配下にある。FDD に関するコミュニティ]のウェブサイトもある。