Scrum 3355

Posted 2023-05-09

参考技术A 接触过敏捷的我们，一定对Scrum都不陌生，Scrum是众多轻量级敏捷框架中应用最广泛的一种。

Scrum的历史可以追溯到1986年《哈佛商业评论》中的一篇文章《新型的新产品开发策略》（The New New Product Development Game，竹内弘高、野中郁次郎，1986）。这篇文章描述了像本田、佳能、富士施乐这样的公司是如何通过可伸缩、基于团队的并行产品开发方式开发出了世界一流的产品。文章同时强调了授权、自组织团队的重要性，并概要描述了管理在开发过程中发挥的作用。

Scrum这个词没有什么标准的中文解释，它来源于橄榄球中的一个争球的动作。

竹内弘高和野中郁次郎在《新型的新产品开发策略》首次提到将Scrum应用于产品开发，他们指出：传统的“接力式”的开发模式已经不能满足快速灵活的市场需求，而整体或“橄榄球式”的方法——团队作为一个整体前进，在团队的内部传球并保持前进，这可以更好的满足当前激烈的市场竞争。

“透明、检验、调整”是过程控制理论的三大支柱，也是Scrum理论的核心。

Product Owner ：主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。 

作为产品负责人，PO清楚地知道产品的愿景，需要对产品待办列表的梳理、优化、优先级排序等负责。PO决定Why和What，一般可以对应为我们理解的产品经理和业务分析师的角色。

Scrum Master ：主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍， 一般可以对应为我们理解的项目经理的角色。

Scrum Team ：主要负责软件产品在Scrum规定流程下进行开发工作。每位成员可能负责不同的技术方面（开发、测试），要求团队有很强的自组织能力，能够交付一个端到端的真正对客户有价值的产品。

Product Backlog ：PO首先将需求按照优先级进行排列，产生一个Product Backlog。作用类似于传统开发中项目经理确定需求文档。产品待办列表就是产品的“What”。PO通过“讲故事”的方式，让团队理解产品的目标，帮助整个团队对用户故事有充分和统一的理解。

Sprint Backlog ：有了Product Backlog列表，我们需要通过Sprint Planning Meeting（Sprint计划会议） 挑选出用户故事（Story）作为每次迭代完成的目标。

潜在可交付的产品增量 ：要求每一个Sprint结束都产生用户可用的软件，也被称着“潜在可交付的产品增量”（Potential shippable product increment, PSPI）。能否每个Sprint生成满足质量定义的PSPI 是Scrum 执行效果的试金石。

因此这里关键的是团队内有一致同意的DOD（完成的定义），基于其中的内容来判断是否迭代内所有东西都做完了。同样，随着时间推移，团队DOD内容会不断修改完善 。“潜在可交付”并不意味着构建出的东西必须实际交付，交付是产品负责人的业务决策，基于发布计划来确定。

Sprint Planning（IPM） ：Sprint计划会议在Sprint一开始召开。PO和团队共同决定计划在这个Sprint完成哪些用户故事。

Daily Scrum Meeting（Standup） ：每日站会，一般在15分钟以内。团队成员相互交流任务的进展，计划以及遇到的困难。

Sprint Review（Showcase） ：Sprint评审会议发生在Sprint将要结束的时候。团队和客户一起评审本次Sprint的产出是否达到预期。

Retrospective ：回顾会议发生在Sprint的最后，由Scrum Master负责召集团队召开。会中大家回顾和小结这个Sprint做的好的地方以及有哪些不足。保证团队能够持续改进，不断提高。

Backlog Refinement ：Product Backlog的梳理，可以发生在整个Scrum周期的任何时间。

Scrum Guide明确指出，Scrum的角色、工件、事件和规则是不可改变的。虽然团队可以只实施部分Scrum方法，但Scrum只有以整体的形式存在，才能作为其他技术、方法论和实践的容器而运作良好。因此，从方法论的本质上，Scrum预定义了一个最小框架，这个框架里的元素不可缺少。

为了让Scrum团队能够高效运作，大家需要对目标承诺，有专注精神、接受挑战的勇气和开诚布公的心态。在分享的同时互相帮助、互相尊重。

当这些价值观渗透到团队之中，前面的3（角色）3（工件）5（活动）才能发挥出最大的价值，才能使团队成为真正的“Agile Team”

勇气： 有勇气去面对各种挑战。

专注 ：每个迭代只专注于该迭代要完成的事情。团队和个人的能力、精力是有限的，在有限的时间内专注于最有价值的事情，以取得好的结果。

承诺 ：作为一个自组织团队，在迭代开始的时候做出承诺，并在迭代中全力完成。

尊重 ：团队是能随时沟通，并且相互理解的。

公开 ：团队所有的进展、问题、阻碍都是对所有人可视化、透明的。这样的团队才能彼此尊重，同时也能随时暴露问题。

亨里克.克里伯格（Henrik Kniberg，资深敏捷教练，《精益开发实战：用看板管理大型项目》的作者）从更深层次解析了Scrum的精髓，提出了Scrum的本质上有三个拆分和两个优化。

Scrum的三个拆分

拆分组织 ：把组织拆分成小规模、跨职能的自组织团队。

拆分产品 ：把工作拆分成一系列小而具体的交付物，按优先级排序，估算每项任务的相对工作量。

拆分时间 ：把时间拆分成固定大小的短迭代（通常为1~4周），在每个迭代结束时对可交付的产品增量进行演示。

Scrum的两个优化

优化商业价值 ：在每个迭代结束后跟客户一起检查发布目标，并据此优化发布计划，更新产品代办事项列表的优先级。

优化流程 ：每个迭代结束后进行回顾，对团队的实践过程做优化。

迭代开发等于Scrum开发吗？

有人认为，敏捷Scrum就是快速迭代，快速迭代就能达到敏捷的效果，这样的理解是有偏差的。敏捷开发是一个总体概念，而迭代式开发只是几乎所有敏捷开发所采用的一个主要的基础实践。敏捷开发除迭代式开发外，还包含了其他许多管理与工程技术实践，如演进式架构设计、敏捷建模、重构、自动回归测试（ART）等等。

迭代的长度如何选择？

选择迭代长度时考虑的因素：

1）不确定性的多少。不确定越多，无论是哪种类型，迭代就应该越短；

2）获得反馈的难易程度。获得反馈越难，迭代就应该越短；

3）优先级可以保持多久不变。优先级变化越快，迭代就应该越短；

4）紧迫感的维持。越保持急迫感，迭代就应该越短。

无论你选择多长的迭代周期，最好选择一个长度然后坚持使用，而不是经常改变它。比迭代周期的初始设定更为重要的是团队在遇见问题后如何应对和改进，并切实将改进任务纳入每个迭代中去实施，逐步达到迭代结束时产品应具备的可交付状态。

开发团队的规模？

Scrum提倡，用小规模保持敏捷性，用大规模完成重要的工作，推荐了5~9人的团队规模。但是我们不用纠结这个数字。重要的是，团队能够拥有完成产品增量的所有技能，同时保持高效的协作。有些团队有11个人，如果可以确保高效协作就不必非要减去几个人。有些团队只有4个人，但是足以完成产品增量，也没必要再加人。

Scrum is simple，but it's not easy。

Scrum框架为团队敏捷实施定义了一个简单和明确的边界。在边界之内，团队探索和完善相关的管理和技术实践。理论的内容总是很简单，但是真正做起来，会遇到各种各样的问题，不断假设、不断验证自己的假设，并不断调整和优化。这也是敏捷的核心思想吧。

Scrum不再是Scrum，Scrum还是Scrum

Scrum（agile中）不再是Scrum（橄榄球赛）

（今天的）Scrum还是（30年前的）Scrum

（why？听我慢慢道来）

今天软件研发推崇敏捷开发，在敏捷开发的众多模式中，大家又推崇Scrum，其应用超过半壁江山，如图1所示。讨论敏捷，不得不讨论Scrum，而

图1  敏捷开发的各种模式应用所占比重

Scrum诞生很早，比敏捷宣言要早15年，可以追溯到1986年。那一年，享有世界“知识运动之父”美誉的、日本一桥大学的教授 Hirotaka Takeuchi & Ikujiro Nonaka 在《哈佛商业评论》上发表了一篇文章《一种新产品开发的新游戏》（A new new product development game，点击文章末尾“阅读原文” 下载原文）。这篇文章是在富士施乐、佳能、本田、NEC、爱普生、兄弟、3M、施乐和惠普等跨国公司如何研发新产品的大量研究调查基础上写成的。对九年后（1995年）——Scrum研发模式正式应用于软件研发领域——有着重要的直接影响。

要理解Scrum，最好去参加一场橄榄球（scrum）赛，体会“在球队成员相互传递时，引导一个团队整体性的活动” 即使不能参加一场橄榄球赛，也要好好读一读 Takeuchi &  Nonaka写的这篇文章，从而更好理解敏捷开发模式。

这篇文章将那些著名公司研发新产品的方法总结为一种Scrum游戏，体现在六个特点：

1. 内建不稳定（Built-in instability）

2. 自组织的项目团队（Self-organizing project teams）

3. 重叠开发阶段（Overlapping development phases）

4. 多样化学习（“Multi-learning”）

5. 微妙的控制（Subtle control）

6. 学习的组织内转移（Organizational transfer of learning）

这些特点像拼图组合在一起，形成了快速灵活的新产品开发流程，它强调建立学习型组织，强调构建不稳定性，以业务驱动组织变革，改变僵化的传统组织，提升产品研发效率和新产品上市的速度。

这张橄榄球快速传递的方式，也蕴意着 产品在研发人员和客户之间快速传递，适应市场的变化，从而更好服务于客户。而传统的开发过程，像接力赛一样，上游的研发人员将接力棒传给下游的研发人员，如同我们熟悉的瀑布模型，从一个阶段到一个阶段，即从概念定义、需求分析、产品设计、编程、试运行到最终上线，经历漫长研发阶段，而且由不同工种的研发人员传递接力棒，增加了知识传递的难度、拉长了学习曲线，甚至造成用户需求信息的严重失真。

而在Scrum模式的研发过程中，多个专业团队的不断互动，始终一起工作，团队的工作并未停滞，而是在从事迭代实验，从线性向整体性方法的转变，鼓励试错，挑战现状。如图1所示，类型A是传统的序列化（阶段式)开发模式，而类型B、C则是叠加式、快速迭代（Scrum）的开发模式，会激发组织内不同层次成员不断学习、不断思考，将这种积极向上的能量和激励传递给整个组织。

图1 序列 (A) vs. 叠加的 (B and C) 研发阶段

1. 内建不稳定

高层管理往往只是指明战略方向，制定极具挑战性的目标（如两年内研发出完全不同的复印机，其成本节省一半而性能依旧），但设想出明确的新产品概念、制定具体的工作计划等工作则是由负责具体研发工作的团队来完成。

这种挑战性目标会传递压力给团队，而高层管理人员给予项目团队极大的自由，团队反而能体会到这种不稳定性，更能激发团队的斗志。正如负责本田汽车开发的某执行官所说：“就像把团队放在二楼，并拆掉梯子，告诉他们往下跳或者做些别的事情。我相信创造力可以通过向人施压到极致而产生。“

2. 自组织的项目团队

自组织的团队像一家初创公司一样运营，能够承担主动性和风险，自己制定计划和进度表，具有三大特征：

1. 自治，即在日常工作中，高层管理很少干预，允许团队自行运作（包括设计开发、销售和服务），仅提供指导和预算支持。某种程度上，高层管理很像“类似风险投资家”——他们打开钱包，但不说话。

2. 自我超越。 从高层管理给予指导开始，团队自己建立目标，否认传统的思维方式，突破原来的惯性思维，在整个开发过程中沉浸在永无止境的 “极限”探索中，每天都在渐进的改进完善，不断提升。
   

3. 交流成长。项目团队在产品开发过程中，显示出不同的专业技能、思维过程和行为模式，进一步促成了新的想法和概念。每个成员可以从更大格局而不仅仅是自己的立场，为团队思考最适合或次优的决策

3. 重叠开发阶段

团队的自我组织特征产生独特的动态或节奏。虽然团队成员在不同的时间介入项目，但都必须以一个整体开展工作，快速地分享有关需求和技术的信息，努力同步其工作满足最后的时间要求。某种程度上，个人和整体是不可分割的。个人的节奏和小组的节奏开始重叠，创造了一个全新的脉冲。这个脉冲作为推动力，并将团队推向前进。但不同的发展阶段有不同速度的脉冲。这个节拍在早期阶段最为活跃，并且接近尾声时逐渐消失。

传统的开发模式，只在上一阶段的所有要求得到满足之后，才能进行下一个阶段的工作，这种方式看似可以更好地控制风险，但没有太多的整合空间，某个阶段的瓶颈可能让整个研发过程停滞不前。但在Scrum方法（如图2）下，各阶段重叠，使得团队始终保持信息通道畅通，可以吸收开发过程中的变动或“噪音”。当出现瓶颈时，噪音水平明显上升，但这个过程没有停止下来，团队仍在努力推动自己前进。 

图2  富士施乐产品开发进度表，缩短了26%研发周期

重叠方式，不仅消除了关于分工的传统观念，获得更高的速度和更大的灵活性，而且增强了责任感和合作精神，激发成员参与和承诺，鼓励采取主动，发展多样化技能，提高对市场的敏感性。

4. 多样化学习

多样化学表现在两个方面：跨越多个层次（个人、团体和企业）、多个专业性。

多层次学习。个人层面的学习是以多种方式进行的。例如，3M鼓励工程师投入15％的时间来追求自己的“梦想”，佳能利用同行的压力促进个人学习，有些工程师直接去市场中学，花上几个小时，观察什么东西销售好......同样，团队也强调追求学习，竞争性比赛（学习），走出去学习......建立公司范围的行动或计划，能更好地实现公司层面的学习。

多领域学习。鼓励专家在自己专业领域以外积累经验，如所有参与研发爱普生第一个微型打印机的项目成员都是机械工程师，起初并不了解电子产品。所以，其团队领导（也是一名机械工程师）重新回到母校，学习电气工程两年，但研究学习的同时，项目同步进行。

5. 微妙的控制

虽然项目团队大部分是靠自己管理，但并不是不受控制。管理层设立了足够的检查点，以避免不稳定性、模糊性等。同时，管理层也避免那种严格的控制对创造力和自发性的损害。相反，重点是“自我控制”，“通过来自同僚的压力来控制”和“爱的控制”，这些统称为“微妙的控制”：

1. 选择合适的项目团队人员，同时监测团队动态变化，必要时增加或剔除成员。例如，如果团队表现比较激进时，我们会向团队增加一个更年长和保守的成员。

2. 创建开放的工作环境

3. 鼓励工程师听取客户和经销商的意见

4. 建立基于团队绩效的评估与奖励制度

5. 有效管理整个开发过程中的节奏差异

6. 容忍和预期的错误。” 1％的成功是由99％的错误支持“、”年轻的工程师犯错误是很自然的，关键在于早日发现错误，并立即纠正“、”相对于成功，我们从错误中学到更多“

7. 鼓励供应商自我组织。参与早期设计是迈向成功的正确方向。

6. 学习的转移

驱动成员积累知识水平和专业只是学习的一个方面，项目成员同样强烈地希望将学习的知识转移给其它成员。定期开展将学习的知识转移给接下来的新产品开发项目或组织的活动。知识也可通过将项目活动作为标准实践，而在组织中传播。大部分的学习是由环境变化引发的。但有些公司有意识地追求学习。

Scrum运动

为了实现速度和灵活性，公司必须不同地管理产品开发过程。有三种变化需要考虑。

首先，需要采取一种可推广这种方式的管理风格。产品开发很少以线性和静态的方式进行、项目也不是以完全合理和一致的方式进行，而是迭代和动态的试错过程。为了管理这样的过程，公司必须保持高度适应性的风格，高层管理通过有意识地保持广泛的目标和容忍模糊地带以鼓励试错，但与此同时，借助挑战性的目标在组织及其内部形成紧张氛围。运营决策是逐步提出的，但重要的战略决策应尽可能推后，以便能更灵活地响应市场最后的反馈意见

第二，需要一种不同的学习方式。鼓励每一个人去获得必要的知识和技能完成产品开发，必须从各个管理领域、不同层级的组织、不同领域、甚至组织的边缘，汲取积累必要知识。

第三，管理层应该为新产品开发视为一种不同的任务，将其视为未来收入来源的新的引擎，也是推动组织变革的催化剂。没有任何公司认为适用环境变化是容易的，特别是在非危机情况下。但是，自我超越的项目团队，其快节奏工作能够在组织中触发危机或紧迫感。因此，对公司具有战略重要性的研发项目，即使在和平时期也能创造出战时的工作环境。

一旦项目组成立，它的可见性（“我们已经被挑选”）、合法权力（“我们有顶级的无条件支持创造新的东西”）及其使命感（“我们正在努力解决危机”）逐渐呈现。当来自不同领域的成员开始采取战略行动时，这可以作为公司变革的动力。

世界市场的竞争游戏规则相应改变，跨国企业必须在产品开发上保持速度和灵活性；为达到这一目标需要使用包括依赖尝试、试错、从工作中学习的动态过程。我们今天需要的是在不断变化的世界中不断创新。

一些局限性

整体性的产品开发可能并不适用于所有的场景，有一些客观的限制：

• 在整个开发过程中，需要所有项目成员非常努力。有时，团队成员在高峰期间每月加班100个小时，其它时候大多在60个小时。

• 它可能不适用于像航空航天业务那样庞大的项目，其中绝对的项目规模限制了广泛的面对面讨论。

• 它可能不适用于产品开发由某一位天才决策，并为接下来的人员制定一套明确的规范的组织。

管理应用

环境竞争加剧，大规模市场分散，产品生命周期缩短，技术和自动化程度的变化正在迫使管理层重新考虑传统开发产品的方式。一个延期几个月的产品很容易就会损失几个月的回报。

（送福利）