玩转Scrum（中）

Posted 2021-04-25 项目经理沙龙

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了玩转Scrum（中）相关的知识，希望对你有一定的参考价值。

来源：欣旋敏捷VIP会员群

敏捷VIP群的各位学员们，满满的Srcum干货又来了，今天继续由我们的嘉宾刘峥老师，进一步深入地为大家讲解Scrum的实战经验。

上期回顾

在的课程中我们学习了以下内容：

1.敏捷宣言中经典的5句话

不少学员在看完之后纷纷会提出“既然是敏捷，文档还要吗？”。其实，敏捷宣言中指的是不是不要文档，而是文档可以少些或简化，应该把更多的关注放在可用的软件上。敏捷宣言并不支持大家“裸奔”。

2.Scrum 概述

嘉宾从Scrum单词的来源到Scrum的流程图，分别给大家做了概要的描述。其中特别强调了要记住Scrum的三个数字“143”，一个流程图，4个活动，3个角色。

3.玩转Standup Meeting

Standup Meeting作为Scrum的方法中重要的活动，嘉宾在上期的课程中做了详细的讲解。对于充分体现敏捷文化的这个活动，要想真正实施好需要遵循3个规则：

每天召开
15Min
鸡与猪的原则

4.讲解了Standup Meeting中常用工具 — 白板（White Board）的运用

Scrum方法中4个活动中的第二个活动Planning Game（规划会议），为什么叫Game？接下来由嘉宾为大家来揭晓。

玩转Planning Game（规划会议）

▼▼▼

Planning Game Ground Rules

（规划会议基本原则）

1.产品Backlog井然有序

Backlog可视为需求列表，但是这里面的需求是经过整理的，有一定顺序的。

一般Backlog就具有以下特点：

需求总是有的，但其实也可能是不存在的。所以，Backlog中的需求是经过深度思考的，需求的品质是有保障。
一个Team只有唯一的产品Backlog
Backlog一般已经初步有优先级的设定，会按照从高到低进行排序（为什么是初步，先卖个关子，之后会给大家详细说明。也就是说开会前一定是有个优先级的）

2. 2-4小时

规划会一定要在2～4小时内结束。对于每一个Scrum Team来说是一个固定值。就像一个时间盒，容量有限，无法压缩或撑破。那么问题来了，为什么设定时间限制呢？这是敏捷设计的巧妙之处。一般基本上2～4小时是能够把问题讨论清楚的。如果时间不够，可以先按时结束，再约会议时间继续讨论。不过～4小时都讨论不清楚的问题，再多4小时也讨论不清楚……因此，要保证2～4小时内完成有效的规划会议以下三点前提：

1）初期Backlog必须是有一定优先顺序，是经过考虑的。

2）对于需求的讨论不要需要到很细很细的程度，一般需求讨论下来80%～90%的方向已经很明确了就可以不用再讨论了。在实施过程中是不断Check不断调整的过程。

3）一般Scrum Master发现时间到了就要出来提醒大家。通常在4小时内Srcum Master整个会议中会时刻提醒大家按照规划会议的实施要求开展会议。

合理的产品Backlog所具备的要素

产品Backlog就是需求列表，没有Backlog就没有需求了，所以，产品Backlog是Srcum的核心和起源。

按照下图我们分别从横向和纵向分别来看Backlog包含哪些要素。

1）横向

每一行代表一个用户故事（Name），可视为一条需求。

2）纵向

① ID：用于唯一标识用户故事，方便统一称呼。

② Importance：重要度。传统情况下，通常我们用紧急、高、中、低、轻微等文字的方式来定义，那么如果同样为紧急的需求就可能撞车了，到底哪个更紧急呢？就无法区分了。但是Scrum方法里是用数字来表示重要度。Backlog中所有需求没有并列的重要度的情况！反映的现实就是在研发过程中一个产品每天只能上线一个需求时，不可能又要这个需求又要那个需求，所以，一定要区分所有需求的重要度。一般用数字表示时，重要度高时相应的数字就大一点，重要度低一点数字就小一点。但是这些数字仅表示重要度的排序，他们之间并没有量的关系，他们是离散性的数值。例如，A需求被估算出30个点的规模，B需求是10个点，并不表示A比B重要三倍。用数字表示的另个一好处是如果需求增加，重要度定义值可以在已有数字范围内插入就行了。

③ Estimate（估算规模）：一般故事点数来估算用户故事（需求）的规模，用“完美人天”来估算，指一个研发人员不受打扰的一天所能完成的故事规模（点数）。要事先定义一个原子规模单位，然后基于单位规模估算各个需求的规模。一般在估算过程中会邀请一些有经验的人员一起来估算，给出大概的估计。

④ How to Demo：就是如何演示。可视为如何验证。与我们常说测试用例有点类似。

⑤ Note：就是备注说明。

3）产品Backlog管理规则

产品Backlog的管理规则有以下几点：

① PO是产品Backlog的Owner。

② 管理运用的工具有很多，一般Excel就够了。

③ 产品Backlog的内容一定是停留在业务层面上的。这里要区分技术方案，产品Backlog是有PO负责的，所以只要到业务层面即可。

怎么做任务拆分和估算

由于之前阶段产品Backlog中对需求已经做了排序，接下来就要把用户故事（需求）拆分成所有可实现需求的任务。例如，编码，测试，用户文档编写，内部质量活动（如：评审）。大家一定好注意：在敏捷开发中永远不要放弃内部质量！很多团队都认为如果项目要如期上线就要放弃质量，结果质量不好有问题就要加班对应。越到后期的返工，成本也就越高。这样就会造成一种恶性循环。

Scrum方法中常用计划纸牌的方法估算需求规模，这点也体现了Game的乐趣。

上图中每张牌的“数字”代表点数，“？”代表不确定，“咖啡”代表休息。一般研发团队成员用上图的纸牌对工作任务进行估算，每个人都有一副纸牌，每个人只能出一张对每个任务进行估算。这样既能实现群体估算，同时让每个成员可以独立去做估算。当然，纸牌估算可能一开始大家出牌点数差异会比较大，所以一般估算会分多次实施，大家在一起，对于每一次出牌点数处于两端的成员进行解释自己的估算结果。通过多轮出牌估算后，大家的出牌的点数会逐渐接近，最后用一个合理的大家都可接受的故事点来代表工作任务的规模。通过打牌方式也是为了促进团队成员间的沟通，鼓励大家去讨论，与其他团队内部成员、PO达成共识。大家是不是觉得和我们之前学习的Dephi估算方法有点类似。他们同样需要满足以下两个前提条件：独立估算和多次实施。

当然，用Scrum统一打牌的方式估算结果与周边团队估算结果不应该差异很大。

怎么确定Sprint内容

Planning Game的输出就是确认哪些需求是可以完成的。一般有以下两种方法来确定Sprint的内容。

1.本能估算

顾名思义就是靠团队成员本能来集体估算，拍一个人的脑袋可能不准确，但是一群人的脑袋，估算的准确率就会大大提升。例如，一个需求问大家是否可以完成是，大家异口同声表示没问题，那么基本就是没有问题；如果有分歧，那么这个需求可以暂时放一放，稍后再讨论；如果异口同声表示无法完成，那么这个需求一般在本次Sprint中不做。

2.生产率（Velocity）

本能估算比较定性，如果不放心可以采用量化估算。一般根据整个团队的生产率来估算。刚才也说了需求规模一般用“可用人天”数来估算，所以如果估算一个Sprint的开发内容时，可采用以下公式：可用人天X投入度=估算点数（即可完成的点数）

例如：6人团队一周工作时间为5×6=30人天，但是如果有1个人预订休半天假，估算时可完成的点数为28.5人天。

大家平时在估算会在可用人天上设定buffer，但是Scrum方法中buffer是留在投入度中，而投入度又是参考以往Sprint的结果。所以，Scrum也是一种经验型的管理方法。

1）生产率估算一般需要横向/纵向进行参考

横向是指要参考其他周边类似Team的生产率，虽然敏捷强调每个团队各有特性，但是横向参考可提升自己团队估算的准确性。

纵向一般指一个团队根据自己以往的Sprint的生产率，估算本次Sprint的生产率。

2）如果是第一轮Sprint没有以往经验参考时，可以默认投入度为70%左右

在确定Sprint内容时需要遵循以下两个原则：

1）一定要在Sprint里确定必做和可选需求

2）研发团队自己做决定

那么如果你是PO，想要团队实现自己的需求，又不能违背以上原则，PO该怎么呢？

从下图你可以得到答案。

Option1：调整需求优先度，上图上中可以看出PO调整了D的优先级。

Option2：调整需求的范围，上图中可以看到PO减少了A的内容。

Planning Game中确定完需求之后，一旦Srpint开始了整个开发过程中需求不能再做很大的调整了。所以，每次规划会议之后一定要召开Kickoff或发送象征Kickoff的通知邮件。宣布开始开发，同时宣告大家在此期间需求不能再做调整了。这封邮件无论大家看不看一定要发。

Q & A

规划会议的介绍就到此结束，接下来是答疑环节。今天的敏捷VIP群学员会有哪些疑问呢？让我们一起来看看嘉宾如何帮助大家解决的。

Q1：规划会议时PO说没空参加怎么办？

A：一般有两种方法：

1）让代理人出席。前提：代理人代表PO发言作决策。他的决定就是PO的决定；

2）改期。

从以上方法来看，原则上PO是一定要参加规划会议的。

Q2：怎么处理技术故事？

一般研发人员都是在研发中做技术改造的。但是建议可采用以下两种方法：

1）不要有纯的技术故事，例如，改造DB，优化查询等。一般从PO的视角来看，不会同意技术故事放在Backlog中作为需求，他们一般从产品角度更关注价值，所以要以商业价值的角度向PO说明处理技术故事的好处；

2）在每轮Sprint中预留一些buffer专门处理技术故事，例如，一般预留5% 。

Q3：怎么处理以前的Sprint的BUG？

A：一般有三种方式可供参考：

1） PO觉得这些BUG无法容忍了，就会作为下轮高优先度需求进行处理；

2）和技术故事方式类似；

3）如果上轮没有BUG出现可以把可选需求提上来做。

Q4：如果团队成员对所做的事情都不了解怎么办？

A：一般有三种做法可供参考：

1）极端情况下规划会议上大家都有这个情况，建议这个时候就该停止Planning Game，事先做个调查；

2）在每个Sprint中都预留出一些时间了解下一个Sprint的需求，作为必做的任务；

3）白板上右下角预留Next Sprint部分用于贴一下需求，让大家预言下一个Sprint的一些需求以便开规划会议时能够更准确的做沟通。

这次的课程内容即将结束，在这次课程中嘉宾介绍的Planning Game实践是不是感觉信息量特别大需要好好消化？大家可以在学习完本期的《玩转Scrum 中》后，再重温一下上期的课程内容，这样才能更好的理解Scrum方法的精髓。同时，我们也期待下期嘉宾为大家介绍Scrum中4个活动的剩余的两个活动演示会和回顾反省会（Demo & Retro Meeting）。