Scrum学习笔记

1. Scrum入门

问题与挑战

产品投放市场的时间慢

项目失败率高 & 投资回报率低

对变化、变更的响应的难度大且成本高

用户体验及客户导向很差

软件质量不过关

生产力看起来还需要提高

员工士气低，缺乏动力和责任感

员工流失率高

……

越来越多的企业开始使用Scrum解决这些问题

•Google
•IBM
•Nokia
•Siemens
•Philips
•Accenture
•Sun
•UbisoB
•Bleum
•SAP
•Microsoft
•Infosys
•Oracle
•Wipro
•Motorola
•Yahoo!
•Schneider
•Agilent
•Irdeto
•Double Click
•Autodesk
•Tencent
•Plenware
•Trendmicro
•Moody’s
•StarCite

哪些类型的项目已经在使用Scrum

•大型企业级软件项目
•商业软件产品
•消费者软件项目/大型网站
•美国FDA批准的应用于X射线和MRI的软件
•高可靠性系统（99.9999％以上）
•财务支付系统
•智能家居项目
•战斗机项目
•大型数据库应用
•嵌入式电信系统
•手机项目
•CMMI5级的组织
•多地点同步开发
•支撑和维护项目
•非软件项目
• ……

Scrum在Yahoo！的应用



敏捷价值观：敏捷宣言



敏捷价值观：敏捷原则

1.1. 15分钟Scrum扫盲

1.1.1. scrum是什么意思

以足球为例，足球比赛为半计划状态的的游戏。赛前会制定计划，如阵型（343、442），打法（全攻全守、边路突破）。赛中可能会遭遇一些意想不到的情况，比如说预定的核心人员被看死无法发挥作用，有球员受伤，客场遭遇不利因素，有一种没有预料过的情况不知道谁来处理等。

Scrum中既有计划会、每日立会、评审会等计划和管理活动，又有迭代期内的灵活应变活动，是一种轻重结合的敏捷过程。

有可执行的计划，同时还要有一定灵活应变的能力。这就是Scrum的思路。

1.1.2. 其他的一些过程

敏捷过程较早出现的极限编程（XP），适用于小团队、创业初期，与客户/产品经理共同办公的情况。没有整体计划，在混沌中找到秩序。与客户在每日的沟通中确定下阶段要做的工作，然后执行，有问题随时沟通。比如一天的工作上午混沌沟通，下午逐渐明细，形成成果，客户check结果看可执行的软件。当团队规模越来越大，这种方式就可能变得越来越无法接受。

1.1.3. Scrum敏捷方法一分钟扫盲

Scrum开发模型



Scrum核心概念



流程：角色 & 动作 & 流转

1.1.3.1. Product Backlog

产品负责人建立条目化的产品待开发项，并进行优先级排序。

要点1：两个概念

Product Owner（产品负责人）

Product Backlog（产品待开发项）

要点2：需求要给PO而不是直接发给开发团队

一般情况下，开发团队的输入缺乏全局观，只有是什么没有为什么，导致开发团队只能去解构输入，完成功能。

到底要做什么样的产品？产品有没有市场有多大市场？我们要花多大的价值去做？客户是真的想要特性A还是仅仅是一个想法，可以在一年后再排上日程？提出的需求是关键客户的想法还是一个细枝末节的功能？

在沟通的过程中，如果两端都产生误差，那做出来的产品将大相径庭

要点3：Backlog的特点

采用条目化需求。传统的整体需求分析（及设计）中条目并不重要，所有的需求都会被分析。但现在互联网时代的产品在初期可能没有人说得清楚需求，需求也可能随时在变，无法一次性把所有需求都分析出来。

方便优先级排序。对于优先级相对低的，暂不实现的可以推后分析。

可以根据内外部情况（市场反馈，内部资源）去调整方向、内容。没有发生的工作就没有成本，可以不用作为变更去管理。

1.1.3.2. Sprint Planning Meeting & 故事&任务

在迭代计划会上，产品负责人（给Team）讲解本迭代要开发的条目（而不是写一篇巨长的文档），团队进行估算并放入下一个迭代（直到达到上线）。

要点1：PO主动讲业务而非开发主动

要点2：完整需求文档 vs PO讲解

需求方面：很难找到一个需求人员能把所有的需求都写出来，即使写出来了，时间成本也很高。

开发方面：很难找到一个开发人员能把所有文档都准确理解，一般有了文档仍然需要大量的沟通

言不尽意。沟通本身就有失真，思想转化成文字再转化成思想，失真更大。讲解的成本会比文字的时间人力成本都底。

要点3：开发人员估算工时

要点4：Sprint周期

一般scrum的周期在2-6周，理想的周期一般在一个月。因为1个月足够长，可以做一些基础设计等奠基工作；一个月也足够短，方便控制。一年12个月，12个sprint，可以比较清晰的看出我们做了哪些重要的事情。

要点4：PO和TEAM的相互承诺

PO尽量不在sprint中途增加任务，如果有意外发生，尽量配合开发调整总工作量。

TEAM应按照迭代计划约定完成sprint中的工作，如果有意外发生，应尽早主动提出风险和问题，以便项目组做好应对。

过程中出现的问题应该在反思会上做分析改进。

Sprint中的一些工具

敏捷扑克。工作量估算。

每日立会。进度监控，发现问题，协调处理。

燃尽图。进度监控。

1.1.3.3. Working Software

1.1.3.4. 评审会（Review Meeting）

针对交付产品

1.1.3.5. 反思会（Retrospective Meeting）

针对交付过程

1.1.4. FAQ

1.1.4.1. PO可以在迭代中加需求吗？
1.1.4.2. TEAM可以调整计划（交付时间、内容）吗？

1.2. Scrum中的工作产品

1.2.1. Product Backlog(产品功能列表)

列出整个产品需要完成的功能。

1.2.2. Sprint Backlog（迭代功能列表）

要点1：PO在排Backlog时最好多排1-2个sprint

因为这样可以让开发人员知道下一个sprint可能会有什么工作，在做设计和开发的时候可以预先考虑到，降低损耗，提高产出。这一点与XP会稍有不同，XP更像是“只做眼前事”，所以叫极限编程不是白叫的。。。。

要点2：故事拆分的颗粒度

如果已经拆分到增加XX，修改XX，可以考虑不再拆分了。

对于有些混杂前后台工作的故事，比如web系统和后台（两个系统），或者软件硬件等等，应该拆成不同的任务

如果一件事情只有一个人做，只要颗粒度是可以管理的（如1-5天），也可以考虑不再拆分了。

要点3：注意拆分任务间的关系

尽量避免串行。避免有人需要等待他人完成才能开工。

尽量避免高手只做设计，不写代码。避免迭代开始一堆人闲着，最后一堆人闲着。不便于跨职能团队的形成。

1.2.3. Working Software（可工作软件）

可交付在不同场景下可能意味着不同的状态。有可能是放到生产环境运行（如微信），也有可能不是。当项目没有中间节点的交付要求时，很可能可交付软件并不是真正的可交付软件，而是保留一个可工作状态的软件，在这种情况下，经常在最后保留几个迭代做最后的性能测试、代码优化等等。

1.2.4. 其他

可以关注下QUML：量化UML,分层级的用户故事。

1.3. Scrum中的角色

PO

Team

Scrum Master

1.3.1. Product Owner

1.3.1.1. PO做什么

Sprint前：编写用户故事，确定用户故事优先级。

Sprint中：解释用户故事。

Sprint后：验收“可工作软件”。

1.3.1.2. PO是谁

产品总监。负责决策、预测、定义产品。

产品经理（对外）。负责需求调研、分析、市场活动、竞争对手分析、评审需求等。

产品经理（对内）。负责描述、跟进、细化需求。

要点1：设其责而不设其职

根据产品定位、团队规模等因素来设定职责对应的人。

1.3.2. Team

所有的设计、开发、测试、UI/UE、脚本编制、现场实施等等角色都算Team中的人。

1.3.3. Scrum Master

1.3.3.1. SM做什么

维持Scrum各种活动的秩序

帮助团队解决非技术问题

发现过程中的问题

1.3.3.2. SM是谁

大多数情况下由项目经理担当。

1.3.3.2.1. 要求

能用心帮助团队拜托困难

不会沉迷于团队自身的技术问题

对scrum过程理解深刻

经常与团队在一起

1.3.3.2.2. 从PM到ScrumMaster

注意：不要简单把PM替换成ScrumMaster，而是PM转换为PM2.0

管理 vs 领导

过程 vs 文化

指令 vs 目标

领导压力 vs 同行压力

1.3.3.2.3. 管理vs领导
传统计划：估算和安排任务时间，只排任务负责人。

敏捷计划：组织小组估算任务时间，激励任务领取，协调任务分配。

传统日常活动：监督任务执行情况。

敏捷日常活动：协调团队工作，保障任务执行，揭示并解决潜在的问题。

管理的最高境界是不再区分管理者和被管理者

1.4. Sprint Planning Meeting & Sprint

迭代的第一天，全员参加，完成故事编写及工作量估算，直到达到工时上限。

1.4.1. 一个小寓言

寓言：

鸡与猪的故事

思考：

鸡：轻松，简单说说。

猪：投入，付出全部。

意义：

换位思考

角色平衡

敏捷中的猪与鸡：

/* *********************************************************************** */
------
SM
------
------ | 客户需求 |                    | 实现方法 | ------
PO   | 优先级   | <<<<<< 平衡 >>>>>> | 所需时间 |  TEAM
------ | 实现标准 |                    | 人员安排 | ------

/* *********************************************************************** */

1.4.2. 故事沟通

1.4.2.1. 如何讲故事

故事应该是有层次的。

传统敏捷方法喜欢用列表结构。这是有问题的，无法表达出故事/功能项之间的关联和层次。最好是利用层次做好分类，有助于从整体上来把握整体的需求，明确各个层次直到细节。

阅读：见书《百度阅读：QUML》。建立分层级的用户故事。

1.4.2.2. 如何听故事

开发人员要做什么，不要做什么

1.4.3. 迭代计划会的整体过程

两种估算方法：

bad way：讲完所有故事，完成所有估算。

good way2：讲1个故事，估算1个故事。

执行步骤：

PO讲解故事1，TEAM估算故事1;

PO讲解故事2，TEAM估算故事2;

……

PO讲解故事n，TEAM估算故事n;

达到Sprint交付极限。

好处

加强互动

避免PO溜号，在估算过程中很有可能发现还需要共同讨论的问题

1.4.4. 计算有效工作日

举个栗子：

22day - 2day         // 计划会1day，评审会&反思会1day
= 20day -5day        // 培训出差请假5day
= 15day * 0.5~0.7    // 修改bug、现场问题处理、额外任务等占用30%~50%
= 7.5day ~ 10day

结论：若团队有10人，则有效工作日有75-105人日（迭代最大工作量）。
注意：一般刚成立的团队或刚实施敏捷的团队，取最低值75人日。

1.4.5. 团队做什么

团队要做的：

对不清晰的需求提出疑问

通过疑问帮助PO分解需求

通过疑问弄清楚何为当前最急迫的需求

帮助PO分析哪些需求会影响到架构

团队不要做的：

执意提出新需求

执意安排优先级

1.4.6. “任务估算”的行为模式

PO。解答需求争议问题。澄清需求实现程度。

Team。讨论，估算。就需求争议提问。

注：PO必须在估算现场。

1.4.7. 一些工具

1.4.7.1. 敏捷扑克

其实就是delphi变体，基于专家判断和共同估算

执行步骤

各自估算

最高值与最低值讨论

新一轮估算

……

达到近似一致

1.4.7.2. 每日“立”会

一般3-7人，很少有超过10人。

5-15分钟。

向团队所有团队汇报而非向PO/SM/PM汇报

三个问题：昨天做了什么。今天准备做什么。在工作当中遇到哪些困难。

更新进度。完善check-list和work-list

关键点1：为什么不是向领导汇报

领导一般无动于衷，写了也不知道我们在做什么，无法对具体问题起到什么帮助。大家会认为写了也白写，应付工作。

汇报对象是同行，是有互动，有共鸣，有交集，有关联的。

1.4.7.3. 故事板/看板

方法要点：

用board区分三类故事：待开发、开发中、开发完毕。

记录不同状态故事的工时、总工时、剩余总工时。

尽量减少开发状态的用户故事数量（WIP）。

每个人最好同时只开工1-2个任务。

最重要的作用：

可以随时看到进行中的任务有哪些。在迭代结束的时候，最理想的情况是，没有任何开发中的故事，要么是待开发项，要么是开发完毕项。

辅助的作用：

工作进展透明化。

1.4.7.4. 燃尽图

为数不多的度量工具。用曲线计划会后的总工时。然后按照实际剩余时间去标记

1.5. 敏捷生态——工具应用成功的关键

如果只做每日立会，其他的活动都不开展，能够成功吗？

这是生态问题。敏捷过程中的每一种活动都有它的意义，都是能够对其他某些活动起到帮助作用，或者需要其他某些活动的支撑，这就是敏捷开发生态系统。

1.6. 评审会与反思会

1.6.1. 评审会

1.6.1.1. 主要工作内容

小组向产品负责人展示迭代工作结果。

产品负责人给出评价和反馈。

以用户故事是否能成功交付来评价任务完成情况。

1.6.1.2. 如何开评审会

要点1：使用Time Boxing(时间盒)

采用时间盒（Time Boxing）的方法，即限定时间而不限定范围。所以迭代不会延期，因为在迭代终点将放弃未完成的故事。

它隐含的意义在于，告诉每个人迭代最重要的目标并不是完成所有工作，而是尽快交付以便实现商业价值。

这种方式的好处在于：

对于开发团队来说，可以避免不出承诺的情况。不是说有任务没有完成就可以再往后拖几天。

对客户来说，尽早发布就可以尽早产生商业价值。Scrum的Sprint交付成果Working Software可以被形象地称作Scrum的心跳，如果心跳紊乱，无疑并不是好事。

评审会将只评审已经完成的工作，未完成的会被放到下一轮Sprint中。这里可能存在一个问题：当前Sprint未完成的工作，在下轮Sprint中是否一定是高优先级的？也未必，PO需要去对比。

要点2：评审的标准是整个故事是否已经达到交付标准

如果一个故事处在“差一点就完成了”的状态，也算没有完成。常常发生很多故事都已经开始开发，但都差一点完成的现象。因此应按迭代内的优先级逐条开发和交付故事。一般总是优先开发MoSCoW方法中必须完成和应该完成的故事，再考虑可以完成的故事。

另外，可以通过设置恰当的故事的大小来提高交付效果。如果一个故事小一些，就会比较容易完成。

要点3：可工作软件是指可在生产环境正常工作而非研发环境

举个栗子，一个OLTP的场景，一个B2C商品交易的史诗故事应该包括挑选、购买、物流、评价、退货等故事。当我们在一个sprint中只完成了购买的测试，并不能证明已经达到working Software的标准，正确的做法是完成整套测试。

要点4：Sprint Planning应该给故事做设好优先级

优先级不仅包括排序，还应该明确该故事是“必须”的（sprint核心故事），还是“应该”的（根据sprint可用工时来说可以完成），还是“可选”的（根据情况选择是否完成，如果进度快就多做一点）。

要点5：Sprint Planning设定每个故事的完成标准

如是否需要测试，是否需要考虑性能，是否需要说明文档等等。这些标准一般由项目组
提前列好，每个故事只需要选中是否需要即可。

有的故事的标准应该是不同的。有些故事是需要科学计算绝对准确的，有些本身就是尝试做看看效果的，交付标准就不会一样。

要点6：可以选择渐进式评审

尽管有正式的评审会，但很多团队习惯在单个故事完成时，就让产品负责人进行单个故事评审，以确保交付时不会有“惊喜”。

要点7：评审发现的问题如何处理

评审会上发现的问题或改进将被累积到Product Backlog，也不会马上或在下一个迭代中开发，而是由优先级排序决定何时开发。

1.6.2. 反思会

1.6.2.1. 主要工作内容

每个迭代末尾召开简短的反思会。

总结哪些事做的好，哪些事做的不好。

选择最多三件可改进的事情，制定改进计划。

1.6.2.2. 如何开反思会

反思会是Scrum（传统瀑布项目也一样）是最难以实施的活动之一

要点1：不要让反思会编程抱怨会

项目中经常出现一些无法控制的事情，比如最典型的客户临时加需求。这些显然会对交付进度和质量以及团队带来一些负面的影响，这些可能并不是反思会能够解决的（总有一些问题是无法处理的），这种都是效果不好的反思会。好的反思会应该是去反思那些我们能够改变的问题。如果还是觉得很不爽，可以想想天朝的房价，看看开反思会有没有意义。

发现问题、持续改进、取得效果才是反思会的目标。

要点2：避免经常出现一些多次被提到但却始终没有解决的问题

应该每次仅就1～3个关键问题做出可行的解决方案，在下一个迭代执行改进。“可行”的概念包括两个含义：第一是方法简单，影响面小，见效快；第二个是目标不要激进，而要现实可行，积少成多。

避免去找客户的茬、老板的茬、企业文化的茬。

要点3：

如果必要可以执行领导回避制度，即具有管理职能的人不参加反思会，即使这些人是产品负责人，项目经理，乃至Scrum Master。

1.7. 扩展Scrum

1.7.1. Scrum的团队规模

1.7.2. Scrum of Scrums

Scrum of Scrums是把Scrum扩展到大型项目团队一个重要的实践。

Scrum of Scrums是跨团队的沟通与交流。

Scrum of Scrums是多层次的

一般做法是由各个Scrum团队的代表参加Scrum of Scrums会议，会议同样要采用固定的频率和时间箱机制，频率可以有团队根据自身情况确定，一般可以一周2到3次，不一定要每天。对于会议长度，Ken Schwaber的建议是控制在15分钟，会上提出的问题应及时组织相关人员处理。

1.8. 敏捷开发的历史，现状与未来

1.8.1. 软件生命周期模型对比

1.8.2. 不定周期开发——看板

不定周期开发：纯看板开发模式（流模式）。

非常适合维护已有软件

1.8.3. 可变周期开发——QUML+Scrum模式

适合持续交付。

1.8.4. 未来动向：企业级敏捷框架SAFe

Scaled Agile Framework 3.0

1.9. 参考资料

1.9.1. 参考资料

《火星人敏捷开发手册》 —— 陈勇

《Scrum介绍》 —— Scrum中文网

《Scrum指南》 —— Scrum中文网