两种类型的敏捷文档——不多不少,刚刚好!
最后更新于:2022-04-01 03:13:44
> 原文出处: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)