大家好，我是阿萨。 最近一直在学习敏捷相关内容。 昨天我们学习了冲刺速度。 今天来学习 定义完成的标准。 也就算是常见的DoD(Ddefinition of Done).
完成的定义标准是什么?
在敏捷方法论中，完成的定义(DoD)是用户故事、冲刺或发布必须满足的一系列标准，才能被认为是“完成”。众所周知，程序员总是说他们“完成了”，而实际上他们只是完成了编码;其实发布一个可工作产品还有其他阶段的事情要去做，例如测试、部署和文档编制。敏捷完成的定义应该在其定义中包含这些没有被开发考虑到的阶段。
敏捷管理强调的理念是，每一次工作增量或冲刺，都应该创建一个潜在的可交付产品。冲刺的结果应该是可以工作的软件。一个构建可以发布给客户，也可以不发布给客户，但是可以根据产品经理/项目经理的决定来发布。
理想情况下，完成的定义应该抓住发布给客户使用的工作单元所需的所有基本内容。
一个完成定义标准的示例
以下是许多开发团队典型的“完成定义”模板。团队可以使用这些标准一部分、或者全部或与其他标准结合使用——作为完成的定义标准。
用户故事已完成检查表
- 代码满足用户故事
- 项目构建成功，通过单元测试
- 在测试环境中部署新的已实现用户故事代码的版本
- 项目在高优先级设备和浏览器上完成测试
- 运行全部测试，解决了bug
- 产品负责人认可
- 文档更新
代表sprint已完成的检查表
- sprint中包含的每个用户故事都是满足DoD的“完成-完成”
- 单元测试通过
- 项目部署在与生产平台相同的测试环境中
- 集成项目已经在所有相关设备和浏览器上完成测试
- 兼容性测试通过
- 性能测试通过
- 安全测试通过
- 所有bug已修复
发布的完成定义标准检查表
- 代码完成
- 生产环境已准备好
- 单元和功能测试都通过
- 满足产品负责人验收标准
- 持续集成和验证工作都已完成
- 完成手工QA和用户验收测试，并解决了所有问题
- 其他来自UX设计师，开发人员，架构师，项目经理，产品负责人和任何其他利益相关者的问题都已处理
完成的定义标准不完善的后果:风险和延迟
在敏捷项目中，完成的定义是流动的，由开发团队自行决定。当完成的定义太“弱”时会发生什么?如果忽略了一些对实现潜在可交付产品很重要的标准，即使没有这些标准，工作也被认为“完成”了，会发生什么?
“完成”的不完善定义最危险的方面是一种错误的进步感。团队报告完成了用户故事、史诗和发布，但实际上，这些工作单元的质量和完整性还不完全清楚。当产品所有者决定发布产品时，他们可能会突然发现产品的某些部分不能工作或还没有准备好用于生产。
底线是，一个不完善的“完成定义”会导致风险，而风险会导致延迟，或者更糟——生产故障和客户对交付产品的不满。
完成的定义标准-找到最佳点
“完成”的定义太弱是不好的，但“完成”的定义太强也是不好的。如果团队过度投资于测试、验证和保障，他们将不能按时交付，速度也会受到影响。
围绕“完成”定义的主要“灰色区域”是质量。用户故事通常都有很好的定义，并且很清楚需要开发什么，但是为了确保客户满意，产品需要测试到什么程度呢?
添加更多的测试和测试级别，肯定会有一些非常复杂和成本测试存在。造成浪费。最佳点在哪里——在这个点你可以说“我们完成了”，并且觉得你已经达到了能让大多数用户满意的质量水平?
识别缺少的关键测试
要找到最佳点，首先需要发现构建中缺少哪些关键测试。这些特征是:
- 此版本或最新版本中有新版本且没有测试?
- 在生产中经常使用?
- 缺少一种基本类型的测试(例如UI特性的UI自动化)?
这些是你应该添加到你的冲刺的第一个测试，以确保你真的“完成了”。
识别不必要的测试——“完成”并不真正需要
有一些不必要的特征被方法完成的检查表里:
- 测试在最近的版本中没有改变的代码，可以在生产中工作得很好?
- 很少或从未在生产中使用的需求需要测试?
- 需要全面测试?
满足其中一个或多个标准的特性不需要测试，项目就会被认为“完成”，因为它们并不代表会影响用户的重大生产故障风险。
通过结合这两个方面——确定关键的测试并将它们添加到冲刺计划中，并从冲刺计划中删除不必要的测试——你可以达到你的最佳状态。准确定义需要做的工作，以确保足够的质量水平。
使用质量数据可视化来实现完成的完美定义
质量数据可视化软件是一种新的工具类别，它可以帮助您调整质量工作，以达到完美平衡的“完成”定义。质量平台可以:
收集质量数据——确定所有测试级别(单元测试、UI测试、集成测试和端到端测试)的测试涵盖了哪些功能，以及哪些功能在生产中使用最多。
识别质量风险——聚合来自所有测试框架的数据，并建议在哪里添加对质量影响最大的测试。
识别浪费的测试——推荐多余的、不需要包含在完成定义中的测试活动，因为它涵盖了最近没有更改或没有被积极使用的特性。
学会了定义合适的完成标准，就不用担心无法达成交付目标啦。
