故事情节
最近第二次迭代时，我们带领的开发小组长文哲，这两天在补需求文档、部署文档（二次迭代完成了哪些客户需求？未完成的？），在迭代开发之前就应该有一个文档即是不全，那该多好啊，不用现在这么着急的补充啦。
思考：倘若没有文档，给客户迭代完后，如何表明我们所做的内容呢？客户是否满意呢？如果没有文档，和客户的交流验收时就很难办了？
到底要不要写文档？
记得合作开发的时候，前期花费了很长时间，我们是采用了传统的瀑布模型，需求文档、概要设计、详细设计、数据库设计、甘特图等文档都是前期设计全了，遵循着文档驱动开发，当我们开发过程中到最后，发现文档、图、解决方案根本对不上了，中间修改了很多，相差很多，再验收以前我们三个是饿补啊，在整个开发的过程中由于前期的设计不可能考虑的很详细，每一步不可能考虑的很清楚，最后的文档成了我们头大的问题。
初设敏捷开发
自从接触了敏捷开发，我们就体会到这个开发思想不提倡写文档（很爽啊，先开发，当初理解的浅显）我们现在根据客户的需求拿来就开始干了，在这个过程中确实使用着禅道等项目管理工具，但是现在体会还是有些乱，规划的还有很多不合理的地方，给大家的每天的目标还不是很明确（时间段、任务、弹性时间、困难、该完成什么功能？）没有明确的规划，可能会引发项目拖延，时间一长大家会有懈怠心里啦。
项目一开始，根据客户的需求我们就开始干了，设计、开发、等真正给客户架过去之时发现需求理解的不是很到位、使用还有常见的bug（测试文档没有）等，造成了没有给客户部署成功、我们浪费时间、给客户留下不好印象等等一系列问题，敏捷开发确实可以应对一些变化，但是因为文档不全的问题又一些给大家带来了苦恼。
今天抽些时间查了敏捷开发的相关资料，敏捷并非不写文档，而是重视文档的作用，也重视文档的维护；它认为文档宜少且精炼，不需要冗余的文档；文档也是作为细化部分，在每个迭代过程中不断重构；一般需求文档、概要设计、详细设计、数据库设计、项目管理文档（甘特图等等）都是必须的，在许多外企的迭代开发中都是这样的，倒是国内的公司确实提倡一种：敏捷无文档，开发效率慢， 基本的文档都是必须的；敏捷开发中的写文档，有了方向性的指导。
总结
开发要有开发文档（需求文档、数据库设计、概要设计）、开发计划（甘特图、燃尽图）、测试计划（时间、地点、人员、任务模块分配、禅道bug提交管理）都应该有一个时间段，在大家的一起商量之下可以每个人做到心中有数，对任务整体有个全局观，我们每天该干什么？紧急重要的需求？客户迫切需要上线的功能？都有一个好的规划，避免在不必要的文档上（官话、客套话）浪费更多的时间，劲使在刀刃上，提高我们的开发效率，有明确的目标、去按照我们的计划一步步的完成。
各个工作流自有它的价值……努力吧，继续深入理解敏捷开发理念！
项目管理---敏捷开发---到底要不要写文档？,布布扣,bubuko.com
项目管理---敏捷开发---到底要不要写文档？
原文：http://blog.csdn.net/lishehe/article/details/22901789
