所以你有了 积压订单, 估计您的积压, 阐明您的要求, 计划了您的冲刺 和 创建了一个协作工作区.
您’ve 冲刺以实现您的冲刺目标, 举行每日站立会议 和 通过每日燃尽图跟踪进度.
现在轮到你’已经到了Sprint的末尾， 当你说你会完成. 所有的’现在要做的是“查看，反映和重复”…
冲刺回顾
在Sprint结束时，举行Sprint评论 会议。邀请整个团队。邀请所有关键业务利益相关者。在适当情况下邀请高级利益相关者，包括高管。各方越感兴趣越好！
查看Sprint中交付的内容。演示软件。无论’发行前的完整，可运行的软件，或长期运行的多Sprint项目中的未完成项目，以演示Sprint中已完成的工作。让团队成员演示他们工作的领域。
冲刺审查的目的 是三方面的：
- 它允许团队成员 展示他们’已经取得并展示了他们的贡献 产品。
- 它使所有关键利益相关者都能看到’已经完成，并提供了有价值的反馈 在那里定期’尚需时日。
- 这有助于团队专注于Sprint的截止日期 –没有人愿意出现在Sprint评论上，而没有任何有用的演示。
冲刺回顾展
在Sprint审查之后，举行Sprint回顾展 会议。邀请整个团队。邀请产品负责人。但是这次会议不适合更广泛的利益相关者。通常，它可能会立即从Sprint审核中继续进行。
Sprint回顾展的目的是反思事情的发展 在冲刺期间。它’团队有机会讨论Sprint并考虑如何改进。
团队应共同：
- 查看最终的燃尽图。怎么样了团队在Sprint开始时是否履行了他们的承诺？注意电子表格中的未完成时间，因此团队’可以将成功率随时间绘制在图表上，以查看是否成功’越来越好。这是团队评估进度的工具。它’不适合管理。
- 审核团队’s Velocity? 速度是指原始产品积压订单中Sprint中* completed *项所估计的点数。团队软件中只有100％完成并已签收的项目’速度。再次将其绘制在图形上，以便团队’可以随时间跟踪速度，因此团队可以查看是否’随着时间的流逝，交付的内容或多或少。速度将逐渐遵循规范，然后可以在Sprint计划中用作衡量团队根据其实际记录可以实际实现的目标的量度。
- 讨论进展顺利？ （尝试确保’下次重复）
- 讨论什么会变得更好？ （尝试了解原因）
- 确定团队在下一个Sprint中将做些什么？ （尝试选择一些可行的点，这些点实际上可以在下一个Sprint中立即完成）
这是一个持续的学习过程。
传统的项目管理方法，例如PRINCE2，也通过编写有关项目结束的经验教训报告来鼓励持续学习。
麻烦的是人们不要’在一个漫长的项目结束时，一定要记得足够多。也许在大型项目结束时有太多需要反思的地方，以至于有太多事情要考虑，而结果仅仅是’不可行。通常在完成传统项目后，项目团队就会分散 转移到其他项目或返回他们来自何处，从而阻止他们将学习成果作为一个团队来应用。
在Scrum敏捷开发中，就像产品开发本身一样，学习是一小块，一小块的。很少，但经常。尽管反馈还有时间对项目产生积极影响。
重复
该团队现在掌握了有价值的信息–有关产品，其性能以及其环境中的某些障碍的信息，例如：
- 该软件如何处理最后的Sprint。
- 到目前为止，有关该产品的反馈意见。
- 团队能够在多大程度上实现Sprint计划中的承诺。
- 团队’速度和典型迭代中可以实现的速度。
- 一切顺利。
- 什么没’t go so well.
- 今后将做些不同的事情。
所有的’团队现在要做的就是重复此过程，并从上面获得更多的知识。
实际上，团队需要3或4个Sprint才能进入节奏。应用改进并习惯该过程。为了使速度稳定于规范。并为团队凝聚 …
那’s all folks!
以便’s it! 那’基本的Scrum，以及如何以10个简单的步骤实现它。
当然，实际上，步骤不是’没那么容易。这些步骤涉及人类。和软件开发。棘手的组合！
但是，Scrum过程本质上很容易。并根据您的情况–当然以我的经验–Scrum和敏捷开发可以帮助您提高成功率 在许多方面。
凯莉
也可以看看：
如何通过10个简单步骤实施Scrum:
– 步骤1：按顺序整理您的待办事项！
– 步骤2：如何估算您的产品积压
– 步骤3：Sprint计划/明确要求
– 步骤4：Sprint计划/估算任务
– 步骤5：创建协作式工作区
– 步骤＃6：冲刺！
– 步骤＃7：站起来，算数！
– 步骤＃8：使用每日燃尽图跟踪进度
– 第9步：完成您说的话
– 步骤10：查看，反映，重复…
