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