CODING 敏捷实战系列课第二讲： Scrum 敏捷项目管理核心要素之 3355

[CodingNET]

Scrum 是敏捷开发流派中最著名和最落地的一支，全球 70% 以上公司的敏捷转型都是以 Scrum 起步。CODING 特邀敏捷顾问、CST & CTC 认证敏捷教练申健老师将在本课程 《 Scrum 敏捷项目管理核心要素之 3355 》 中介绍 Scrum 框架的核心要素，帮助大家更好地学习实践 Scrum 。

大家好，本次我将为大家详细讲解敏捷的一个流派，叫做 Scrum 敏捷项目管理核心，它起源于 2001 年，当时有 17 位大牛共同讨论了他们的想法和各种软件开发方法，经过交流，他们最后达成了价值观和原则上的共识，共同发布了敏捷软件开发宣言。

而迭代的概念则可以追溯到 1970 年左右，Scrum 也是用迭代式去进行发展，与之相应对的就是瀑布式，所有工作像流水线一样有计划且按部就班的去进行。例如：在软件开发中，先是需求分析、设计，然后进入开发编码、测试，到最后上线，整个过程有前后顺序，不过现实中总会在某个地方出现问题从而造成返工。

有两个日本学者在 1986 年研究了丰田、本田、佳能等高科技公司怎样在一个不确定的情况下去研发一个新产品，他们发现这些公司不再去区分职能部门，而是具有跨职能团队的特点。就像打英式橄榄球，每个人都有各自的专长，但是目标是统一的：要进球赢球。

所以他们在管理智力型研发项目时，没有再用瀑布流式来管理，而是用一种不断迭代的方式。项目的迭代时间不超过四周，在这四周里必须包含所有的必备工作，包括分析、设计、编码、测试，确保快速交出一份相对简单可用的产品，及时获得用户反馈。否则如果等到产品上线再来收取用户反馈，改动成本、项目风险将是非常高的。Scrum 通过事务减少工作任务和工作时间，给予跨部门小团队充分的授权，让他们自己决定如何工作，同时又保持目标一致。

1995 年创立 Scrum 时，也吸收了丰田汽车的精益思想，例如减少浪费、限制流动。Scrum 是一个解决复杂自适应问题的框架，让我们以迭代和增量的方式，在最短时间内交付最大价值的产品。要知道你的人力、物力、财力，包括你的时间，永远是有限的，有一句老话叫“钱要花在刀刃上”，集中优势兵力干一件大事，先做价值最高的那个，分清主要矛盾和次要矛盾。越想全都解决，越解决不了，而 Scrum 就是希望你能做出取舍。例如你的项目上线后，真正被用户使用的部分占比多少，创造了多少价值？通常我们叫二八原则，是指 80% 的价值一定是在 20% 的工作任务里，剩下的都是锦上添花，也有可能是无用功，如果能够减去没有价值的任务，就能让我们获得更充分的时间把质量做的更好。Scrum 并不是必须把所有东西做完，有一句名言叫做“遇到事要尝试反过来想一想，世界每天都在变化，所有事情没有一个尽头”，要学会适应变化、破解和应对复杂性、拥抱变化。

其实在敏捷 Scrum 里，我们更喜欢用这种产品的思维，而非项目，因为按照定义项目是一次性的，也就是说必须先做一个计划，然后按部就班去遵循这个计划的固化思维。你需要分清你的产品到底是什么类型，在业务目标之下，大家可能会有很多的想法，所以有时会缺乏一个真正的决策者，或者决策者的位置特别高，信息流动不畅，导致大家想法不一样，那真正干活的人实际上是无所适从。在 Scrum 里首先要定义一个很重要的角色，叫产品负责人，他要综合各方的想法，进行艰难选择，将所有想法根据投入产出比进行排序，形成一份产品待办列表清单。它可以无限地增长，但并不意味着要把列表里所有东西都做完，而是从业务、运营角度来说时间挺重要，那在这个时间点我们就要集中优势兵力做最重要最有价值的。

“倒排期”是指一开始规划很多任务，把所有任务全都扔进固定时间内，从进度上来说可能磕磕绊绊做完，但是质量就惨不忍睹了。而 Scrum 可以从时间往后倒推，根据可持续的方式来进行动态取舍和排期，先形成一个初始的产品待办列表，团队和 PO 、业务干系人可以约定迭代周期，顾名思义它是一个短的时间周期，通常不超过四周。

首先需要开一个 Sprint 计划会，从长长的产品待办列表里面去拉取一批工作，进行分解，形成工作计划。每一个短的时间周期里都有一个小的目标，在小目标之上一定有个大目标，小目标是从大目标里进行分解，之后进行开发、编码、测试等等。而每日还有一个站会活动（ Daily Scrum ），让团队成员聚在一起分享今天的进展与遇到的问题，这是一个强制沟通的机会。在项目快结束时，我们将工作集成起来，如果是软件则进行集成测试，其他的产品类型则进行相应的产出。然后将完成的产品增量拿到 Sprint 评审会上，邀请产品相关人士并做演示，这时可能会有人提出产品跟预想的不一样，那么赶紧修改，反馈来得越早越好，越早去发现问题，修复的成本越低，根据反馈可以调整出我们到底要做哪些内容。最后来到回顾会，这时不止需要对产品进行调整，还要进行检测调整。

接下来讲讲三大角色，分别为：产品负责人（ PO ）、开发团队、Scrum Master 敏捷教练。 做产品只能有一个 PO，负责最大化的投资回报率，并且不断地重新调整优先级和梳理列表。开发团队顾名思义就是干活的，这个团队就像球队一样，它是“跨职能”，并且是“自管理”，被给予很高程度的自治和责任。Scrum Master 敏捷教练，顾名思义就是教练，帮助你具备独立解决问题的能力，所以他并不是一个管理者和管控者，更多的是服务型的领导者，有什么不会的可以教你，但是最终干活的一定是开发团队，例如龙舟队，龙舟队上划船的就是开发团队，掌舵人就是 PO，前面敲锣打鼓把握节奏、鼓舞士气就是 Scrum Master，这三个角色就组成了一个龙舟队。

三个工件分别是指产品待办清单、Sprint 迭代待办清单和符合完成定义的产品增量。例如首先产品有个大的目标方向，经过我们的收集信息分解，变成 1-8 号需求，我们需要选取需求到待办清单，团队再分成子任务，之后迭代开始，将产品进行集成，变成可以测试验收上线的产品增量，最后经过反馈，PO 可以再去调整剩余的需求。

在 3355 中，第一个 5 是指五个事件，是 Sprint 本身短时间盒和其他四个会，分别为 Sprint 计划会、每日 Scrum 站会、Sprint 评审会、Sprint 回顾会。在做同一产品多团队时首先要拆团队，维持不超过 9 个人的团队结构，类似 LeSS 结构，强调工作在同一个产品的多个团队，只有 1 个 PO 和 1 份 PB，所有团队的迭代时间盒对齐。在 Sprint 末尾要交出已集成、完成的产品增量。如果是超过 8 个团队，可以考虑 LeSS Huge 结构，增加领域产品负责人（ Area Product Owner ）角色。第二个 5 是五个价值观：开放、尊重、勇气、专注、承诺。承诺这个词在 Scrum 中表达的是全身心投入去完成 Scrum 团队的目标，而不是说必须按计划完成，两者之间还是有些不同。

Scrum 是一面照妖镜，它的设计“故意不完整”，也故意让项目团队“更难受”，你认为做的产品是完美的，而 Scrum 就是指出产品的不完美，也就是挑错。原来一个月交不出产品，那么就把时间缩短成一周或两周迭代，逼迫团队做出改变。敏捷不是从 0-1 的非黑即白，它是一个持续优化的过程，通过持续交付、持续优化、持续改进、持续提升、持续塑造，最终实现小步快跑，快速迭代。那么今天就分享到这里，谢谢！

点击观看完整录播视频