包括的なドキュメントよりも動作するソフトウェアを
この文を最も的確に表すプラクティスは、ソフトウェアをごく短い定期スケジュールで提供するというものです。通常、XPやスクラムでは作業を反復的に行います。チームは、プロジェクトの開始時にイテレーション（反復）の期間を選定し、一般的にはプロジェクトが終わるまで、その期間を変えません。1回のイテレーションの中で、チームは完成させるストーリーや機能を選択します。いったんイテレーション期間が開始すると、作業中のストーリーを変更することはできません。変更は、次のイテレーションの開始時に取り入れることができます。
通常は、イテレーションの終了時にデモや計画ミーティングが行われます。このミーティングでは、新しい機能／ストーリーを含むソリューションをチームが利害関係者／顧客に向けてデモします。顧客がそれを気に入れば、チームはソフトウェアのそのバージョンを直ちにリリースできることになります。リリースと言っても、実際にはQAまたはユーザー承認テスト（顧客が新機能をテストしたり試用したりするテスト）向けのリリースとなります。場合によっては、製品としてリリースすることもあります（Googleのベータ版ソフトウェアがこれに当たります）。
イテレーションの期間は一般的に1週間から1か月であると考えられています。期間はチームが決定します。チームが自主的にこの期間を決定するべきであり、上層部が定めた期間を押し付けるべきではありません。リーン／かんばん方式を採用しているチームの多くは、このイテレーションを適用せず、代わりに頻繁にリリースを行います。この場合はイテレーションと同様のスケジュールでリリースが生じます。そのため、リーン／かんばん方式を採用するチームは、動作するソフトウェアを頻繁にリリースできます。
詳細で包括的なドキュメントよりも動作するソフトウェアの方に重きを置く理由は、提供される価値がソフトウェアだからです。システムのドキュメント化は、ソフトウェア提供のプロセスに組み込まれていなければなりません。アジャイルではこれを実現するために、自動ユニットテストや自動ユーザー承認テストを使用するテスト駆動開発（Test Driven Development）のようなソフトウェア設計原則を推奨しています。
ユニットテストやユーザー承認テストを使用するテスト駆動開発では、ドキュメントとしての役割を果たすテスト記述を推奨します。適切に記述されたユニットテストやユーザー承認テストとは、テスト対象の要件を十分にドキュメント化したものです。メンテナンスが必要な場合は、別の開発者がこれらのユニットテストを参照し、必要な要件を理解できるようなものでなければなりません。
さらにこのテストスイートは、ソフトウェアを後で変更する場合にも有用なセーフティネットの役割を果たします。ソフトウェアを1年後に変更するときも、新チームはこのテストスイートを使えば既存の機能が正しく動作することを確認できるので、安心して新機能の開発を始めることができます。
契約交渉よりも顧客との協調を
計画主導型の環境では、多くの場合、顧客はアナリストと膝をつき合わせて、要件をまとめた包括的なドキュメントを作成します。このドキュメントがベンダーまたは社内のITグループに引き渡され、要件を実現できるかどうかの検討が行われます。ベンダー／ITグループは要件について質問することができ、回答が得られれば、検討結果が顧客に返されます。
ここで顧客の関与は終わり、後は大きな節目ごとにたまに連絡を取るだけとなります。そして合意に基づく期間が満了すると、ベンダー／ITチームはソフトウェアを提供します。多くの場合、顧客はここで初めてソフトウェアを目にすることになります。このような流れでは、顧客が機能追加を求めたり、完成品が求めていたものと違うと感じたりすることが多々生じます。
契約交渉よりも顧客との協調を説くアジャイルの方法論では、より緊密な顧客の関与を期待します。つまり、イテレーションの終了ごとに行われる計画ミーティングに利害関係者が参加するということです。また、顧客に対しても、要件検証についての協力を求めます。場合によっては、自動ユーザー承認テストを作成する際に顧客の協力を求めることもあります。
これらのユーザー承認テストでは、fitnesse、selenium、rSpecなどのツールを使用して、合意に基づく形式を用いてテストを定義します。テストは自然言語に近い形式で記述され、ビジネスロジックを実装するソフトウェアコンポーネントの呼び出しとテストを行います。
つまり、「契約交渉よりも顧客との協調を」というのは、顧客に今まで以上に開発に関与してもらうということです。顧客には、この節の最初に示した例よりも強い主体性が求められます。また、顧客と開発チームの間の信頼関係を促進するような協調体制を築くことも必要です。
