Scrum仪式：冲刺计划

Scrum Sprint计划：深度潜水

每个冲刺的基石Sprint Planning为即将到来的迭代设定了舞台。 产品所有者，Scrum Master和Development团队之间的合作努力定义了Sprint的目标以及实现这些目标所需的工作。

核心目标：

为冲刺建立明确的议程。产品所有者提出了优先考虑的用户故事，并将其与产品愿景保持一致。然后，团队估算涉及的努力，并承诺根据其过去的表现（速度）完成一系列现实的故事。结果？ 一个相互同意的Sprint Backlog。

（本节是M. David Green的“ Scrum：Scrum：Navice to Ninja”的摘录。

Scrum主有助于促进，但是产品主驱动了Sprint计划的内容。

时间分配：持续时间是灵活的，具体取决于冲刺的长度（例如，为期两周的冲刺3-4小时，可能是一整天的时间）。 彻底的计划是有效沟通和对可交付成果的共同理解的关键。 熟练的Scrum大师确保过程保持专注，并在分配的时间内。

准备：

>产品所有者准备了精致的产品积压，与利益相关者合作，以确保故事清晰，明确和优先级。 每个故事都包含明确完成的接受标准。> >

介绍故事：产品主介绍了准备好的故事，促进了公开讨论并允许团队质疑可行性和完整性。 这项协作审查确保对准并积极应对潜在的挑战。

技术考虑：团队积极参与，引起了对技术债务，重构需求或基础设施升级的担忧。 当产品主设定优先级时，团队保留拒绝定义不当或在技术上不可行的授权。

>

故事估计：团队使用所选方法（例如，点，T恤尺寸）来估算每个故事的相对精力。 这是相对的，而不是时间估计，重点是基于过去经验的比较努力。 所选估​​计系统中的一致性对于跟踪速度至关重要。

团队共识：

关于故事估计的协议是必不可少的，促进透明度和共同的理解。 每个团队成员都应该理解所涉及的努力，即使不直接在故事上进行工作。>

处理错误： bugs（已完成或接受的故事中错过要求），但不会收到点。 他们的分辨率会影响速度，但并未将其纳入点估计。 没有分配错误的错误修复能力。>

任务与故事：任务（代码维护，基础架构改进）至关重要，但由于无法直接提供用户价值而没有收到点。 与产品所有者进行谈判确保优先考虑这些重要任务。

尖峰：不确定的技术挑战可能需要尖峰（研究任务）。 这些定义了接受标准和时间限制以防止资源流失。

致力于Sprint积压：团队合作根据他们的速度和故事估计来创建Sprint积压。 尽管产品所有者在内容和秩序上具有最终权限，但团队可以主张调整以优化工作流程并保持连续性。 在开始冲刺之前，最终协议至关重要。

最终结果：共享的冲刺积压，明确的冲刺目标以及在Sprint时间范围内交付优先故事的集体承诺。 每个人都了解他们的责任和前进的道路。>

常见问题（常见问题解答）：

> Sprint计划的目标

>

定义可交付成果和Sp​​rint的工作计划。

会议持续时间：
• 根据冲刺长度而变化（例如，为期2周的Sprint 4小时）。
Scrum Master的角色：促进，确保遵守Scrum原则。
• > Sprint目标确定：基于选定的积压项目和团队能力的协作决策。
• 不完整的任务：返回产品积压;回顾解决根本原因。
• 团队容量：由团队规模，可用性和历史表现确定。
• 冲刺目标更改：在冲刺期间不应改变；如果情况发生巨大变化，则取消是一种选择。>
• 产品主的角色：澄清积压项目，验收标准并在任务选择方面进行合作。
• 会议成果： Sprint目标，选定的积压项目和交付计划（Sprint Backlog）。
• 会议频率：在每个Sprint的开始时。>
• 这种详细的解释提供了对Scrum Sprint计划的全面理解，强调协作，透明度和承诺。

以上是Scrum仪式：冲刺计划的详细内容。更多信息请关注PHP中文网其他相关文章！