写在前面：
近一年来，做了很多与敏捷相关的分享，也写了好几篇以敏捷为主线的文章。最近计划将这些文章稍作整理后陆续发在“其识”上，此文是第一篇。
本文初稿写于17年9月，发布在简书后点击量一路升高，想想可能是很多读者对敏捷的历史与发展感兴趣的原因吧。
全文导读
1.敏捷产生的契机
从历史上来讲，敏捷之所以能产生，有三个方面的原因：软件危机、瀑布模型和互联网的兴起。
2.敏捷的发展
轻量级软件开发方法、敏捷的核心价值。
敏捷产生的契机
软件危机
20世纪60年代以前，计算机刚刚投入实际使用，软件设计往往只是为了一个特定的应用而在指定的计算机上设计和编制，并采用密切依赖于计算机的机器代码或汇编语言。那时软件的规模比较小、文档资料通常也不存在、很少使用系统化的开发方法。设计软件往往等同于编制程序：基本上是个人设计、个人使用、个人操作、自给自足的私人化的软件生产方式。
60年代中期，大容量、高速度计算机的出现，使计算机的应用范围迅速扩大。高级语言、操作系统的发展引起了计算机应用方式的变化；大量数据处理催生了第一代数据库管理系统的诞生。软件系统的规模越来越大、复杂程度越来越高、软件可靠性问题也越来越突出。原来的个人设计、个人使用的方式不再能满足要求，改变软件生产方式、提高软件生产率的诉求越来越强烈，软件危机开始爆发。
软件危机表现在以下几点：
1. 超预算
2. 超时
3. 低效
4. 低质量
5. 不满足需求
6. 无法管理、难以维护代码
7. 永远无法交付
为了试图解决这个问题，产生过很多方法论，曾在不同角度和程度上取得了一定成功。通常来说，越大型的、复杂的、不熟悉业务领域的项目，会遭遇更大的、难以预测的问题。这是敏捷产生的第一个契机。
瀑布模型为代表的软件开发方法
瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作（形如瀑布流水），最终得到软件产品。该模型正式提出是在1970年，直到80年代早期，瀑布模型被指代为软件开发方法的典型。
瀑布模型分为五个大的阶段：需求分析——设计——实现——验证——维护。相邻的两个阶段互为唯一的输入、输出。能进入下一阶段的要求是上一阶段严格完成，并得到审查和验证。瀑布模型不鼓励回顾和修订已经完成的流程阶段，如果审查确认到有可能的变化，会有正式的变更流程。
支持瀑布模型的论点
软件开发早期阶段的时间投入会影响到后期的经济支出。在软件开发早期修复缺陷所需要的时间和努力乃至经济成本，都要远远低于在后期修复同样这个缺陷带来的成本。举个极端的例子，如果程序设计出了问题，注定无法实现或者集成。这个问题如果在设计阶段发现并解决，成本要远远低于把程序都实现出来之后。
在需求分析和设计阶段花的时间都是值得的，会节省大量后期的时间和努力。只要确保前期阶段百分百完成，并绝对正确，就可以进入下一阶段。需求应该在设计之前绝对的不变和稳定，一旦程序员开始实现编码了，设计就不能变，否则就实现了错误的设计，努力白白浪费了。这是瀑布模型的中心思想。
瀑布模型简单、线性、直观、容易理解、有纪律性，提供非常容易识别的里程碑。所以瀑布模型一度成为软件开发过程的首选入门模型。
反对瀑布模型的观点
瀑布模型是一个完美的模型：需求稳定、设计者可以完全预见所有的问题，产生正确的设计；实现者完全遵守设计、精确实现、平滑集成。
然而对于任何一个项目，不可能在进入下一阶段前，完美完成当前阶段。
客户不看见可以工作的软件系统，不会很清楚自己的需求是什么。一旦需求在设计完成之后改变，就意味着设计需要修改，越是在项目后期发生的需求变化，浪费越大。
另外一个忽视的地方，客户在实现前无法完全感知到新技术的能力，依靠“觉得可能”来定义需求和期望。而一旦客户发现新技术的能力，就会倾向于改变需求。一个潜在的解决方案是有经验的程序员会不断地通过重构、模块化的方法来应对可能的变化。
瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式。这是敏捷产生的第二个契机。
互联网的兴起
敏捷产生的第三个契机是互联网的兴起。客户面对强大的市场竞争，需要尽快的投放市场，以验证和证实市场需求，并根据用户的反馈及时地调整需求和策略，这需要有能快速实现和帮助验证的软件过程来支撑。传统的、响应很慢的瀑布模型显然是不合时宜的。而敏捷提供了一种可能，随时停止项目系统的开发，提交给客户的始终是一个可以工作的软件。
敏捷的发展
轻量级方法
软件开发在上世纪90年代受到两个大的因素影响：对内，面向对象变成开始取代面向过程编程；对外，互联网泡沫导致快速投向市场以及公司的快速发展成为关键商业因素。快速变化的需求需要短的产品交付周期，这与传统软件开发流程并不兼容。
什么叫轻量级方法？相对比重量级方法而言，只有一些规则和实践需要遵守，而且更容易遵守。轻重之分，也是交付频率的分别。从上个世纪90年代开始，一些轻量级方法开始涌现。极限编程就是其中的一个例子。
极限编程旨在提高软件质量，和对客户需求变化的响应性。何谓“极限”？
因为和客户交流是好的，所以要推到极致，于是要跟客户坐在一起工作。
因为持续review代码是好的，所以要推到极致，于是要每天都做code reivew、要结对编程。
因为项目尽早集成是好的，所以要推到极致，于是要持续集成、要每一次提交代码都触发集成。
敏捷的诞生
2001年2月，Martin Fowler（敏捷开发方法的创始人之一，现为ThoughtWorks公司的首席科学家），Jim Highsmith（2010年加入ThoughtWorks）等17位著名的软件开发专家齐聚在美国犹他州雪鸟滑雪圣地，举行了一次敏捷方法发起者和实践者的聚会。在这次会议中，他们讨论了这些轻量级方法，发现了彼此的共性：
团队能力
开发实践
客户协作
过程适应性
最后他们正式提出了Agile（敏捷开发）这个概念，并共同签署了《敏捷宣言》。
个体和交互胜过过程与工具
人是软件开发中最重要的因素，开发团队要能做到团结协作，人与人面对面的交流、沟通，是最高效的途径。
可以工作的软件胜过面面俱到的文档
比起在客户会议上只是向客户展示文档，时刻可以运行和提交的软件，更有价值、更受欢迎。
客户协作胜过合同与谈判
承认需求是无法在软件开发周期的早期阶段完全收集清楚的，所以持续的客户参与和沟通非常重要。
响应变化胜过遵循计划
敏捷开发注重快速响应变化，以及持续交付价值。
敏捷是一种价值观，“胜过”不是好的意思，是价值观取向的体现。敏捷认为右边的各项有其价值，但敏捷更重视左边各项的价值。
在代表敏捷联盟介绍宣言的时候，Jim Highsmith解释敏捷运动并不是反对方法论：
敏捷运动并不是反方法论的，实际上，我们许多人希望能重新建立方法论这个词的公信力。我们想恢复一种平衡。我们拥抱建模，但不是只为了画些图纸填满落满灰尘的公司仓库。我们拥抱文档，但并不是编写动辄上百页的文档但从不维护。我们做计划，但我们意识到在混乱的环境中做计划的限制。那些把XP、Scrum或者其他敏捷方法论的提倡者认做是黑客的人，是出于对方法论和黑客这个词最初定义的无知。
12条原则
1. 通过快速交付有用的软件让客户满意
2. 欢迎变化的需求，即使变化发生在开发阶段这么晚
3. 频繁交付可以工作的软件（几周而不是几个月）
4. 在业务人员和开发者之间存在每日紧密的沟通
5. 项目由自我驱动的个人共同参与，他们应该得到信任
6. 面对面的对话是沟通的最好形式
7. 可以工作的软件是进度的主要衡量标准
8. 可持续的开发节奏，能够维持不变的步调
9. 对技术卓越和良好设计的持续关注
10. 简单性是本质——最大化未完成工作数量的艺术
11. 自组织团队
12. 对变化的环境有规律的适应
写在后面：
敏捷开发方法的核心思想概括起来，是“以人为本”和“响应变化”。
以人为本
敏捷方法认为，人是软件开发中最重要的因素。敏捷开发的理念是充分的信任团队能够很好的完成任务，它们注重调动团队的能动性，以积极、愉悦、乐观的心态完成软件开发，并致力于提升团队的能力。
响应变化
传统的软件开发强调的是足够清晰的需求，并制定详细的文档，按照预定的计划逐一进行开发、测试。这样的方式在制定好计划之后拒绝变化，无法应对市场的变化和客户对需求的实时更改，后续的维护必将会付出巨大的代价。
而敏捷方法则是以最简的方式来迎接变化，客户在整个开发过程中都是参与者，开发团队能够在最短的时间内得到市场的反馈，不断响应需求的变更，从而使得最终的产品能够充分的符合用户的要求，并持续交付有价值的软件。
本文作者万学凡，ThoughtWorks首席咨询师，武汉。作者保留本文一切权利，未经许可请勿转载。
网友评论