两种类型的敏捷文档——不多不少，刚刚好！

  • Vikas Hazrati
  • 金毅

2009 年 8 月 16 日

话题：敏捷文化 & 方法

敏捷宣言提出：“可以工作的软件胜过面面俱到的文档”。这使得很多团队认为敏捷项目中不需要有文档。敏捷评论家们纷纷把有限的文档看作敏捷方法学的弱点。Ron Jeffries 提出，敏捷并非推崇不需要文档或很少的文档，而是强调适当的文档化。他提到，

大家对于 XP 的那个最普遍的质疑其实并不正确。他们认为我们觉得文档化是个坏主意。而 XP 其实致力于将对话的效率最大化。我们关于文档化的建议正是由此而来的。

如出一辙，Eelco Gravendeel 也提出敏捷中就只有两种文档，

  • 为了保证项目运行，所有团队成员都觉得有需要的文档 ——在理想情况下，团队在同一个地方一起工作，所有的知识可以通过直接交流得到共享和传播。然而，如果是分布式的团队，知识就不得不通过文档进行传播了，附带一些的影音媒介应该更有效。这时团队至少需要有一套共同的文档规范，来保证大家都说“普通话”，能有相同的理解。

Eelco 建议：需要多留意许多用于产品立项的文档，因为项目一结束它们就没用了；也就是说，

一旦你承认，这些文档仅仅是为了符合产品立项流程而写的，当项目结束或产品发布以后，它们就没用了，那么，理所当然地，对那些主张你把文档做全并保证 100% 正确的声音，你就可以开始说不了！这就是为何写文档是项旷日持久（而且昂贵！）的工作的原因。一旦你认识到这一点，其实只需要写 到刚刚够用，能传话、起到备忘作用就好了，你也会理解形式也不那么重要了：写在纸上、给白板上的图拍个照、茶杯垫后面的草稿、story board 等都行。

  • 最终产品的附带文档 ——这是一些和客户事先定好的、作为产品一部分发布的文档。比较典型的例子包括

  1. 用户手册
  2. 发布手册
  3. 维护手册（用于操作软件）
  4. 技术文档（用于维护代码）等。

对这些文档，Eelco 甚至还建议到：

尽管已经确定哪些文档需要附在产品中，你还是可以在文档的形式上做一些创新。你可以写个冗长的用户手册，抑或用更多 2.0 的技术，像屏幕投影（screen casting），来做文档。后者通常比较便宜（据统计大概便宜 10 倍！），而且可能实际上更加实用。

因此，敏捷中就需要两种文档，一种是对团队有帮助的，另一种是要和最终产品一起发布的。如果一个敏捷团队正在准备一些超出这两类的文档，那就需要多留意一下了。大多时候，团队可以避免做这些文档。

查看英文原文：Two Types of Agile Documents - No More, No Less!

敏捷文化 & 方法