> Scrum Sprint演示:综合指南
关键要点: Sprint Demo展示完成的Sprint工作,允许产品所有者根据接受标准进行验证。 它阐明了完成的工作,改进估计并告知团队的速度。重点是可证明的价值,而不是技术细节或问题(这些细节属于回顾)。 然后,根据可持续时间表将公认的功能集成(释放)。
>
(本节基于的新手:戴维·格林(M. David Green)。
在Sprint的结论上举行的Sprint演示是至关重要的仪式。开发团队展示了完成的工作,而产品主则根据接受标准,接受或拒绝每个故事评估完成。 这提供了冲刺进展并完善未来估计的清晰图片。
Sprint演示目标:
>主要目标是了解Sprint的输出和产品的更新状态后整合。 公认的故事决定了团队的速度,改善了未来的冲刺积压估计。
Sprint演示的客人:
>欢迎客人观察员,但他们的存在不应破坏演示的目标或时机。 他们是观察者,而不是参与者,除非有积极征求反馈。
>
定时箱Sprint演示:
时间分配取决于完整故事的数量和复杂性。 为期两周的冲刺很常见半天。 Scrum Master确保遵守分配的时间。
结合演示和回顾性:
>通常,团队在同一天安排回顾性,以最大程度地减少生产力中断。 但是,这优先考虑Scrum伪像,而不是有形产品开发 - 需要仔细考虑。
准备Sprint演示:
演示展示了所有“完成”故事,无论发行状态如何。 每个贡献的团队成员都应准备解释他们的工作。 与产品所有者进行的事前会议确保与接受标准保持一致,并为示威做准备。 Scrum Master协调准备并确保演示适合时间表中的演示。
>
>产品所有者驱动的演示:
虽然工程师可以呈现,但让产品所有者进行实时测试是有益的。 工程师知道“快乐的道路”,但是产品主确定了边缘案例并确定了接受标准,确保了全面的测试和利益相关者的参与。
演示一个故事:
Scrum Master指导过程,系统地检查每个故事。 在设置演示时,产品所有者会阅读故事和接受标准,以确保每个人都了解期望。 该演示重点介绍了产品的功能添加,展示了每个接受标准的实现。 演示期间确定的接受标准不足会导致未来冲刺的新故事。
避免对问题进行详细讨论:
虽然有价值,详细的关于发展挑战的讨论应推迟到回顾展。 专注于产品可以防止演示在技术细节上陷入困境。
> talling点和速度:
Scrum Master根据分配给公认故事的点来计算Sprint的速度。 跟踪拒绝或不完整的故事并更新其状态。 总结Sprint进度的报告经常会产生。
>
释放故事:
>释放将完整的功能集成到实时产品中。 释放方法各不相同;一些团队立即发布,而另一些团队则将大型版本的故事分组。 连续集成支持立即发布,消除了demo后发布步骤。
连续集成:
>连续整合,工程师在发布并进行了测试之前不应放弃故事。 这可能需要专门维护和改进的时间。
>
>发布调度:
发布时间表应与团队的可持续步伐和产品所有者的目标,而不是任意截止日期保持一致。 避免急于以牺牲质量为代价的截止日期; 如有必要,请确定关键功能。
常见问题(常见问题解答)
(为简洁而省略了FAQ部分,因为它在很大程度上重复了主要文本中已经涵盖的信息。)
以上是Scrum仪式:Sprint演示的详细内容。更多信息请关注PHP中文网其他相关文章!