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计划的目标
> 定义可交付成果和Sprint的工作计划。
会议持续时间:- 根据冲刺长度而变化(例如,为期2周的Sprint 4小时)。
Scrum Master的角色:促进,确保遵守Scrum原则。
-
> Sprint目标确定:基于选定的积压项目和团队能力的协作决策。
-
不完整的任务:返回产品积压;回顾解决根本原因。
- 团队容量:由团队规模,可用性和历史表现确定。
- 冲刺目标更改:在冲刺期间不应改变;如果情况发生巨大变化,则取消是一种选择。>
- 产品主的角色:澄清积压项目,验收标准并在任务选择方面进行合作。
- 会议成果: Sprint目标,选定的积压项目和交付计划(Sprint Backlog)。
- 会议频率:在每个Sprint的开始时。>
- 这种详细的解释提供了对Scrum Sprint计划的全面理解,强调协作,透明度和承诺。
以上是Scrum仪式:冲刺计划的详细内容。更多信息请关注PHP中文网其他相关文章!