Agile 敏捷研发可能是现今 IT行业最为流行，也是被广为应用的研发模型。但实际运作中，似乎和预期总有不少的偏差。所以开一个系列来详细梳理下和 Agile 敏捷研发相关的知识并谈一谈自己的 Agile 的理解。

敏捷的起源

要谈敏捷，首先我们还是要看看它被提出的背景是什么。

软件危机

我们知道，在上世纪70年代到90年代，计算机逐渐开始成为普通消费品，开始进入千家万户。以此为契机，计算机软件行业也开始高速蓬勃发展。但同时，随着软件应用规模的增大，其复杂性也急剧增强，这个阶段发生了大量因为软件导致的问题，也就是现在称为的“软件危机”时期。

软件危机主要表现为：

• 超预算
• 超时
• 低效
• 低质量
• 不满足需求
• 无法管理、难以维护代码
• 永远无法交付

而为了应对上面软件危机 中产生的问题，软件工程 开始作为一个学科，快速发展，针对软件研发的各种理论、论文开始涌现。这其中，从制造业的工程管理转化而来的 瀑布模型 以及其衍生而来的 V模型, W模型 占据了主流，影响直到今天

瀑布模型

但是瀑布模型也存在很明显的缺点，也就是它是一种线性的研发流程，一些影响发布的问题往往要到后期才能暴露。而且这种模型，对风险控制的要求很高，看重计划和流程，所以文档、规范要求非常严格，各种繁文缛节也造成了很大的效率问题。使用瀑布模型，但软件项目失败的例子也依然层出不穷。

互联网兴起

另外一个背景，就是90年代互联网的兴起。基于互联网的应用，和传统的桌面应用不同，软件发布即送达，且用户群极为庞大。另外互联网的免费策略，使得用户切换同类产品的成本极低，所以互联网应用先天就是一个需求变化极为频繁，对于产品的迭代、更新有极高要求的行业。传统重流程的瀑布模型已经很难适应互联网产品的这种高速的要求。

正是在以上背景下，敏捷模型应运而生。

敏捷的历史

图源自smartSheet

• 早在上世纪40年代，丰田在它的汽车生产管理上，就采取过不少现在敏捷研发中推崇的理念。最典型的就是kanban。这个kanban的主要作用就是通过可视化的方式管理生产过程和物料，让生产根据需求而不是早期的计划来推动。

• 到90年代了，互联网开始兴起。1991年，Crystal水晶方法提出，1994年 动态系统开发方法（dynamic system develop methodology）DSDM被提出。

• 1995年, Scrum正式作为一种研发模式被提出，由Scrum之父 ken schwaber 和 Jeff Sutherland共同发表。这也是现在敏捷研发中应用最广泛的一种模式，几乎是敏捷的代名词。

• 1996年，XP极限编程 发表，作者是Kent Beck。他也是后面发表的敏捷宣言中排名第一的牛人。敏捷中的很多原则其实都来源于极限编程。题外话，Kent还是著名自动化测试框架Junit的作者。可以说后世的很多自动化框架都受Junit的重要影响。

• 2001年，敏捷宣言发表，包括ken，Jeff，kent，还有marting fowler等17个软件开发领域的专家，在美国犹他的雪鸟滑雪胜地共同签署发表。也从此，敏捷开始逐渐走向主流。

• 2005， 大型敏捷框架LeSS( large scale scrum) 框架被提出

• 2006年， 第一届敏捷中国大会召开，由著名的咨询公司ThoughtWorks牵头。

• 2009年，敏捷认证体系DA (Disciplined Agile) 建立

• 2011年，大规模敏捷框架 SAFe(Scaled Agile Framework) 被提出。

• 2018年， BizDevOps被提出，旨在打通业务到研发的通路.

发展到现在，敏捷依然在全球范围内广泛传播，但同时，敏捷也暴露了一些本身的问题，所以 Agile 2.0 也已经开始被提及和讨论。

敏捷宣言

在敏捷的发展中，敏捷宣言的发表是一个里程碑的事件。 从此 敏捷开始逐步走入实践领域并逐步得到广泛应用

敏捷宣言官网

个体和互动高于流程和工具： 敏捷更加强调个体的作用，强调个体的主观能动性比靠流程和工具能更加高效和有用

工作的软件高于文档：这里说详尽的文档，就是指的是很重的僵化的文档，写出来也没多少人真的去看的繁文缛节。而工作的软件，是指能实际运行的软件，“百闻不如一见”

客户合作高于合同谈判： 强调的是沟通，开发者是软件生产者，客户是使用者，二者更多直接的沟通才能更好地去确定做的东西和你要的东西是不是一样的，而不是提前靠所谓的合同来约定

响应变化高于遵循计划，就是变化是肯定存在的，一个好的软件开发过程应该去适应这种变化，而不是按部就班一条道走到黑。

签署敏捷宣言的17位签署人，都是在其领域内有很高成就和声望的专家，这也为敏捷的广泛传播打下了良好的基础。 但是这17人主要都是软件开发领域的专家，对于整个软件产品的生命周期而言，其他角色的缺位，也为敏捷本身的适应性埋下了局限性上的不足。

敏捷 12 原则

除了敏捷宣言外，敏捷还针对实际的应用提出了12项基本原则

• 客户满意 ： 以用户的价值位导向。客户满意意味着软件的价值得到体现，软件体现出价值是我们研发软件的最终目标。

• 拥抱变化： 变化是一定存在的，与其控制变化，不如接受变化。

• 频繁交付： 小步快跑，快速交付，快速得到反馈，方便及时纠偏

• 相互合作（业务和研发）： 业务的需求方，用户代表和生产者、开发团队应该一起工作。及时确认

• 积极的团队：自我激励的团队，团队本身是积极主动的，没有内耗

• 面对面：及时沟通，百闻不如一见

• 可工作的软件：所见即所得

• 稳定的节奏：固定的节奏能更好地形成默契

• 好的设计（技术卓越）：强调软件开发的内功，通过的更好的设计解决问题，降低风险。强调技术卓越

• 简单即美：软件不应该过度开发，逐步满足用户的需求

• 自组织：研发过程的控制权要在开发者自己手中，不要有各种行政命令。  Scrum之父ken 曾经明确表明过，敏捷的目的就是要干掉经理这个职位。😂😂

• 反思和调整: 这条是自我组织的补充，敏捷运作过程种，不可避免也会出现各种失败或者运作不畅的地方，这时要及时回顾和反思，及时调整补救。

笔者对敏捷的看法

敏捷虽然如今在业界广为应用，但也并不是银弹，我们依然要辩证地看待敏捷，天底下没有放诸四海而皆准的理论和方法。

1. 它提出的理念和发展出的一些原则和实践出发点是极好的，但并不是所有的情况都适用，应用敏捷依然要根据产品、项目的实际情况来确定应用方式。

2. 从敏捷宣言和原则中其实也看出来，敏捷本身更多传递的是一种价值观，是软件研发理想的方向，而不是一套方法论。它不是一个指导项目如何运作的执行层面的方法。

3. 敏捷的提出，更多是从软件开发角度来思考的，是这些开发大牛们基于软件开发视角出发得出的思考结论。但敏捷应用在产品领域，很多做法是过于理想化的，比如和客户一起工作，自组织团队等等，特别在一起传统企业，会面临极大阻力。非组织层面的根本性转变是不可能进行推进的。

所以，敏捷本身不是银弹，它也不是方法论。而是一种文化层面的思想，真正理想地得到应用，是需要组织层面的变革方可推进，并不是一个可以从十数人的小团队自下而上推行就可以成功应用的实践。

关于敏捷实际应用，后续还会针对 Scurm 框架进行更多分享。敬请关注。

秋草观“测”台，观察测试业。（公众号：秋草说测试）