Bruce有话说
最近在和一个新的项目团队一起工作。由于是两个异地团队一起合作，在Sprint 1 启动前的一周，我和团队想一起制定一个团队契约来保证合作顺畅。我们一起制定各个Scrum Event的形式，哪些属于团队自己活动，哪些需要两个团队协作参与等等。当问到如何说明迭代完成这一话题的时候。大家明显分歧多了一些。从开发人员的角度做完了功能开发就算完成了；从测试人员的角度，跑完所有case才算完成；从BA或者PO的角度来说，部署到生产环境的用户故事才算迭代完成的标志。如何将Scrum Team中不同角色的人员协调一致呢？迭代“完成标准”(Definition of Done)就起到了作用。同时多团队之间也需要有一个基准线，例如 Bug级别的定义标准就是一种。
另一种场景也经常出现在完成标准不一致或未定义的团队中，那就是每次迭代都留有无法测试的条目。在给客户交付之前就需要有一次集成测试，或者几次迭代之后有一次迭代清理之前几次中没有完成的这些条目。无论是哪种，都会降低迭代的质量，因为每次都有无法搜集反馈的条目。
“完成标准”当然也不是越高越好，如果和当前Team的现状不符合，会给Team造成压力反而无法完成好迭代工作。所以找到并制定符合Team现状的完成标准才是实际的操作。
一个好的“完成标准”除了能够让团队内部和团队之间获得一致的工作标准、更好的协作之外，还有其他一些好处：
- 高质量的交付物为后期的内容提高使用效率。
- 一些团队职业行为的梳理，可以形成团队文化的一种。
今天翻译的这Scrum Pattern就是完成标准(DoD)的。希望对大家有所启发。
正文
团队的一个成员向产品负责人(PO)演示了一个刚刚“完成”的产品待办事项列表项。当产品负责人询问开发团队功能何时可以为用户使用准备好时，开发团队告诉她一切都完成了，但是还需要更多的测试，并且只需要将系统迁移到客户环境中，而这又依赖于另一个任务。继续讨论，另一个团队成员说，因为这个条目是系统的基础部分，开发团队和产品负责人应该在发布之前对其进行审查。“所以，什么时候能够完工?”绝望的产品负责人问道。“你刚刚看到的就是完工的了，但还有一些事情要做。”
✥ ✥ ✥
每个团队成员可能对团队可交付成果的“工作完成”有不同的理解。
在Sprint评审期间，产品负责人需要了解在进展方面开发处于什么位置，以便能够对在下一个Sprint中要做什么作出明智的决定。产品负责人需要知道哪些问题需要关注，并需要获得一些信息来支持他们的工作，同时让利益相关者了解情况。对产品负责人来说，常规产品增量越透明，产品负责人和利益攸关者就越能判断他是否符合要求并做出适当的决策([1], p. 71)。
对于一个人来说，“完成”可能是当工作被文档化、评审、并且没有任何已知的bug时。而对于另一个人来说，当它在轻度探索性测试中没有崩溃时，它可能是“完成”的。这种差异可能会导致交付工作中存在不同的质量标准。
团队应该能够在Sprint结束时交付一个潜在的可交付的产品增量。如果质量低于干系人的期望，团队就不应该将增量看作是可发布的。因此，团队可能需要更多的时间来稳定、调试和测试系统。但是，如果Sprint结束了，时间也就结束了。
不均衡的完成质量和意外的延迟可能会把责任推给团队，也会在团队内部制造紧张气氛。对于团队中的开发人员来说，他们必须在质量方面保持一致，这样他们才能朝着同一个方向工作。
完成不仅仅是关于外部可见的东西，而是关于任何可能对干系人有价值的东西，包括开发团队本身也是干系人之一。例如，遵循编码标准的软件源代码将减少开发人员的挫败感，甚至在将来使用它时提高效率。
团队很容易无意识地(甚至是有意识地)隐藏自己跳过了一致性或质量惯例的事实。这样做会产生技术债务:他们欠系统一些工作，迟早要还回来的。然而，这些工作项一般在所有的待办事项中都是缺失的。虽然产品的外在属性在Sprint Review中是可见的，但技术债仍然是隐藏的。为这些不可见的条目制定一个标准是很重要的，即使你相信团队会尽其所能。
因此:
Scrum团队完成的所有工作都必须遵循开发团队和产品负责人一致同意的标准，他们共同形成了“完成的定义”。完成意味着开发团队已经验证了关于这些标准没有已知的剩余工作。如果工作不符合“完成定义”，那么根据定义，该工作就不是“完成”，团队可能不能交付相应的产品待办事项列表(Product Backlog Item, PBI)
在“完成的定义”中包含不能为任何干系人增加价值的项目都是很浪费。记住哦，开发团队成员也是干系人之一。
一个完整的“完成定义”包括团队要将产品发布到客户手中所必须完成的所有工作。Scrum团队从他们当前能力范围内的“完成”定义开始，然后随着时间的推移加强它。一个更完整的“完成定义”可以让团队更准确地了解开发进程、使开发更有效、并确保在开发过程中团队遇到更少的意外情况。
“完成的定义”通常可以获得对于产品待办事项列表来说过小的、重复的工作项。它们通常只是一些良好的职业行为习惯:在编写一个软件模块后，检查所有版本管理分支;更新设计变更的工程文件;更新所使用部分的代码库存记录;清洁工作现场或桌面，或测量部件是否符合制造标准。团队可以从将这些项目中的一些放到Product Backlog中开始，但是这种方法往往会使Backlog中包含许多相同的任务。如果这些任务既没有出现在待办事项列表中，也没有出现在“完成定义”中，那么产品是否达到“完成”就取决于开发人员的专注度、专业性和良好的记忆力。最好在现有流程中创建“完成定义”，并随着团队发现缺失项而逐渐补充起来。
Sprint回顾会是回顾和增强“完成定义”的好时机，但是团队实际上可以在任何时候重新审视这个定义。ScrumMaster应该要求团队定期收紧“完成定义”;看到改进的节奏。这有助于团队成长，因为它提高了团队自身的门槛。
Scrum团队拥有自己的“完成定义”，“完成”的标准总是在开发团队的能力和控制范围内。ScrumMaster强制遵守“完成的定义”——通常是通过在团队将要交付未完成的工作时使其可见。Scrum团队通常会根据他们当前的运作方式来创建他们最初的“完成定义”，并仔细审查哪些内容可以明显增加价值。
一个可理解的、清晰的和可执行的“完成定义”在产品负责人和开发团队之间创建了一个共享的理解和共同的协议。这减少了开发团队和产品负责人之间冲突的风险。开发人员可以向产品负责人保证，在Sprint结束时交付工作不需要额外的工作(比如额外的稳定期)。Scrum团队应该偶尔探索是否应该在“完成的定义”中添加一些看不见的工作。
“完成定义”中的每一个标准都应该是客观的和可测试的。每个父母都知道下面的故事。一个父亲问一个孩子:“你打扫房间了吗?”孩子回答说:“是的。”然后父亲接着说:“玩具收好了吗?衣服挂好了吗?床整理好了吗?地板用吸尘器吸干净了吗?”孩子说:“还没有。” 所以，不要测试活动，而要测试具体的结果状态。这也使得将“完成的定义”形成一个检查清单变得容易。这是一个值得称赞的实践。与此相比，可测试的改进更适用于过程改善;完成的大多数元素都是产品属性。
当开发团队遇到不符合当前“完成定义”的旧工作时，应该删除或减少技术债务。通常，团队只清理修改附近的区域，将更改的范围限制在合理的范围内。从长远来看，“完成定义”有助于消除技术债务。
在更大的组织中，所有团队共享的“完成定义”可能会建立一个共同的质量级别。平衡共享完成定义的想法和团队自治的需要。如果多个开发团队工作在一个产品上，他们都共享相同的“完成”定义，因为他们在Sprint结束时交付了一个集成的产品增量。
团队不会为每个PBI创建自定义的“完成定义”，而是应用一组通用的标准。然而，一组通用的标准可能并不总是很好地匹配所有的工作项。例如，文档、计算和代码的标准可能不同。如果你有很多不同类型的工作项，单个集合不能充分涵盖这些工作项，那么你可能需要为每种类型的工作项单独定义“完成”。这很常见。
✥ ✥ ✥
有了“完成”的规则，Scrum团队就可以交付已知质量的常规产品增量。仅仅是实践“好管家”就可以让一个团队避免陷入技术债务的麻烦。作为每个PBI在每个Sprint中都被完成的结果，迭代中不会出现“高质量的PBI”、“高质量的Sprint”或“强化的Sprint”这类的描述。更多的关注已完成会减少了在以后的开发中出现不愉快的意外情况，并且知道以前的工作已完成没有留下任何“尾巴”，会使得进度预测更加可靠。例如，有一个“完成”的强制要求可以消除DevOps团队为客户配置发布的过程，这正是以一种符合良好精益实践的方式，消除了移交的步骤。完成的最终目的是为最终用户的使用或应用做好准备。
一个好的“完成定义”可以在多个sprint中出现在多个PBI中,作为重复的所需任务。拥有一个固定的、通用的列表可以避免重复这些项目作为PBI预期或SBI(Sprint Backlog Item)活动。
有了一个好的“完成定义”，团队就可以避免技术债务。在Sprint评审中，将“完成”的定义添加到产品负责人用来批准产品待办事项项的标准中。好的SrumMaster要求开发团队坚持一致同意的“完成定义”;产品负责人强制遵守可见的需求，并在产品待定项中作为规格说明进行沟通。产品负责人将允许组织只交付完成的PBIs，并且应该选择只让完成的PBIs进入Sprint评审。有一些灰色区域，比如用户界面指南(想想苹果的人机界面指南)，它们是面向外部的，但是可以自动执行，并且有可能被置于开发团队的管辖范围内。
[1] Ken Schwaber. Agile Project Management with Scrum. Redmond, WA: Microsoft Press, 2004, p. 71.
Picture credits: The Scrum Patterns Group (Ville Reijonen).
