敏捷宣言提出:“可以工作的软件胜过面面俱到的文档”。这使得很多团队认为敏捷项目中不需要有文档。敏捷评论家们纷纷把有限的文档看作敏捷方法学的弱点。Ron Jeffries 提出,敏捷并非推崇不需要文档或很少的文档,而是强调适当的文档化。他提到,
大家对于 XP 的那个最普遍的质疑其实并不正确。他们认为我们觉得文档化是个坏主意。而 XP 其实致力于将对话的效率最大化。我们关于文档化的建议正是由此而来的。
如出一辙,Eelco Gravendeel 也提出敏捷中就只有两种文档,
- 为了保证项目运行,所有团队成员都觉得有需要的文档 ——在理想情况下,团队在同一个地方一起工作,所有的知识可以通过直接交流得到共享和传播。然而,如果是分布式的团队,知识就不得不通过文档进行传播了,附带一些的影音媒介应该更有效。这时团队至少需要有一套共同的文档规范,来保证大家都说“普通话”,能有相同的理解。
Eelco 建议:需要多留意许多用于产品立项的文档,因为项目一结束它们就没用了;也就是说,
一旦你承认,这些文档仅仅是为了符合产品立项流程而写的,当项目结束或产品发布以后,它们就没用了,那么,理所当然地,对那些主张你把文档做全并保证 100% 正确的声音,你就可以开始说不了!这就是为何写文档是项旷日持久(而且昂贵!)的工作的原因。一旦你认识到这一点,其实只需要写 到刚刚够用,能传话、起到备忘作用就好了,你也会理解形式也不那么重要了:写在纸上、给白板上的图拍个照、茶杯垫后面的草稿、story board 等都行。
- 最终产品的附带文档 ——这是一些和客户事先定好的、作为产品一部分发布的文档。比较典型的例子包括
- 用户手册
- 发布手册
- 维护手册(用于操作软件)
- 技术文档(用于维护代码)等。
对这些文档,Eelco 甚至还建议到:
尽管已经确定哪些文档需要附在产品中,你还是可以在文档的形式上做一些创新。你可以写个冗长的用户手册,抑或用更多 2.0 的技术,像屏幕投影(screen casting),来做文档。后者通常比较便宜(据统计大概便宜 10 倍!),而且可能实际上更加实用。
因此,敏捷中就需要两种文档,一种是对团队有帮助的,另一种是要和最终产品一起发布的。如果一个敏捷团队正在准备一些超出这两类的文档,那就需要多留意一下了。大多时候,团队可以避免做这些文档。
评论