本文节选自《敏捷实战：破解敏捷落地的60个难题》

有刚接触敏捷的朋友问：「有些基本概念不是很清楚，问敏捷、精益、六西格玛、PMP 等方法论之间的有什么差异？」

这是一个很好的问题，很多想要了解敏捷的 PM 或开发者经常以不同形式提到类似的问题。

尽管并非总会问到上面列举的所有方法论，有时会提到 Scrum、软件开发生命周期(software development lifecycle，SDLC) 等，但这个问题一定少不了。

首先应该明确「方法论」和「框架」这两个概念之间的差别，然后再讨论具体方法。

「方法论」是由各种方法、工具和实践构成的系统，明确勾画出了各个阶段，以及每个环节需要 做的工作。

「框架」定义了一些基本实践和模式，但是允许在执行这些实践和模式时适当调整。

01

敏捷  

Agile

敏捷本身既不是方法论，也不是框架，而是一套价值观和原则。反映了关于价值交付的一种哲学和思考方式。

由于「敏捷宣言」的提出者属于他们那个时代的先驱，各自都在探索不同的软件开发实践，因此敏捷代表了许多方法的总和，而不是特定方法。

敏捷更像一个概括性术语，它定义了 Scrum、极限编程、看板方法、自适应软件开发、快速应用程序开发等方法的共同宗旨，从信念和精神的层面描述了这些实践目标的共同点。

02

精益  

Lean

精益和敏捷的共同点是通过减少浪费来交付价值的。

就某些方面而言，精益和敏捷几乎是一回事，但精益也有一些特定元素。

例如下面这 5 条原则:

(1) 识别价值;

(2) 分析价值流;

(3) 创造流动;

(4) 构建拉动式系统;

(5) 追求完美。

精益还识别出了在任何生产过程中都可能存在的 7 种浪费，无论生产类型如何，都包括:

(1) 搬运;

(2) 库存;

(3) 动作;

(4) 等待;

(5) 生产过剩;

(6) 过度加工;

(7) 缺陷。

我们需要在考虑外部依赖约束的情况下，寻找减少甚至避免这些浪费的方法。也就是说，系统会受到不可控问题的影响，所以应该对系统性能而不是局部性能进行优化，因为局部性能的提升不一定会导致总吞吐量增加。

因此，这不是一个“使用 Scrum 还是......”或者“使用极限编程还是......”的问题。这些方法之间并非完全互斥，其中很多实践是相通的，即使是不同的实践，从更大的范围来看也是互补或兼容的。

03

六西格玛  

Six Sigma

六西格玛(Six Sigma，6σ)是一组实践和工具，但更注重通过度量和指标来实现优化，而 不是通过有机的反馈循环。

六西格玛的核心就是精益的总体目标：减少浪费，将价值最大化。

然而，由于六西格玛强调定量和定性的度量，因此许多敏捷倡导者认为六西格玛过于笨重，甚至在应用中有些差错。

但是对于受到严格法规要求的行业来说，六西格玛为企业的转变和优化提供了理由。

对于不会对人身安全和公共福利构成极大风险或威胁的软件系统来说，优化性能和调整目标更多是由与顾客互动而不是指标检测来驱动的。

看板方法是一个框架，通过从头至尾追踪每项工作的状态，提高工作流(系统)中工作的透明度。其关键特性是，每个工作流状态都有一个相应的「进行中工作」(work in progress，WIP) 数量上限，从而将整个工作流从一个推动式系统变成一个拉动式系统。

在推动式系统中，可以将工作持续向工作流下游发送，不必担心瓶颈或溢出问题。在拉动式系统中，在下游的工作流状态出现空位之前，新增工作都不能在工作流中推进。

唯一的例外是，在出现紧急工作的罕见情况下，可以使用快速队列来突破「进行中工作」数量上限。

04

 看板 + Scrum 

Kanban + Scrum

看板方法可以与 Scrum 结合使用并取得一定的成功，尤其是在开发团队专注于建立一个符合「完成的定义」(definition of done)的连贯特性流，并且该特性流是通过持续部署而不是批量部署来得到可发布产品增量的情况下。

Scrum 的作用在于，Scrum 仪式(活动)可以提供优化机制(反馈循环)，例如团队成员可以定期审视团队的成长和成绩，并讨论团队工作的优化方式。这就是

Scrum 中「冲刺回顾会议」的概念。团队还可以定期反思产品，以确保产品符合顾客和利益相关者的预期，这就是 Scrum 中「冲刺评审会议」的概念。

相比 Scrum，极限编程更偏向工程实践而不是角色形式。这些工程实践包括持续集成、测试驱动开发、结对编程、验收标准的采用、代码重构，以及代码共有，等等。

05

项目管理 

Project Management

还有其他一些实践组合，例如快速应用开发、动态系统开发方法(dynamic systems development method，DSDM)和 Crystal Clear 等，都影响并启发了「敏捷宣言」。

甚至统一软件开发过程 (rational unified process，RUP) 的某些方面、「The New, New Product Development Game」(Takeuchi 和 Nonaka 于 1986 年发表)一文，以及传统项目管理的某些部分，都对敏捷有所影响。

也就是说，虽然没有明确提及项目管理，但是用于「管理项目」的活动会自然而然地出现在敏捷的各种实践过程中。

更重要的是，企业需要建立一种文化，将变化、学习、人文关怀、负责任的成长、好奇心、实验、娱乐以及余量(见 Andy Stanley 的 Take It to the Limit 一书)看作可持续的开发节奏和关键动态，致力于提高顾客和员工的生活质量并造福世界。

主动学习、提倡思想自由交流而无惧负面影响的企业，擅长创造让顾客满意的创新产品。

按照 Steve Denning 的 《The Leader’s Guide to Radical Management》一书中的说法，唯一重要的事情就是致力于让顾客满意，而这可以通过持续创新来实现。

Steve Denning 的结论是，对利润、成本和股东价值的关注并不能带来预期的利润增长，但如果专注于交付让顾客满意的产品，利润自然会随之而来。

Daniel James Gullo  | 著

倪琛 | 译

敏捷对于软件开发，乃至更广泛意义上的企业运作和项目管理都很有指导意义，但成功地在企业内实践敏捷并非易事。

本书详细探讨了敏捷之路上最常遇到的问题，旨在帮助读者扫清敏捷实践路上的种种障碍。

本书主要内容包括：敏捷的真实含义和相关概念，从瀑布式开发模式向敏捷开发转型时的常见问题，Scrum 的使用方法，顾客需求分析，产品负责人和项目经理的角色定位，团队组织方式，敏捷相关会议，敏捷社区经验分享，等等。

图灵官方小店

享受正版低价折扣