> 原文出處：http://www.infoq.com/cn/news/2009/08/agile-documentation [敏捷宣言提出](http://agilemanifesto.org/ "敏捷宣言提出")：“可以工作的軟件勝過面面俱到的文檔”。這使得很多團隊認為敏捷項目中不需要有文檔。敏捷評論家們紛紛把有限的文檔看作敏捷方法學的弱點。Ron Jeffries提出，敏捷并非推崇不需要文檔或很少的文檔，而是強調適當的文檔化。他提到， > 大家對于XP的那個最普遍的質疑其實并不正確。他們認為我們覺得文檔化是個壞主意。而XP其實致力于將對話的效率最大化。我們關于文檔化的建議正是由此而來的。 如出一轍，Eelco Gravendeel也提出[敏捷中就只有兩種文檔](http://blog.xebia.com/2009/08/09/agile-documentation-the-good-the-bad-and-the-ugly/ "敏捷中就只有兩種文檔")， * **為了保證項目運行，所有團隊成員都覺得有需要的文檔**?——在理想情況下，團隊在同一個地方一起工作，所有的知識可以通過直接交流得到共享和傳播。然而，如果是分布式的團隊，知識就不得不通過文檔進行傳播了，附帶一些的影音媒介應該更有效。這時團隊至少需要有一套共同的文檔規范，來保證大家都說“[普通話](http://www.c2.com/cgi/wiki?UbiquitousLanguage "普通話")”，能有相同的理解。 Eelco建議：需要多留意許多用于產品立項的文檔，因為項目一結束它們就沒用了；也就是說， > 一旦你承認，這些文檔僅僅是為了符合產品立項流程而寫的，當項目結束或產品發布以后，它們就沒用了，那么，理所當然地，對那些主張你把文檔做全并保證100%正確的聲音，你就可以開始說不了！這就是為何寫文檔是項曠日持久（而且昂貴！）的工作的原因。一旦你認識到這一點，其實只需要寫 到剛剛夠用，能傳話、起到備忘作用就好了，你也會理解形式也不那么重要了：寫在紙上、給白板上的圖拍個照、茶杯墊后面的草稿、story board等都行。 * **最終產品的附帶文檔**?——這是一些和客戶事先定好的、作為產品一部分發布的文檔。比較典型的例子包括 1. 用戶手冊 2. 發布手冊 3. 維護手冊（用于操作軟件） 4. 技術文檔（用于維護代碼）等。 對這些文檔，Eelco甚至還建議到： > 盡管已經確定哪些文檔需要附在產品中，你還是可以在文檔的形式上做一些創新。你可以寫個冗長的用戶手冊，抑或用更多2.0的技術，像屏幕投影（screen casting），來做文檔。后者通常比較便宜（據統計大概便宜10倍！），而且可能實際上更加實用。 因此，敏捷中就需要兩種文檔，一種是對團隊有幫助的，另一種是要和最終產品一起發布的。如果一個敏捷團隊正在準備一些超出這兩類的文檔，那就需要多留意一下了。大多時候，團隊可以避免做這些文檔。 **查看英文原文：**[Two Types of Agile Documents - No More, No Less!](http://www.infoq.com/news/2009/08/agile-documentation)