行业内有太多人吐槽敏捷开发，原因各不相同，有觉得 Agile 就是一坨翔的，有觉得 Agile 太低效的，也有觉得团队小暂时不需要敏捷的，etc。
人的本性都是敏捷的，谁都不想浪费宝贵的时间。抱怨敏捷的人，一是对敏捷理解不够深刻，生搬硬套，觉得不行，然后就一大堆抱怨；二是老板觉得敏捷不能完全的压榨劳动力，也就是行业金句——工作不饱和。

美国人埃里克·莱斯提出了《精益创业》的方法论，它强调的是在风险极高、创业资本有限的情况下，需要快速摸索出最小化可行产品（MVP）尽早进行市场验证，现在精益创业已风行创业领域，但是如何将此方法论具体应用到创业团队产品开发的实践之中？很多创业公司/团队声称自己的精益创业，然而却对团队管理漠不关心，更别说敏捷开发，开发流程乱七八糟，全是小作坊操作，美其名曰：我们要快速的迭代产品，顾不上这些。
我在敏捷的团队做过好几年，敏捷的目的并不是为了让开发事儿更少，而是让大家在有限的时间效率更高。在工作量不变的情况下，更少加班；在工作时间不变的情况下，产出更大。
在欧美软件企业中,有近半数企业已采用敏捷方法进行开发，硅谷FLAG，国内如腾讯、阿里、百度、Fackbook、Yahoo!等等一线互联网公司内部几乎所有的开发团队都在实施敏捷方法。相关统计表明，敏捷开发可以将效率提高3~10倍，项目质量也有更加可靠的保证。

什么是敏捷开发？

1. 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

怎么理解呢？首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；

2. 为什么说是以人为核心？

我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。

3. 什么是迭代？

迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

敏捷的套路 —— 实践框架

• XP（极限编程）较早出现在中国的原因，得益于当初翻译的几本书（2001年），不过有点极端了，很多传统企业都不能适应。
• Scrum 是精益创业很好的实践方法，概念清晰，可操作性强，落地快，在中国也出现了日渐普及的态势；当然骂声也不少，认为它什么都没讲，太虚了。实际上他们大多数人把自身的问题归结于 Scrum 了。
• FDD（Feature Driven Development）等还有一些其他的过程，声音慢慢就越来越少了。

目前流行的敏捷套路就只有 Scrum 而已，另外一些都越来越少有被人提起了。
这里，我们主要以 Scrum 来讲解敏捷，但千万别以为 Scrum 就是敏捷。

• 关于Scrum和XP

前面说了敏捷它是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而 Scrum 和 XP 就是敏捷开发的具体方式了，你可以采用 Scrum 方式也可以采用 XP 方式；Scrum 和 XP 的区别是，Scrum 偏重于过程，XP 则偏重于实践，但是实际中，两者是结合一起应用的，这里主要讲 Scrum。

Scrum 关键词汇解释

1. product backlog: 可以预知的所有任务， 包括功能性的和非功能性的所有任务。

2. sprint: 一次跌代开发的时间周期，一般最多以30天为一个周期.在这段时间内，开发团队需要完成一个制定的backlog,并且最终成果是一个增量的，可以交付的产品。

3. sprint backlog: 一个 sprint 周期内所需要完成的任务。

4. Scrum Master: 确保团队合理的运作 Scrum，并帮助团队移除实施中的障碍。

5. PO (Product Owner): 即产品负责人，确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品负责。

6. scrum team(开发团队): 一个跨职能的小团队，包括开发测试，人数5-9人为佳，团队拥有交付可用软件需要的各种技能。

7. time-box: 一个用于开会时间段。比如每个 daily scrum meeting(每日站立会议) 的time-box为15分钟。

8. sprint planning meeting: 在启动每个sprint前召开。该会议需要制定的任务是：PO 和团队成员将 backlog 分解成小的功能模块,决定在即将进行的 sprint 里需要完成多少小功能模块，确定好这个 Product Backlog 的任务优先级。另外，该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。

9. Daily Scrum meeting：开发团队成员召开，一般为15分钟。每个开发成员需要向 team 汇报三个项目：

   1. 昨天完成了什么，完成了百分之多少，还剩百分之多少？
   2. 今天你打算做什么？
   3. 完成你的目标是否存在什么障碍？

   通过该会议，团队成员可以相互了解项目进度。

10. Sprint review meeting：在每个 Sprint 结束后，这个Team将这个 Sprint 的工作成果演示给 Product Owner，客户，老板和其他相关的人员。

11. Sprint retrospective meeting：对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为1小时。

什么是scrum?

Scrum的基本假设是：

开发软件就像开发新产品，无法一开始就能定义软件产品最终的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证专案成功。Scrum 将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。
Scrum 开发流程通常以 30 天(或者更短的一段时间)为一个阶段，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部分，开发团队必须尽力于 30 天后交付成果，团队每天用 15 分钟开会检查每个成员的进度与计划，了解所遭遇的困难并设法排除。

Scrum 三大角色

Scrum“角色”–无规矩不成方圆

1. PO
   必须有一个项目持有者，制定规划并把握项目走向，一般就是产品经理。
2. SM
   敏捷教练。一般由对技术开发以及当前项目明晰的技术经理担任。
3. TEAM

Scrum 的流程

引用一张图，结合上面的名词解释

1. 我们首先需要确定一个 Product Backlog（按优先顺序排列的一个产品需求列表），这个是由 Product Owner 负责的；

2. 正式开始一个 sprint 开始之前，产品、研发、测试需要一同开一次 sprint planning meeting，共同讨论本次 sprint 的功能点，需求讨论或技术讨论；成员预估需求所需开发时间；团队输出是否满足需求，排入 sprint backlog；

3. planning meeting 下来之后每个团队成员对自己在这个sprint中的工作进行整理，拆分小任务，预估开发完成时间，自己排自己的优先级；

4. 进行 Daily Scrum Meeting，这个环节在 agile 中非常关键，是 agile 的日常修炼，控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出来寻求帮助。完了以后SM负责根据结果更新 burndown chart；

7. 当一个 Sprint 结束时，我们要进行 Sprint Review Meeting，也称为评审会议，产品负责人和客户都要参加，每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；

8. 最后就是 Sprint Retrospective Meeting，复盘这个 sprint，以轮流发言方式进行，每个人都要发言，总结并讨论做得好的地方、需要改进的地方；根据实际情况进行下一个 sprint 的任务安排。

这样周而复始，按照同样的步骤进行下一次Sprint.

Scrum 的特性

• 不断交付软件以满足客户需求，每个迭代版本都是可运行的
• 欢迎需求的变化
• 及时沟通，拒绝过度设计
• 量化了工作项目的进度和团队的产出
• 流程简单，沟通顺畅

随便总结一下

敏捷是一种流程、方法、理念，甚至信仰；
敏捷不是一种工具，不是用了敏捷的软件就是敏捷了；
敏捷是为了团队成员能够更加紧密地配合完成工作；
敏捷是需要本土化的，可以根据项目团队的情况指定自己的敏捷计划。