组织实现的实际敏捷性取决于如何使用复杂的Scrum。 除了仅采用Scrum之外，如果组织重新围绕Scrum重组其结构，则企业敏捷性将大大提高。 通过重新验证，我提醒人们，通常在重新构想Scrum时，需要重新构想结构，而不是预测或复制结构。

通过Scrum，团队和组织可以创建，交付，维护和发展出色的产品和服务。 通过Scrum，团队和组织创造了不迟于每个Sprint结束发布产品版本的机会，Sprint花费的时间不超过4周，并且通常更少。 这为组织提供了基本的敏捷性，在市场上market壮成长的潜力，同时创造了激励性的工作环境。

到Sprint结束时产品增量的状态在Scrum中称为“完成”。

为了使每个人都了解“完成”的含义，团队对“完成”进行了定义 。 “完成”的定义对完成工作意味着什么有着共同的理解，并确保工作完整性的透明度。

在几个时间点上，这提供了至关重要的清晰度：

• 在预测工作时认为对Sprint可行。
• 评估产品积压项目和产品增量的工作是否完成。
• 整个Sprint的开发进度。
• 考虑增量中提供的产品功能的机会价值时（不必将检查变成质量询问）。

理想情况下， 专业组织定义要纳入产品的质量要求 。 无论如何，Scrum专业人员都遵循“完成”的适当定义。 总是。 增量工作不包含任何未完成的工作。 没有未完成的工作投入生产。 曾经 同时，敬业的专业团队不断寻求改善产品质量的方法，这体现在“完成”的定义中。

世界各地的许多团队似乎无法创建实际上可发布的产品增量。 在团队中输入了代码，并可能对其进行了测试。 但是实际的增量仍然分散并隐藏在长期存在的分支中。 或者，在Sprint结束时交付的工作仍需要与其他产品团队集成。 或者，甚至更糟的是，将其运送到不同的部门。 在这些情况下，Scrum会揭示有关关键组织障碍的重要信息，这些障碍会阻止团队创建实际发布的产品版本。 从未完成的工作到完成的增量需要大量的“未完成时间”。 这一次阻碍了组织迫切需要的敏捷性。 它杀死了机会释放的选择。

在Scrum中进行Sprint的目的不仅仅是为了完成一件可以交付给另一个团队，职能部门或部门的工作。 预期增量处于可用状态，可以投入生产。 释放后，没有任何损坏。 系统中没有不可预测的大量工作积累，等待在某个未知的时间点进行处理，同时破坏了每个人对进度和质量的理解。 实际的发布决策取决于产品的实用性，这取决于产品所有者，开发团队的用户和利益相关者的唯一代表。

至少在团队和系统之间集成了一个增量，以使其处于可生产部署状态。 大多数情况下，团队将要执行的所有开发活动（通常需要进行大量测试）定义为“完成”，以将增量视为“可发布”。

想象一下任何非软件行业。 您能想象要使用的机器，工具和实践来表达“质量”吗？ 这不是创造质量的“方法”，而是质量的定义吗？

质量是通过产品的特性定义的。

质量是产品应展示的品质。 Scrum中的“完成”产品不仅仅是应用了严格正确的开发标准的产品，因此可以发布。 “完成”产品是展示您组织对产品质量的定义的产品。

正如我在《 Scrum –一个袖珍指南 》（2013） 一书中已经指出的那样， 宝贵的增量是Scrum的核心。

将平衡转移到创造有价值的增量上，就是真正地制定了Scrum，并遵循最高敏捷原则：

• 敏捷宣言 ：我们的首要任务是通过尽早并持续交付有价值的软件来满足客户（ 我的粗体表示 ）。
• Scrum指南 ：一个框架，人们可以在其中解决复杂的适应性问题，同时以富有创造力的方式交付可能价值最高的产品 （ 我的粗体表示 ）。

那么，您是否有“完成”的定义？ 如果是这样，您将其定义为“完成”？ 是“可释放”还是“有价值”？ 您创造的每一个增量都有价值吗？ 为什么不？ 您的Scrum Master知道吗？ 您的管理？ 那你在做什么呢？

翻译自: https://www.javacodegeeks.com/2017/06/what-are-you-defining-as-done.html