本文阐述敏捷开发的相关要点，做到理解切忌照搬硬套，特别是如果针对面试，对于场景类的描述，一定要变通！

敏捷开发的一些问题
说一下你对敏捷开发的理解，为什么要使用敏捷开发？
》瀑布模型的典型问题就是周期长，发布烦，变更难。
》敏捷开发就是快速迭代，持续集成，拥抱变化。
    所谓“敏捷”，顾名思义，可以通俗的理解为“短平快”，抽象点的可以说是“一种需求进化”。
采用快速迭代、循序渐进的方法进行软件开发，通过持续交付的方式不断的交付一个一个子系统，每个交付的子系统都经过测试，具备可集成可运行的特征（这也决定了大的项目在一开始就要被合理的规划和切分为多个子项目）。换个说法就是把一个大项目拆分为多个相互联系，但也可以独立运行的小项目，并分别完成。
    a) 因为敏捷开发的特征，将项目的大目标切分为N个小目标，使得每个目标都简单直观可达性更强。不管是客户、项目经理还是开发者本身，能快速的看到“成果”都是一种好事。化整为零的方式是一种更好的方式，就好像搭积木，将复杂事情简单化的，问题这个攻克，项目逐块交付。
    b) 对于客户而言，也有这样一个场景：我做过整体交付的项目，也带过持续交付的项目。同样跨度都是八九个月（你要能对应到你简历上的具体项目，别一问就穿了）。其中一个项目就是，我们分了4次迭代交付，前面几个月交付了一个版本。客户就推向市场下发给普通用户使用了，然后后面每隔一个月上了一块功能。这样对客户来说可以更快的抢占市场（我理解市场的时间价值成本是非常昂贵的）。不断的更新新的模块，从用户角度也能感知产品的升级带来的效果（这就是为什么我们有的APP产品要每隔1年左右做一个UI改版一样，明明业务没有什么改变，单也要换个皮，其目的就是为了用户，话说不在乎用户感受的项目经理和产品都是不合格）。
    c) 还有就是甲方一般都特别担心的质量问题：谁付钱谁忧虑这本就人之常情，敏捷开发逐步交付的成果“相对较小”，对于质量更容易量化，因为持续交付，问题可以提前发现提前解决。不合理的问题可以“提前转舵”，避免后续持续产生类似的问题。
    d) 因为敏捷开发的特性，使得团队互动性增强。因为互动性的增强，使得每个人都能相对收益。
    e) 劣势：上面说了敏捷注重人员的沟通，若项目人员流动大太，会给维护带来不少难度，特别项目存在新手比较多时，老员工比较累。需要项目中存在经验较强的人，要不在大项目中容易遇到瓶颈问题，对项目的把控者有更高的要求，或者在必要的时候公司有相对专业的人或团队给予指导和支持。
总结： 敏捷开发是是一个非常有价值的方式，特别适用于持续演进的项目（比如互联网产品或长期执行下去的项目）。对于短小交付就彻底结束的项目则不太适合。对产品对成本对成员有价值的东西，没有理由不用。
    严格来说敏捷开发由迭代+增量组成。持续交付的敏捷才是更有价值的，也就是上面说的不止迭代了，还可以不断的增量上新（用户可感知）。
由于敏捷开发可以不断试错，迎合市场的可以加强投入，反之可以淘汰。而不是等整个大而全的项目完整完成统一上线才发现就有些不合适了。

上面是叙述，下面的内容来自互联网，供参考（要理解记忆和挑几点说就行了）：

一、敏捷开发技术的几个特点和优势：
1．个体和交互胜过过程和工具
2．可以工作的软件胜过面面俱到的文档
3．客户合作胜过合同谈判
4．响应变化胜过遵循计划
二、敏捷开发技术的原则：
1．我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2．即使到了开发的后期，也欢迎改变需求。
3．经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
4．在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5．围绕被激励起来的个人来构建项目。
6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7．工作的软件是首要的进度度量标准。
8．敏捷过程提倡可持续的开发速度。
9．不断地关注优秀的技能和好的设计会增强敏捷能力。
10．简单使未完成的工作最大化。
11．最好的构架、需求和设计出自于自组织的团队。
12．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
三、敏捷开发技术的适用范围
1.项目团队的人数不能太多
2.项目经常发生变更
3.高风险的项目实施
4.开发人员可以参与决策
四、其他条件
1.团队要小，人数超过一定规模就要分拆
2.团队成员之间要紧密协作，客户也要自始至终深度配合
3.领导们得支持。敏捷需要扁平化的组织结构，更少的控制，更多的发挥项目组成员的主动性
4.写代码时要有一定比例的自动化测试代码，要花时间搭建好源码管理和持续集成环境。

你哪个项目中使用了敏捷开发？如何实施敏捷开发？产生了哪些实际效果？
    上面敏捷开发的理解和方式，其实对面试官考察表达能力和理解能力的。现在这个问题更重要的是“如何做的”，能真正知道怎么做的，才是相对靠谱的，因为执行力很重要。
    关于敏捷开发方面如何管理，如何计划，如何把控更偏重于管理，根据自己经验，使用“举例场景”的方式叙述，下面说一下微服务和持续集成的一些要点。
举例说明之前做的某项目或某项目和某项目是自己实践过的。
    当今主流方式微服务、CICD、容器化、自动化，你可以说你当时使用了微服务、CICD、容器（也不一定说全，你不是万能的，有的工作是有单独的团队做的，但是你要强调你在不同团队协作中的作用，这也是你胜任项目经理的职责）持续部署和自动化测试一般都有独立的运维和测试团队来完成，但是你作为项目经理，你也不能只会协调（开发、测试、运维三板斧的第一板斧是必须要擅长的）
    微服务按业务拆分，做到业务层面的高内聚低耦合。有利于扩展也是微服务的一大特性。作为项目经理，前期你抓设计，做好计划的基础性，自己主要负责或者带领核心开发人员构建良好的基础框架并编写封装公共代码（你要叙述你参与了重点技术工作）。持续交付和微服务开发，基础很重要，这是“速度”的基础（比如高铁的铁轨要求就很高）。必要基础平台和基础框架是堆积业务的根本（你可以说你最近几年做的项目和产品自己本身也积累了相关经验）。
    实施敏捷开发，前期要做好很好的设计功底，该拆的拆该细化的细化。你当时推动的时候，不能一蹴而就，要使用新的业务模块来演进（这也是引入任何新的东西的一种常用方式），也叫“试水”。将风险较低的业务走这种路线，打造一个完整的体系后，接下来就是其他业务逐步迁移的事了。如果老业务不需要迁移升级，未来的新需求按新的方式进行即可。
    实施过程中，需要公司领导和重要技术岗位成员的支持，比如你当时项目中因为推动的时候也有一些成员排斥、遇到了一些阻力（革命哪有不流血的，适应了就好）。跟相关人说明这样做的原因，甚至可以说这是公司领导层对未来趋势的要求（有时候把领导搬出来也是做事的一种方法，可以适当的采用，做人做事要灵活嘛）。然后从自己负责的范围内（毕竟自己对自己这块还是有话语权的）推进和落实，再横向推动到其他团队甚至整个公司（整个过程是需要很长时间的，不要张口就说你一个月就推完了（如果你直接上到一个没有包袱的新项目中那可能很快），正常来说整个公司都演进下来步入整个轨道，至少半年以上，1年左右很正常，因为公司本身业务是要持续前进的，不是停下业务的脚步只干技改）。
    产生的效果：很明显，老板经常能看到产品在变动，不断有功能上线也获得了用户的反馈（当时有的用户甚至说：呀，最近XXX客户端的程序猿是不是开启机器人模式了，老发版发功能，面试是一个综合的过程，不只是死气沉沉的回答问题，你既然是项目经理活跃气氛也是这个岗位的职责）。还有就是我们为快速迭代拆了微服务，当时就有某个模块因为开发代码写的不够好性能压力上来了，我们单独给这个服务加了个节点部署，开发都没参与，运维搞一下扩展个节点即可（然后开发这边优化处理后又升级的）。如果是中心化系统，要整个系统部署一套，影响面就不好说了。
    刚刚也提到了CICD，你当时进公司的时候公司是什么现状（比如大家都是手工做事，经常出一些小问题，回退版本什么的都麻烦，发布包管理不够好，经常扯皮等等）你的CI是基于Jenkins的（按你对行业的持续关注度一般来说Jenkins可以满足大部分公司使用，如果公司的基础平台和架构团队发展到一定程度，变会衍生开发自有平台）：你们当时基于git管理代码，因为git更适用于CI，分支和版本很强大。开发者提交代码后，Jenkins可以感知代码变动，会自动对代码进行编译，如果编译失败发送邮件通知开发者。同时会自动触发sonarqube进行代码扫描，开发者可以到sonar平台查看代码的质量问题，对存在的隐患bug或不规范写法进行纠正（你可以说很多时候机器比人靠谱所以代码扫描很有必要，重要的业务逻辑需要人工参与代码review）。你写了Jenkinsfile文件，使用pipeline脚本（你说到这块对方一般就知道你真实使用了）做了配置，针对develop、release、master（gitflow的分支模型你要了解一下，人家可能会问你分支模型）分支会自动将编译后的包打成docker镜像并自动发布到docker仓库。你要求重要的业务必须要写junit用例（可以说下因为写junit用例会增加开发量，所以你根据项目和公司的质量情况做的要求是针对核心和重要业务必须写没有强制全部写因为需要代价啊也就是要花钱啊，代价和成本是项目经理要考虑的职责），这是CI的过程。
    CD的过程，也是基于Jenkins触发服务器脚本来实现自动发布（服务器脚本前期采用docker-compose简单化编排），后期公司让运维慢慢引入了K8S（你如果熟你可以详细说，如果这块不熟悉，你就说这块交给了专业的运维，这块更重运维）。K8S给Jenkins提供一些脚本和接口，CD这块便OK了（在前期直接Jenkins操作服务器脚本完成自动部署）。

使用微服务进行敏捷开发要解决哪些问题？
    服务被颗粒化之后，就更适合容器化了，现在docker+springboot微服务组合比较常见。
服务多了，就要管理，管理代价就会提示，加上容器化之后容器可能随时升级被整体删除替代。加上springboot的打包方式（jar）和docker镜像的方式，使得配置可变性变的困难，文件存储、日志、配置、调度，这些都要提取进行统一管理，服务的注册发现可以使用Spring的Eureka，服务调用使用Feign，你熟悉dubbo的话也可以说。如果使用容器，有专业的运维可以上K8S一套进行容器编排更好。
    比如日志使用ELK，可以在docker内启动filebeat被动收集日志，也可以在项目中直接将日志写入Logstash、kafka、ElasticSeach都有方案（高可用的架构会带来复杂度，所以要根据项目实际业务情况选型决定，任何脱离业务的技术架构都是耍流氓）。
配置中心你使用过Spring Cloud Config 、Nacos、Disconf，现在使用Apollo（或其他，你熟悉哪个就说哪个，不过Apollo现在挺主流的），这2个东西你要简单了解下，更多的你要告诉对方你为什么用这个。或者为什么从A换成了B。
    调度中心，用xxljob就够用（如果你自研过也可以讲讲，根据自身情况介绍），也OK。
    公司有独立的文件系统，你知道的提一下就行，你也可以说你直接用的阿里云OSS（或其他你熟悉的NAS、fastdfs、ceph等等）。
    服务化之后，服务变多了。全链路跟踪也变的更为必要，这个你之前的方案是SpringCloudSleuth+Zipkin，你如果熟悉Jaeger也可以说。
    监控方面，SpringCloud的Hystrix Dashboard+ Turbine。
其他方面的，根据自己情况发挥，这些应该说了不少了。只要你理解了并描述清楚，基本也差不多了。
    不是每个人都可以全盘非常熟悉所有，对于会用和没有深入研究的。你可以根据自己的岗位来折中的回复对方。比如你是项目经理，你重点在项目成员、进度和质量把控，但是你持续关注技术，也会参与重点开发，平时重点解决团队内大家都不熟悉的技术（让开发人员更专注业务开发）。如果某块有很熟悉的团队成员，可以更好的利用团队成员的能力，把人用好对项目经理来说也很重要。
相关的问题可能性太多了，平时还是要多看资料，灵活的协调人和回答问题本身也是一种能力，所以面试上不仅仅只考验纯技术，其实是对一个人的综合判断。

有一句话是这么说的：敏捷是瓷器活，你得有金刚钻。字里行间都表达了对人的能力的要求。