敏捷开发中文档的取舍

敏捷开发中文档的取舍

 先说需求文档，分为两部分，一方面是框架性的需求文档，对功能、交互方式、出错或边界情况的表现进行总体描述，这种文档不需要过于细致，因为产品经理组织语言写文档，开发读文档，理解文档都要消耗大量时间，最好是以总体概括的方式来做，开发在做需求设计时候与产品人员进行频繁密切沟通，最终一起形成完整文档，这中间开发、测试人员对于文档严谨性是有很大贡献，不必要求产品经理全部把边界细节都写出来。另外一方面，作为良好的协作习惯，任何沟通产生的结论都应该存档！邮件是一种比较好的形式。每次会议结束，问一句结论呢？谁出纪要？不是说文档不重要，而是通过见面沟通，把需要文档描述很细节的内容达成共识。概要设计详细设计，视需求逻辑难易，规模大小而定。逻辑复杂的项目，概要设计作为帮助开发理解需求的一种手段。大型项目，详细设计架构设计不可避免。一句话规模的需求，随便做做就算了。这其中都要不断的当面沟通！  

文档的功能

追本溯源，我们应该先问的是“为什么要文档？”，我相信答案应该是“为了沟通”。关于沟通，有一个图表，大家应该知道：“沟通渠道丰富度和沟通成效的关系”

 图上的虚实两条曲线，大家只需要关心上下两个端点即可：最左下角“Paper”，也即基于纸面阅读的单向交流，是沟通效果最差的；而右上角“面对面交流”，则是效果最佳的。
基本上也是因为这个原因，在[敏捷宣言](http://agilemanifesto.org/iso/zhchs/principles.html)遵循的原则中明确说到：“不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。”

关于敏捷文档，敏捷大师 Scott Ambler 有一篇著名的文章详细探讨了这个话题：

Agile/Lean Documentation: Strategies for Agile Software Development

敏捷开发是不是不用写需求分析、概要设计、详细设计之类的文档了啊？
概要设计文档、详细设计文档是源自传统软件工程的说法。  
如今传统的 Word、PDF 版的详细设计文档通常可以省略，大部分这类文档可以结合代码注释用工具自动生成，Web/HTML 版的详细设计/代码参考文档才是更好的做法。在敏捷开发中，需求文档、概要设计（改成架构设计）文档通常是不能省略的。