> 原文出处：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)