一、什么是敏捷？
凡是符合敏捷价值观和原则的方法论，都可以归到敏捷的大伞下。
敏捷 = 价值观 + 原则 + 一系列符合价值观和原则的方法。
单纯说敏捷是一种方法，肯定是片面的；但只强调它的价值观和原则，而不重视方法也是不对的，因为那样敏捷就飘在空中，不能落地了。
二、敏捷宣言（价值观）解读
2.1、个体互动高于流程和工具
团队的能力最终取决于团队中每个人的能力以及人与人之间丰富而微妙的互动，流程和工具只能辅助，无法替代优秀的个人与默契的团队；
2.2、工作的软件高于详尽的文档
很多企业长期苦于软件质量不佳、交付进度无法保障、客户需求把握不准等问题，而传统软件工程方法提倡的文档（需求分析文档、总体设计文档、详细设计文档）对于这些问题帮助往往并不明显。
能在漫长的项目过程中更早、更频繁地看到真实运转的软件，对于降低项目风险明显是有益的。这也是为什么后来华为等通信企业在敏捷转型时都选择了持续集成作为重点突破口：因为持续集成解决了通信系统集成慢且难的问题，使项目团队能够更早、更频繁地获得可工作的软件。
错误认知：敏捷来了，太好了，我们只要负责开发软件就够了，再也不用做文档，也不用做设计了。
对项目交付、维护有风险的文档和设计还是必不可少的。
2.3、客户合作高于合同谈判
避免以甲方乙方的姿态抠合同细节和纠结于复杂的变更管理流程，建立包含技术和业务的一体团队，超越单个项目、单个合同的局限，在长期的合作中建立共赢关系。
2.4、响应变化高于遵循计划
软件工程常使用“需求采集”或“需求分析”的说法，会给人一种错觉，似乎精准而确定的需求一直就在客户的脑子里，软件团队只需要找到办法将其全部“采集”并正确“分析”即可。
然而实际上，客户经常自己也并不完全清楚软件应该具备什么功能以及应该如何运作。当他们看到并试用真实的软件时，模糊的想法会变得更加清晰，新的想法会被催生出来，他们就会要求改变或增加需求。
“响应变化高于遵循计划”，很大程度上是对软件团队的能力要求。
三、敏捷12原则
- 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
- 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
- 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
- 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
- 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
- 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
- 工作的软件是首要的进度度量标准。
- 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
- 不断地关注优秀的技能和好的设计会增强敏捷能力（避免建立技术债务）。
不要做一些在短期内让它变得更快的事情，或者减少一些步骤，但从长远来看这实际上成本更高。如果您继续积累技术债务，您将不会有太多的敏捷性！ - 保持简单并消除不必要的工作。
也就是说，我们应该审视我们的流程并消除任何对客户没有价值的东西。 - 最好的构架、需求和设计出自于自组织的团队。 我们应该让最接近工作的人决定如何最好地完成它。
- 定期复盘：每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
四、常见误解解读
误解：敏捷就是快
如果你将“快”理解为用了敏捷以后，你的代码编写速度就立马加快了，那是非常不现实的。
虽然在敏捷中，我们也会用到一些方法来训练整个团队的代码编写能力，但这并不意味着，程序员敲代码的速度就得到了显著提升。况且，即使敲代码的速度加快了，项目整体上线的速度就也一定能加快吗？
那么敏捷在交付上会带来什么变化呢？你可以先看一下原则中的第1条和第3条，总体的意思是：敏捷希望能尽快把可用的软件持续性地交付给客户，交付的时间越短越好，而不是最后才一次性交给客户。
所以说，敏捷中的“快”其实指的是反馈更快，反馈更及时。
这样，我们就能更快、更准地得到客户的真实反馈，也能尽早修正。在这个过程中，客户也可能会更早一点想清楚自己要什么样的产品，你也可能更早达成客户的目标（这里你也要注意，是有“可能”，而不是“一定”）。甚至，由于客户比预计的时间早些看到了产品，他觉得很满意，结果可能比大家预想的上线时间都要早。
但这绝不是通过快速写代码来完成的，而是通过不断检视客户的需求，总是优先做最有价值的事和减少浪费来完成的。
敏捷是以业务价值和业务目标为导向的，在这个导向下，短迭代使客户更清楚自己的需求了，不必要做的事情减少了，所以时间才减少了，交付也就更快了。
误解：敏捷就是加班
第8条原则，你可以清晰地看到，敏捷强调“可持续的开发速度”。
这指的是团队要能一直以稳定的开发速度持续下去，而不是为了加速开发，本次或几次迭代一直加班，透支团队成员的健康，这么做反而会因为员工身体不支，导致接下来的迭代开发产能下降。
那怎么才能保持“可持续的开发速度”呢？能做到这一点的开发团队，通常都是这样做的：
- 他们在迭代开始的时候，不会过度承诺，也就是能完成多少工作，就承诺多少工作。
- 严格遵守纪律。他们在迭代开始以后，原则上不会再增加需求，如果一定要往他们的迭代待办事项列表里增加其它需求，就要同时从中拿走等量的需求。
这么做有什么好处呢？我认为这可以使开发团队聚焦在自己的事情上，不受干扰，效率更高，这样就能形成稳定的开发节奏；而稳定的开发节奏可以让客户更习惯于定期反馈，真正做到客户价值最大化。
误解：Scrum就是敏捷，敏捷就是Scrum
敏捷是理念，有很多具体方法，比如：极限编程（XP）、精益开发(LSD)、看板（Kanban）、Scrum、特性驱动开发（FDD）、结对编程、测试驱动开发等。
Scrum 只是大家用的比较多的一种方法。
敏捷一定要全盘照搬么？
不需要，还是看定义，敏捷是理念，你可以用其中的部分或全部方法。
敏捷核心是持续改进，如果敏捷只引入一个的，就是每轮迭代的回顾会，通过复盘来决定下个周期改进或引入哪些？其它可以在不断迭代中因为痛点而引入。
排好迭代的产品功能后，紧急上线来了打断如何办？
紧急上线不遵循每周两次的上线周期，如果对迭代周期计划有影响，可以随时调整。敏捷是拥抱变化的，迭代周期内仍然可以调整工作。
敏捷的目标是业务价值最大化，只要服务这个目标的，都是可以调整的。
不过在该轮迭代结束的复盘会上，需要讨论为啥会出现这个计划之外的事情，是哪些没做好？有啥改进的方法和策略。
敏捷不适用，或者效果差的场景。
敏捷需要满足一些条件才容易能用好，例如：
- 团队要小，人数超过一定规模就要分拆；人员多了，沟通成本会增大，效率变差。
- 团队成员之间要紧密协作，客户也要自始至终深度配合；
- 领导们的支持。敏捷需要扁平化的组织结构，更少的控制，更多的发挥项目组成员的主动性；
- 写代码时要有一定比例的自动化测试代码，要花时间搭建好源码管理和持续集成环境。这些是频繁交付的基础。
敏捷变成了“小瀑布”
在客户或产品参与度不足或理解敏捷不够时，进入迭代的工作未必是客户最在意的，敏捷会变成“小瀑布”。
假如我们需要3个月完成项目，我们的目标不应该是“3个月完成项目”，而应该是“3个月做一个让客户满意的产品”。这就需要我们：
- 先把客户的需求拿来看一下，挑选好需求，并先从有价值的、优先级最高的开始做。
- 客户其实也不清楚哪些是自己最需要的，这就需要尽早的、持续的交付，让客户使用反馈。
要能更早，更频繁的让客户反馈，这时候我们就面临拆分需求的挑战，拆分的原则：
- 把大需求拆成一个个能够独立开发测试的小需求；
如果需求涉及到很多微服务一起改造，这就得反思架构是否过于笨重了。
大团队如何做敏捷？
大型团队敏捷的导入和推广，首先要打造端到端的、从需求到开发到测试到运维到运营的敏捷全生命周期，向业务敏捷靠拢。
业务敏捷分下面五个层次：
- 快速交付(软件和IT团队在保质保量的前提下尽快完成交付)
- 全员敏捷发布（让运营、架构、安全性、合规性和分析团队成员都参与交付团队和全员敏捷发布计划中，敏捷规划、工作定序和DevOps。）
- 产品组合带来的敏捷性（为业务价值而优化，将策略与执行相连。）
- 全价值流敏捷性（以季度为单位，通过全员季度动员和发布计划以及战略部署流程，动态并有意变更或扩大您所投资的机会。）
- 业务敏捷性感知与响应 （抓住市场机遇：感知变化并快速而自信地作出响应，并将变化视为日常业务的一部分。）
从上面可以看出，敏捷的目标是团队的价值最大化输出。当团队负责某个业务时，就是业务敏捷；当团队负责某个中间件、某些服务时，也还是要做到这部分的价值最大化，这个价值最大化要跟整个企业的方向是一致的。
五、总结
敏捷推广过程中有各种误解，一般都是陷入到局部利益中了，这时候跳出来，从更大视野的业务价值角度看，就知道该如何做了。
