"包括的ドキュメントよりも，動作するソフトウェアを。"，アジャイマニフェスト 2001 より。
アジャイルのコミュニティにおいて，ドキュメントは明らかなテーマであっただろうか？ どれ位の量のドキュメントを作る必要があるのだろうか？ 必要なものは？ 不要なものは？ 従来の開発プロセスのドキュメントをアジャイルに移行する方法は？ アジャイルコミュニティにおいてドキュメントは，明確な定義に欠けている分野なのだ。
Zen Agile の最近のブログエントリに，次のような問いかけがあった。"十分なドキュメントとはどの程度なのか？"。 この記事の筆者は，政府機関での自身の開発経験と，そこでドキュメントが重視されている理由について，次のように語っている。
私はずっと，これらのドキュメントがすべて必要なのは “顧客が政府だから”，と聞かされてきました。しかし少し調べてみると，おおよそ次のような理由が分かってきたのです。
営業面から，仕様承認とビルド承認のための包括的な情報が必要である。 システムの設計目的を開発者に伝える必要がある。 改良を行う開発者が，システム構成を知る必要がある。 メンテナンスを行う開発者が，システム構成を知る必要がある。 政府が費用発生の理由と，その用途に関する詳細な情報を要求している。 経験から言えば，しかし要件定義資料に関して理解できる営業関係者は非常にまれです。彼らは，プロジェクトのバックグラウンド資料を読んでプロジェクトの現状と原理の明確な定義を確認したり，ユースケースより理解の簡単なプロジェクト説明図としてビジネスプロセスマップを確認するようなことは行います。しかし全般的に，まだ実現できていないものを書面で承認するために，というのはあまりなく … そう … 論理的でないのです。
筆者は次に，ドキュメントの代替手段について説明している。その内容は次のようなものだ。
- ペルソナ，シナリオ，コンテキストダイアグラムによるコンテキストの明確化
- プロセスマップ，トレーサビリティマトリクスを使用した要件定義
- データモデル，サイトマップ，ナビゲーション設計，UI設計によるソリューションのドキュメント化
- プロトタイプを使用した，ソリューションの評価・承認の繰り返し実施
- コード，テスト，管理，物理データモデルを含むシステム構造の文書化
このプロセスは実体験を元に，よく検討されてはいるが，私たちすべてがコミュニティで行っている事とほとんど同じではないだろうか？
ストーリー，ユースケース，あるいはテストを仕様とする ことの議論がある。他にもあるだろうか？ この記事の筆者も今回始めて知ったのだが，アジャイルのドキュメントだけを取り上げた 書籍もある。ドキュメントに関して 示唆と表現性に富んだ章 を含む本もある。さらには ３年以上前の InfoQ のアーティクルでも この主題が取り上げられている。
ドキュメントに関しては，私たちには合意（コンセンサス）どころか，ほんのいくつかの一致した '見解' さえ持っていないのではないだろうか。この主題に関する資料はあまりにも少なく，それを語ることさえ本当に難しい。何か書をなすにはテーマが単純すぎるのか。あるいは逆にあまりにも複雑で，推奨すべき良案を私たちが持ち合わせていないのか。読者の考えはどうだろう？