行业内有太多人吐槽敏捷开发，原因各不相同，有觉得 Agile 就是一坨翔的，有觉得 Agile 太低效的，也有觉得团队小暂时不需要敏捷的，etc。 人的本性都是敏捷的，谁都不想浪费宝贵的时间。抱怨敏捷的人，一是对敏捷理解不够深刻，生搬硬套，觉得不行，然后就一大堆抱怨；二是老板觉得敏捷不能完全的压榨劳动力，也就是行业金句——工作不饱和。
美国人埃里克·莱斯提出了《精益创业》的方法论，它强调的是在风险极高、创业资本有限的情况下，需要快速摸索出最小化可行产品（MVP）尽早进行市场验证，现在精益创业已风行创业领域，但是如何将此方法论具体应用到创业团队产品开发的实践之中？很多创业公司/团队声称自己的精益创业，然而却对团队管理漠不关心，更别说敏捷开发，开发流程乱七八糟，全是小作坊操作，美其名曰：我们要快速的迭代产品，顾不上这些。 我在敏捷的团队做过好几年，敏捷的目的并不是为了让开发事儿更少，而是让大家在有限的时间效率更高。在工作量不变的情况下，更少加班；在工作时间不变的情况下，产出更大。 在欧美软件企业中,有近半数企业已采用敏捷方法进行开发，硅谷FLAG，国内如腾讯、阿里、百度、Fackbook、Yahoo!等等一线互联网公司内部几乎所有的开发团队都在实施敏捷方法。相关统计表明，敏捷开发可以将效率提高3~10倍，项目质量也有更加可靠的保证。
什么是敏捷开发？
- 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。
怎么理解呢？首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；
- 为什么说是以人为核心？
我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。
- 什么是迭代？
迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
敏捷的套路 —— 实践框架
- XP（极限编程）较早出现在中国的原因，得益于当初翻译的几本书（2001年），不过有点极端了，很多传统企业都不能适应。
- Scrum 是精益创业很好的实践方法，概念清晰，可操作性强，落地快，在中国也出现了日渐普及的态势；当然骂声也不少，认为它什么都没讲，太虚了。实际上他们大多数人把自身的问题归结于 Scrum 了。
- FDD（Feature Driven Development）等还有一些其他的过程，声音慢慢就越来越少了。
目前流行的敏捷套路就只有 Scrum 而已，另外一些都越来越少有被人提起了。
这里，我们主要以 Scrum 来讲解敏捷，但千万别以为 Scrum 就是敏捷。 - 关于Scrum和XP
前面说了敏捷它是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而 Scrum 和 XP 就是敏捷开发的具体方式了，你可以采用 Scrum 方式也可以采用 XP 方式；Scrum 和 XP 的区别是，Scrum 偏重于过程，XP 则偏重于实践，但是实际中，两者是结合一起应用的，这里主要讲 Scrum。
Scrum 关键词汇解释
- product backlog: 可以预知的所有任务， 包括功能性的和非功能性的所有任务。
- sprint: 一次跌代开发的时间周期，一般最多以30天为一个周期.在这段时间内，开发团队需要完成一个制定的backlog,并且最终成果是一个增量的，可以交付的产品。
- sprint backlog: 一个 sprint 周期内所需要完成的任务。
- Scrum Master: 确保团队合理的运作 Scrum，并帮助团队移除实施中的障碍。
- PO (Product Owner): 即产品负责人，确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品负责。
- scrum team(开发团队): 一个跨职能的小团队，包括开发测试，人数5-9人为佳，团队拥有交付可用软件需要的各种技能。
- time-box: 一个用于开会时间段。比如每个 daily scrum meeting(每日站立会议) 的time-box为15分钟。
- sprint planning meeting: 在启动每个sprint前召开。该会议需要制定的任务是：PO 和团队成员将 backlog 分解成小的功能模块,决定在即将进行的 sprint 里需要完成多少小功能模块，确定好这个 Product Backlog 的任务优先级。另外，该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。
- Daily Scrum meeting：开发团队成员召开，一般为15分钟。每个开发成员需要向 team 汇报三个项目：
- 昨天完成了什么，完成了百分之多少，还剩百分之多少？
- 今天你打算做什么？
- 完成你的目标是否存在什么障碍？
通过该会议，团队成员可以相互了解项目进度。
-
Sprint review meeting：在每个 Sprint 结束后，这个Team将这个 Sprint 的工作成果演示给 Product Owner，客户，老板和其他相关的人员。
- Sprint retrospective meeting：对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为1小时。
什么是scrum?
Scrum的基本假设是：
开发软件就像开发新产品，无法一开始就能定义软件产品最终的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证专案成功。Scrum 将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。
Scrum 开发流程通常以 30 天(或者更短的一段时间)为一个阶段，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部分，开发团队必须尽力于 30 天后交付成果，团队每天用 15 分钟开会检查每个成员的进度与计划，了解所遭遇的困难并设法排除。
Scrum 三大角色
Scrum“角色”–无规矩不成方圆
- PO
必须有一个项目持有者，制定规划并把握项目走向，一般就是产品经理。 - SM
敏捷教练。一般由对技术开发以及当前项目明晰的技术经理担任。 - TEAM
Scrum 的流程
引用一张图，结合上面的名词解释：
-
我们首先需要确定一个 Product Backlog（按优先顺序排列的一个产品需求列表），这个是由 Product Owner 负责的；
-
正式开始一个 sprint 开始之前，产品、研发、测试需要一同开一次 sprint planning meeting，共同讨论本次 sprint 的功能点，需求讨论或技术讨论；成员预估需求所需开发时间；团队输出是否满足需求，排入 sprint backlog；
-
planning meeting 下来之后每个团队成员对自己在这个sprint中的工作进行整理，拆分小任务，预估开发完成时间，自己排自己的优先级；
-
进行 Daily Scrum Meeting，这个环节在 agile 中非常关键，是 agile 的日常修炼，控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出来寻求帮助。完了以后SM负责根据结果更新 burndown chart；
-
当一个 Sprint 结束时，我们要进行 Sprint Review Meeting，也称为评审会议，产品负责人和客户都要参加，每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
-
最后就是 Sprint Retrospective Meeting，复盘这个 sprint，以轮流发言方式进行，每个人都要发言，总结并讨论做得好的地方、需要改进的地方；根据实际情况进行下一个 sprint 的任务安排。
这样周而复始，按照同样的步骤进行下一次Sprint.
Scrum 的特性
- 不断交付软件以满足客户需求，每个迭代版本都是可运行的
- 欢迎需求的变化
- 及时沟通，拒绝过度设计
- 量化了工作项目的进度和团队的产出
- 流程简单，沟通顺畅
随便总结一下
敏捷是一种流程、方法、理念，甚至信仰；
敏捷不是一种工具，不是用了敏捷的软件就是敏捷了；
敏捷是为了团队成员能够更加紧密地配合完成工作；
敏捷是需要本土化的，可以根据项目团队的情况指定自己的敏捷计划。
