敏捷如何应对变化：敏捷团队检查和适应

在任何项目开始时创建的计划都不能保证会发生什么。事实上，这只是一个时间点的猜测。很多事情会合谋使计划失效，项目人员可能来或去，技术会比预期更好或更糟，用户会改变主意，竞争对手可能会迫使我们做出不同或更快的反应，等等。敏捷团队认为每一个这样的变化都会带来机会，并且需要更新计划以更好地反映当前情况的现实。

在每一个新的迭代开始时，一个敏捷团队整合在前面的迭代中获得的所有新知识，并相应地进行调整。如果一个团队学到了一些可能影响计划准确性或价值的东西，他们就会调整计划。计划的准确性可能会受到团队发现他们过度或低估了进展速度的影响。或者他们会发现，某种类型的工作比以前想象的要耗费更多的时间。

计划的价值可能会因产品所有者对潜在用户的需求所获得的知识而改变。也许，根据从早期迭代中看到软件的反馈，产品所有者已经了解到，用户希望看到更多的一种特性，并且他们没有像以前想象的那样重视另一种特性。在这种情况下，计划的价值可以通过将更多所需的特性移动到发布中来增加，而牺牲了一些价值较低的特性。

通过在Scrum中检查和采用来处理需求的变化

也许Scrum和Agile最重要的因素是对沟通，开放和透明的热情。这些因素是我们在日常工作中使用敏捷和Scrum实践所做的一切的基础; 这就是为什么我们重视合同谈判中的客户协作以及为什么我们不害怕回应变化，因为我们知道反馈非常重要。

敏捷方法只要求我们从错误中吸取教训和/或找出改进的新方法。作为敏捷宣言的原则之一：

“团队定期反思如何变得更有效，然后相应地调整和调整其行为。”

正是通过这种开放式沟通的呼吁，Scrum鼓励我们在Sprint期间举办五项重要活动，旨在帮助我们高效，紧密地合作，以及提高我们的知识，并在未来变得更加有效。

这五个事件是：

• Sprint计划 (Sprint Planning)
• 每日Scrum (Daily Scrum)
• Sprint评论 (Sprint Review)
• Sprint回顾 (Sprint Retrospective)
• 冲刺 (Sprint)

下面的摘要显示了在各种Scrum事件中的检查和调整。

所有这些对于他们自己的权利至关重要，正因为如此，我将在这里简要地研究每一个。

Sprint计划 (Sprint Planning)

这是启动每个Sprint的事件，也是产品负责人和开发团队讨论哪些产品待办事项项目（PBI）将包含在Sprint中的地方。虽然产品负责人有权优先考虑每个PBI以确定是否可能包含在Sprint中，但我们鼓励开发团队在必要时做出回应，提出问题并进行回击。然后，开发团队预测他们可以在Sprint中提供多少PBI，因为他们了解速度，资源以及可能影响其可用时间和资源的任何因素。

Sprint计划会议的结果是获得Sprint目标和Sprint Backlog，每个人都同意这是现实和可实现的。

每日Scrum (Daily Scrum)

Scrum寻求有效利用您的时间和资源，Daily Scrum活动也不例外。每日Scrum的时间限制为15分钟。站起来不是强制性的。然而，许多团队认为这是一种有用的技术，可以使会议保持简短和重要。

每日Scrum为开发团队提供了一个机会，可以检查，评估实现Sprint目标的进度，并在接下来的24小时内审核和规划他们的活动。

Sprint评论 (Sprint Review)

从敏捷宣言再次看上述原则 - “定期，团队反思如何变得更有效，然后相应地调整和调整其行为。”_这一原则本身就总结了我们接下来两次会议背后的原因，Sprint回顾和Sprint回顾。

这两项活动都在Sprint结束时举行。敏捷方法的目标不是第一次让所有东西“完美”，而是持续改进。这些事件有助于实现这一目标。

Sprint评审通常在Sprint的最后一天进行，让您有机会向利益相关者（客户，管理层以及任何其他被认为相关和感兴趣的人）展示“完成”增量。除了展示Sprint期间产生的工作特征外，您还可以获得有用的反馈，这些反馈可以包含在产品Backlog中，可以帮助指导未来冲刺的工作。

Sprint回顾 (Sprint Retrospective)

Sprint的最后一次会议是Sprint Retrospective。这是Scrum团队审查未来Sprint可以改进的内容以及他们应该如何做的事情。Scrum的精神要求无论Scrum团队有多好，总会有机会改进，Sprint Retrospective给团队一个专门的时间来识别，讨论和计划。整个Scrum团队应该参与其中，包括开发团队，Scrum Master和产品负责人。会议应该是一个协作努力，就像整个Scrum和敏捷过程一样。