Scrum中的就绪定义——它是什么以及为何重要

最终用户有时会提出新的功能想法或概念。这一概念将被表示为一个或多个史诗，并由产品负责人添加到产品待办事项列表。团队将共同确定如何将这一概念转化为一个或多个史诗，然后细化为更小、更清晰的用户故事——作为实际的产品功能——这些内容将包含在下一个冲刺的实施中。

产品负责人可以与团队共同定义一个名为“就绪定义”的工件，以确保待办事项列表顶部的项目已准备好进入冲刺，从而使开发团队能够自信地承诺并在冲刺结束前完成这些工作。

为何需要就绪定义？

就绪定义（DoR）是一组公认的准则，用于告知所有人某项工作何时已准备好启动——例如，当一个用户故事已准备好进入冲刺，或团队已满足所有必要条件可以开始冲刺时。一个明确的就绪定义能显著提高Scrum团队成功实现其冲刺目标的可能性。以下是结构良好的就绪定义能为团队带来的好处：

• 衡量待办事项列表中各项的“就绪”状态
• 确保待办事项被认为“已足够就绪”
• 帮助团队识别产品负责人或其他成员是否已超负荷
• 促进团队成员之间的相互责任
• 减少团队在故事真正“就绪”前就承诺估算的压力
• 减少开发过程中的需求漂移

示例——冲刺的就绪定义

不同团队可能对就绪有不同的定义——有些团队需要的条件更少。例如，有些团队只需描述对用户的价值、对项目的优先级排序，并写下如何展示它。估算和沟通发生在冲刺计划会议期间。在制定团队的就绪定义时，可考虑以下一些示例项目：

• 冲刺待办事项列表已排序冲刺待办事项列表已排序
• 冲刺待办事项列表包含团队承诺的所有缺陷、用户故事及其他工作
• 无隐藏工作
• 所有团队成员均已计算出自己的冲刺容量
• 项目全职 = 每天X小时
• 所有用户故事都符合就绪标准

示例 – 用户故事的就绪标准

本节展示了一个用户故事就绪标准的示例，以及一个冲刺就绪的示例。您可以将其作为基线或起点进行采纳：

• 该故事明确说明了对用户的价值。
• 该故事的验收标准已明确界定。
• 已识别用户故事的依赖关系。
• 交付团队已接受该用户故事。
• 该 Scrum团队接受用户体验相关成果。
• 性能标准已适当定义。
• 已明确由谁来接受该用户故事。
• 团队知道如何演示该故事。

总结

“就绪标准”这一术语在Scrum指南中并未提及，与其中嵌入的用户故事和验收标准不同。也许您可以将就绪标准视为待办事项列表细化活动的一部分，而不是将其作为顺序或阶段门检查清单。待办事项列表细化是一个持续的过程，因此不限于单一事件——它是一项活动。