Scrum简介

1. 什么是Scrum

　　Scrum是一种轻量级的框架，适合于小型的、结合紧密的团队开发复杂的产品。Scrum是二十世纪后期一些软件工程师协同努力的脑力劳动的成果，现已成为技术领域最具魅力的方法。但Scrum并不因此而复杂难用，相反，它不仅适用于技术领域，你还可以轻易将本文中介绍的工具和实践应用于其他领域。

　　一个Scrum团队通常由7人±2人组成，他们在固定的周期用迭代开发的方式一起协同工作。在每个迭代中，他们有充分的时间来评审和反思。“检查和调整”是Scrum的口头禅之一，Scrum团队还有一个显著的特点就是非常关注持续改进——既包括他们采用的过程，也包括他们的产品。

 

 

 

2. 角色（Roles）

 

　　Scrum中有三种角色：产品负责人（Product Owner）、Scrum Master和团队成员。

 

2.1. 产品负责人（Product Owner）

 

　　从企业的角度看，一个开发团队代表了一笔重大的投资，包括：人员工资、办公室租金、计算机和软件的采购和维护费用等等。产品负责人的责任在于帮助企业获得最高的投资回报（ROI）。

 

　　其中一个最大化ROI的方法是引导团队做最有价值的工作，同时远离那些低价值的工作。产品负责人控制团队的待办列表中待办事项的优先级顺序。在Scrum中，产品负责人是唯一有权给团队布置任务，或改变待办事项的优先级顺序的人。

 

　　使团队工作价值最大化的另一个方法是产品负责人要确保团队充分理解了需求。如果团队充分理解了需求，那么他们就能开发出正确的产品，而不是浪费时间用于开发错误的产品。产品负责人负责记录需求，通常以用户故事的形式（比如：“作为<角色>，我想要<特性>，以便我能<实现某事>”），并把它添加到产品待办列表中。每实现一个用户故事，都会增加产品的价值。正因如此，我们说：每完成一个用户故事，我们将获得一个新的产品增量。

 

 

产品负责人的职责概述：

• 持有产品愿景
• 代表业务
• 代表客户
• 管理产品待办列表
• 确定产品待办列表中待办事项的优先级
• 确定待办事项的验收标准
• 回答团队成员提出的问题

 

2.2. Scrum Master

　　Scrum master担当教练的角色，引导团队提升凝聚力、自组织能力和团队效能。团队的交付物是产品，而Scrum master的交付物是更高效自组织的团队。

Scrum master是团队的牧羊犬、捍卫者、守护者、引导者和Scrum专家。Scrum Master从团队实际出发，帮助团队学习和运用scrum和其他的敏捷实践，并持续帮助团队清除工作障碍。再次强调一下：Scrum Master不是团队的老板！Scrum master与团队处于同等地位，他们之间的区别是知识和职责，而不是职位等级。

Scrum Master的职责概述：

• Scrum专家和顾问
• 教练
• 障碍推土机（bulldozer）
• 引导者（facilitator）

2.3. 团队成员（Team Member）

　　高效能的Scrum团队是高度协同和自组织的。团队成员可以全权决定如何完成工作；团队可以自行决定使用什么工具和技术，以及团队成员如何瓜分任务。这其中的原理是：干活的人有最高的权利去决定用什么样的方式把活儿干得最好！。同样道理，如果项目需要估算进度，团队负责估算完成特性或任务所需要的时间。

　　团队应该具备开发潜在可交付产品所需要的所有技能。通常情况下，这意味着我们将有一组专家，每个专家都会带来他们独特的技能，并为团队成功做出其贡献。但这不代表每个团队成员只在其特定的领域做出贡献，每个团队成员都要帮助团队在每个迭代交付潜在可交付产品。大多数情况下，团队成员做自己擅长的事情效果最好，但有些时候需要团队成员承担其专长领域以外的工作，使得待办事项（如用户故事）能更好地从“开发中”状态迁移到“已完成”状态。我们的思维模式应从“完成我的工作”转变为“完成团队的工作”，我们的关注点也应从“我们正在做什么（任务）”转变为“我们将完成什么（结果）”。

团队成员的职责概述：

• 负责完成用户故事以持续增加产品的价值
• 自组织地完成所有工作
• 创建和决定估算结果
• 有权决定如何完成工作
• 避免“这不是我的工作”的封闭想法

　　那么，一个Scrum团队应该有多少团队成员呢？经验法则通常是七个人，可以增减两个人，也就是五到九个人。如果团队人数过少，团队可能会缺乏足够的多样化技能，难以完成用户故事所需的全部工作。如果团队人数过多，沟通开销会激增。

 

3. Scrum 工件（Scrum Artifacts）

　　Scrum实践者可以把Scrum工件用作进度可视化的工具。

3.1. 产品待办列表（The Product Backlog）

　　产品待办列表是产品预期交付物的累积清单，清单中包括了特性、缺陷修复、文档变更和任何对产品有意义和有价值的东西，通常称之为“待办事项”。虽然待办事项的说法是正确的，但很多Scrum团队更喜欢使用术语“用户故事”，因为它能提醒我们开发产品的目的是为了满足用户的需要。

　　用户故事列表是按优先级排序的，最重要的故事，也就是团队接下来就要实现的故事，位于列表的顶部，排在它下面的是第二个要实现的故事，以此类推。因为接近产品待办列表顶部的故事是马上就要实现的，所以他们应该是很小的故事，并且是被团队成员充分理解的故事。列表再往下，故事的颗粒度可以粗一点，理解也可以不那么充分，但等到它们的优先级往上升时，它们应该如上面的规则一样，变得更小，且被团队成员充分理解。即优先级越高，其颗粒度越细。

产品待办列表的每一个条目或故事都应包含以下信息：

• 故事的受益者是谁（为了谁）
• 想要的功能概述（要实现什么）
• 故事的价值所在（为什么要做）
• 实现故事的工作估算
• 用于确认故事被正确实现的验收标准

3.2. 迭代待办列表（The Sprint Backlog）

　　迭代待办列表是团队当前迭代的任务清单（to do list）。跟产品待办列表不同的是，迭代待办列表的生命周期是有限的，即仅限于当前迭代。迭代待办列表中包括团队承诺本迭代交付的所有故事及其相关任务。故事是可交付的，可以看作是价值的单位。任务是为了交付故事而必须完成的事情，可以看作是工作的单位。故事是团队整体工作的交付物，任务是团队成员工作的交付物。通常，一个故事可拆分成很多任务。

3.3. 燃起图/燃尽图（Burn Charts）

　　燃起图/燃尽图表示时间与范围的关系，横轴是时间，纵轴是范围。燃起图描述了已完成工作随时间变化的情况，随着工作的不断完成，曲线从左到右向上增长。燃尽图描述了剩余工作随时间变化的情况。通常来说，我们会按照团队工作的速度来预计剩余的工作量。有时，需求的增加或移除，会导致剩余工作量发生突然变化，此时燃尽图会有垂直线出现，增加工作时该线向上，移除工作时该线向下。

 

 

 

3.4. 任务板（Task Board）

　　如果团队成员能随时随地看见团队任务，你根本就不需要担心一些重要的工作会被遗忘。

　　最简单的任务板包括三列：待开发（ to do）、开发中（doing）、已完成（done）。任务在板上移动，可以直观地看到哪些任务已完成、哪些任务进行中、哪些任务还没有开始。这种可视化有助于团队检查他们当前的状况并根据需要适时调整。任务板还有助于干系人看到团队取得的进展。

 

 

 

3.5. 完成定义（Definition of Done）

　　完成是一个奇妙而精彩的词，当团队完成了一个用户故事，就可以庆祝了。有时我们不禁困惑：“完成”这个词到底意味着什么。开发人员可能会将“代码写好了”称为完成；测试人员可能会认为“所有测试通过”才能称为完成；运维人员可能会认为“部署到生产环境上”才能称为完成；市场人员可能会认为“它现在可以卖给客户，客户可以使用了”才称为完成。当销售人员质问“开发人员两周前就声称已经完成的故事，为什么团队还在做？”时，这个关于“什么是完成”的疑问确实会引发很多困惑和麻烦。

　　为了避免困惑，好的Scrum团队会创建团队自己的用户故事的完成定义。团队成员一起确定在团队可以声称一个用户故事完成前需要完成哪些事情。团队的定义可能包括：代码编写完成、代码评审完成、单元测试通过、回归测试通过、文档编写完成、产品负责人签字验收等等。在声称一个用户故事完成前，团队达成共识要做的事情列表就称为团队的“完成定义”。团队很可能将他们的完成定义作为检查单打印出来，并紧挨着张贴在他们的任务板旁边。当团队认为一个用户故事完成了，所有的成员会聚在一起评审完成定义的每一项。只有每一项都确认已经完成，团队才能声称用户故事完成了。

 

4. 迭代周期（The Sprint Cycle）

　　迭代周期包含若干个会议，通常称为Scrum活动：迭代计划会、每日立会、需求梳理会、迭代评审会、迭代回顾会。

 

 

 

 

4.1. 关于节奏（rhythm）

　　迭代周期是Scrum过程的基本节奏。无论开发周期被称为冲刺（Sprint）、周期（Cycle）或迭代（Iteration），说的都是一件事：在一个固定周期中，把项目分成一小块一小块并逐个完成它们。在迭代结束演示时，要么演示的软件可工作（意味着迭代成功），要么软件压根工作不了，这就是给团队抹一笔黑（迭代失败）。

　　团队越是频繁地交付潜在可交付产品增量，商务人员将有更大的自由度确定什么时候向用户发布什么内容。请注意这里有两个独立的决策：

　　产品是潜在可交付的吗？也就是说，产品质量是否达到业务向市场进行发布的要求？所有故事都完成了吗？团队负责做出这个决策。

　　现在发布我们已有的东西是否有商业意义？将当前的产品向市场进行发布是否能展示足够的价值增量？业务负责做出这个决策。

　　此外，团队越频繁地交付和展示潜在可交付产品增量，团队将越频繁地获得反馈，这促使Scrum中最重要的“检查和调整”活动进入良性循环。迭代周期越短，团队越能频繁地向业务交付价值。

　　Scrum团队的迭代周期通常是两周，也有很多团队的迭代周期是一周。很多Scrum早期著作设想迭代周期为一个月，这在当时真的是非常短的了！

　　下面的表格列出了为期一周的迭代中需要安排的一些会议。如果你对会议这个词很反感，或者对你而言，会议就意味着重复的压力的话，你可以把下面的这些会议叫做活动。表格中建议的活动时长也是基于一周的迭代而言。

一周迭代的日历

周一	周二	周三	周四	周五
迭代计划会 2小时	每日立会 15分钟	每日立会 15分钟	每日立会 15分钟	每日立会 15分钟
				迭代评审会 0.5小时
		需求梳理会 1小时		回顾会 90分钟

4.2. 迭代计划会（Sprint Planning Meeting）

　　Sprint计划会标志着迭代的开始。通常来说，这个会议分为两个部分：第一部分的目标是团队要确定当前迭代承诺的交付物；会议的第二部分中，团队要罗列出交付用户故事所需完成的所有任务。我们推荐的比例是：为期一周的开发需要1到2小时的迭代计划时间。

　　第一部分:“要做什么?”

　　迭代计划会第一部分的目标在于，团队要找出他们有信心在迭代结束时交付的一组“已承诺的”故事。产品负责人引导这一部分的会议。

　　产品负责人按照优先级顺序，逐个地介绍他希望团队在当前迭代完成的那些故事。团队成员们要和产品负责人讨论每个故事，评审其验收标准，确保大家对预期结果有一致的理解。接着团队成员就要决定他们是否承诺在本次迭代结束时能完成这个故事。重复上述流程处理每一个故事，直到团队决定再也无法承诺更多工作为止。要注意责任分工：产品负责人需要考虑可以做哪些故事；团队成员负责完成实际工作，决定能做多少个故事。

　　第二部分:“要怎么做？”

　　会议的第二部分，团队卷起袖管开始工作，把选定的故事分解成任务。要记得故事是交付物，是干系人、用户和客户想要的东西。团队成员需要完成这些任务才能交付故事，这些任务包括：获取用户的追加输入、设计新屏幕、新增数据库列、完成新特性的黑盒测试、书写帮助文本、按目标用户的语言完成菜单项的翻译、运行发布脚本，等等。

　　迭代计划会的第二部分，产品负责人应一直在场，以便回答团队提出的问题。在拆分任务的过程中，团队也许会发现他们挑选了过多或过少的故事，那就需要调整将要承诺的故事清单。

　　迭代计划会的输出就是一份迭代待办列表，其中包含了所有已承诺的故事和相关联的任务。产品负责人同意迭代开始之后就不再追加故事，除非团队明确地提出请求。产品负责人还承诺，直到故事已可接收而且已完成之前，他都会准备好回答故事相关的问题，跟团队协商故事的范围以及提供产品方面的指导。

4.3. 每日立会（Daily Scrum）

　　每日立会有时候也被称作站立会议，它是这样的：

　　每天。大多数团队选择在一天工作刚开始的时候开这个会。你可以根据团队的偏好来修改会议时间。

　　简短。站立的意义在于阻止各种跑题情况发生，避免开会变成受罪。每日立会不应该超过15分钟。

　　直截了当。参会者轮流快速地分享：

• 在上一次立会后我已经完成的任务。
• 到下一次立会前我期望完成的任务。
• 导致我慢下来的障碍。

　　每日立会的目的是检查和调整团队成员的工作，以便成功完成团队承诺要交付的故事。检查是在立会上做的；调整可以是会后做的。这意味着立会时团队是不需要解决问题的，简单暴露问题并且确定哪个团队成员来解决就够了。记住，立会要简短！

4.4. 需求梳理（Requirement Refinement）

　　在需求梳理会议上，讨论和改善待办列表中后续迭代将用到的故事。请注意，不是讨论当前迭代的故事，当前迭代的故事已经放到迭代待办列表中。关于会议频率，不管迭代多长，建议每星期开一次，每次1小时。在会议上，团队与产品负责人一起定义和完善验收准则，产品待办列表中的每一个用户故事都应该有验收准则。验收准则是一些可测试通过/不通过的条件，用来判断故事是否已按照预期实现。也有人把验收准则作为验收实例，团队演示这些例子证明故事已经完成。

　　故事规模（估值）

　　在需求梳理会议中，团队对故事规模分配一个值（如果你喜欢估算这个词，也可以说对故事规模进行估算），共同猜测完成某一故事需要多少工作量。

 

　　故事拆分

　　在待办列表中，优先级高的故事规模要足够小，这样团队更容易理解，在短期内也更容易完成。待办列表中优先级低的故事颗粒度可以稍大一些，解释也可以不那么充分。这意味着随着故事优先级的提高，我们必须把大的故事拆分成小的故事。虽然梳理待办列表的大部分工作应由产品负责人负责完成，产品负责人可以利用需求梳理会议获得整个团队的帮助。

4.5. 迭代评审（Sprint Review）

　　迭代评审会标志着迭代正式结束，邀请所有的相关干系人参与迭代评审会。这是团队的绝佳机会去展示他们的工作成果，即那些已经满足团队完成定义（DoD）的用户故事。相关干系人也有机会看到产品通过迭代过程逐渐得到改进。

　　如果团队承诺的用户故事没有完成，请在会议上与干系人沟通该信息。迭代评审会议最重要的议题是：演示已完成的故事。毫无疑问干系人会反馈意见，产品负责人和团队成员会收集这些反馈，用以帮助团队“检查和调整”产品。

　　迭代评审会不是决策会议，不是用来决定用户故事是否已经完成的，用户故事是否完成应在迭代评审前就确定了。也不是用来决定或承诺团队在下个迭代要做的工作，那是在迭代计划会要做的事情。

　　迭代评审会应该开多长时间？推荐对应每个星期的开发工作应花费半个小时到一个小时。也就是说，如果是一周的迭代，那么会议时间在半个小时到一个小时。如果是两周的迭代，那么会议时间在1个小时到两个小时之间。经过几个迭代之后，你会了解你的团队需要多长时间进行“检查和调整”。

4.6. 回顾（Retrospective）

　　虽然迭代评审会意味着迭代的正式结束，但团队还需要举行另外一个会议——回顾会。Scrum就是为了帮助团队持续地进行“检查和调整”的，它能够带动团队效能和幸福感不断提升。每个迭代末都要开回顾会，这是专门留给团队的时间，让团队专注于讨论他们当前迭代的心得体会：学到了什么，怎样才能将学到的东西用于持续改进。如果迭代周期是一周，回顾会的时长建议为1到2个小时，以此类推。

　　回顾会议不同于传统的“事后分析”会议，它的目标不是罗列一份“哪些做得好”或者“哪些做得不好”的冗长清单，而是找出一到两件可以在下一个迭代里进行的策略性改进。回顾会就是关于过程的改进。

4.7. 迭代异常终止（Abnormal Sprint Termination）

　　在Scrum中，管理层和团队之间基本的约定是：在迭代期间管理层不会改动需求。但有时还是会发生一些事情使得迭代计划不再有效，比如：公司卖掉了某项业务，市场的游戏规则发生了变化，竞争对手采取了某项行动，等等。遇到这种情况，业务上要决策是否提前终止迭代，这就需要产品负责人来主持决策。尽管异常终止这个名字听起来高端霸气，但这个业务决策过程既不需要阿诺施瓦辛格也不需要詹姆斯卡梅隆来参与。

　　如果产品负责人决定提前终止迭代，团队将把本迭代中所做的变更进行回退，以免做了一半的工作引入新问题。迭代异常终止后，召开回顾会显得尤为重要，因为团队可以从中学到很多东西。

4.8. 检查和调整（Inspect & Adapt）

　　归根结底，我们以短周期形式做开发工作的原因何在呢？是为了学习。经验是最好的老师，而Scrum周期的设计就是要为你提供多方位接收反馈的机会，包括客户、团队和市场，并从中学习。你从当前周期所做工作中得到的收获，会影响你为下个周期所做的计划。Scrum称之为“检查和调整”，你也许叫它“持续改进”，但不管叫什么，它都是件美事。

 

 

------20191203闪