本站首页 返回顶部 关于博主

Scrum的事件–敏捷框架Scrum系列(4)

PDF版

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回顾会给大家提供了一个聚焦于审视和调整的机会。

 


相关文章




请你留言