Day2 Scrum玩法基于Scrum框架的敏捷究竟如何运行

Posted 2021-04-25 百丽敏捷工作坊

2019-03-19 12:03:14

全世界只有不到 1% 的人会朝着自己的梦想行动

你真是个特别的人

                   

7天训练营-Day2

在Day 1的课程里，大家已经了解到Scrum，那今天我们就一起来看看Scrum究竟是怎么玩的呢？

Scrum自1995年开始，到今天已经有20多岁了。到了弱冠之年的他，终于焕发出了他“青年军”的力量。

在神州大地，推行敏捷的企业几乎都是从Scrum开始，这就是“青春风暴”。可是我们依然能看到很多企业被这股“风暴”虐得很惨，Scrum的真实模样究竟如何，今天一起来揭晓喽。

七天训练营-Day 2的课程内容大致如下：

1.Scrum的开发流程和模型是怎样？

2.Scrum中提到的“3355”是什么呢？

3.为什么Scrum有那么多会议？

4.Scrum落地时说的“GASP”是什么，有什么用？

Scrum的开发流程和模型是怎样的？

“Scrum”这个词来源于橄榄球队的技术术语，然而形成如今风靡全球的Scrum大法，却并非一朝一夕的事情。

作为Scrum之父，Jeff老师的一生可谓传奇至极，他曾经是越战的侦察机飞行员，在执行任务时他就已经学会了：观察、导向、决定和行动的良性循环作战方法。

 

越战结束后，Jeff老师回到了美国，并在斯坦福大学攻读硕士与博士学位。在他求学的这段时间，他花费几年的时间发现了一个正常细胞发生癌变的因素。

他在这段时间学到了很多关于系统论的知识，理解了为什么一个细胞开始演变时，会从一个稳定状态过渡到另一个稳定状态。

 

此后的10年时间里，他一直扎根于研究如何推动一个复杂的自适应系统从一个状态过渡到另一个状态，以及如何确保下一个状态是积极的，而非消极的。

 

到了上个世纪80年代，Jeff老师服务于一家计算机服务公司，这家公司为全美多达150家银行提供ATM，最终，Jeff老师也成功地带领团队完成了交付任务。

而我们今天看到的几乎所有的自动柜员机系统都是以他当时开发的Nonstop Tandem系统为蓝本。

 

正是因为这一次非常成功的产品开发经历，Jeff老师抽丝剥茧地提出Scrum的管理流程和要素，逐渐形成了比较系统的一套方法论。

 

时间到了上个世纪90年代，因为一个偶然的机会，Jeff老师在一家公司时，受到他们制造机器狗的启发，机器狗是采用去中心化的理念打造的，Jeff老师将这一点加入Scrum，让Scrum的方法论更加完善。

 

直至1993年，Jeff老师正式提出了Scrum理论，他是对自己过往近30年的思想融合，也是过往实践经验的高度浓缩。并于1995年与Ken一起发布论文阐述Scrum。

 

Scrum之父，是对Jeff老师最精华的概括，即使到今天，他仍然在思考如何能让Scrum的流程更有效，适用的范围更广。

 

那么接下来我们就来看看这一套让谷歌、亚马逊等知名或者不知名的更多公司飞速运转的Scrum，究竟是如何跑起来的。

Scrum是怎样工作的

想必我们已经在其他很多地方都看到过它的流程，但是这些流程之间的关键是什么，哪些环节是更加重要的，如何确保Scrum更好地实施等，这些问题，是Scrum工作方法给予我们更深入的思考点。

 

这一次，我们一起看看Scrum流程究竟是怎么一回事？

     

Scrum的实施流程

1.如果我们从一开始就是奔着想要成功的角度去看待Scrum，那么一开始就要做好准备。而第一件事情就是对Scrum价值的认同，这绝不是也不应该是一句空话，相关人员都应该能够Get这一点，不是听过、看过就足够。

 

2.当大家已经做好了准备，都认为有做这个事情的必要时，那么才开始接下来的事情。

  

然后我们要去解决两个问题：一个是谁来通过什么安排大家做事情，另一个是大家应该怎么去做事情。

 

2.1这时候我们就要挑选一位产品负责人，也就是PO，让他通过Product Backlog来梳理需求，而且梳理出差不多一个迭代可以完成的事情。怎么界定这个Product Backlog梳理出来的需求满足了一个迭代需求呢？当我们认为拥有Confindence，可以满足一个迭代的工作量了，就可以了。

 

2.2关于大家应该怎么去做这个事情？其实就涉及到Team的队形设计，这其中就包括技能、专业知识、职能的各种搭配，完成全职能的队形设计。这一点极其关键，甚至会成为敏捷转型成功与否的先决条件。队形一定要正确，它会成为运转Scrum流程的最尖端利刃。

 

3.由于Scrum提供了框架，我们需要自主配置参数，而且这个步骤是和第2步并行的，大概可以从三个方面去配置参数：

3.1关于迭代的参数配置，比如说迭代周期是多久，是全部采用普通迭代，还是会涉及一些强化迭代，发布迭代等，这需要根据产品的场景来判断，更需要一些实践经验的辅助。

3.2 关于角色任职，比如说PO谁来任职，Scrum Master谁来任职，是专职的还是兼职的，占比大概是多少等。

3.3 关于Team Agreement,比如说站会的时间和地点，分布式团队的沟通办法，奖惩机制等。

 

4.解决了上面陈述的难点问题，Scrum框架才能填满内容，一次性冲破我们原有的障碍，这个时候我们才能按照流程，按照Scrum Guide去实施运转。

 

我们可以看到，只有做足了准备工作，在刚开始的时候冲破了最难的部分，我们才有可能在接下来真正运转Scrum流程时有机会成功。

Day2-『Scrum玩法』

Scrum框架下的敏捷转型属于裂变式的转型，而其他国内流行的一些框架下的敏捷转型，就属于渐进式的转型。比如说只打造持续交付工具链的，只通过“Information radiator”信息发散器解决信息透明度的方法等

 

Scrum将所有最难的问题前置，如果要搞这样的转型，我们就需要在最开始的时候就尝试要冲破这些瓶颈障碍，然后真正运转流程时才有可能大范围的成功。而渐进式的转型，根本的难题就在于后续需要强力的资源支撑，外加上没有时间节点，让渐进式的转型在初始时比较容易获得成功，越到后期愈加困难，失败的风险成倍增加。

Scrum中说的“3355”是什么呢

Scrum作为框架，有许多参数需要配置，需要调参数，可是这里有个核心是万万不可以调的，这就是“3355”，它是Scrum中的核心。

     

那么它为什么能作为Scrum的核心呢？

 

这里有非常关键的一点就是，Jeff老师在对Scrum的构架设计思考的点是：最小，最简洁的架构。他的本意是团队如何才能高效，不要团队做那么多的汇报，写没有用的文档，而是在最小的管理架构内产生最高效、最有价值的交付。

 

所以运行Scrum的要义就是，除了Scrum核心的东西，最小，最少能够运用多少东西来更好地帮助团队。

虽然下面是一张被用烂了的Scrum老图，但更证明了它的经典，我们就一起来看看吧。

     

三个角色：

Product Owner，简称PO，产品负责人负责最大化产品以及开发团队工作的价值。

Scrum Master，负责整个Scrum流程在项目中的顺利实施和进行。

Team，就是团队，他们是真正干货，实操的人。

 

为什么Scrum团队中有这三个角色就能够顺利运转，他们之间应该如何配合，Jeff老师又是为何要这样设定三个角色，这些问题，我们将会在Day3的课程重点介绍。

三个工件

这里我们必须强调一下，三个工件最早的时候并非像如今这样，我们来通过一张图来看看它的变迁：

     

我们务必要强调，最小、最简洁的架构这个核心概念，这也是为什么只有3个工件的原因，它们是Jeff老师通过实践得出的最少的能够帮助团队高效运转的条件。

 

在起初，有Product Backlog来管理整个项目和产品和需求，有Sprint Backlog来管理迭代内的需求以及实施细节，而Burndown Chart则可以控制过程风险。

 

这是一套非常有效的运行机制，可是后来Jeff老师发现当迭代周期从原来比较推荐的2~4周缩短至1周，甚至日迭代时，风险控制的必要性就大大降低了，而且大家也可用更多的方法去控制风险。

 

那么索性将三个工件变成两个工件不就好了吗？真是这样就好了，以价值为驱动的Scrum势必要强调这种迭代式的增量开发方法背后，一定要有一个条件或者工件可以度量迭代，而此时潜在可交付的产品增量几乎成了毋庸置疑的工件选项。

 

这就是3个工件的变迁历史和背后原因，相信从这里我们更能看到Scrum始终在强调的核心理念：最小、最简洁的架构。

Product Backlog，就是我们前面讲到的产品待办列表，一个排序的列表，包含所有产品需要的东西，也是产品需求变动的唯一来源。

 

Sprint Backlog，就是迭代待办列表，一组为当前 Sprint 选出的产品代办事项列表条目,外加交付产品增量和实现 。

 

潜在可交付的产品增量：要求每一个Sprint结束都产生用户可用的产品，也被称着“潜在可交付的产品增量”。 

 

“潜在可交付”并不意味着构建出的东西必须立即交付，交付是PO的业务决策，基于发布计划来确定的。

五个仪式

这五个重要的Scrum仪式，或者叫活动、会议，是Scrum实施不可或缺的环节，我们就叫他们Big 5吧，到底是什么呢？

Sprint Planning：

这个会规划大家在新的迭代周期里干什么活，做成什么样子，也就是要完成哪些用户故事。

Daily Scrum Meeting：

不是为了让团队罚站，而是让工作更有仪式感，每天15分钟，一起聊聊任务进展，有没有啥困难。

Sprint Review：

这是个表演真正技术的会议，团队和客户一起来评审本次迭代的产出是否达到预期，听听其他人对交付产品的建议和意见。

Retrospective：

回顾会议发生在迭代最后，这个会议上大家可以夸夸在本次迭代中有哪些做得好，再检讨一下自己有哪些做得不好，然后再拟定出行动计划。

Backlog Refinement：

对Product Backlog进行梳理，其实就是对需求本身进行梳理，可以发生在整个Scrum周期的任何时间。

五个价值观

其实最早的时候，并没有价值观这个核心点，只是我们发现想要Scrum可以更好地运转，必须具备基于此框架的工作价值观。

 

这样才能将上面讲到的角色，工件，仪式有机高效地串联起来。

大家需要对目标承诺，有专注精神、接受挑战的勇气和开诚布公的心态。在分享的同时互相帮助、互相尊重。

 

Anyway，we are 伐木累！

 

要坚决把这些价值观渗透到团队之中，前面的3（角色）3（工件）5（活动）才能起化学反应，发挥出意想不到的效果，才能使团队成为真正的“Agile Team”。

     

勇气：不要怕失败，要有勇气去面对各种挑战

专注：每个迭代只专注于该迭代要完成的事情，哪怕只做一件事情，也把它做好，而不是贪多却都是泛泛，小π非常认可一句话：世界上没有同等重要的两件事情，所以去做那些在当下最有价值的一件事情。

承诺：不用发誓的，但是承诺还是要有，为了维护团队信誉，说到就要全力以赴的完成。

尊重：亚圣说：敬人者人恒敬之，所以团队之间要随时沟通，相互理解，不要打架。

公开：这不仅要求我们要善于集体分享成功，还要善于“揭短”，问题得到不及时、不透明的暴露，可能会导致迭代一事无成，团队大受打击，一蹶不振。

Day2-『Scrum玩法』

3355，绝不是仅仅记住这个数字代表什么，而是要知道它是Scrum框架可配置参数的核心，是最小、最简洁架构的理念体现。

为什么Scrum有那么多会议？

小π经常听到一些团队中的小伙伴抱怨:Scrum会议这么多，哪有时间写代码？

这么多会议，真的会让你写代码的时间减少吗？它们真的是不合时宜的事情吗？

如果真是这样，为什么Scrum还要搞这么多会议，这不是降低工作效率，减少工作产出嘛！然而事实并非如此。

为什么Scrum有那么多会议？

很多运用Scrum的公司，认为Scrum中的会议太多了，而这里提到会议就是我们在3355中讲到的仪式。

 

那么我们首先要Say No的是：Scrum中并没有那么多仪式。Jeff老师，一个主打以最小、最简洁架构为核心的Scrum创始人，一定不会去想要设计任何多余的仪式与会议。

 

如果你坚持认为Scrum就是仪式太多，浪费了太多的工作时间，那我可能会认为你们敏捷可能出了一些小问题哦。

 

为什么这么说呢？

我们来通过下面这张图片，来捋一下这些仪式的必要性。

     

在整个Sprint中，我们必须拿出计划会的时间来做任务梳理，让每个人都明白在迭代中要按顺序做哪些事情，做到什么样子，这无疑是必须的，无论我们处于哪种开发模式。

 

到了迭代结束时，一定会有评审会帮我们去看看这个迭代中究竟有哪些交付，大家对这些交付的意见和建议是什么。

 

然后就来到了回顾会，有点类似于传统的复盘会议，我们需要对在迭代中的整个Scrum流程进行反思，并形成行动计划，方便做新的改进。

 

而在迭代过程中，为了让大家能够互通信息，知道目前的进展，遇到了哪些困难，Daily Scrum无疑会成为不可或缺的会议。

 

而针对大多时候PO是没有办法在Sprint Planning时，拿出一份优秀的Sprint Backlog，所以Product Backlog Refinement就是来解决这个问题。

 

所以这个时候我们再来从整体上去看待这些仪式，就发现这些已经非常精简，全部属于必要条件，而且每种仪式都有自己独特的价值，值得Scrum团队去花费时间认真执行这些仪式。

反过来如果缺失了这些会议会怎么样呢？

1.团队对于目标可能也就是迭代的第一天被提及，中间出了问题谁来告知。

2.这些问题又会不会引发连锁的其他问题呢，没有人知道。

3.目前我们取得了什么进展，如果没有成果展示，大家会更加质疑Scrum本身。

4.仅仅只是文档传递这些，很快将会造成问题的堆叠，造成最终的交付拖期或者不具备交付的水平。

好的ScrumMaster和团队，一定会让你感受到人类语言是最好的，而不是php。

这些能让你们的Scrum会议开得更好

就是这些会议如此重要，如此不可或缺，那么怎样才能做得好一点呢，我们可以尝试从下面去努力：

基本要求

1.做个守时的团队，每次会议都要准时开始、准时结束。

2.做个Open的团队，每次会议都采取开放形式，所有人都可以参加。

在一起！

•大家都懒得动，尽量让“PO”和“团队”都坐在一起！

•互相听到：不一定要促膝长谈，但要保证所有人都可以彼此交谈。

•互相看到：所有人都可以看到彼此，都能看到任务板，达成默契，保证都可以做到“确认过眼神”。

•隔离：为了把“真理”辨明，团队可能会突然站起来，自发形成一个激烈的讨论，隔离可以让团队外的任何人都不会被打扰到，反之亦然。

Day2-『Scrum玩法』

一旦我们开始怀疑这些会议的作用和必要性时，说明我们正在步入“伪敏捷”的怪圈，大家尚未意识到这些会议原来对我们如此举足轻重，而不是在浪费你写代码的时间。

Scrum落地时说的“GASP”是什么，有什么用？

讲到“GASP”，我们要知道非常重要的一点，这些是大多数实践情况下，更多人在应用Scrum时普遍接受的工具。

 

所以到这里就要澄清一点：没有这些GASP可不可以运转Scrum？答案当然是可行的，只是有了这些可能会让更多团队运转Scrum时更高效。

 

那接下来我们就来看看究竟有哪些重要的GASP，是我们经常在实践终于到的。

小π认为GASP就是与Scrum中的最佳实践，但不是每个团队都需要去捆绑使用这些工具，我们需要根据场景来判断使用哪些工具。

老大——用户故事和故事点

用户故事是具有固定格式的一种描写需求的工具，Team看到它就可以知道用户需求的内容究竟是什么。而故事点是团队为了估算需求复杂度的一种度量指标，类似于大家需要花费多少努力才能完成这个故事点。

     

老二——任务看板（Scrum-Board）

Scrum讲究透明化，所以Team要对任务需求要做到透明化，可视化，任务看板就是非常得力的助手。大家把每个人的任务都放在同一页上, 了解当前迭代的进度。这是一种快速、直观的方式, 可以看到每个人都在做什么。

     

老三——估算扑克

这可不是用来炸金花的扑克牌，而是用来估算故事点的工具扑克，大家针对Scrum-Board上贴的用户故事给出故事点，并最终要求达成一致。

     

老四——燃尽图

简单地说，就是团队估算用户故事的故事点后，又把它拆分为细分任务并估算工时，然后累加求和就得到了燃尽图坐标系中Y轴的起始点。随着工作推进，也就是X轴上的最大值就是设定的迭代周期时长。

     

Day2-『Scrum玩法』

工具并不能帮助你敏捷成功，为什么运行Scrum的时候，是先确定人，再确定事呢？因为能让你成功的是因为人本身。

工具只是让我们更高效了，GASP的作用对于Scrum而言，就是如虎添翼。

     

Day3课程预报

有了今天课程的积淀，我们已经对Scrum有了初步的了解，清楚了它的玩法，那么明天来看看Scrum中这几个角色究竟是干什么的，他们是如何高效率地衔接在一起工作的。

明天的课程非常精彩，及时学习哦！