导读：敏捷是目前业界最流行的软件开发模式，尤其是在互联网公司，作为产品经理应该要了解一些敏捷常识，以方便与开发团队交流。
一千个人心中有一千个哈姆雷特，每个人对敏捷的理解也可能会各不相同。你心中的敏捷是什么样子的？请用一些词语描述，把它们写在纸条上。等看完本文，再回顾它们，可能会有收获，欢迎评论交流。
敏捷的发展历程
敏捷起源
很多人以为CMMI是传统方法，而敏捷是很潮、很酷的新方法。其实不然，需要澄清一点：敏捷不是很新的方法。第1个有记载的使用敏捷方法（迭代和增量开发）的项目，是在上世纪七十年代，为美国第一艘三叉戟潜艇开发的指挥和控制系统。整个系统一百万行代码，非常成功。
敏捷比CMM更早
1977年就有介绍敏捷方法的书，同时也有敏捷的实践。而SEI（卡耐基大学软件工程研究所）在1984年才成立，1987年才开始研究CMM，1991年才发布CMM1.0。
看到这里很惊讶吧？敏捷的历史其实比CMM还要长。敏捷早出现了，但发展缓慢，长时间不成体系、不成主流。在CMM高速发展的时代，敏捷很长时间里仍默默无闻。直到2001年，第一本敏捷开发的专著《敏捷软件开发》才出现。
软件过程的重与轻
关于软件过程的重与轻，CMM曾经是这样看自己的
然后又是这样看敏捷的
2000年以后，敏捷随着互联网的高速发展也快速兴起。而2010年以前，CMMI为代表的重量级软件开发方法仍然是主流。2010年是一个分水岭，敏捷的流行程度开始超过CMMI。
敏捷是这样看CMMI的：
敏捷是这样看自己的：
敏捷的春天
2001年敏捷宣言发布，才宣告敏捷的春天来了。敏捷宣言实际上就是屌丝们的武林大会宣言。
为什么敏捷很长时间没有发出自己的声音？因为敏捷是屌丝。
我们来看看，敏捷宣言的发起者是些什么人？
全部是单枪匹马的民间屌丝，没有一个机构。当然他们都是英雄——屌丝中的战斗机。
再回想一下：CMM的发起者是谁？SEI。SEI是美国国防部资助成立的，是官方组织，CMM项目一直拿着官方大把的钞票。而且，CMM颁布后是作为甲方招标的标准，谁敢不听，还不想中标了不是。所以，CMM是官二代和富二代，与敏捷这种屌丝不一样。
后来，时代不一样了，互联网2.0时代来了，得屌丝者得天下。
屌丝们的春天来了，敏捷翻身了，日益蓬勃发展起来。
敏捷成为主流
据统计到2008年，欧美软件企业中有近半采用敏捷进行开发。2010年左右，采用敏捷的软件组织早已过半，敏捷成为主流。
人红是非就多！在敏捷大流行的时候，关于敏捷的论战也开始多起来，谁都想争武林正统：Scrum联盟和LEAN联盟，暂时Scrum更胜一筹，因为它的商业化运作得更好。
SEI也不甘示弱，2010年发布CMMI-v1.3，这个版本更加开放，把敏捷最佳实践也纳入规范框架（没办法，敏捷太火了）。
关于CMMI的内容，参见我的另一篇文章《产品经理应该熟悉的CMMI模型》。
敏捷宣言
敏捷武林大会
有一些人一直在探索，期望找出一种轻量级的、够用的、能自我改进的方法论。他们就是敏捷的发起人。2001年2月11日，在美国犹他州雪鸟滑雪圣地的一间小屋中，由Kent Beck、Alistair Cockburn、Martin Flower等17位轻量级软件方法专家成立了“敏捷联盟”，发布了《敏捷软件开发宣言》。Agile这个词正式用于描述敏捷软件开发，代替轻量级软件方法。
<穿插一点小故事：Martin Fowler的故事>
敏捷宣言里最重要的一句话是这句：“我们一直在实践中寻找更好的软件开发方法，身体力行的同时也帮助他人。”
随着时代的进步和技术的发展，敏捷方法必然会被更先进的方法淘汰，但它的精神永存。推荐阅读：敏捷已死。
敏捷方法
敏捷不是一种方法论，而是一套价值观。敏捷宣言从一开始就是多种方法论的求同存异，是一个相互妥协的产物。所以，符合敏捷价值观的方法都可以归入敏捷方法，它是一堆方法论，而不是一种方法论。
敏捷方法很多都是经验主义。它们有一些公认的特征，例如：迭代和增量开发；以人为核心；及时交付等。
敏捷价值观
当时正在学习或正在实践敏捷开发的开发者们，经常关心自己的团队或组织是否敏捷，并以此来划分阵营或贴标签：你不敏捷！你是假敏捷！
我的经验是，不要太在意这些，少谈一些价值观，因为这容易陷入无谓的争论。有没有敏捷，不是看你是否喊着敏捷的口号，也不是看你是否用着敏捷的方法，而是看你是否取得了敏捷的实效。不看口号，看疗效！君不见，那些高调大喊口号的互联网公司或软件公司，往往死得更快吗？
注重实效的敏捷开发，不崇尚空谈。与其坐而论道，不如起而行之！
大量喜欢谈“价值观”的公司，极少去践行“价值观”，大多是在耍流氓。我理解的所谓敏捷价值观，就是少谈价值观。我们只需了解敏捷的价值观，但我们在实践中要少谈价值观，多谈实践论，多做少说。
敏捷是以人为本，价值驱动，消除浪费。
敏捷实践
敏捷方法
敏捷方法论都是注重实践的方法论。归根到底，不在于你说了什么，要看你做到了多少。
你听说的敏捷，你理解的敏捷，与真实的敏捷也许不一样。
你有没有按期交付可工作的软件？如果没有，那你不是敏捷！
你有没有改变沟通协作的工作方式？如果需求人员、设计人员、编码人员和测试人员，甚至市场人员或客户，还仅仅通过文档进行交流，没有面对面的沟通，那你不是敏捷！
敏捷方法的优点
敏捷能提高产品质量。敏捷能提高项目成功率。敏捷能让开发人员少加班。敏捷能让团队不写文档……诸如此类关于敏捷优点的传言，都是假的，“Fake News”！唯有一条是真的：敏捷会让你死得更快！从而避免了更多浪费。
主流的敏捷方法
敏捷从来没有统一的方法论，而是有一组方法供大家选择。
其中，国内大家用得最多的组合是Scrum+XP，被誉为敏捷实践最佳CP，一个负责管家（敏捷项目管理），另一个负责打拼（敏捷工程实践）。
Scrum简介
Scrum的原意是橄榄球运动的一个专业术语，表示“争球”的动作。
一个开发流程取名为Scrum，想必发明者是希望开发团队在开发项目时像打橄榄球一样打了鸡血，人人你争我抢地完成工作任务。
Scrum是一个基于团队进行复杂系统和产品开发的框架。
——Scrum联盟
Scrum角色
Scrum有三个角色：
产品负责人（Product Owner，PO）：负责确定产品的需求和优先级，确定故事的完成标准，确定版本发布计划和交付内容，通常由产品经理担任。
管理员（Scrum Master）：负责整个Scrum团队按流程顺利实施，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
开发团队（Scrum Team）：负责软件产品在的开发工作，建议人数控制在5-9人，每个成员负责不同的技术方面但可以相互备份，要求成员要有较强的自我管理能力。
Scrum里的角色用龙舟团队里的角色来比喻最形象：PO是龙舟尾部的舵手，他是部队主官，他掌控着龙舟的方向；Scrum Master是龙舟头部的鼓手，他是部队政委，他通过鼓点声协调团队的节奏；Scrum Team是龙舟的桨手，保持着节奏划船，他们知道团结一致的步骤是保持团队战斗力的关键。
Scrum模型
Scrum的开发过程很像工厂的生产过程：工厂生产时，根据生产线的月产量（Scrum的周期也通常是一个月），从产品订单中按优先级选取一定量的订单进行生产。生产线上每天早晨开例会，月初计划会议上“打鸡血”，月末总结会议上算成绩然后表扬或批评。
Sprint原意是一次短距离的冲刺，这里指的是一次迭代开发过程，一次迭代的周期Scrum建议是2-4周，最好保持固定。
Scrum会议
Scrum会议是Scrum主要的交流沟通方式，有三种类型的会议：
1）每日站会（Daily Scrum Meeting）：每天都要开的会议，要求简短高效 ，所以不能坐着而要站着开会，而且会议时间控制在15分钟以内。每个人轮流发言，只说三件事：我昨天完成了什么；我遇到了什么障碍；我今天计划要完成什么。每个人说完后，在任务看板前更新自己的任务贴纸。
2）Sprint计划会议（Sprint Planning Meeting）：从产品订单（Backlog） 中按优先级挑选出若干故事作为本次迭代要完成的内容。在计划会议上可以调整故事的估计点数，可以修正故事的描述等。
3）Sprint演示和回顾会议（Sprint Review Meeting and Retrospective Meeting）：这是两个会议，但通常在一起开。Sprint Review Meeting（演示会议，也叫评审会议），产品负责人和客户（客户代表）都要参加，开发团队要演示自己完成的软件产品供与会者评审。Sprint Retrospective Meeting（回顾会议，也叫总结会议）团队成员轮流发言，说出自己认为做得好的地方和需要改进的地方，然后大家投票选出需要改进的地方（一次不要超过三点），讨论改进措施，在下一个迭代中实施。
后话：Scrum的一些问题在实践中受到一些团队的诟病，Kanban方法以其更灵活和更简便的优点正有日益代替Scrum的趋势。
XP简介
极限编程方法论可以说是敏捷联盟中最鲜艳的一面旗帜，也是被研究、尝试、应用、赞扬、批判最多的一种方法论，也是相对来说最成熟的一种。极限编程的主要目标是降低因需求变更而带来的成本，比较适合小团队开发。
极限编程（ExtremeProgramming，简称XP）是Kent Beck在1996年提出的一种软件开发方法，是最富有成效的几种敏捷方法学之一。极限编程和传统软件开发方法学的本质不同在于它更强调可适应性，Kent Beck把它叫做“拥抱变化”。
关于极限编程的价值观与敏捷的价值观类同，这里不赘述，请查阅相关图书。
极限编程由一系列简单却互相依赖的实践组成：
这十三个实践，开发组织可以根据自己的情况，选择一些实践来实施，不要急于求成，不要期望一步到位，应该是渐进式的改进。不要指望有哪个团队可以把这十三个实践都施行得富有成效，因为每个团队的能力和组成不一样，面临的业务情况也不一样。实施极限编程的团队，应该把那些施行得富有成效的XP实践强化再强化，争取做到极致，而放弃或弱化那些自己团队不擅长或没有成效的实践，这也是“极限”的一个解释，即扬长避短。
以内圈实践为例：
结对编程（Pair Programming）：由两个开发人员结成对子一起完成工作任务。结对的方式多种多样，可以使用领航员模式（一个写代码，另一个评审），也可以使用乒乓球模式（一个写测试代码，另一个写实现代码）。结对编程的关键在于，要间隔一段时间后互换角色，因为一直被另一个人盯着写代码是高度紧张的，感觉像监工下的工作，而且可怕的是这个监工只盯你一个人。现实中极少有团队全程使用结对编程，因为成本太高了。但是，针对核心代码或难点代码的开发使用结对编程，仍然是非常有价值的。另外，针对新人的传帮带使用结对编程非常有效果，这样做有利于知识在团队中的传递。
测试驱动开发（Test-Driven Development，TDD）：先写出测试代码，然后完成实现代码，要求恰好满足测试代码即可。一定要注意恰好二字，可以避免过度设计，减少代码不必要的复杂度。
重构（Refactoring）：随着开发的进展，特性添加了一个又一个，Bug处理一个又一个，代码结构会逐渐地退化，所以需要我们经常性的进行重构，以防止技术债务累积。重构是持续的、不定时的活动。
简单设计（Simple Design）：极限编程推荐设计要尽量的简单，只考虑恰好能够工作的最简单的方案。
推荐扩展阅读：
[1] 敏捷软件开发（原书第2版），Alistair Cockburn，机械工业出版社，2008年01月
[2] Scrum敏捷项目管理实战，Ken Schwaber，清华大学出版社，2000年01月
[3] 解析极限编程——拥抱变化（原书第2版)，Kent Beck，机械工业出版社，2011年09月
