敏捷开发(2)-Scrum

什么是SCRUM

Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;把一个开发流程的名字取名为Scrum,我想你一定能想象出你的开发团队在开发一个项目时,大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它,你一定会感到非常兴奋的。

原始含义

Scrum原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。争球双方各有8个队员参与,各方出3名前锋队员,并肩各站成一横排,面对面躬身互相顶肩,中间形成一条通道,其他前锋队员分别站在后面,后排队员用肩顶住前锋队员的臀部,组成3、2、3或3、4、1阵形。然后,由犯规队的对方队员在对阵一侧1码外,用双手低手将球抛入通道,不得有利于本队。当球抛入通道时,前排的3对前锋队员互相抗挤,争相踢球给本方前卫或后卫队员,前卫和后卫队员必须等候前锋将球踢回后,方可移动。

用于产品开发

Scrum 是一个用于开发和维持复杂产品的框架 ,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中,使用产品Backlog来管理产品的需求,产品backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中,Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表,我们称它为Sprint backlog。在每个迭代结束时,Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目,但它适用于任何复杂的或是创新性的项目。

Scrum开发模型

敏捷开发(2)-Scrum

SCRUM团队的三个角色

产品负责人(Product Owner)

产品负责人是管理产品待办事项列表的唯一责任人。产品待办事项列表的管理包括:

  • 清晰地表达产品代办事项列表条目
  • 对产品代办事项列表中的条目进行排序,最好地实现目标和使命;确定优先级;
  • 确保开发团队所执行工作的价值
  • 确保产品代办事项列表对所有人可见、透明、清晰,并且显示 Scrum 团队的下一步工作
  • 确保开发团队对产品代办事项列表中的条目达到一定程度的理解

开发团队(Scrum Team)

开发团队有以下几个特点:

  • 他们是自组织的,没有人(即使是 Scrum Master 都不可以)告诉开发团队如何把产品 代办事项列表变成潜在可发布的功能。
  • 开发团队是跨职能的,团队作为一个整体拥有创造产品增量所需要的全部技能。
  • Scrum 不认可开发团队成员的头衔,无论承担哪种工作他们都是开发者。此规则无一例外。
  • 开发团队中的每个成员可以有特长和专注领域,但是责任归属于整个开发团队
  • 开发团队不包含如测试或业务分析等负责特定领域的子团队。

流程管理员(Scrum Master)

Scrum Master 负责确保 Scrum 被理解并实施。为了达到这个目的,Scrum Master要确保 Scrum 团队遵循 Scrum 的理论、实践和规则。Scrum Master是Scrum团队中的服务式领导。

Scrum Master 帮助 Scrum 团队外的人员了解他们如何与 Scrum 团队交互是有益的。 Scrum Master 通过改变这些交互来最大化 Scrum 团队所创造的价值。

SCRUM的三个工件

Product Backlog – 产品待办事项列表

产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。

SPRINT BACKLOG

Sprint 代办事项列表是一组为当前 Sprint 选出的产品代办事项列表条目,外加交付 产品增量和实现 Sprint 目标的计划。

燃尽图(BURN-DOWN CHART)

Sprint Burndown Chart 显示了Sprint中累积剩余的工作量,它是一个反映工作量完成状况的趋势图。

SCRUM的五个活动

产品待办事项列表梳理

产品待办事项通常会很大,也很宽泛,而且想法会变来变去、优先级也会变化,所以产品待 办事项列表梳理是一个贯穿整个Scrum项目始终的活动。该活动包含但不限于以下的内容:

  • 保持产品待办事项列表有序
  • 把看起来不再重要的事项移除或者降级
  • 增加或提升涌现出来的或变得更重要的事项
  • 将事项分解成更小的事项
  • 将事项归并为更大的事项
  • 对事项进行估算

产品待办事项列表梳理的一个最大好处是为即将到来的几个Sprint做准备。为此,梳理时会特别关注那些即将被实现的事项。需要考虑不少因素,这包括但不限于以下的内容:

理想情况下,下一个Sprint的备选事项都应该提升“商业价值”。 开发团队需要能够在一个Sprint内完成每一个事项。每个人都需要清楚预期产出是什么。

产品开发决定了,有可能需要其它的技能和输入。因此,产品待办事项列表梳理最好是所有团队成员都参与的活动,而不单单是产品负责人。

Sprint计划会议

每个Sprint都以Sprint计划会议作为开始, 这是一个固定时长的会议,在这个会议中,Scrum团队共同选择和理解在即将到来的Sprint中要完成的工作。

整个团队都要参加Sprint计划会议。针对排好序的产品待办事项列表(Product Backlog),产 品负责人和开发团队成员讨论每个事项,并对该事项达成共识,包括根据当前的“完成的定 义”,为了完成该事项所需要完成的所有事情。所有的Scrum会议都是限定时⻓的。Sprint计划会议推荐时⻓是Sprint中的每周对应两⼩时或者更少(译者注:比如,一个Sprint包含2个星 期,则Sprint计划会议时长应为4个小时或者更少)。因为会议是限制时⻓长的,Sprint计划会议的成功⼗分依赖于产品待办事项列表的质量。这就是产品待办事项列表梳理十分重要的原因。

在Scrum中,Sprint计划会议有两部分:

  1. 决定在Sprint中需要完成哪些工作
  2. 决定这些工作如何完成

第一部分:需要完成哪些工作?

在会议的第一部分,产品负责人向开发团队介绍排好序的产品待办事项,整个Scrum团队共同理解这些工作。

Sprint中需要完成的产品待办事项数目完全由开发团队决定。为了决定做多少,开发团队需要考虑当前产品增量的状态,团队过去的工作情况,团队当前的生产能力,以及排好序的产品待办事项列表。做多少工作只能由开发团队决定。产品负责人或任何其它人,都不能给开发 团队强加更多的工作量。

通常Sprint都有个目标,称作Sprint目标。这将十分有效地帮助大家更加专注于需要完成的工 作的本质,而不必花太多精力去关注那些对于我们需要完成的工作并不重要的⼩小细节。

第二部分:如何完成工作?

在会议的第二部分⾥里,开发团队需要根据当前的“完成的定义”一起决定如何实现下一个产品增 量。他们进⾏行⾜足够的设计和计划,从而有信心可以在Sprint中完成所有工作。头几天的工作会 被分解成⼩小的单元,每个工作单元不超过一天。之后要完成的工作可以稍⼤大些,以后再对它 们进⾏行分解。

决定如何完成工作是开发团队的职责,决定做什么则是产品负责人的职责。

在计划会议的第二部分,产品负责人可以继续留下来回答问题,以及澄清一些误解。不管怎样,团队应该很容易找到产品负责人。

Sprint计划会议的产出 Sprint计划会议最终需要Scrum团队对Sprint需要完成工作的数量和复杂度达成共识,并预期在一个合理的条件范围内完成它们。开发团队预测并共同承诺他们要完成的工作量。 总而⾔言之:在Sprint计划会议中,开发团队和产品负责人一起考虑并讨论产品待办事项,确保他们对这些事项的理解,选择一些他们预测能完成的事项,创建足够详细的计划来确保他们能够完成这些事项。

最终产生的待办事项列表就是“Sprint待办事项列表(Sprint Backlog)”。

每日Scrum会议

每日站会;

开发团队是自组织的。开发团队通过每日Scrum会议来确认他们仍然可以实现Sprint的目标。 这个会议每天在同样的时间和同样的地点召开。每一个开发团队成员需要提供以下三点信息:

从上一个每日Scrum到现在,我完成了什么; 从现在到下一个每日Scrum,我计划完成什么; 有什么阻碍了我的进展。

每日Scrum中可能有简要的问题澄清和回答,但是不应该有任何话题的讨论。通常,许多团队 会在每日Scrum之后⻢马上开会处理他们遇到的任何问题。

每日Scrum既不是向管理层汇报,也不是向产品负责⼈人或者ScrumMaster汇报。它是一个开发 团队内部的沟通会议,来保证他们对现状有一致的了解。只有Scrum团队的成员,包括 ScrumMaster和产品负责⼈人,可以在会议中发⾔言。其他感兴趣的⼈人可以来旁听。在必要时, 开发团队会基于会议中的发现重新组织他们的工作来完成Sprint的⺫⽬目标。

每日Scrum是Scrum的一个关键组成部分,它可以带来透明性,信任和更好的绩效。它能帮助 快速发现问题,并促进团队的自组织和自⽴立。所有Scrum会议都是限定时⻓长的。每日Scrum通 常不超过15分钟。

Sprint评审会议

Sprint结束时,Scrum团队和相关⼈人员一起评审Sprint的产出。所有Scrum会议都是限定时⻓长 的,Sprint评审会议的推荐时⻓长是Sprint中的每一周对应一个小时。

队会找到他们自己的方式来开Sprint评审会议。通常会演⽰示产品增量,整个小组也会经常讨论他们在Sprint中观察到了什么、有哪些新的产品想法出现。他们还会讨论产品待办事项列表 的状态、可能的完成日期以及在这些日期前能完成什么。

Sprint评审会议向每个⼈人展⽰示了当前产品增量的概况。因此,通常都会在Sprint评审会议中调 整产品待办事项列表

Sprint回顾会议

在每个Sprint结束后,Scrum团队会聚在一起开Sprint回顾会议,目的是回顾一下团队在流程人际关系以及工具方面做得如何。团队识别出哪些做得好,哪些做得不好,并找出潜在 的改进事项,为将来的改进制定计划。所有的Scrum会议都是限定时⻓长的,Sprint回顾会议的 推荐时⻓长是Sprint中的每一周对应一个小时

SCRUM的五个价值观

  1. 承诺 – 愿意对目标做出承诺
  2. 专注– 把你的心思和能力都用到你承诺的工作上去
  3. 开放– Scrum 把项目中的一切开放给每个人看
  4. 尊重– 每个人都有他独特的背景和经验
  5. 勇气– 有勇气做出承诺,履行承诺,接受别人的尊重

SCRUM术语

Scrum: Scrum无对应中文翻译

Agile: 敏捷

Lean: 精益

Iterative:迭代式的

Iteration:迭代

Agile Manifesto: 敏捷宣言

Empirical: 经验性的

Empirical Process:经验性过程

Transparency: 透明性

Inspect and Adapt: 检视与调整

Sprint:原意为冲刺,Scrum中的Sprint无对应中文翻译,指一个迭代

Sprint Goal:Sprint目标

Product Owner :产品负责人 简称PO

Scrum Master :简称SM, 一般不翻译

Development Team : Scrum开发团队

Scrum Team:指PO,SM和开发团队

Scrum Roles:Scrum角色,指PO,SM和开发团队

Emergent :涌现的

Product Backlog:产品待办列表,指需求清单

Sprint Backlog:Sprint待办列表,指Sprint任务清单

Sprint Burn-down Chart:Sprint燃尽图,团队用于做Sprint内的进展跟踪

Release Burn-down Chart:  发布燃尽图,产品负责人做发布进展跟踪

Sprint Planning Meeting: Sprint计划会议

Daily Scrum Meeting:每日站会

Sprint Review Meeting:Sprint评审会议

Sprint Retrospective Meeting: Sprint回顾会议

Product Backlog Refinement: 产品待办列表梳理

Product Backlog Item: 产品待办清单条目,简称PBI

User Story: 用户故事,指一条需求

Story Point:衡量用户故事的工作量大小的计量单位

Velocity: 团队速度

Sprint Task: 实现一条需求需要做的一个技术任务

Definition of Done: DoD,完成的定义

Stakeholders: 干系人

Backlog: 待办列表

Artifact :工件

Estimation :估算

Collaboration: 协作

Scaling Scrum:大规模Scrum

参考文章

敏捷开发之Scrum扫盲篇

SCRUM中文网

上一篇:一步步学敏捷开发:1、敏捷开发及Scrum介绍


下一篇:SCRUM敏捷开发规则一栏