【敏捷开发每日一贴】DoD“完成”的定义


DoD“完成”的定义
常有团队对于本迭代是否完成无法达成一致意见，有的认为我编码完成，就表示我的任务完成了；有的认为还需要简单自测一下，确保功能能跑通；还有的认为需要把自动化用例写完并测试通过。
为了避免这个问题，在敏捷软件开发中，常用Definition of Done“完成的定义”来表示工作是否已完成，不同的活动有不同的完成定义。
典型的是迭代DoD，这也是最初DoD应用的地方。比如:
1.  所有代码通过静态检测，严重问题都已修改，静态分析的规则参见...
2.  所有新增代码得到人工评审
3.  所有完成的用户故事都有对应的测试用例
4.  测试用例都已执行
5.  所有完成的用户故事得到PO的验证
而对于发布，一般就有更加严格的要求，发布DoD的典型条款有：
1.  完成发布规划所要求的重点需求
2.  至少通过一次全量回归测试
3.  修复所有等级为1、2的缺陷，3、4级缺陷不超过20个
由于发布需要达到比迭代更高的要求，所以一般很难强制规定发布测试所需要的时间长度，也就是说敏捷中常用的时间箱方法不适宜用在发布前的测试上，因为高质量发布是第一要务，如果到了原计划测试结束的时间，仍然留有影响发布的缺陷，必须修复后才能发布。
而迭代成果一般是为了内部或者可控范围内的展示，相对发布而言，要求较低，所以适用时间箱方法，当然迭代本身就是时间箱，迭代内的测试本来就有时间限制。采用时间箱来安排迭代内的测试可以获得时间箱安排的种种好处。
此外还有版本DOD，比如：
1.  产品文档已全部更新
2.  代码已部署到产品服务器上
3.  运维在验收测试环境上冒烟通过
4.  原始需求提交人对功能已经验收通过
5.  对运维、市场、客服的新功能培训已完成
其他典型的DOD有每日DoD，典型条款有：
搭建每日构建环境，晚上自动静态代码检查、编译、部署和测试，每日修复前一日构建和测试发现的缺陷和问题。
1.  下班前必须检入当天编写的代码，checkin的log要填写清晰
2.  当天的代码必须在当天或者第2天邀请同伴进行代码评审
3.  检入的功能代码必须要有对应的单元测试（严格采用TDD）
4.  每天晚上触发静态代码检查、自动化回归测试
5.  当天持续集成、构建环境中的问题，请当天解决
还有针对用户故事（或者用例）的DoD，比如
1.  用户故事最终的描述符合INVEST
2.  用户故事得到测试用例的对应覆盖
3.  用户故事得到对应的自动化测试用例
4.  用户故事得到PO试用并初步认可
当测试集比较大的时候，无法在1天之内完成测试，可以开展每周全量回归自动化测试，这样就有每周DoD，典型条款有：
1.  上上周发现的缺陷是否解决
2.  上周新增功能的自动化测试是否加入到每周测试集。
需要强调的是，DOD必须是团队在项目启动时共同讨论出来的，团队愿意共同遵守的原则，一旦确定团队就应共同遵守。