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

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

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

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

经过在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和敏捷过程同样。

冲刺 (Sprint)

Sprint自己就是一个事件，它包含全部工做以及在开箱时间内发生的全部其余事件。

更多推荐的 scrum 文章

• Scrum的基本功 - 集合中英文版本 (Scrum事件)
• Scrum的基本功 - 集合中英文版本 (Scrum工件)
• Scrum的基本功 - 集合中英文版本 (角色和责任篇)
• Scrum的基本功 - 集合中英文版本 (基础篇)

---

1. 它为客户提供了一个在开发周期早期看到软件的机会，并提供反馈和输入，以便可以快速、轻松地进行更正。
2. 工做软件是一个很好的进度度量。从实际完成、测试和交付到用户满意程度的增量软件功能方面衡量进展要准确和有效得多，而不是试图衡量未完成的大型开发项目的完成百分比。