すでに指摘したように、アジャイルとはドキュメントがほとんどまたはまったくないという意味ではなく、「包括的なドキュメントよりも動作するソフトウェア」です。
私がドキュメンテーションにアプローチする方法は、ほとんど物事をひっくり返し、ドキュメンテーションのすべての部分 (技術仕様としてのコードと単体テストを含む) を検討することです。したがって、ビジネス/ユーザーの要件を説明するストーリー (または作業を分割するために使用するその他のメカニズム) は、作業を行うチームが見積もるのに十分なほど詳細である必要があります。そうでなければ、それは不完全で曖昧です。さらに、私自身の実践で行っていることですが、ストーリー (またはその他のもの) がチームの「完了」の定義に適合するまでに 1 営業日以上かかると推定される場合、おそらく分解する必要があります (この原子化してからコンパイルすると、最終的には非常に広範なドキュメントですが、実行しない場合ほど多くの未知数を想定していません - そして、非常に興味深い再利用とパターンの発見につながる可能性があります)。
BDD スタイルの要件を使用した例:
Given I am working on a document
When I select "Save As..."
Then a menu should appear allowing me to choose a name,
and a file type,
and a location in the file system,
and a file should be created in the file system
これを実現するために、UI 要素、メニュー項目、ストーリーボード、キーボード ショートカットなどをこの説明に追加する必要がある場合があります (「ファイルの保存」という同じテーマで複数のバリエーションがある場合があります)。等々。
これらの関連成果物はすべて、基本ストーリー/要件に添付できます。その結果、より完全なドキュメントが作成されます。ただし、実際に実装するストーリーのみを、Web バージョンのソフトウェアのドキュメントに追加してください。
ここで物事がひっくり返り、より「アジャイル」になります。開発中および開発後に、文書化された要件を再検討し、チームの編集によって行われた変更/修正/改善を追加します (文書化のみの CCB を通過する必要はありません)。すべての審査委員会などを通過せずにドキュメントと関連アセットを編集/更新する機能、または開発中にドキュメントが何らかの形で不完全であることがわかったときにドキュメントを「壁の向こうに」投げ捨てる機能により、適応することができます未知へ - したがって、アジャイル。
このドキュメンテーションには、何らかの形のバージョン管理または履歴が必要です。これにより、希望するシステムを説明できるだけでなく、実際に実装されたシステムについても説明できます。ドーンの定義の一部であるドキュメンテーションに関する別の回答/提案に注意してください (私も行う）。(Wiki はこれに適しています。ただし、完全に統合された概念の方がもう少し望ましいです。たとえば、バージョン管理システムのトランク内のファイルにチケットを関連付けることができると便利です。)
結論として。開発作業中および/または開発直後に変更できない完全なドキュメントを前もって作成すると、機敏性、つまり未知のものにすばやく適応することができなくなります。ただし、Leading Lean Software Development を参照すると、ポリシーが特定のプラクティス/プロセスを適切に使用することを許可していない場合、リーン (またはスクラム、またはアジャイル) であるかどうかは問題ではないと述べています。
過度に網羅的ではないことを確認する1つの方法-おそらくこの回答でこの考え方を使用できた可能性があります-必要なときに必要なものだけを書くことです(同様の概念が開発全般に存在します)。もう 1 つの方法は、事前にすべてを理解しようとする必要はないことを全員に理解してもらうことです(ウォーターフォールからアジャイルへの最大の移行)。そして最後に、適用されなくなったものはすべて非推奨 (および削除) します...システムのドキュメントを一度見たことがありますが、システムを確認したとき、ドキュメントの半分は実際にはシステムに適用されていませんでした。