谈谈敏捷开发中的文档

敏捷开发提成过程快，轻文档。这个说法现在有很多的支持者。今天就说说这个话题。我本人是个文档支持者，因为我觉得所有的逻辑能写清楚，说明是真的清楚了。如果不能清晰的写出来，那很可能还有很多的细节想的不是很清晰。当然这个思路本身就是不敏捷的。

今天和一个以前在猎豹的同事聊天，说起了他之前在猎豹的经历。入职后拿到的第一份文档是员工手册，第二份文档是系统说明手册。其中详细说明系统的架构、逻辑、流程、主要组件和类、关键 API 接口等，让新入职的员工通过这个手册来了解接下来的工作。而且猎豹还有一个额外的手段来促进文档的及时和准确：新入职员工如果发现系统说明手册有和实际不一致的地方。维护文档的人罚钱奖励给发现问题的新员工。

从心里来说，我是非常赞成这种做法的。大致有以下好处：

• 形成产品的完整描述，现在产品都是迭代式的，人员流失等一些场景会让产品的文档出现断层。这些断层带来的后续迭代开发的影响非常大。

• 开发人员的事后检查。形成文档的过程是所有参与者进行事后检查的过程。没有这个过程，可能会有一些测试环节都没有发现的问题隐藏下来。

• 好的做法和机制，对新人的帮助更是巨大的。新人入职第一印象会非常好。会觉得整体的研发过程非常规范。这些会让他在后期自己的工作中自觉的遵守规范。持续下去就会形成好的团队氛围。

• 减少后续的摸索时间。没有文档，每个想了解产品细节的人，都要自己从各个细节摸索具体内容。摸索到的内容也只会留在自己的领域里。再有其他人想了解的时候，就还要进行一遍上述动作。

总之，即便是为了强调速度而轻文档的敏捷开发，在功能完成之后，也建立形成完整的产品说明文档。这样能最大限度的形成知识积累。