前言

在本系列上一篇博文 《敏捷Agile概述，何为敏捷？》 中，我们初步介绍了何为敏捷，敏捷提出的背景和为什么目前得到了广泛的应用。

但敏捷本身，更多只是一种价值观，是一个思想层面的指引。在组织中实际应用，还是需要借助一些具体的实践模型来进行落地。随着敏捷的发展，其实涌现出非常多不同的实践模型，基于这些模型来组织我们的研发过程，都可以称之为敏捷研发。

下面，我们将重点梳理下，在敏捷研发实践中，比较常见的一些模型以及它们的优缺点。

团队级敏捷

敏捷从提出之初，更多是首先从开发者的个人视角出发，在软件开发、协作过程中，希望建立的合作关系和开发理念，这种合作，通常是团队内部的开发协作。所以敏捷初期的主要实践模型，主要还是面向团队级别的实践。

Scrum

Scrum其实提出得比较早，1995年，Jeff Sutherland和Ken Schwaber在他们的论文《Scrum_软件开发过程》中首次提出了Scrum框架。这两位也都参与了敏捷宣言的签署。

随着敏捷的推广，Scrum被广为采用。根据最新版的敏捷状态报告(17th)，Scrum 依然是目前最流行的团队级敏捷框架，调查的团队中使用率超过6成。所以完全可以说，Scrum就代表了敏捷的主流实践。

我们这个系列后续的敏捷实践分享，也将主要以 Scrum 为准来进行探讨。

Scrum 模型框架的的构成：

• 核心过程：以Sprint 为固定研发周期
• 三大角色定义：PO、Scrum Master、Dev Team
• 三大工件： PBI（产品待办清单）、SBI（Sprint 待办清单）、Increment（产品增量）
• 四大工作仪式：计划会、站会、评审会、回顾会

Scrum框架强调以一个固定的短研发周期（sprint），定期地交付产品的增量，通过四种不同的工作仪式来跟踪、协作日常工作，强调团队自组织和紧密、机动的合作关系。

Kanban

Kanban 其实起源更早，来源于上世纪四十年代丰田汽车的生产管理理论。强调的是用一种可视化的方式来提高工作效率，同时便于工作流的调整和优化。

Kanban的核心原则是通过可视化的看板向所有成员清晰地展示项目进度和工作分配情况，限制在制品的数量避免过载和积压导致资源浪费，在看板上定义并区分出清晰的工作流程，如任务的创建、分派、执行、测试和完成等。 强调持续集成，通过定期回顾来进行持续改进。

极限编程（XP）

极限编程（Extreame Programming）简称 XP，是Kent Beck在1996年提出并在自己参与的C3项目中进行了实践。

Kent Beck 进行 XP 实践的C3项目，是克莱斯勒公司的一个薪酬管理系统，项目参与人包括多位后来敏捷运动的重要人物，如敏捷宣言的另两位签署人Ron Jeffries， Ward Cunningham也都参与过该项目。但该项目其实并不成功，延期多个月才交付，并且在运作了一段时间后因为存在严重性能问题，之后被彻底关闭。还是比较讽刺的。

XP 主要从团队运作、研发过程和开发技术实践三个维度， 定义了13种实践原则，包括持续集成、结对编程、测试驱动开发、客户验收等等，对后续敏捷宣言以及敏捷的12条原则有重要影响。

精益研发（Lean）

Lean Development，精益研发，其实也是脱胎于丰田的精益生产管理理论。

后来发展到软件领域，主要包括以下7大核心：

• 消除浪费：Eliminate Waste

• 内嵌质量：Build Quality In

• 创造知识：Create Knowledage

• 延迟决策：Defer Commitment

• 快速交付：Deliver Fast

• 尊重他人：Respect People

• 整体优化：Optimize Whole

精益更强调在向用户交付价值的同时尽可能消除浪费，并从更整体的业务环境来看待研发。

水晶方法（Crystal）

水晶法是Alistair Cockburn于 1991 年为 IBM 开发的一种团队协作和沟通制定指导方针，Alistair Cockburn被认为是敏捷早期的普及者，敏捷宣言发表后，包括Crystal在内的方法开始走入大家的视野。

水晶方法可细化为透明水晶方法（Crystal Clear）、黄色水晶方法（Crystal Yellow）、橙色水晶方法（Crystal Orange）以及红色水晶方法（Crystal Red）。这几种水晶方法论按照项目重要程度以及参加人员规模进行划分。

• Crystal Clear ： 6人左右的团队
• Crystal Yellow：20人左右
• Crystal Orange：40人左右
• Crystal Red：80人左右

Crystal方法中同样也强调了7大主要特征：

1. 经常交付

2. 反思改进

3. 渗透式交流

4. 个人安全

5. 焦点

6. 与专家、用户建立方便的联系

7. 自动化测试、配置管理和经常集成的技术环境

相比于XP、Scrum等，Crystal纪律性较弱，它的主要原则依据团队规模不同会动态变化，所以实际中被应用得并不多。

除了以上5种常见的团队敏捷框架外，还有类似DSM、FDD等团队级别的敏捷实践模型，但目前应用最广的其实主要还是Scrum。

敏捷模型虽然多种多样，实际应用其实也并没有非此即彼的排斥性，因为它们更多还是敏捷思想的落地，我们理解这些模型定义背后的出发点，取长补短应该才是更加务实地去进行敏捷实践的方式。

当然，现代软件的规模其实越来越庞大，仅仅依赖一个小型团队，并不能完成软件产品的系统级研发，这些基于团队级别的敏捷框架，如果应用到大型的软件系统，在组织级别的敏捷，通常并不适用，因此针对这种级别的敏捷，又出现了 大规模敏捷框架， 下一篇我们会继续分享敏捷框架中的这部分框架介绍

大规模敏捷

以上敏捷模型，是基于敏捷提出之初的一些理念发展而来，主要是面向小规模团队的敏捷实践。但是现代软件规模其实越来越庞大，仅仅依赖一个小型团队，并不能完成软件产品的系统级研发。所以为了整合多个通过的小型团队，敏捷组织又提出了多种不同的大规模敏捷模型。

相比 Scrum 在团队级别敏捷中绝对优势的主流地位，大规模敏捷框架则显得百花齐放，并没有某种模型占据绝对主流。下面我们介绍其中比较知名的几种规模敏捷框架。

SAFe

基于最新的敏捷状态报告，SAFe是目前应用最多的大规模敏捷框架，但也只有 22% 左右的占有率。

SAFe是 Sacled Agile Framework 的缩写， 诞生于2011年，到目前已经更新到 6.0 版本。

它提供了一整套结构化的方式来对敏捷实践进行扩展，并提供了四种不同的配置以适应不同级别，分别是：

• Essentail：团队级别（中小型项目）
• Large Solution：大型解决方案级别（大型项目）
• Portfolio：投资组合级别（产品线）
• Full：组织级别（企业级）

SAFe 框架中，在Scrum 迭代（Sprint）的基础上，引入了PI（Program Increment）和敏捷发布火车（ART）的概念，以一个包含数个 Sprint 的周期，构成PI，通过多个不同Scrum团队的合作，来共同致力完成一个较大规模的产品增量。

在 Scrum 定义的三大角色PO、Scrum Master、Dev Team之外，SAFe中又定义了产品经理PM（product manager）、发布列车工程师RTE（release train engineer）、方案架构师SA（Solution Architect）、业务负责人BO（Business Owner）等新角色，以管理多个团队和更大规模的产品路线图、技术架构以及跨部门的协调。

SAFe强调的四个核心价值观：

• 一致性（Alignment）：确保组织中的每个人都朝着相同的方向努力，清晰的目标和愿景是关键。
• 内置质量（Built-in Quality）：从一开始就关注质量，避免后期修复，确保产品在每个开发阶段都符合高质量标准。
• 透明度（Transparency）：创建一个开放、透明的工作环境，鼓励团队成员间的沟通和反馈。
• 程序执行（Program Execution）：通过一致的开发和交付节奏来确保程序和产品的顺利交付。

SAFe 以其比较完备的、适应不同规模组织的实践方法论，以及广泛的认证推广，目前在规模敏捷领域，得到越来越多的应用。

SoS

SoS （Scrum of Scrums）其实是一个非常早的规模敏捷模型。2001年（敏捷宣言发布那一年）就由Scrum创建者 Jeff Sutherland提出，并在GE的项目实践中进行了应用。

这个框架其实理解比较简单。

本质上是一个同步机制，每个Scrum团队派出一个成员，通常称为大使，这些人再组成一个Scurm，也就是SoS。这个团队同样参照Scrum的原则来运作，有Sprint，站会，backlog等。但SoS的主要关注事项是跨团队的进展、障碍和协调。

SoS也是目前规模化敏捷中采用比较多的方式，但是它的规模一般也不会太大，5~7个Scrum小组的规模。在其之上还扩展出SoSoS，但这个复杂度就进一步上升，运作起来容易混乱。

NEXUS

另一个规模框架Nexus， 是由scrum的另一个提出者，scrum之父Ken Schewaber创建，然后通过scrum.org 于2015年推出的，可以说属于Scrum半官方性质的规模敏捷框架。它的提出时间较晚，目前应用得很少，敏捷状态报告中看到只有约 1% 的应用率，推广不利。

Nexus主要是在Scrum的基础上，针对更大范围的团队合作进行了少量改进。框架上本身没有太大的变化，也是主要有几点不同：

1. 它的主要工作会在跨团队层面完成，包括sprint计划、复盘、回顾， 但站会是分小组来开。

2. 由3-9个Scrum team组成Nexus team。 规模更大就会难以组织。这些不同 scrum小组会在同一个迭代周期来运作

3. Nexus引入了一个Nexus 集成团队。这个集成团队，职能和SoS差不多，主要负责不同scrum团队间的工作协调，进展同步。

4. Nexus 共享同一份产品backlog，只有一个PO角色，在召开计划前，会召开跨团队的需求提炼会。 而工作成果也是同一个increment

这个框架对团队间的协同要求非常高，而且很多事项是多个Scrum小组共同参与完成并同步，所以效率上较难保证，这可能也是这个框架难以得到更多应用的主要原因。

LeSS

LeSS（Large-Scale Scrum）是一种轻量级的敏捷框架，旨在将Scrum扩展到多个团队，同时保持Scrum的核心原则和简单性，于2005年提出。也是比较早的一个框架

和NeXus类似， LeSS敏捷框架采用同一个产品列表，所有敏捷团队在同一个Sprint中工作，各团队协同完成这个冲刺。

但在 LeSS 中，Sprint开始时有2个 Sprint 计划会，第一个冲刺计划会中由各团队派人参加讨论和管理彼此间的依赖及协作工作。第二个 Sprint 才是Scrum团队自己的冲刺。在 Sprint 结束时，同样有2个回顾会，一个是敏捷团队内部的回顾会，一个是整个大型敏捷项目的回顾会。

LeSS灵活度比较高，相比Scrum来说，保留了Scrum的所有角色并且没有引入新的角色，更加依赖团队的自组织能力。

相比SAFe等其他框架，LeSS不会引入额外的角色或过多的其他流程，而是通过简化结构来扩展敏捷，但也造成了落地时可操作性上的困难。目前最新的敏捷状态报告中，应用率在2%

以上就是关于敏捷各种实践模型的梳理和总结。帮助大家可以对敏捷的应用和当前的发展状态，有一个整体上的认知。

欢迎继续关注这个系列，努力持续更新中~