author：李小波
根据在线统计数据门户网站Statista数据显示，2018年，超过90%的软件开发采用敏捷开发（Agile Development）方式。那么究竟什么是敏捷开发，它又具有怎样的特点和优势呢？
敏捷开发背景
90年代，流行的软件开发方法论比较重，文档多，开发周期长，而且最终的成本、进度、质量大多不太令人满意。因此有人提出了轻量级的软件开发方法Scrum、极限编程、水晶方法等等。2001年，提出这些方法论的17位软件工程界泰斗在美国的雪鸟山庄组织了一场聚会，最终得出了2个东西：敏捷宣言（价值观）和敏捷的12条原则。
普遍认为敏捷分为三层：
上层- 价值观和原则。这一层比较务虚，没有教人具体的做事方式。
中层- 方法论。目前敏捷落地主流有2个方法论：Scrum和极限编程。方法论会告诉你团队怎么组建，角色分工，怎么进行协作。
下层- 实践。每个方法论里有诸多实践，包括需求管理，项目管理，配置管理和质量保障这几个方面如何落地。
现在的敏捷被泛化了，同时又在提大规模敏捷、业务敏捷等，甚至延伸到了软件研发领域之外，例如HR，市场销售领域等。Scrum方法论其实是一个通用的方法论，市场、内容等团队都可以采用。
Monstarlab梦思特中国认为敏捷的三大特点：
聚焦价值 – 始终做最有价值的事，用最少的投入获取最大的回报；
持续改进 – 消除浪费，持续提高效率和质量；
以人为本 – 充分激发和赋能团队中的人。
敏捷开发、瀑布式开发、迭代式开发的区别与共同点
敏捷宣言签署人之一的Martin Fowler画了这张图，这几个概念的关系就显而易见了。
这张图中首先是两种计划的方式，预测型计划和适应性计划。
预测型计划：传统的计划方式，典型的表现形式是甘特图，提前计划好什么时间做什么事情，A依赖B，B就要放在A的后面。
适应性计划：环境越不确定，越需要边走边看，这时过于详细的计划，就是浪费。较好的做法是，做一个比较粗的计划，把近期的计划做细一点，然后定期去回顾并调整计划。
预测型计划适合打靶子，适应性计划适合猎豹子。
根据此图可以得出：
- 瀑布开发是典型的预测型计划，跟敏捷无关；
- 迭代开发也不等于敏捷，它也可能包含预测型计划，尤其是传统企业敏捷转型时，在旧的预算机制和考核机制下，还是非常重视「预测」；
- 不是做了适应性计划就是敏捷，要聚焦价值，持续改进，以人为本。
敏捷开发流行的原因
- 对外：提升用户的满意度
过去的管理方法更追求的是利用率，就是别让「资源」闲着，这个资源主要就是团队中的人，并且让专业的人做专业的事，这样效率才最高。
那为了让大家不闲着，就得让每个人的任务栏始终不空着。让专业的人做专业的事，就把工作越分越细，成立更多的职能部门。
结果呢，从客户的视角看，我提出一个需求，在各个环节都要等待（因为每个人的任务栏都是满的），而且环节又多，每个人都在忙，每个人都有自己的KPI，只管自己的一亩三分地，把我的需求当皮球踢，根本没有响应力。
敏捷的核心思想是：
在响应力和利用率之间，更倾向于响应力。
响应力高的表现是什么呢？
客户提出反馈说网站xxx功能不好用，需要改进，从他提出来改进意见到功能上线可使用，其中的周期越短，说明响应力越强。
为什么要提高响应力？因为现在市场变化快，包括竞争对手的变化、新技术出现、新政策等等。在所谓的VUCA（易变，不确定，复杂，模糊）时代，响应力就是竞争力。对客户的响应越及时，客户留下来的意愿就越强。敏捷中很多的实践就是帮助团队去提升响应力，在更短的时间内，把一个东西呈现在客户面前，以便获取用户的反馈，持续迭代改进。
回到软件开发上，以前那些非常重的方法论，接到一个需求后你要写冗长的需求分析文档，做大而全的设计，包括概要设计、详细设计，然后再编码、测试，这个过程周期太长，客户就会心生不满。
敏捷开发是轻量级的，客户提出反馈，团队内的工程师，或者需求分析师直接与客户交流，理解客户的痛点，马上开发出一个最简单的版本给到客户用，了解客户使用感受，然后再不断地迭代。这样客户有参与感，响应时间缩短，客户更加满意。
- 对内：降低成本
创业公司，初期可能会牺牲一点成本去追求响应力，成立特攻队，每个人都是一专多能的“特种兵”，所有人聚焦在同一个目标上，快速地完成产品，去验证想法，去占领市场。等用户数量提升后，再获取收入，降低成本，滴滴出行、共享单车无不如是。
已经上轨道的业务，用的资源越少，就有越多的资源去做新的业务。
敏捷中有许多降低成本的实践，比如：聚焦更有价值的需求。都知道开发产品有些功能都是拍脑袋提出来的，并不知道其实际价值，敏捷提倡的是别一来就做很大的软件，先把核心流程搞出来，让用户去用一用，然后通过反馈得出什么是最有价值的部分，再把精力放在更有价值的地方，这样成本就可以降低。
还有大量的自动化实践，包括自动化测试、持续集成、自动化部署等等，都可以大大降低成本，释放产能。
敏捷开发的角色分工
不同方法论有着不同的角色定义。
以Scrum为例，包含三个角色：
Scrum Master：帮助团队导入Scrum的专家，相当于团队的教练，让团队将Scrum很好地运作起来。
Product Owner：出预算的人，TA管理团队的待办列表，包括条目和优先级。
Development Team：开发团队是一个端到端的全功能团队，包括前后端、移动端、UI设计、需求分析、运维等等，但是开发团队里的角色就不会分得那么细，最好每个人都是多面手，响应力才会高。举例：如果当前有很多功能堆积在测试环节，一味地开发更多功能，并不能增加团队的产出，所以这个时候应该大家都戴上测试的帽子，去做测试，将瓶颈给消除掉。
有了三个角色，再加上三个工件，五个事件，五个价值观，团队就能形式上敏捷起来了。
敏捷开发中可能面临的挑战
实施敏捷开发面对的挑战，可以从2个维度去看。
一个是人的维度，一个是事的维度。
人：
敏捷的环境下其实对于人的心态，要开放、要学习、要拥抱变化。以沟通为例，做软件开发的人一般不太喜欢面对面交流。具体表现是，能发文字就不发语音，能发语音就不打电话，能打电话就不视频，能视频就不见面。敏捷价值观第一条个体和互动高于流程和工具，这就是一个挑战，作为团队的敏捷教练，就要营造轻松的氛围，通过团建让大家熟悉起来。
事：
不管是传统方法还是敏捷方法，都要做好需求管理、项目管理、配置管理、质量保障这四个方面。在敏捷方法里，有许多新的实践需要团队去学习。
需求管理：以前写需求的时候，需要写一个需求规格说明书，也叫做PRD，是一个比较重的文档；现在呢，敏捷团队的需求实践叫做用户故事地图、用户故事、待办列表。那就需要负责需求的人去学习这种新的沟通需求的方式。
项目管理：原来的项目管理是偏PMP那套，理清楚资源、目标、里程碑，做计划画甘特图这些；敏捷的项目管理，强调的是适应性计划，面对面的沟通，典型的活动有迭代计划会议、每日站会、迭代评审会议、迭代回顾会议等。通过燃尽图等可视化工具来暴露风险。
配置管理：原来可能几个月才发布一个版本，只在上线之前才会发布一个测试版。但是敏捷之后，最好做完之后马上让客户看到。这就对配置管理提出了要求，比如开发人员接到一个任务时，要有意识地暂存手上的工作，单独地提交，而不是和现在手上做的事情混杂在一起。这就需要有好的版本控制工具和工作流。提交后，能自动完成代码规范检查，自动化测试（单元测试、接口测试、功能测试等），自动化部署（开发联调环境、测试环境、用户验收环境、预生产环境、生产环境等），这些环境如何管理，如何灵活地创建和销毁。过程中产生的二进制文件、Docker 镜像等，都需要版本化。这一块的实践在 DevOps，持续交付的领域探讨的比较多。
质量管理：原来几个月才发一次版本，可以留一段时间去做集中测试，但是现在快速迭代，每周甚至每天都要更新多个版本，那质量如何把控呢？就需要把质量的保证工作前移，我们叫做质量内建，就是将质量管理工作内建到开发的整个过程中去。这里最核心的实践就是持续集成、自动化测试、TDD、重构、代码评审、结对编程等。
敏捷转型的挑战不在于敏捷，而在于转型。人的心态怎么转变，如何在高压之下拥抱变化、主动学习。