文章目录
思维导图：
1. 敏捷开发模型发展历程
在软件开发的早期阶段，人们开发软件是没有模型、方法、流程的，这样会导致产出的软件产品质量很难控制，人们为了解决这些问题，发展出了软件工程、开发方法、开发模型。随着开发方法的不断升级，规范程度不断提高的时候，人们发现，在开发软件的过程中按照某些重量级的开发模型去开发，往往是得不到很好的效果的，因为重量级的开发模型往往更加关注于文档、流程，通过这些方式来规范你的开发，这样一来我们会发现开发人员的负担会越来越重，而产生的大量的文档、流程并不一定能够真正的用的上，所以花了很多时间，但是最终做出来的东西却并一定好。
所以有人就提出来，要给开发人员减负，那么怎么减负呢？就是把一些没有必要的流程砍掉，把没有用的文档减去。这样就形成了敏捷开发的基本思想。
值得注意的是敏捷开发模型并不是一个模型，而是一组模型，它包含有：
- 自适应开发
- 水晶方法
- 特征驱动开发
- SCRUM
- 极限编程(XP)
- FDD（特性驱动开发）
这些模型有着共同的价值观、原则、思想和理念，甚至很多最佳实践也是保持一致的
我们应该重点学习敏捷开发模型的一些基本原则和价值观
2. 敏捷开发模型相关术语
2.1 什么是敏捷开发？
敏捷开发(Agile Development)是一种
以人为核心、迭代、循序渐进的开发方法。怎么理解呢？首先，我们要理解它不是一门
技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；
2.2 为什么说是以人为核心？
我们大部分人都学过瀑布开发模型，它是以
文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。
2.3 什么是迭代？
迭代是指把一个复
复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品
2.4 什么是Scrum？
Scrum的英文意思是橄榄球运动的一个专业术语，表示
争球的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作
2.5 Scrum开发流程中的三大角色
- 产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果
- 流程管理员（Scrum Master）
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发
- 开发团队（Scrum Team）
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标
2.6 如何进行Scrum开发？
1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；
2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；
3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；
4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；
6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；
7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
3. 敏捷开发模型基本原理
3.1 短平快的会议
对于一些大型的机构，开展项目的会议会比较多，而会议又比较耗时，这样往往会消耗软件开发人员的大量时间，对于软件开发项目而言，最重要的资源就是人力资源，如果把人力资源用来开过多的会议，往往会降低效率。短平快的会议的核心思想就是，将过多的没有必要的会议砍掉，将仅用来传达指令的会议用其他形式代替，将现有的会议缩短，甚至是站立式的会议，以达到控制时长的目的，从而让会议更加的高效、快速
3.2 小型版本发布
敏捷开发模型强调，做再多的文档，最终给用户呈现的是软件产品，得到用户认可的也是软件产品，所以应该做一些小型的版本，让用户或客户整个开发流程中能够用到一些开发过程中的版本，并发现一些问题，提出一些建议。这一点跟原型开发模式是相近的
3.3-12…
TODO
小结
这些规则都是为了化繁为简，简化开发的流程。但是这种状态和一开始就简单化的模式是有区别的，正因为简化了开发了流程（例如砍掉了一些文档），导致敏捷开发模型也有一系列的弊端，例如敏捷开发模型只能开发一些小型的项目，对于大型的项目就显得力不从心了，
IBM曾经用XP极限编程开发一个大型的软件项目，并将其作为极限编程的样板工程，但是最终失败，原因就是敏捷开发模型不适合开发大型项目，它适合的是小步快跑的开发项目
4. 四大价值观
敏捷开发模型的四大价值观是：沟通、简单、反馈、勇气
- 沟通就是在项目开发的过程中应更加注重于
人与人之间的沟通，而不是人与文档之间的沟通。 - 简单强调的是开发过程中不要产生过多冗余的部分，不要
过度设计，能够满足需求即可。例如留了很多接口，但是后续却不一定能够用的上 - 反馈就是要跟客户及时的沟通交流，对项目能够及时的进行更改
- 勇气指的是在需求变更的情况下，开发人员应该要有勇气去面对变更。很多人面对需求变更是非常头疼的，对于开发人员（比如我），总是会觉得需求变更不是什么好事（确实也不是什么好事）。
需求变更是无法避免的，既然如此我们应该有勇气去面对💪
5. 十二个最佳实践
5.1 计划游戏
计划游戏指的是在开发的过程中就好像是在设计一个游戏，能够让用户直接参与进来，而不是像一些墨守成规的项目一样，有大量的文档化的东西，让用户或客户无法参与开发的过程，无法交流自己的想法
5.2 隐喻
隐喻是指要善于用一些浅显易懂的隐喻跟客户进行沟通，让客户能够更加了解软件开发的过程和项目的进展
5.3 测试先行
测试先行强调的是在软甲开发的过程中就要把测试引入进来，而不是等到各个模块已经耦合在一起了再进行测试
5.4 结对编程
结对编程指的是两人一组，一个人负责编码，另一个人负责检查编码，看上去是两个人在做一个的事情，效率降低了，但是事实上往往两个人开发出的产品质量更高、一次开发成功的概率也更高，因为两个的思考会更加的全面，我们知道编码其实并不耗时，耗费时间的是思考、设计和调试的过程，两个人开发能够大大减少调试的时间
6. 开发生产中敏捷模型开发思想的应用——DevOps
DevOps是 Development 和 Operations 的合成词，其目标是要加强开发人员、测试人员、运维人员之间的沟通协调。如何实现这一目标呢？需要我们的项目做到持续集成、持续交付、持续部署。
时下流行的DevOps工具有: Gradle、Git、Jenkins、Docker、Kubernetes、Ansible、Raygun等等
国内的互联网巨头们也纷纷布局，早早加入了
DevOps生态的布局中。其中以华为最具有代表性：那时候（2005年左右）的电信业，产品的稳定性和可靠性是压到一切的（其实现在也是）。所以，电信业的软件版本，更新速度非常慢。对朗讯、爱立信这样的传统巨头来说，通常大半年才出一个正式版本。这个版本经过重重把关、精雕细琢，所以非常稳定。
随着
3G的兴起，全球运营商开始对网络进行更新换代。华为和中兴开始趁机切入国际运营商市场，试图从国际巨头那边分一杯羹。除了价格之外，华为中兴最大的杀手锏是什么？就是响应速度。
那个时候，运营商客户对电信设备软硬件的需求非常多、非常频繁。像印度这样的地方，客户尤其难缠，每天都会提出新的需求。
当时几家海外设备商的响应速度是非常慢的，从不轻易同意接受需求。即使接受，也会答复半年甚至一年后实现。客户听了直接就崩溃了。
而华为和中兴则不同，两家公司的售前市场人员对于客户需求非常“大方”，基本上有求必应。（当时售后同事都会骂售前同事，可是仔细想来，不答应的话，根本没有进入市场的机会。）
当时华为和中兴的版本发布频率，快到什么程度呢？最快的时候，三天一个版本。甚至，长期都有大批研发人员驻扎在客户办公室，现场改版本，提交“热补丁”。
那时候是2006年，
DevOps这个概念的影子都还没有。研发那边，好像也就是刚刚提出敏捷开发。在没有理论框架和工具平台的支持下，纯靠人力，实现了版本的飞速迭代。当然，这其中的代价和风险也是很高的。不仅是开发人员很累很辛苦，项目里的工服（工程服务）工程师，也就是技术支持工程师，本文里面的运维工程师，更是苦不堪言。你想啊，以前几个月升一次级，现在几天就要升一次级，能不辛苦么？
但就是这样的辛苦付出，才硬生生从传统巨头嘴里抢下来市场份额，最终一步一步做大做强。
后来，才慢慢有了敏捷开发的概念，现在更是有了
DevOps，各种工具啊平台啊都有了，给版本快速迭代提供了很好的条件。|
