5.3 度量的边界——DoD（Definition of Done）

我们经常在开发过程中看到类似于这样的现象，一个开发人员对项目经理说，这个功能快做完了，己经80％了，第二天说还差一点，一周过去了，没做完，又一周过去了，还是没完。

出现这种情况可能有以下两个主要原因。

●一个原因是这个开发人员和项目经理讨论的这个交付对象，也就是这个功能，可能过于复杂而存在太多不确定的因素，说白了，其实就是太大了。我们希望通过前面提到不同粒度的端到端的划分来解决这个问题，使开发人员和管理人员应该都知道讨论的对象是在什么样一个粒度，其中包含的风险在什么样的一个量级上。

●另一个可能的原因是，基本功能虽然实现了，但是在自测的时候，或者是在跟其他功能进行联调，又或是测试人员测试的时候，发现了各种各样的问题，所以一直不能完成。开发人员在计划时间和汇报进度的时候，经常不会太注意功能编码完成后的工作环节，低估其中的不确定性对时间产生的影响；而管理人员其实更加关心的是距离软件可用的时间和工作量，不是编码完成了百分之多少。要解决这个问题，我们需要对完成做出清晰的定义，使开发人员和管理人员对完成所表达的意义上有了统一的认识。

这里我们需要使用一个重要的概念——DoD（Definition of Done）。根据Dhaval Panchal在Scrum联盟发表的一篇文章上的说法，DoD（Definition of Done）是软件生产所需活动的一个检查列表。这些活动可能包括：需求澄清、功能设计、编码、单元测试、功能测试、联调、集成测试，还有一些我们暂时在这里没有考虑的活动，在生命周期中靠前的有需求的发现、体验的设计，往后靠还有部署、线上反馈等相关的活动。DoD引导开发行为示意如图5-3所示。

DoD的计划分成以下3个层面。

（1）特性/用户故事DoD。

（2）迭代DoD。

（3）发布DoD。

Dhaval Panchal在他的文章里提到决定各个层面DoD的策略的因素如下。

●我们是否能在特性层面完成这项活动？如果不能，那么……

●我们是否能在迭代层面上完成这项活动？如果不能，那么……

●我们需要在发布层面上完成这项活动。

对于一个软件开发组织而言，定义不同层面的DoD分别包含什么活动取决于多项因素，例如产品本身的复杂度、业界适用的开发和测试手段，以及团队和组织本身的复杂度。相对来说，如果交付周期非常短，比如互联网产品，可能需要在特性级别完成所有的质量保障活动，包括性能和负载测试，真正做到精益里的单件流；而对于一个产品复杂度高、自动化测试工具不具备，或是由于硬件和环境等条件的限制导致自动化成本很高，可能就需要在拓展特性和迭代DoD的范围时，合理权衡成本收益。

我们在帮助一个电信设备供应商的软件团队采纳敏捷实践的时候，评估的结果大致如下。

●产品本身生命周期很长，已有近10年的历史。

●软件的复杂度相当高，团队工作在数百万行的遗留代码上。

●单元测试基本不存在。

●功能层面的自动化测试有限，只覆盖少数关键功能，主要目的是冒烟测试。

●各个模块之间的联调需要数周，通常会发现大量问题。

●系统层面的自动化测试有一定的覆盖。

●各级持续集成设施都暂时还不具备，模块间和团队间的接口调试依赖全部编码完成后的集中调试阶段，这个阶段通常占据开发周期的20％～30％的时间（通常长达2个月）。

根据上述情况，我们推荐这个团队起步于：

●以单元测试作为用户故事级别的DoD；

●以功能测试作为迭代级别的DoD；

●其他质量保障活动，只能暂时在发布级别做。

对于DoD的定义并不是一成不变的。因为随着团队技能的扩展，更有效的工具和框架的引入，测试、构建基础设施的完善，提前完成更多质量保障活动的投资收益平衡点是在移动的。我们对上面的这个团队制定了下一步的目标，那就是在当前版本结束之前（6个月），通过完善各级自动化测试体系，搭建覆盖个人构建、团队级、版本级，以及产品级的持续集成设施，在当前版本尝试将用户故事的DoD拓展到功能测试，如图5-4所示，并在下个版本实现把迭代DoD拓展到联调和系统测试。

团队应该对DoD的定义达成共识，并将其明确地记录下来，严格执行。随着团队交付能力的提升，DoD应该逐渐演进。在这个演进过程中，度量体系起到的作用是牵引团队。

（1）拓展DoD的范围：提高用户故事、迭代的验证级别。

（2）提高流程和质量可靠性：减少联调、系统测试周期的不确定性对交付时间点的影响。

（3）降低缺陷的修复成本：提前发现和去除潜在问题和缺陷。