Scrum3.0 敏捷开发白皮书
一、什么是敏捷？
敏捷是一种以用户需求为核心、采用不断迭代的方式进行的软件开发模式。敏捷依靠自组织
的跨职能小团队，在短周期内，做出小块的东西来，通过快速、频繁的迭代，迅速的获取反
馈，进而不断的完善产品，给用户带来更大的价值。敏捷的特点是轻文档、频繁发布、高效
沟通。
二、为什么敏捷？
1）拥抱变化。信息时代瞬息万变，存在着太多不确定性。今天有价值的东西，可能明天会
变得不那么有价值。我们没有变法让一切不变，也没有办法来控制变化，我们只能选择去拥
抱变化。快速迭代的敏捷就是拥抱变化的方法。
2）快速响应。市场环境的变化，越来越要求产品、服务的响应及时。无法快速响应用户的
需求，就没有办法留住用户，没有用户就没有一切。
3）迅速将功能推向市场。没有人能预测未来，没有人的想法是绝对正确的，只有经过市场
验证的产品知道它的好坏。敏捷可以让产品快速推行市场，快速试验，避免走弯路。
三、敏捷的方式有哪些？
敏捷的方式有很多，给大家介绍几种我们常见的：
XP（极限编程）：
XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周
期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚的知道开
发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。XP
注重的核心是沟通、简明、反馈和勇气。
SCRUM：
Scrum 是一个用于开发和维护复杂产品的框架 ，在这个框架中，整个开发过程由若干个短
的迭代周期组成，一个短的迭代周期称为一个冲刺（Sprint），每个冲刺的时间通常是1到4
周。在冲刺中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。在每个迭代
结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum它是一种可以集合各种开发实
践的经验化的框架，也是目前最流行的敏捷开发方法。
精益开发（ Lean Development ）：
精益软件开发模式是从丰田公司的产品系统开发方法中演化而来。
它主要包括两个部分：一部分是核心思想及原则，另外一部分由相应的工具构成。
精益开发的核心思想是查明和消除浪费，在软件开发过程中，错误（ bugs ），没用的功
能，等待以及其他任何对实现结果没有益处的东西都是浪费，浪费及其源头必须被分析查
明，然后设法制止。
敏捷开发方法还有很多种，每一种敏捷方式都有自己的特点，只要选择适合你们团队的就可
以，这里我们会给大家着重介绍SCRUM3.0。
四、SCRUM 3.0 敏捷方法
1、什么是Scrum？
Scrum本意是指橄榄球中的“带球过人”。
在球场上，在比赛每段的开始，双方都要摆开阵势，并计划本段的进攻/防守路线和策略，
教练和队长都可以参与计划。当哨声响起，尽管队员们努力按照既定计划推进，然而场上瞬
息万变，队员不可能实时按照教练或队长的指令亦步亦趋地行事，而是靠平时训练中形成的
素养见机行事，达成目标。
在软件开发公司，在每个迭代的开始，团队领导者都应该做好本迭代的计划，尤其是需求条
目的优先级排序、选择本迭代的工作、设定必须完成的内容等。在每个迭代开始后，团队领
导不可能也不需要事必亲恭地介入每件事情，而是应该由具体执行的人选择如何去做。团队
领导要做好的是协调资源、解决困难、提供指导，以达成目标。
Scrum 3.0是2017年6月发布的一个Scrum衍生版本，相比Scrum Guide 更贴近国内的组
织架构，产品开发模式，更适合我们的使用场景。
2、Scrum 3.0 的主要构成
scrum3.0中主要包括三个部分：六个角色、两个工具、四个会议
2.1 六个角色
Scrum团队是一个自组织的团队，整个团队除了开发人员外，共有六个角色。
1）业务所有者（Business Owner，简称BO）：
我们的产品经理，他负责对运营、市场、销售等部门人员（利益相关者）提出的需求进行拆
解以及进行优先级排序，并负责后期的产品评审，同时负责预测一个sprint周期的时间。
2）团队队长(Team Captain，简称TC)：
我们的开发经理，负责安排一个sprint内的工作安排，通过合理安排让scrum团队的效率以
及价值最大化。
3）协调人/教练(Facilitator/Coach，简称F/C)：
scrum制度的落实者，让scrum在团队中流畅的运作，解决问题，提高Scrum和敏捷的使
用。
4）推动者 (Change Agent，简称CA)：
Scrum的咨询顾问，将Scrum引入团队中，并帮助教练理解如何最好地支持和与Scrum团队
合作。
5）利益相关者(Stakeholders)：
我们的CEO、运营、市场、销售等部门相关人员，他们向产品经理提出产品需求。
6）行业专家(Subject Matter Experts，简称SME)：
行业专家拥有Scrum团队需要的，但团队中没有的知识和专业技能。
2.2 两个工具
1）产品清单（Product Backlog ）：
产品清单是记录所有产品需求的列表。产品经理（BO）收集来自CEO、运营、市场、销售
等部门（Stakeholders）所提出的产品需求后，将产品需求进行优先级排序，排序后的产
品需求列表就是产品清单。产品清单中的产品需求是以用户故事的形式描述。
2）冲刺清单（Sprint Backlog）：
冲刺清单是开发团队在一个Sprint中所要开发的全部产品需求。冲刺清单的内容，一部分是
从产品清单中筛选出的高优先级的产品需求。另一部分是开发团队提出的技术需求，这些技
术不能以功能的形式展现给用户，例如数据库优化、接口优化等。冲刺清单中的需求是以细
化后的产品需求文档的形式描述。
2.3 四个会议
在整个Scrum 3.0中，会有四个会议，它们是:
1）冲刺计划会：
冲刺计划是Scrum团队在冲刺开始时进行的一个会议，目的是确定本次冲刺的目标是什么，
决定本次冲刺需要做完那些需求，判断所有的需求是否足够的？
2）产品评审会：
Scrum团队在冲刺结束时会进行产品评审，产品评审会上，产品经理（BO）会对做出的功
能进行验收，功能是否符合CEO、运营、市场、销售等部门（Stakeholders）提出的需
求。
3）进度回顾会：
产品经理、开发经理（TC）、团队开发人员共同进行进度回顾，了解我们在结束的sprint中
哪些功能完成了，哪些功能没有完成，没有完成的功能如何做出调整（删除、重启、延
后）。进度回顾可以帮助我们对冲刺的交付周期以及一些需求安排做出调整，让团队更高效
的产出。
4）团队回顾会：
团队回顾由教练(F/C)来推动，讨论我们这次冲刺做的怎么样，我们团队还存在着什么问
题，我们需要如何改进，并在下一个冲刺中，将改进措施付诸实践。
3、Scrum 3.0流程
Scrum 完整的流程是怎样呢？
3.1 冲刺准备
1）整理产品清单
产品经理（BO）收集来自CEO、运营、市场、销售等部门（Stakeholders）所提出的产品
需求后，将产品需求进行优先级排序，形成我们的产品清单。产品经理收集的产品需求往往
可能是一个很大的、定义不是很明确的功能，需要产品经理将它拆分成一个一个小的用户故
事，记录到产品清单中。
2）
制定冲刺清单
产品经理与开发经理（TC）从产品清单中，筛选优先级高的产品需求，放入本次冲刺清单
中。此外，收集开发团队的技术需求，挑选本冲刺需要完成的，一同放在冲刺清单中。产品
需求和技术需求统一排序后形成最终的冲刺清单。注意，冲刺清单中的产品需求必须是已经
准备好的，以产品需求文档形式描述的，可随时进入开发阶段的需求。
3）
开冲刺计划会
会议上，产品经理讲解冲刺目标，即通过实现产品清单要达到的目的以及达成该目标所需完
成的产品需求。整个 Scrum 团队拆解具体的执行任务，评估每个研发任务的工作量，确保
所有工作符合整个团队的产能。
3.2 冲刺中
冲刺计划会后，正式的冲刺就开始了。每天可以通过每日立会，为今天一整天的工作制定计
划。同时，通过检视昨天工作和评估剩余的工作来优化团队协作和效能。
3.3 冲刺结束
1）开产品评审会
在Sprint结束时，会由产品经理对一个sprint内的交付结果进行评审，验收功能是否符合
CEO、市场、销售、运营等部门提出的需求。
2）开进度回顾会
产品评审会议后，产品经理、开发经理、团队开发人员共同进行进度回顾，了解我们在结束
的sprint中完成了哪些功能，有哪些功能没有完成，没有完成的功能如何做出调整（删除、
重启、延后）。
3）开团队回顾会
最后是团队回顾，团队回顾由教练(F/C)来推动，讨论我们做的好么，我们团队还存在着什
么问题，我们需要如何改进等问题，将讨论的结果付诸于下一个sprint中。同时开启下一个
Sprint。
五、日事清实施 Scrum 最佳实践
5.1 组建Scrum团队
实施Scrum的第一步就是组建我们的Scrum团队。通常我们的产品团队会有产品经理、开发
经理、前端工程师、后端工程师、测试人员这些角色。组建一个Scrum团队，只需任命产品
经理担任我们的业务所有者（BO），开发经理担任我们的团队队长（TC），将前端工程
师、后端工程师、测试人员组成开发团队，我们的Scrum团队就组建完成了。
5.2 创建开发项目
在组建了Scrum团队之后，我们要为我们的团队在日事清中创建一个计划，将整个产品的开
发过程可视化。通常我们会以产品的名字来创建一个计划，比如【日事清项目】。创建的计
划的同时，我们要将Scrum团队中的所有成员添加到计划中。
创建好计划后，我们要将整个【日事清项目】划分成【RoadMap】【产品开发】【用户需
求】【BUG管理】4个子计划，下面我们会介绍如何使用这四个子计划完成敏捷开发。
5.3 构建产品清单
在创建计划之后，整个团队就要按照Scrum的流程开始运转了。整个Scrum流程的起点是产
品清单，每一次冲刺迭代都是围绕产品清单展开的。在日事清，产品清单是通过
【RoadMap】完成的。Roadmap中，每个卡片是一个冲刺迭代，卡片中的任务是该迭代
的产品需求，整个Roadmap中的所有需求就是产品清单。
Roadmap是如何制作的呢？
首先产品经理将从CEO、运营、市场、销售等部门收集产品需求，然后将这些需求根据优先
级、产品策略，划分到不同的冲刺迭代中，并不断的去维护更新每个迭代版本中的需求。
Roadmap中的产品需求以用户故事的形式描述，越近的迭代版本描述越需要完善。当前版
本中的每个产品需求要以产品需求文档形式描述，因为这个是开启一个sprint的基本前提。
下图中展示了产品迭代版本的规划，以及详细的需求记录：
5.4 开启冲刺
在每次开启冲刺前，会有一个冲刺计划会。这是一个非常重要的会，一定要用日事清的日程
功能下发一条任务，和所有人沟通好时间，确保会议顺利进行。
在冲刺计划会上，我们会用到【产品开发】子计划，这个子计划中包括【规划池】【开发
中】【测试中】【待发布】【已发布】5个流程卡片。
每次在冲刺计划会开始之前，产品经理需要将规划的本次迭代的需求从【roadmap】中复
制到【产品开发】的【规划池】中。
同样，技术经理也需要提前将开发团队提出的技术需求放入【规划池】中。
在开会时，开发经理需要带领这个开发团队去细化规划池中的产品需求，并将每条需求任务
添加成员和时间，合理的安排开发团队中每个人的具体开发工作。
如果整体工作量超出了团队的产能，需要适当的将一些需求放到下个迭代；如果低于产能，
需要将后续版本中的需求放入本次冲刺，以确保团队的效率最大化。同时，产品经理需要确
保所有的需求处于准备好的状态。冲刺计划会的结束，宣告了本次冲刺的开始。
5.5 确保冲刺按规划进行
冲刺是一个scrum中耗时最长、最复杂的环节，整个冲刺过程是以看板的形式展示，每个人
都可以清晰的知道当前冲刺的每一个需求的进度。
当开发人员准备开发某个需求时，会将该需求从【规划池】拖入【开发中】，当该需求开发
完成后，开发人员，会将该需求打钩。开发经理将开发好的需求提交测试后，会统一将【开
发中】所有任务移动到【测试中】供测试人员测试。测试通过后的需求，测试人员会将该需
求拖入【待发布】中，等待产品经理验收。当然在整个开发过程中，开发人员以及测试人员
都会及时的与产品经理进行沟通，以免需求出现偏差。
为了更加直观的反馈冲刺进度，我们提供了统计功能，可以查看本次冲刺中需求的走势，每
天的需求完成情况，以及每个成员的完成情况，确保所有的需求都是按照规划进行。
除此之外，开发团队会进行每日立会，用来及时发现团队中的问题，及时解决。立会中，每
个人会反馈3个问题：
我昨天做了什么？
我今天要做什么？
我遇到了什么困难？
5.6 完成冲刺
当冲刺的时间到期时，就意味着本次冲刺正式结束了。无论需求是否有做完，都需要停止，
并将未完成的需求放入下一个冲刺中。
一次冲刺结束后，产品经理会对【待发布】中的需求进行验收，对通过验收的需求打上标签
【产品已验收】。
当所有需求都通过验收后，产品正式迭代更新。更新完成后，所有的任务拖入【已发布】
中。
同时，会进行一次进度评审会，进度评审会上会分析一个周期内，我们完成了哪些任务，哪
些任务没有完成，并对没有完成的任务做出调整，将未完成的任务回归到【规划池】中，或
者删除。
除此之外，还会开一个团队回顾会，会上讨论三个问题：我们上个迭代有哪些事情做的好希
望继续，那些事情做的不好希望改进，有何改进计划。
5.7 开启下一个冲刺
一个冲刺已经结束了，回顾也做好了，那接下来我们要做什么？当然是开启下一个冲刺了。
当产品更新迭代新版本后，我们的运营、市场、销售的相关人员（利益相关者）会收到用户
反馈的需求和BUG，这时就需要用到【需求管理】【BUG管理】子计划了，【需求管理】
用来记录用户的需求，【BUG管理】用来记录产品的BUG。
这时产品经理也需要注意，【需求管理】【BUG管理】也会变成你【Roadmap】中的重要
组成部分，在做【Roadmap】时不要忘记他们。
每一个冲刺之间都是环环相扣的，一个结束意味着要快速的进行下一个，所以在产品经理需
要在上一个冲刺进行过程中准备好用户故事，当一个冲刺结束后，马上进入各种会议，开启
下一个冲刺。
六、写在最后
你是否已经明白如何在日事清上实践scrum3.0了呢？scrum3.0提供给我们的只是一种方
法，每个团队都可以根据自己的情况去做适当的调整，让这个方法更适合你的团队。
欢迎您通过我们的官网（www.rishiqing.com）来体验我们
