Scrum中用到了几个规定的事件，即Scrum中的常规会议。Scrum框架使会议的需求做到最小化，以保证团队有更多的时间开发需求。所有的事件在固定的时间发生，这意味着每个事件的持续时间不应超过预先设定的最大值。当Sprint开始之后，Sprint的长度就固定下来了，不允许延长或缩短。在进行某个事件时，如果会议目标已经达到了就可以结束，即使花费的时间没有原计划那么长，这样可以避免不必要的时间浪费。
所有事件都包含在Sprint中，Scrum中的每个事件都是团队检查和调整的机会。设计这些活动的目的在于实现关键的透明度和自检。遗漏其中任何一项事件都可能导致透明度的降低，失去一个自检和完善团队的机会。
Sprint
Scrum的核心就是Sprint，它的时间期限是1个月或更短，在此时间期限内创建“完成”，即可用的、潜在的、可交付的产品增量。最好所有的Sprint的时长保持一致，并且在一个Sprint结束之后立即开始新的Sprint。
Sprint包含Sprint计划、每日站会、开发工作、Sprint评审会、Sprint回顾会。
每个Sprint均可被视为不超过一个月的项目。同项目一样，每个Sprint要完成一定的功能。在每个Sprint中，都会定义创建的内容、设计的内容和计划。计划用来指导开发工作，并保证交付期望中的产品。
Sprint目标
Sprint目标是一系列的目标集合，达到目标集合通过产品待办清单中的事项来实现。完成产品待办清单事项，就意味着目标已实现。它为开发团队提供引导，解释为什么要构建这些功能需求。这些功能需求是在Sprint计划会议上创建的。开发团队在实现功能需求时，Sprint目标为他们提供能了一定的灵活性。产品清单中的事项给产品提供的一系列相关的功能，可以把它们定为Sprint目标。当然，Sprint目标也可以是任何相关的功能。在开发这些功能时，开发团队应该作为一个整体共同开发，而不是每个团队成员独自作战。
在开发过程中，开发团队应该时刻把Sprint目标铭记于心。所有实现的功能和技术，都是围绕Sprint目标进行的。如果工作与开发团队的期望不一致，他们应该与产品负责人一起沟通，讨论当前Sprint中的Sprint待办清单是否应该调整。
Sprint计划会议
在Sprint计划会议中，团队一起计划在当前Sprint中要做的工作。注意，计划工作由团队全体人员共同协作完成。
Sprint计划会议是限时的，对于一个月时长的Sprint而言，Sprint计划会议不宜超过8小时。对于周期更短的Sprint，其对应的Sprint计划会议时间也更短。敏捷教练必须确保会议按时举行，确保每个人理解会议的目的。同时，敏捷教练有义务引导整个团队遵守时间规则。
Sprint计划会议回答如下内容：
-
在接下来的Sprint中，我们可以交付哪些增量？
-
我们应该怎样工作以保证完成需要求交付的增量？
Sprint计划会议中，开发团队致力于计划Sprint内即将开发的功能。产品负责人讨论Sprint的目标和产品待办事项。当Sprint中的所有待办事项完成了，目标就实现了。整个Scrum团队在理解Sprint的工作方面进行合作。
在Sprint计划结束的时候，开发团队应该能向产品负责人和敏捷教练清晰地解释：作为一个自组织的团队，他们将如何完成Sprint目标并创建预期的增量。
图8 Sprint计划会议
每日站会
每日站会是一个15分钟的短会。在站会上，开发团队同步自己的活动，并计划接下来的24小时做什么。向整个团队汇报：自上次站会以来，做了哪些工作，以及在接下来的24小时（下一次每日站会之前）做哪些工作。为了避免不必要的误会，每日站会应该在每天相同的时间、相同的地点进行。
每个成员向团队展示自己的工作，团队审视开发进展是否是朝着Sprint目标发展，审视完成Sprint待办事项的进度如何。每日站会可以促使开发团队朝着Sprint目标的方向前进。开发团队应该思考，作为自组织的团队，他们应该怎样相互协作以完成Sprint目标，为Sprint创建预期的工作增量。对此，开发团队（或团队成员）往往会在每日站会之后展开详细的讨论，或重新讨论后续的工作计划。
敏捷教练确保团队成员参加每日站会，但开展每日站会的责任在于开发团队，而不是敏捷教练。
每日站会促进大家的沟通交流，消除一些不必要的会议，识别并移除障碍，突出并促进快速决策，并提高团队的知识水平。这是一次关键的审视和适应会议。
Sprint评审会议
开发团队在每个Sprint至少交付一次产品的新功能。这里，我们用到“至少”意味着有可能一个迭代交付两次新功能。而Sprint结束时的评审会议的目的是评审发布的功能是否是需要的产品清单。在Sprint评审中，Scrum团队与干系人一起沟通，详细阐述当前Sprint完成的功能。讨论当前迭代对产品做了哪些改动，在下个Sprint可能有哪些改进空间。这并不是一个正式的会议，也不是一个汇报会，不是功能发布前的一道关卡。
如果一个Sprint的时间是1个月，建议Sprint评审会议的时间为4个小时。如果Sprint周期没那么长，那么评审会议的时间应该随之变短。敏捷教练要确保会议正常进行，并确保每位与会者理解会议的宗旨。同时，敏捷教练在会议中做好时间管理，保证会议按时完成。
Sprint评审的结果是修正后续的产品清单，并定义下个Sprint的潜在产品清单事项。产品清单可能整体做调整，以适应新的机会。
图9 Sprint评审会议
Sprint回顾会议
Sprint回顾会议给整个Scrum团队审视自身的机会，并创建改进计划，在下一个Sprint实施。
Sprint回顾会在Sprint评审会之后、下一个Sprint的计划会议之前召开。对于周期为1个月的Sprint，回顾会议的时间通常为3个小时。与评审会议类似，如果Sprint的周期更短，回顾会议也应该更短。敏捷教练负责组织会议，让所有与会者理解会议的目的，并做好时间管理，确保会议按时完成。在回顾会议中，敏捷教练对敏捷流程负责，同时他也是会议中的一个团队成员。
Sprint回顾会的目的是：
-
审视上个Sprint中人员、关系、过程和工具表现如何；
-
识别出哪些做好的地方、哪些需要改进的地方，列出最重要的几项并行排序；
-
创建改进计划，并在下个Sprint中付诸实践。
敏捷教练鼓励团队成员在Scrum流程框架下改进开发流程和实践，让团队在下个Sprint中更高效、更享受这种开发流程。在每个Sprint回顾中，Scrum团队计划怎样完善“完成”的定义，采取哪些措施让产品质量变得更好。
在Sprint回顾结束的时候，Scrum团队应该已经鉴别出了在下个迭代周期的待改进项。完成这些改进项是对团队的不断完善和调整。虽然随时可以改善，但Sprint回顾会给大家提供了一个聚焦于审视和调整的机会。
相关文章
请你留言