敏捷研发DoD：怎样才算“完成”
当团队说产品待办事项列表条目以及产品增量“完成”的时候，每个人都应该理解“完成”意味着什么。在一家互联网企业P，小强作为ScrumMaster带领一个Web开发团队。在第一个Sprint计划会议上，团队就Sprint要完成哪些需求与产品负责人达成了一致。在Sprint评审会议上，团队为产品负责人和利益干系人演示产品，大家也很满意。当产品负责人问，这些已经上线了吗？小强说：“刚到测试环境里完成功能测试，还没有做回归测试呢。此外，上线是运维组的事，不是我们的事。”
这让产品负责人大跌眼镜：“我们需要的是上线啊，没上线怎么能算完成呢？还给我们演示（Demo），这是在浪费我们的时间啊？”
团队很诧异：“没人说一定要上线啊？此外，运维组也不是我们的人啊，什么时候上线不在我们的管辖范围啊。”
这种情况在许多初次尝试敏捷的团队很常见。对“完成的定义”，产品负责人与团队没有一致的理解，大家在各自没有说出来的理解下工作，当Sprint结束的时候，分歧 出来了。所以，在第一个Sprint开始之前，团队应该就“完成的定义”达成一致。那么应该定义什么样的DoD呢？
因为每个团队的DoD可能不一样，所以团队应依据自己产品和业务的特点，就DoD与产品负责人达成一致的意见。表6-3是一个DoD检查表示例，仅供参考。
表6-3DoD检查表
在企业P，小强引导团队列出了如下“完成的定义”：
[*]完成用户体验设计；
[*]通过需求设计评审；
[*]提交代码；
[*]通过代码评审；
[*]通过测试。
团队有人问：“这里通过的测试包括哪些？是集成测试、功能测试、回归测试，还是性能测试？”
大家商议，如果这些测试都包含，由于现在团队的自动化测试脚本很少，回归测试和性能测试无法在一个Sprint内完成。那么该怎么办呢？是不是可以将其移到下一个Sprint做呢？
小强引导团队达成了如下共识。
回归测试和性能测试暂时不在“完成的定义”里，而是安排在产品发布前的一个Sprint里执行。但是团队从下一个Sprint起，引入自动化测试框架，对每个基本特性补充测试脚本，并着手调研性能测试工具。团队设定了目标：用4个Sprint的时间做完产品已有特性的回归测试和性能测试的脚本开发工作。
现实中这样的情况很常见，因为通常从0开始尝试敏捷的组织，其自动化测试基础都很薄弱。这种情况下，无法按照将产品发布给客户的标准来定义DoD。因此，DoD的范围有多大，本质上反映了组织的敏捷成熟度。DoD范围越靠近上线的最后一步，说明组织的敏捷成熟度越高。
其实对于小强团队的情况，并没有完美答案。“完成的定义”也体现了组织敏捷转型的范围。产品发布到用户（或客户）手里需要做的所有工作都应该在“完成的定义”里，但是那些不在“完成的定义”里的工作是省不掉的，如果不是在Scrum团队范围里做，必然由另外一些部门或团队完成。那些承担Scrum团队未完成的工作的部门，称为“Undone部门”，这些部门正是组织敏捷转型未来要覆盖的目标。
对于当前Sprint做不完的工作，必须安排在下一个Sprint，或者是在发布前专门安排一段时间来完成，如图6-6所示。
图6-6未完成的工作不断累积
资料来源：《精益和敏捷开发大型应用实战》（PracticesforScalingLean&AgileDevelopment），2010年12月
每个Sprint不断累积的未完成的工作，不仅推迟了产品的反馈周期，蕴藏的缺陷也会不断增加。因此，未完成的工作越少越好。
在企业P，小强的团队在前几个Sprint没有做性能测试，而是在发布前的最后一个Sprint做的。但是团队发现了严重的性能问题，产品存在严重的内存泄露，需要对架构进行整改。而架构改动的影响范围巨大，导致前几个Sprint做的很多工作都需要返工。原定的产品上市时间也不得不推迟。
因此，团队要尽量将产品的质量反馈闭环控制在一个Sprint之内，不要推迟风险 的时间。
页:
[1]