为什么要在敏捷项目中使用已完成的定义？

如果你想学习弹钢琴，当按下琴键 30 分钟后才能听到声音，这将是一项艰巨的任务。
当你在最后期限前演示你的软件时，你肯定项目不会提前完成。当你每周都进行演示，并且实施是根据产品所有者的优先级进行的，那么很有可能产品所有者即使在所有请求的功能都未实现之前就会批准该应用程序。

反馈将帮助你更有效地改进、学习并实现目标。
重要的是，你需要快速且频繁地获得反馈，迭代开发可以促进这一点。
你实际获得反馈的内容在已完成的定义中定义。已完成的定义定义了在冲刺结束时交付最高质量的已完成增量所需的所有步骤。
你在冲刺中做得越多，获得的反馈就越多，你就能改进和学习得越多。

                           

这引出了使用已完成的定义的原因：

反馈和改进的定义。

当已完成的定义完整时，它将定义交付已完成增量的所有步骤，因此会产生关于产品以及冲刺内流程的反馈。
通过冲刺演示、性能测试、验收测试等步骤，会产生关于产品的反馈。当产品所有者在演示过程中试用应用程序时，他会给出他的反馈。验收测试会持续生成关于验收标准的反馈，特别是当所有标准都使用 SpecFlow 或任何其他示例驱动开发框架实现时。
通过同行评审和部署等步骤，会产生关于流程的反馈；部署流程是否正确，我们是否按照我们想要的方式进行编码等？
已完成的定义中定义的步骤越多，你获得的反馈就越多。

改进发布计划。

使用已完成的定义的第二个原因是它改进了发布计划。
通常在冲刺结束时，仍然有不同的项目未完成。
代码中仍存在一些错误，集成测试尚未完成，在类似生产的环境中尚未进行性能测试，手册尚未更新等。所有这些工作都被称为未完成的工作，必须在某个时候完成。这些未完成的工作的问题在于它们每个冲刺都会堆积起来；每个添加的功能都会导致这些未完成的工作增长。

 

在敏捷项目发布计划会议中，会根据用户故事点和吞吐量来计划发布。例如，如果团队的吞吐量为 6，需要实现 22 个用户故事点，则发布日期可能在 4 个冲刺之后。

 

问题是，4 个冲刺后，这些未完成的工作仍然存在。许多团队通过引入所谓的“稳定冲刺”或“发布冲刺”来解决这个问题。这些冲刺用于创建部署包，解决一些最后的错误，进行一些最后的测试等；一切都是为了使软件为生产做好准备。

 

这些发布冲刺的问题在于它们是糟糕的敏捷实践。你试图对未知的工作（最后一分钟的测试可能会暴露出各种错误）、未计划、未估算的工作进行时间盒限制，但仍然真的需要在固定的时间内完成所有工作，并在发布日期之前完成。

此外，你的发布日期与发布计划不符。不再基于发布计划中定义的冲刺来计划发布，而是基于“计划”的冲刺加上一个或多个额外的发布冲刺。
当团队定义并应用完整的已完成的定义时，所有未完成的工作都在冲刺中完成，不再需要发布冲刺。

使燃尽图有意义。

应用完整或理想的已完成的定义也使燃尽图有意义。
燃尽图显示了随时间推移仍待完成的工作量，由绿线表示。

 

大多数团队都能看到这个燃尽图，但在软件已为生产就绪时，它会提供“虚假”的指示。当未充分应用已完成的定义时，未完成的工作会每冲刺堆积一次，由橙线表示，这条线大多数时候在常规燃尽图上不可见。

 

由“理想”燃尽线和未完成工作线组成的黑线代表了真实的燃尽图，但大多数时候不显示，产品所有者会在 4 个冲刺后才发现仍有工作未完成，即使燃尽图显示不同。
如果没有使用发布冲刺，黑线和绿线之间的差值将显示延迟的风险。如果在冲刺中不拾取这些工作，它将在生产中显现；例如，如果在冲刺中未进行性能测试，那么将来在生产中可能会出现性能方面的问题。

几乎完成不等于完成。

大多数开发人员都会认识到一个典型对话如下：
产品所有者 (PO)：软件完成了吗？
开发人员 (Dev)：是的，差不多了。
PO：我们可以上线生产吗？
Dev：还没呢。
PO：为什么不行？
Dev：嗯，还有一些错误要解决，还有一些集成测试要做，还需要更新发布包等等。
PO：什么时候能上线生产？
Dev：我不知道……

为了避免这类讨论，应该对“已完成的软件”有共同的理解。已完成的定义将提高团队在每个冲刺中所做的工作以及交付内容的透明度。例如，如果已完成的定义中没有关于生产类环境的性能测试的内容，因为组织无法在每个冲刺中完成这项工作，那么产品所有者就会意识到这一点。

已完成的定义最小化了风险的延迟。

当已完成的定义包含了交付最高质量增量所需的所有步骤时，你就最小化了风险的延迟。已完成的定义中的所有步骤都经过反馈的检验，因此风险项在早期阶段尽可能多地被检查、适应和改进。换句话说，风险在项目非常早期就被多次覆盖。
已完成的定义越小，每个冲刺后可能堆积的未完成工作就越多。这些未完成的工作不受反馈的约束，但会在生产中的某个时间点显现出来。
完整的已完成的定义将最小化这些未完成的工作，从而最小化风险的延迟。

已完成的定义代表了团队的敏捷性/质量/成熟度。

团队能够在一次冲刺中完成（新的）功能，并立即发布到生产环境，其中包括已完成的定义中为保证最高质量所需的所有步骤。
团队的敏捷性在于它可以在每个冲刺发布功能到生产环境，但是
团队的质量体现在发布此功能到生产环境时所应用的已完成的定义中的步骤数量。

如何将已完成的定义付诸实践。

首先定义已完成定义的两个版本：一个理想的已完成定义和一个当前的已完成定义。
需要两个版本的原因可能是能力和成熟度。
能力，因为不是每个团队都能在一次冲刺中完成所有工作以交付生产就绪的产品，尤其是在项目初期。
要在一次冲刺中交付已完成的增量，你需要自动化已完成定义中的许多步骤，例如自动化构建过程、自动化测试、自动化部署，也许还有自动化文档等。这可能非常复杂且耗时。

成熟度。

成熟度是已完成的定义可能尚未理想化的另一个原因，一些团队还没有准备好想在一次冲刺中做所有事情。他们认为只在冲刺结束时进行回归测试，或者在上线生产前更新手册是更好的，因为他们觉得没有必要或每冲刺做这些会花费太多时间。这些团队还没有敏捷思维。

理想的已完成定义定义了从开发到生产部署的已完成增量所需的所有步骤。不再需要其他工作。
当前的已完成定义定义了团队当前能够在一次冲刺中完成的步骤。
最好将两者都放在墙上，以便产品所有者清楚团队在冲刺中交付的内容，并建立对“已完成”的共同理解。
重要的是要理解，如果团队没有使用理想的已完成定义，产品所有者也负有责任。
他可以决定每冲刺不需要进行性能测试，因为在快得多的生产服务器上从未出现过问题，而且由于团队尚未自动化性能测试，因此每冲刺进行此项测试需要花费太多时间。通过此决定，产品所有者会故意延迟出现生产性能问题的（潜在）风险。
如果产品所有者希望在当前已完成的定义中增加更多步骤，例如自动化验收测试；他应该优先创建一个促进这些测试自动化的框架。
这可以通过在产品积压工作中为包含此框架的工作项赋予更高的优先级来完成。
因此，将两个版本放在墙上将为产品所有者创造透明度，代表团队当前的能力，并展示你可以改进的地方。

尝试定期将当前的已完成定义扩展到理想的已完成定义中的步骤。
扩展已完成的定义实际上意味着在质量/成熟度方面成长。

结论

一个好的已完成定义将有助于
获取反馈并改进你的产品和流程
更好的发布计划
使燃尽图有意义
最小化风险的延迟
提高团队质量/敏捷性
为利益相关者创造透明度