完成标准（DOD）浅析

最近，我的团队问我一个问题：“为什么我安排下去的每个迭代任务，总是做不完？”

经过沟通，我发现团队中每个开发人员对自己的“任务”完成，都有不一样的理解：

• 有的认为我编码完成，就表示我的任务完成了
• 有的认为我还需要简单自测一下，确保功能能跑通
• 还有的认为需要把自动化用例写完并测试通过

我们先不说这个团队目前的敏捷开展水平如何，还有其他的哪些问题。
我们今天就这个“工作完成标准”做一些探讨。
当你有两个或更多的人参与同一个事情的时候，我们的“团队”就产生了，那么，我们最重要的事情，就是要设定和统一团队的期望值，在本文中，这就是“完成标准”。

哪些节点可以设置DOD？

首先，我们要清醒地知道，所有的DOD，都不是一成不变的，在随着时间的推移、经验的积累、成员的变更、项目的变更，我们的DOD也会有很大的不同，所以，我们也需要定期地检查和改进。
有了上面的思想准备，我们再来看下面的DOD定义，心情就不会那么沉重了！

用户故事DOD

嗨，你怎么理解用户故事完成标准？是否有看到这里的两层意思？

• 针对需求分析，用户故事是否已经准备完成，可以纳入最近的sprint开发了？
• 针对故事本身，开发完成后，是否可以产品交付出去了？

哈，你可能和我一样吓一跳，原来如此，那要怎么办呢？

1. 用户故事就绪标准

• 用户故事优先级已排定
• 用户故事拆分粒度，已可以放入迭代中
• 用户故事已经估算完成
• 用户故事的验收条目已完成

是不是有点像用户故事的准出条件？

2. 用户故事完成标准

• 故事涉及的自动化用例全部跑通
• 完成和其他功能的集成测试
• 完成回归测试
• showcase通过
• 产品经理做完内部验收
• 相关的部署文档已更新

每日DOD

对于团队每天的工作情况，清晰的DOD定义有利于团队的高效协作和质量保障：

• 每天下班前，至少checkin代码一次，checkin的change-log要填写清晰
• 当天的代码必须要经过结对走查
• checkin的代码有经过自动化单元用例
• 每天晚上触发静态代码检查、自动化回归测试
• 当天持续集成、构建环境中的问题，请当天解决

版本DOD

是不是上面的每个故事都测试通过了，每天也都有持续集成，是不是就可以直接对外交付了？
理论上来讲，如果每日DOD和用户故事DOD，比较完善的话，是可以直接对外交付了，但是理想很丰满，现实很骨感，我们总是会发现要发布的时候，我们还是有很多事情忘记了，于是我们不得不再定义个版本（或者直接叫交付）DOD：

• 产品文档已全部更新
• 代码已部署到产品服务器上
• 运维在验收测试环境上冒烟通过
• 原始需求提交人对功能已经验收通过
• 运维、市场、客服对新功能已经培训完成

每个团队在实际开展过程中，都会有自己的DOD，这里我只阐述几个自己有用到的例子，不是模板，各团队在基于这样的案例中，学习并定义适合自己的DOD才是真正有意义的事情。