敏捷回顾会议

Scrum的六个时间箱

时间箱机制是Scrum的一个非常重要的方面。在Scrum框架中有六个时间箱。

时间箱一:Sprint

Sprint的本意是指冲刺,在Scrum中,一个Sprint就是一个迭代,Sprint长度通常2-4周,它是一个时间箱,在项目进行过程中不允许延长或缩短Sprint长度。在Sprint中,ScrumMaster要确保没有任何影响Sprint目标的变更发生。团队构成和质量目标在Sprint中均保持不变。Sprint由Sprint计划会议、开发工作(需求分析、设计、开发、测试、质量控制等)、每日站会、Sprint评审会议和Sprint回顾会议等活动组成。Sprint一个紧跟一个进行,之间没有任何时间间隔。

其它的5个时间箱对应Scrum的5个仪式:

时间箱二:发布计划会议(Release Planning Meeting)

发布计划会议的目的是建立Scrum团队以及组织内的其他部门能够理解和沟通的计划和目标。发布计划会议需要回答以下两个问题:“我们如何以最佳方式将愿景转化为成功的产品?我们怎样才能达到或甚至超越客户的满意度和投资回报?”发布计划确定发布目标、具有最高优先级的产品Backlog条目、重大风险和发布所包含的全部特性和功能。另外, 发布计划会议确立大致交付日期和费用,如果没有任何变化就应当保持该日期和费用。组织可以检视开发进程,以每个Sprint为基础调整发布计划。
发布计划会议是完全是可选的。如果项目开始的时候没有这个会议,那么这些工件的缺少将成为一个需要被移除的障碍,解决这个障碍便成为了产品Backlog中的一个条目。
Scrum以迭代的方式构建产品,每个Sprint中都会交付产品增量,通常价值最高、风险最大的部分先开发。产品增量随着Sprint交替而完成,每个增量都是整个产品的可交付一部分。当创造出足够多的有价值的、可供投资方使用的产品增量时,产品就可以发布了。
大多数组织已经有自己的发布计划过程,并且在大多数过程中的大部分计划已经在发布之初完成,而且也不会更改。在Scrum发布计划会议上确立一个整体目标和预期结果。发布计划会议通常不超过组织构建传统发布计划的15-20%时间。然而,Scrum发布在每个Sprint评审和计划会议上都执行准时(Just-in-time)计划,同时,在每日站会上执行每日准时(Just-in-time)计划。总的看来,Scrum发布可能比传统的发布计划耗费略多的工作。

发布计划会议需要为该发布做产品Backlog条目的估算和优先级排列。

时间箱三:Sprint计划会议(Sprint Planning Meeting)

Sprint计划会议的产物是Sprint Backlog。对于一个月为周期的Sprint,计划会议的时间箱限定为8小时。对于较短的Sprint,计划会议一般安排整个Sprint周期的5%时间。Sprint计划会议的内容包括以下两个部分:第一部分,4小时的时间箱中需要确定该Sprint将要完成什么任务。第二部分,也是4小时的时间箱,团队研究在Sprint内如何构建产品增量。
Sprint计划会议包含两部分内容:“做什么”和“怎么做”。一些Scrum团队将这两部分结合起来。第一部分,Scrum团队处理“做什么”的问题。产品负责人给团队介绍最高优先级的产品Backlog条目,并一起决定接下来的Sprint中开发什么功能。Sprint计划会议需要输入包括产品Backlog、最新的产品增量、团队的能力和以往的表现。团队自己决定选择多少产品Backlog的条目,因为只有团队可以评估在接下来的Sprint内可以完成什么工作。
选定产品Backlog条目后,Sprint目标也就明确了。Sprint目标通过实现产品Backlog的条目来达到。Sprint目标为团队提供指导,使团队明确构建的产品增量的目的。Sprint目标是发布目标的子集。
确定Sprint目标的原因是在功能方面为团队留出一定的回旋余地。例如,上一个Sprint的目标可能是:“通过一种安全、可重获的交易中间件实现客户账户修改功能的自动化”。所以当团队工作时,就会紧记这个目标。为了达到这个目标,团队就需要实现该功能和技术。如果团队感觉实现过程比预期的难度大,那么就可以和产品负责人协商,只实现部分功能。
在Sprint计划会议的第二部分,团队需要处理“怎么做”的问题。在Sprint计划会议的第二个4小时时间箱中,团队需要弄清楚如何将“做什么”会议阶段选定的产品Backlog条目转化成完成的增量。通常团队会先以设计展开工作,设计过程中,团队确定任务,这些任务就是将产品Backlog转化成可用软件的具体工作。任务需要被分解,以便在一天之内完成。这个任务列表就是SprintBacklog。团队通过自组织,并且是自己认领的方式分担任务,任务认领可以在Sprint计划会议上进行,或也可以Sprint中及时(Just-in-time)确定。
通常,Sprint计划会议上只设计出SprintBacklog的60- 70%。剩余部分后续完成,或者给出大体的估算并在Sprint中再分解。
产品负责人会参加Sprint计划会议的第二部分,为团队讲解产品Backlog条目,并协助团队权衡取舍。如果团队认为工作量过大或太小,就可以和产品负责人重新协商、确定产品Backlog。团队也可以邀请其他人员参加会议,以寻求技术和领域建议。新组建的团队常常在这次会议中第一次意识到:整个团队要么一起成功,要么一起失败,没有个体这个概念。团队同时认识到必须依靠自己。正因为意识到这一点,整个团队才逐渐自组织并形成自己的特色,真正成为一个团队。

时间箱四:每日站会(Daily Scrum Meeting)

团队每天15分钟的检视和调整会议称之为每日站会。每日站会在各个Sprint都是在同一时间,同一地点进行,因为会议时间很短,通常,会议都是站立进行的。会议上,每个团队成员需要回答以下三个问题:

从上次会议到现在都完成了哪些工作?

下次每日站会之前准备完成什么?

工作中遇到了哪些障碍?

每日站会可以增强交流沟通、省略其他会议、确定并排除开发遇到的障碍、强调和提倡快速决策、提高每个成员对项目的认知程度。

ScrumMaster要确保团队举行每日站会,团队则负责召开会议。ScrumMaster指导团队执行规则来控制会议时间,并保证团队成员进行简短有效的汇报。ScrumMaster也要确保“鸡” 的角色不允许在会议上发言或以各种方式干扰会议。

每日站会不是进度汇报会议。这个会议是为那些将产品Backlog条目转化成为产品增量的人( 团队)召开的。团队承诺实现Sprint目标和完成产品Backlog条目,每日站会对Sprint目标的进展的检视(三个问题)。紧随每日站会之后的一些解决问题的会议通常是对Sprint中的下一步工作进行调整,目的在于增加团队实现目标的可能性。这是Scrum经验过程中的重要检视和调整的会议。

时间箱五:Sprint评审会(Sprint Review Meeting)

Sprint结束时要举行Sprint评审会议,一个月的Sprint通常对应时长4小时Sprint评审会议。对于时间少于一个月的Sprint来说,该会议的时长不要超过整个Sprint的5%。

Sprint评审会议中,Scrum团队和利益干系人沟通Sprint中完成了哪些工作。然后,根据完成情况和Sprint期间产品Backlog的变化,他们确定接下来的工作。这是一个非正式会议,会议中进行功能演示,以促进下一步工作的互助与合作。

评审会议至少要包含以下因素:产品负责人确定完成了哪些工作和剩余哪些工作。团队讨论在Sprint中哪些工作进展顺利、遇到了什么问题、问题是如何解决的。然后,团队演示完成的工作并答疑。产品负责人和与会人员讨论产品Backlog,并根据不同的速率计划出可能的完成日期。接着,整个团体就哪些工作已经完成,同时这对下一步工作有何意义进行探讨。Sprint评审会议为接下来的Sprint计划会议提供了宝贵的参考信息。

时间箱六:Sprint 回顾会议(Sprint RetrospectiveMeeting)

在Sprint评审会议结束之后和下个Sprint计划会议之前,Scrum团队需要举行Sprint回顾会议。对于长度为一个月的Sprint,回顾会议的长度一般为3小时,在会议上,ScrumMaster鼓励团队在Scrum过程框架和时间的范围内,对自己的开发过程进行改进,使下一个Sprint的效率更高、工作更容易。许多书籍都介绍了召开回顾会议的技巧。

回顾会议旨在对前一个Sprint周期中的人、关系、过程和工具进行检验。检验应当确定并重点发展那些进展顺利的,和那些如果采用不同方法可以取得更好效果的条目。这些包括:Scrum团队、会议安排、工具、“完成”定义、沟通方法和将产品Backlog条目转化成“完成”工作的过程。在Sprint回顾会议的最后,Scrum团队应该确定将要在下个Sprint中实现的有效改进方法。这些变化更适应于经验检验。