Scrum中有一个“完成的定义”(Definition of Done)，其实就是对于Sprint待办事项列表(Sprint Backlog)中的每一个承诺的用户故事，都要达到的质量标准。通常包括：

• 代码签入到主线
• 代码审查
• 单元测试
• 功能测试
• 系统测试
• 。。。

教科书上的Scrum要求，每个sprint都能上线，也就是对于每个用户故事都需要达到所有的内部质量标准（也就是完成的定义）。因为功能上下，客户才会去使用，然后就会有反馈，从而指导产品演进的下一步方向。从而实现健康的关于产品演进发展的反馈环。如果功能不能达到上线的质量要求，与客户之间的反馈环就断了。那很有可能团队制造出很多sprint的垃圾。

 

但是不是所有的团队都有足够的能力去把功能推上线。很多团队不能在sprint内做系统测试，很多由于软硬件依赖的原因甚至不能做功能测试，不能把相关功能的所有bug都解决掉。因此在上线前，需要经过很长的stabilization阶段，不能在Sprint中完成，而只能在发布前的Stabilization阶段完成的工作叫“未完成工作”(Undone Work)，这其中也包括很多技术负债。“未完成工作”越多，债就越多，用来还债的stabilization阶段就越长。 而这直接后果就是拉长了客户之间的反馈环。在当前竞争激烈的市场中，这种缺陷可能是致命的。所以好的团队会花一部分精力去提高自身能力，“完成的定义”增强之后，从而减少“未完成工作”，

 

但是还有一个问题，既然“完成的定义”是不断发展、扩充的。那是否需要一个最小集合的“完成的定义”，而连这个最基本要求都没有达到的团队，连最起码的Scrum都不是呢？首先看一下Scrum，Scrum是一个基于反馈的框架，不断审视反馈中获得的数据，然后相应去调整。如果连反馈都没有的话，那就不是Scrum了。那软件开发中的反馈包括开发人员与测试人员、开发团队与产品负责人、团队与客户等等，那其中最小的反馈是什么呢？是开发人员和测试人员之间的反馈，从这个意义上说，最起码的“完成的定义”必须包括最基本的测试人员测试，哪怕是手动测试。如果连手动测试都没有的话，对团队正在做的功能来说，连最小的反馈都没有了。前一阵子网上看到一些公司的Scrum实际经验，其中很多公司提出了“具有XXXX特色的Scrum”，就是把未完成的工作放到下个Sprint去测试，对于这些团队来说，哪怕他们也有每日Scrum站会、各种各样的Scrum会议，由于连最基本的“完成的定义”都没有达到，违反了Scrum的最基本原则。

 

总结：

Scrum团队应该有一个“完成的定义”，哪怕是一个很弱的“完成的定义”，但是再弱也不能弱到连一点儿测试都没有。团队能力提高的过程就是不断强化“完成的定义”的过程。