Scrum不再是Scrum，Scrum还是Scrum

Posted 2021-04-25 软件质量报道

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个小时。

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

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

管理应用

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

（送福利）