本文的目的不是为了告诉你什么是敏捷，而是为了介绍敏捷的发展历程。本文会介绍为什么传统的软件工程无法满足软件行业的发展，为什么我们需要敏捷。这篇文章也是关于《敏捷中国史话》的读后感。感谢作者对敏捷的贡献，这是我接触过的的第一本研究“敏捷历史”的作品。
一、软件业发展背景
说到敏捷不得不提软件工程，说到软件工程不得不先提一下软件业的发展背景。
国内的计算机技术在建国后就有在发展，软件行业的发展可以追溯到80年代，不过那个时候不是所有人都有条件能够接触到软件，所以软件的发展相对缓慢。一直到90年代，PC逐渐普及、中国接入国际互联网，国内的软件业才开始展现出蓬勃的生机。
政策扶持
80年代（定义）
- 《软件产品计价收费办法》
- 《关于建立和发展我国软件产业的报告》
90年代（保护）
- 《中华人民共和国著作权法》
- 《计算机软件保护条例》
- 《计算机软件著作权登记办法》
00年代（鼓励、扶持）
- 《鼓励软件产业和集成电路产业发展的若干政策》
- 《鼓励软件产业和集成电路产业发展有关税收政策问题的通知》（即18号文）
- 《关于印发国家规划布局内的重点软件企业认定管理办法（试行）的通知》
- 《振兴软件产业行动纲要》
- 《进一步鼓励软件和集成电路产业发展的若干政策》
“18号文”的出台，对软件产业从投融资政策、税收政策、产业技术政策、出口政策等方面给予支持。通过政策引导，鼓励资金、人才等资源投向软件产业，鼓励国内企业充分利用国际、国内两种资源，努力开拓两个市场。从此，拉开了中国软件产业“黄金十年”发展的序幕。
政府上网工程
1999年，40多个部委的信息主管部门共同倡议发起了“政府上网工程”。
- 政府机关内部的信息共享与无纸化办公；
- 从地方到中央的联网智慧调度和快速反应；
- 在互联网上提供公众服务；
企业信息化
90年代，发展的比较好的软件企业几乎都是工业软件，或者做企业信息化的。
- 金蝶软件，成立于1993年，国内领先的财务管理软件公司，2001年在港交所上市。
- 用友网络，成立于1995年，国内领先的财务管理软件公司，2001年在上交所上市，是A股第一家私营软件上市公司。
- 宝信软件，成立于1996年，国内领先的冶金行业软件公司，2001年在上交所上市。
- 远光软件，成立于1998年，国内领先的能源行业企业管理软件公司，2006年在深交所上市。
- 石基信息，成立于1998年，国内领先的酒店管理软件公司，2007年在深交所上市。
- 广联达，成立于1998年，国内领先的建筑行业软件公司，2010年在深交所上市。
- 软控股份，成立于2000年，国内领先的橡胶行业信息化公司，2006年在深交所上市。
- 启明信息，成立于2000年，国内领先的汽车行业管理软件公司，2008年在深交所上市。
- 中望软件，成立于1998年，国内领先的二三维制图软件公司，2020年申请科创板上市中
二、急需软件工程
软件危机
软件的技术跟不上硬件的发展，造成了许多问题，这时候，诞生了一个概念叫做“软件危机”。
软件危机主要体现在：
- 大多数软件开发成本都超预算，开发进度一拖再拖；
- 软件产品质量不可靠；
- 软件难以维护；
- 软件产品开发效率跟上不硬件的发展、跟不上用户需求的增长；
国内同样有了中国化的软件危机。首先，国际版的软件危机在国内一样存在，除此之外，由于国内软件行业发展比较晚，所以国内还存在人才少、高级软件人才更少、企业规模小、开发缺乏规范性等特点，当软件业务越来越复杂，对软件的要求越来越高的时候，国内的人才储备不良、软件开发方法的缺失等问题成为了影响行业发展的瓶颈。
第一次尝试（编程技术的自救）
观察软件技术自身的发展，当业务开始变得复杂的时候，人们发明了面向对象编程。
人们寄希望于通过通过面向对象的思想来实现对数据的抽象和封装，以提升软件的可复用性和可靠性，使软件更容易被理解和维护。
虽然面向对象通过继承和封装提升了软件的可读性和可复用性，能够在一定程度帮助开发者解决一部分软件复杂度日益提升的问题。
但是软件技术的提升，并不意味着程序员自身技术的提升。回顾我们自己写的代码，有多少用到了面向对象的思想呢。
这说明软件危机并不是单纯地提升软件技术本身就能够解决的。
第二次尝试（向传统行业学习&CMM）
尽然无法依靠软件开发者自己去解决问题，那么就去参考一下其他行业是怎么做的吧。
既然国内软件人才不够，那么就想办法降低软件开发对技能的要求就好了。以工业为例，原先的手工作坊，通过工程化、流水线的方式去处理，通过构建标准，通过分工合作，从而快速生产高质量产品。于是，有一部人开始试想着，让一部分高端人才去负责“零件”的设计和开发，让大部分低技能的人负责零件的拼装。这部分负责零件拼装的人主要从事着简单的、重复的劳动，也就是“软件蓝领”。
但在实践中我们发现，要让一个程序员只在电脑前做零件拼装，根据规范踏踏实实工作，不受任何外界干扰，这简直就是天方夜谭。因为软件行业并不像传统行业那般，可以通过高度的规范化来解决问题，因为需求来自于不同背景的客户，不同的客户需求千差万别，程序员必须不断地学习和沟通、不断的创新和挑战自我，才能够完成客户的需求。这跟“低技能”、“简单重复劳动”的描述相差甚远。
此时业界存在一套叫做CMM（软件成熟度模型，主要是CMM，不是CMMI）的模型，“18号文”正好鼓励企业通过CMM认证，所以国内开始了大量的CMM认证。
CMM将软件过程的成熟度分为5个等级,以下是5个等级的基本特征：
- 初始级(initial)。工作无序，项目进行过程中常放弃当初的计划。管理无章法，缺乏健全的管理制度。开发项目成效不稳定，项目成功主要依靠项目负责人的经验和能力，他一旦离去，工作秩序面目全非。
- 可重复级(Repeatable)。管理制度化，建立了基本的管理制度和规程，管理工作有章可循。 初步实现标准化，开发工作比较好地按标准实施。 变更依法进行，做到基线化，稳定可跟踪，新项目的计划和管理基于过去的实践经验，具有复现以前成功项目的环境和条件。
- 已定义级(Defined)。开发过程，包括技术工作和管理工作，均已实现标准化、文档化。建立了完善的培训制度和专家评审制度，全部技术活动和管理活动均可控制，对项目进行中的过程、岗位和职责均有共同的理解 。
- 已管理级(Managed)。产品和过程已建立了定量的质量目标。开发活动中的生产率和质量是可量度的。已建立过程数据库。已实现项目产品和过程的控制。可预测过程和产品质量趋势，如预测偏差，及时纠正。
- 优化级(Optimizing)。可通过采用新技术、新方法，集中精力改进过程。具备防缺陷、识别薄弱环节以及改进的手段。可取得过程有效性的统计数据，并可据此进行分析，从而得出最佳方法。
CMM的引入，促进了国内软件行业的发展，督促企业反思内部管理流程，使用各种流程和工具去构建和规范企业内部的各个过程域的标准，在需求管理、项目管理、配置管理上都有了或多或少的实践，软件危机的一部分问题得到了解决。
这时候，我们才开始相信软件工程。
什么是软件工程？
所谓软件工程，有很多种解释，比如：
- 《计算机科学技术百科全书》：软件工程是应用计算机科学、数学、逻辑学及管理科学等原理，开发软件的工程。软件工程借鉴传统工程的原则、方法，以提高质量、降低成本和改进算法。其中，计算机科学、数学用于构建模型与算法，工程科学用于制定规范、设计范型(paradigm)、评估成本及确定权衡，管理科学用于计划、资源、质量、成本等管理。
- ISO 9000：软件工程过程是输入转化为输出的一组彼此相关的资源和活动。
- ...
我们暂且不去管所谓的定义，我们只需要知道他是为了解决什么。
记住这两点：
- 软件工程是为了更好的去做复杂软件系统的开发与维护；
- 软件工程包含了一系列概念、理论、模式、方法、工具，是一门综合性学科；
三、敏捷的引入和误解
相信每个开发者都很烦写文档，什么详细设计、什么概要设计一堆文档，如果你没写过，要么你是前端，要么你已经处于一个敏捷团队中，要么就是你们的团队还没到需要标准的阶段。
明明事情都做不完，还要写一堆让人头疼的文档，可能是开发者觉得比较困惑的一个问题了。那么首先，为什么要写文档？答案是因为标准化，一个企业必定会要求对生产的各个环节去制订一些标准，那么比较通用的行业标准是什么？那自然就是CMM/CMMI了。
CMM/CMMI的确是一个比较重的综合性模型，他对于不同级别有着不同的要求，对于规定的阶段或者动作要求产生对应的一系列文档。一般来说，项目周期比较长、需求比较确定的项目可能比较使用CMM/CMMI模型。
但实际上我们在日常工作的时候，并不是一开始就写那一堆文档的，往往是要交付的时候才补上。这就说明CMMI对于软件开发者似乎有一些太重了——这是普遍现象！
敏捷如何解决传统问题
传统软件工程通常从以下四个方面去解决问题：
- 需求管理；
- 项目管理；
- 配置管理；
- 质量保证；
敏捷认为，需求是一个持续迭代的过程，所以应该将需求拆解到比较细的粒度，通过多次迭代去交付。
| 领域 | 方法 |
|---|---|
| 需求管理 | 用户故事（INVEST原则）、通过迭代的形式交付增量 |
| 项目管理 | 围绕用户故事开展计划会议、回顾会议、每日站会；可视化； |
| 配置管理 | 以持续集成为核心，软件时刻保持可用状态 |
| 质量保证 | 持续集成、测试驱动、自动化、软件技术自身（模式+重构） |
CMM和敏捷的视角差异
CMM/CMMI的视角是流程和文档，CMM/CMMI认为，流程是控制生产的手段，文档是确保每一个阶段完成的标志，然后再通过工具来协助计量和管理，如果质量不好，就说明流程没按要求落实，管理不到位；理论上不管用什么人，只要通过CMM/CMMI的管理，都可以成功；具体如何去实施CMM/CMMI不作要求。企业在实践CMM/CMMI的时候，要么缺乏工具，要么缺乏好用的工具，这就导致很大一部分的工作被转移到人的身上，反而加重了人的负担。
所以软件开发者必定会更向往一个轻量级的开发方法。那就是敏捷。敏捷的视角是人，敏捷认为实际编写代码的程序员才是对软件开发效率和质量负责的主要角色，所以软件开发应该是以人为本的工作，应该减少浪费，集中精力做最重要的事；敏捷提供了落地实施的一系列手段，比如持续集成、测试驱动、用户故事等具体措施。敏捷认为，项目成功的关键是团队，过程只是为团队提供支持。
解读敏捷宣言
接受过敏捷培训的同学或多或少都会记得敏捷宣言中的四个价值观：
- 个体和互动大于流程和工具；
- 工作的软件大于详尽的文档；
- 客户合作大于合同谈判；
- 响应变化大于遵循计划；
对敏捷的误解
人们在看到敏捷价值观的时候，下意识认为，敏捷就是没有文档、没有流程、可以快速响应变化。
当我们站在不同的视角，这四条价值观带给我们的感受都会不同。
如果是开发人员，可能最容易接受的是第二条“工作的软件大于详尽的文档”，很显然，尽量少的文档能够减轻开发者的工作负担，这样才能将精力完全投身于业务逻辑的实现上。
而对于甲方来说，敏捷的前3条价值观可能都无法接受。因为甲方最怕风险，一是审计风险、二是违约风险。所以他们希望一切都能留底，并希望你更早地去承诺，否则凭什么给你去做？但是第4条还是表示喜欢，这样需求就可以“随便改”了。
**如果是乙方，**可能最希望的是往往是第三条和第四条：“客户合作大于合同谈判”以及“响应变化大于遵循计划”。因为乙方是专业的软件开发公司，他们必定知道软件开发过程中总会有各种说不清道不明的问题，所以最希望的反而是遵循变化（当然了，那必须是遵循乙方自己想要的变化，比如适当延期、砍掉一些功能等等）。
这里存在两个问题：
- 不同角色看重的东西各有不同，但要求它满足自己的价值观和利益；
- 大部分企业都认为敏捷就只适合小项目、敏捷是一种自由散漫的工作方式；
市场因素
主导权在于需要更多信息的甲方，以及业界和企业对敏捷的误解，导致了敏捷的推广步履维艰。
但除此之外，还有其他的因素，比如激烈的市场竞争、传统教育理念。
这里有必要先补充一下敏捷的核心之一：减少浪费。敏捷就是让人将最重要的人和时间去做最重要的事情，关注与软件所提供的价值。
but
存在很多“一定会成功”的项目，这部分项目关注的更多的是需要具备齐全的功能，并且做的要快。
企业更关注的是降本增效——用更少的人、在更短的时间、做更多的事。
......
敏捷还是被接受了
因为，人们逐渐意识到，敏捷的思想不仅仅能够作用在软件开发上，还可以进一步延伸到业务上和企业战略上。
- 敏捷向非研发人员的延伸。这里指的是在需求管理上，除了研发人员，如果需求的提出者无法提供真实的需求、如果产品经理只是简单记录用户的需求、如果需求的传递存在较高的失真率，不仅无法提供搞的产品实现软件价值，更无法获得良好的用户体验。而敏捷方法能够进一步提升团队和产品整体水平。
- 企业的自救。在严峻的外部压力面前，诺基亚和华为选择了敏捷转型，希望能够通过敏捷缩短产品研发和市场反馈的周期，跟上竞争日益剧烈的市场变化。
四、还有什么
这里其实已经超出这篇文章的范围了。
只是想再提一句。
我们在做敏捷的时候，不能只关注 “高质量、低成本、快速响应” 这几个误区，而要关注如何去支撑敏捷、以及敏捷思想本身。
要注重反馈和改进，不能只关注敏捷的形式（站会、看板）。
敏捷不是降本增效。敏捷不是通过简化流程，提高工作效率，从而能够让团队可以做更多的工作。而是要在合理的设计下，通过小批量的迭代，控制风险，通过持续改进，减少变化所带来的额外工作量。（一个是变化多，你们就要做更多的事，虽然一个是变化多，但是你们要做的事变少了。二者存在本质的区别。）