Scrum入门之三三五五

引言


在敏捷软件开发中,Scrum[1]是个相当简单、容易上手的框架。据有关调查[2],93%以上的软件开发团队都在用Scrum的敏捷方法来推动他们的软件交付。

说Scrum是个框架而不是方法,是因为Scrum只提供了进行敏捷开发的指导方针,但没有提供详细的实践方法和工具。今天我们就来了解一下Scrum最基本的框架[3],简单地讲,就是Scrum的“三三五五”

Scrum的三三五五


下面这张图是Scrum的框架,它包含了Scrum的所有必备要素,也就是我们所说的三三五五。简单来讲,就是:

  • 三个角色:Scrum Master、Product Owner(产品负责人)和 Team(团队)。
  • 三个工件:Product Backlog(产品待办事项)、Sprint Backlog (Sprint 待办事项)和 可交付产品增量。
  • 五大仪式(事件):Sprint(冲刺)、Sprint Planning(Sprint规划)、Sprint Daily Standup(每日站会)、Sprint Review(Sprint 评审)和 Sprint Retrospective(回顾)。
  • 五大价值观:Coverage(勇气)、Openness(开放)、Focus(专注)、Commitment(承诺)和 Respect (尊重)。

ScrumFramework

下面,我们就来逐个看看他们的具体内涵。

Scrum 的角色

Scrum的三个角色(Role)分别是:Scrum Master、Product Owner(产品负责人)和 Team(团队)。

Scrum Master

Scrum Master是团队的主心骨。他的职责包括:

  • 促进团队的工作
  • 精心组织Scrum的各种仪式
  • 相对于项目经理而言,Scrum Master是一个不同的角色
  • 负责设定Scrum的价值和实践
  • 确保团队的组件完整性且保证效率高产
  • 促成所有角色和职能之间的紧密协作
  • 排除障碍
  • 保护团队不受外界干扰

Product Owner

Product Owner是Scrum团队的舵手。他的主要职责包括:

  • 在产品团队中扮演业务的发言人,是项目的客户或者代表
  • 有充足的知识和授权
  • 通过参与测试规划传达期望
  • 定义业务需求,定义产品的最高优先级的特征和功能
  • 根据需求的商业价值对其进行优先级排序
  • 确定发布日期和发布内容
  • 根据需要调整每个Sprint的需求和优先级
  • 在Sprint交界处可以变更功能和优先级
  • 定义验收标准
  • 接受或者推翻工作成果
  • 对于每个敏捷团队做的所有工作的价值、优先级和细节拥有最终的权威
  • 对于业务目标和期望的最终结果的深层的了解使得其拥有此权威
  • 与团队一起更紧密地工作

Team

Team是交付最终成果的主力军,负责按照Product Owner优化和排序过的用户故事,开发出最终的可交付成果。团队主要有以下特征:

  • 典型团队通常为5-9个人
  • 跨职能团队,囊括了开发人员、测试人员、业务分析师等开发最终软件所必需的角色
  • 团队成员应该是全职的。也可能有特殊情况 (例如, 数据库管理员DBA等兼职)
  • 保持纪律,遵守承诺,按时交付软件成果。
  • 自组织、自管理的团队

Scrum的工件

Scrum的工件,又叫资产,主要包括:Product Backlog(产品待办事项)、Sprint Backlog (Sprint 待办事项)和 可交付产品增量。除此之外,还有辅助软件开发和管理的其他产出物,包括但不限于:Sprint目标、燃尽图(Brundown chart)、燃起图(Burnup chart)、障碍列表和任务仪表盘等。

产品待办事项列表

Product Backlog,中文叫产品待办事项列表,是待开发软件的需求集合。它具有如下特点:

  • 是项目的需求列表
  • 以用户故事的形式表示
  • 包含功能性以及非功能性需求
  • 每项需求应该描述其商业价值
  • 产品负责人负责进行对Product Backlog Item (产品待办事项,PBI)优先级排序
  • 每个Sprint开始之前要重新进行排序,以确定最重要的事项
  • 随着项目的进行,可能新增、变更或减少条目,比如:需求变更

Sprint 待办事项列表

Sprint Backlog,中文叫Sprint 待办事项列表,是当前Spint中需要进行开发的PBI,它是Scrum团队在Sprint 规划会议上选出的优先级最高、最具有客户价值的用户故事

Sprint Backlog具有如下特点:

  • 从产品Backlog中取出前面若干项,在当前Sprint中被实现
  • 每个用户故事应该能够在当前Sprint中被实现
  • 每一个用户故事都会被分解并关联到若干个子任务(Task)
  • 团队成员自愿挑选任务
  • 每日更新任务剩余时间
  • 团队成员均可按需在Sprint Backlog中增加、修改、删除任务
  • 如果Sprint工作不清晰,创建Sprint Backlog时先估算一个比较大的时间段,在后续阶段再做进一步的缩短
  • 伴随着任务的逐步清晰化,及时更新剩余时间
  • 对于用户故事的完成,团队一起定义“完成”的标准(DoD)
  • DoD代表了各种用于确保sprint backlog中质量、准确性、业务关联性活动

可交付产品增量

可交付产品增量,就是Scrum团队最终要交付给客户或PO的可工作的软件功能增量,也是要在Scrum Review会议上进行演示的软件制品

这一项毋庸赘述。

Scrum的事件

Scrum的五大事件,也称为五大重要仪式,包括:Sprint(冲刺)、Sprint Planning(Sprint规划)、Sprint Daily Standup(每日站会)、Sprint Review(Sprint 评审)和 Sprint Retrospective(回顾)。

Sprint

Sprint,有人将之中文译为冲刺、短跑等,在Scrum之外,被称为迭代(Iteration)。Sprint是Scrum的专有术语,是Scrum中最具代表性的事件之一,也是敏捷软件开发的核心特征之一。

简单来讲,Sprint就是Scrum里面的迭代时间盒,是一个固定时间长度的软件开发、交付周期。Sprint 具有如下特点:

  • Scrum通过一系列Sprint落实开发任务,实现项目进展
  • 典型Sprint时长2-4周,最长一个自然月
  • 固定Sprint 时长有助于保持好的团队节奏
  • 在每个Sprint 中团队对产品进行设计、开发以及测试
  • Sprint具有固定时间段,按时结束,每次Sprint 成果则可能因实际情况而有所不同

Sprint Planning 会议

Sprint Planning 会议,及Sprint 规划会议,在每个Spring开始之时召开,由Product Owner、Scrum Master和Scrum 团队全体人员参加。这个会议主要有两件事情要确定,1)要确定当前Sprint的目标,2)选定当前Sprint要处理的最具价值的用户故事,创建Sprint Backlog。Sprint backlog的创建是团队协作的结果,而不是由Scrum Master单独完成。必要时候,技术分析和设计任务也可以被添加到Sprint Backlog。

Sprint规划会议上,团队要:

  • 确定当前Sprint的目标(Goal)
  • 从产品Backlog中选择他们承诺可以完成的工作项
  • 对选定的用户故事进行估算
  • 创建Sprint Backlog,
  • 识别任务,且每个任务都完成了估算
  • 可以考虑概括设计
  • 对每个选定的用户故事,如有问题,当场向PO进行咨询,请求进行澄清。

Scrum 每日站会

Scrum 每日站会,我更喜欢称之为“每天碰头会”,是Scrum用来沟通、通报当前进展及后续计划的主要场合,因其提倡大家都站着开会而得名每日站会不是用来解决问题的会议,会上不讨论具体的问题细节、解决方式等占用时间的细节内容。项目遇到的问题或障碍,应当会后通过专门的问题解决会议或其他方式进行解决。

每日站会通常不超过15分钟,提倡每天举行一次,早上或下午均可,由团队自行决定。

全体团队成员、有兴趣的项目干系人均可参加,但只有团队成员、产品负责人和Scrum Master可以发言。确保分清Scrum的“猪”类角色和“鸡”类角色对团队非常有帮助。

Scrum每日站会上,每个团队成员都要回答三个问题:

  • 本次会议之前,自己做了什么?
  • 本次会议之后,自己打算或计划做什么?
  • 目前,是否遇到了什么问题,阻碍了自己的进展?

特别强调,每日站会不是用来向 Scrum Master 或 Product Owner 汇报个人状态或进展的,它是用来在团队面前确认自己的个人承诺并展示当前进展和问题的

Sprint Review 会议

Sprint Review 会议,又叫做Sprint 评审会议、Sprint演示会议、Sprint 展示会议等,是团队用来展示当前Sprint 的开发成果的会议。Sprint Review 会上,团队直接向相关干系人演示当前Sprint所开发出来的软件产品。Sprint Review 会议有如下特点:

  • 团队展示当前Sprint的成果
  • 一般采取演示新特性、底层架构、可工作软件等形式
  • 通常是非正式的,不需要特意准备
  • 不需要复杂的事先准备,尤其不要进行幻灯片的展示
  • 整个团队全员参与
  • 邀请所有项目干系人参与
  • 会议时间依据Sprint的长短而定,通常每个Sprint中,每周1个小时的原则
  • 产品负责人确认sprint目标是否实现
  • 产品负责人可以拒绝接受团队的软件成果。

Sprint 回顾会议

Sprint Retrospective 会议,用来回顾在当前结束的Sprint中的工作,进行经验的总结、反思,并拟定相应的改进措施。 Sprint Retrospective 会议通常具有如下特点:

  • 用于周期性检视团队最佳实践以及存在的问题
  • 每个Sprint中,一周45分钟原则
  • 每个Sprint结束时举行
  • 整个团队全员参与,还包括 Scrum Master、产品负责人、客户以及其他项目干系人

Scrum 五大价值观

价值观是任何一种方法学都应当具备的核心,它也是把认同相同价值观的人群聚拢在一起的精神力量。Scrum的五大价值观[4],从敏捷实践中来,应用于敏捷实践中去,真实、生动而又准确地反应了敏捷运动中重视人的因素。

Scrum的五大价值观包括:Coverage(勇气)、Openness(开放)、Focus(专注)、Commitment(承诺)和 Respect (尊重)

Coverage – 勇气

Scrum团队中的成员,既要有勇气接受看似不可能的挑战,又要有勇气拼尽全力去完成个人承诺要交付的成果,更要有勇气对不合理的要求说“不”。Scrum团队不是单打独斗,大家能够相互支持,因而应当具备足够的勇气去接受更大的挑战。

为了接受并负责任的交付产品,团队成员必须有足够的勇气来对大家说“不”,比如不能承诺时,对纳入Sprint的故事说“不”等,做这些决定其实是需要很大的勇气的,因为前面并不一定是平坦之路,但对自己要绝对自信。

Openness – 开放

在Scrum团队中,每个人都会遇到障碍,每个人都会有长于别人、弱于别人之处。保持开放的心态,公开透明地展示自己的强项、弱点,明确地展示自己的工作进展、遇到的障碍等状态,有助于构建更加团结、凝聚的团队氛围,构建更加稳固的自组织、自管理、跨职能的Scrum团队。

当团队成员遇到障碍,或对某些事项表示担忧,明确无误地表达出来,有助于团队及时采取措施解决问题,预防风险的发生,按时完成团队承诺的交付成果。

开放是体现敏捷可视化、透明性的重要保证。

Focus – 专注

俗话说:“专心成就专注,专注造就专业,专业铸就成功”。通过在一段时间内只专注于少数几件事情,团队可以很好地进行合作并交付出优质的成果,也能够更快地交付有价值的事项。

Commitment – 承诺

自组织、自管理团队成员主动认领开发任务,既是对团队的承诺,也是对自己个人能力的自信,更是对交付客户价值的渴望。中国人向来讲究“一诺千金”,每个人都恪守对团队的承诺,不遗余力、竭尽全力去交付自己的承诺,团队才能前进、客户价值才能实现。

由于对自己的命运有更大的掌控,团队会有更坚定的信念去创造成功。

Respect – 尊重

古语有云,“君子和而不同”,“寸有所长、尺有所短”。

跨职能团队的成员具有不同的技能、经历背景,在技术上各有所长,因而才具备交付客户价值所需要的各种技能。保持对别人的尊重,既是最基本的个人涵养,也是团队保持团结、凝聚所必需的人际技巧。

就个人而言,三人行必有我师,常怀空杯心态,尊重每一个人,向不同人的学习,自己才能真正不断成长。就团队而言,彼此尊重,才能凝聚更大力量,才能塑造团队成员之间的信任,在工作中彼此支持、相互帮助,协同工作,分享成功和失败。

总结


下面,我们通过一张图来总结一下Scrum的“三三五五”。

3355

参考资料


[1] 《Scrum Guide》, Jeff Sutherland, Ken Schwaber, http://www.scrumguides.org/scrum-guide.html,2013 July。

[2] 《2015 Scrum 状态调查报告》,https://www.scrumalliance.org/why-scrum/state-of-scrum-report。

[3] 《Scrum精髓:敏捷转型指南》,Ken Rubin 作, 姜信宝、米全喜、左洪斌 译,清华大学出版社出版。

[4] 《Scrum Values》, https://www.scrumalliance.org/why-scrum/core-scrum-values-roles