敏捷开发模式

        我对敏捷开发的理解就是快速影响客户的真正需求。
        以前的开发是重文档的，先做需求调研，整出个需求文档出来，然后根据文档开发。我见过最厉害的需求文档连每个界面包括上面的控件大小、颜色什么的都画出来了。我们多数人并不能很好的把业务流程抽象成合适的需求文档，由于能力和沟通上的问题，经常会发生我们做出来的东西和客户真正想要的东西差异很大。

        所以敏捷的思路就是减少使用需求文档，改用可以使用的程序原型让客户体验，使用较小的更新让客户可以更多的反馈意见，根据客户的意见进行灵活的调整。

敏捷开发总的流程如下：

1.需求规划和分期

2. 需求评审

3. 需求讲解

4. 方案评审

5. 每日晨会

6. 性能测试

7.  CodeReview

8.  Demo

9. 测试阶段

10.线上Bug修改流程

Scrum概览

     Scrum是一种兼顾计划性与灵活性的敏捷开发过程，原词来自于橄榄球中的“带球过人”。在橄榄球比赛的每次冲刺前，都将有一个计划安排的过程，但冲刺开始后则由队员在原计划的基础上随机应变。
    在日常工作时，产品负责人会维护一个按优先级排序的“产品待开发项”（Product Backlog），即从客户价值理解和描述的产品功能条目。
    在每次迭代的第一天，召开迭代计划会(Sprint Planning Meeting)。产品负责人会逐一挑选最高优先级的部分进行讲解。团队可就需求细节、完成标准等进行询问，并逐条估算，放入本次迭代的开发任务中，直至任务量饱和。一旦迭代开始，这些任务将不会发生大的变化。
    在迭代期内，团队将决定任务分配、所需的技术等，逐一完成任务。每天团队会进行一个简短的站立会议即每日立会 Daily Stand-up Meeting，沟通当前进度、下一步任务和当前存在的问题，以借助团队的力量解决。团队还维护一张“燃烧图”（Burn Down Chart），即所有任务的累积剩余时间随开发进程与日递减的图形，以观察和预测所有任务是否会按期完成。
    在每个迭代的最后一天，团队会召集评审会(Review Meeting)，邀请产品负责人等参加，对已经完成的产品功能条目进行评审，后者做出判断并给出改进反馈。当天还会召开反思会(Retrospective Meeting)，对本次迭代中的成功与失败之处做出总结，并在以后迭代中进行改进。

XP概览

XP是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比，其最大的不同在于：

• 在更短的周期内，更早地提供具体、持续的反馈信息。
• 在迭代的进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断的发展它。
• 依赖于自动测试程序来监控开发进度，并及早地捕获缺陷。
• 依赖于口头交流、测试和源程序进行沟通。
• 倡导持续的演化式设计。
• 依赖于开发团队内部的紧密协作。
• 尽可能达到程序员短期利益和项目长期利益的平衡。

Kent Beck曾经说过“开车”就是一个XP的范例，即使看上去进行得很顺利，也不要把视线从公路上移开，因为路况的变化，将使得你必须随时做出一些这样那样的调整。而在软件项目中，客户就是司机，他们也没有办法确切地知道软件应该做什么，因此程序员就需要向客户提供方向盘，并且告知我们现在的位置。

XP方法论秉承的是“持续集成，小步快走”的哲学，也就是说每一次发布的版本应该尽可能的小，当然前提条件是每个版本有足够的商业价值，值得发布。

由于小型发布可以使得集成更频繁，客户获得的中间结果也越频繁，反馈也就越频繁，客户就能够实时地了解项目的进展情况，从而提出更多的意见，以便在下一次迭代中计划进去。以实现更高的客户满意度。

敏捷方法之极限编程(XP)和 Scrum区别

区别之一： 迭代长度的不同

XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周。

区别之二: 在迭代中, 是否允许修改需求

XP在一个迭代中，如果一个User Story(用户素材, 也就是一个需求)还没有实现， 则可以考虑用另外的需求将其替换， 替换的原则是需求实现的时间量是相等的。而Scrum是不允许这样做的，一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队受到干扰。

区别之三: 在迭代中，User Story是否严格按照优先级别来实现

XP是务必要遵守优先级别的。但Scrum在这点做得很灵活，可以不按照优先级别来做，Scrum这样处理的理由是：如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进度就耽误了。另外一个原因是，如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10。

区别之四:软件的实施过程中，是否采用严格的工程方法，保证进度或者质量

Scrum没有对软件的整个实施过程开出工程实践的处方，要求开发者自觉保证。但XP对整个流程方法定义非常严格，规定需要采用TDD、自动测试、结对编程、简单设计、重构等约束团队的行为。

Agile联盟提出了"四个价值"、"十二个指导原则"。

Agile方法的四个价值：

（1） 较之于过程和工具，更注重人及其相互作用的价值。

（2） 较之于无所不及的各类文档，更注重可运行的软件的价值。

（3） 较之于合同谈判，更注重与客户合作的价值。

（4） 较之于按计划行事，更注重响应需求变化的价值。

Agile方法的指导原则：

（1） 在快速不断地交付用户可运行软件的过程中，将使用户满意放在第一位。

（2） 以积极的态度对待需求的变化（不管该变化出现在开发早期还是后期）。Agile过程紧密围绕变化展开并利用变化来实现客户的竞争优势。

（3） 以几周到几个月为周期，尽快、不断地交付可运行的软件供用户使用。

（4） 在项目过程中，业务人员和开发人员最好能一起工作。

（5） 以积极向上的员工为中心建立项目组，给予他们所需的环境和支持，对他们的工作予以充分的信任。

（6） 在项目组中，最有用、最有效的信息沟通手段是面对面的交谈。

（7） 项目进度度量的首要依据是可运行的软件。

（8） Agile过程高度重视可持续开发。项目发起者、开发者和用户应能始终保持步调一致。

（9） 应时刻关注技术上的精益求精和设计的合理，这样能提高软件的快速应变力。

（10） 简单化（尽可能减少不必要工作的艺术）是基本原则。

（11） 最好的框架结构、需求和设计产生于自组织的项目组。

（12） 项目组要定期对其运作方面进行反思，提出改进意见，并相应进行细调。

此外，Agile方法实施中一般采用面向对象技术（接口定义良好的其它开发技术也可），另外还强调在开发中要有足够的工具（如配置管理工具、建模工具等）支持。

TDD：Test-Driven Development(TDD)即测试驱动开发，它是一种测试先于编写代码的思想用于指导软件开发。测试驱动开发是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。

BDD：Behavior Driven Development，行为驱动开发是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作

二、TDD和BDD联系与区别

总而言之，TDD和BDD解决的是不同层级的问题，BDD更多的是对TDD的补充，而不是像有些说法BDD是对TDD很好的回应。同时相较于现在比较完善的项目这两者都集合在开发过程中使用；可能一些小型的公司or项目，相对于没有更多的关注TDD层面，甚至可以说并未涉及到敏捷开发层面。

CI：持续集成（CONTINUOUS INTEGRATION）
基本概念

CI的全称是Continuous Integration，表示持续集成。

在CI环境中，开发人员将会频繁地向主干提交代码。这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试流进行验证。

    持续集成过程中很重视自动化测试验证结果，以保障所有的提交在合并主线之后的质量问题，对可能出现的一些问题进行预警。

需要具备的条件

    团队需要为每个新功能、代码改进、或者问题修复创建自动化测试用例。
    你需要一个持续集成服务器，它可以监控代码提交情况，对每个新的提交进行自动化测试。
    研发团队需要尽可能快的提交代码，至少每天一次提交。

带来的效益

    通过自动化测试可以提早拿到回归测试的结果，避免将一些问题提交到交付生产中。
    发布编译将会更加容易，因为合并之初已经将所有问题都规避了。
    减少工作问题切换，研发可以很快获得构建失败的消息，在开始下一个任务之前就可以很快解决。
    测试成本大幅降低，你的CI服务器可以在几秒钟之内运行上百条测试。
    你的QA团队花费在测试上面的时间会大幅缩短，将会更加侧重于质量文化的提升上面。

CD：持续部署（CONTINUOUS DEPLOYMENT）
基本概念

CD的全称是Continuous Deployment，表示持续部署。

在CD环境中，通过自动化的构建、测试和部署循环来快速交付高质量的产品。某种程度上代表了一个开发团队工程化的程度，任何修改通过了所有已有的工作流就会直接和客户见面，只有当一个修改在工作流中构建失败才能阻止它部署到产品线。

持续部署是一个很优秀的方式，可以加速与客户的反馈循环，但是会给团队带来压力，因为不再有“发布日”了。开发人员可以专注于构建软件，他们看到他们的修改在他们完成工作后几分钟就上线了。

    基本上，当开发人员在主分支中合并一个提交时，这个分支将被构建、测试，如果一切顺利，则部署到生产环境中。

需要具备的条件

    研发团队测试理念比较完善。测试单元的健壮性直接决定你的交付质量。
    你的文档和部署频率要保持一致。
    特征标志成为发布重大变化过程的固有部分，以确保您可以与其他部门（支持，市场营销，公关…）协调。

带来的效益

    发布频率更快，因为你不需要停下来等待发布。每一处提交都会自动触发发布流。
    在小批量发布的时候，风险降低了，发现问题也可以很轻松的修复。
    客户每天都可以看到我们的持续改进和提升，而不是每个月或者每季度，或者每年。

CD：持续交付（CONTINUOUS DELIVERY）
基本概念

持续交付的英文全称是：Continuous delivery，缩写也是CD，它是一种软件工程手法。

它可以让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。

    有时候，持续交付也与持续部署混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付。

需要具备的条件

    你需要有强大的持续集成组件和足够多的测试项可以满足你代码的需求。
    部署需要自动化。触发是手动的，但是部署一旦开始，就不能人为干预。
    你的团队可能需要接受特性开关，没有完成的功能模块不会影响到线上产品。

带来的效益

    繁琐的部署工作没有了。你的团队不在需要花费几天的时间去准备一个发布。
    你可以更快的进行交付，这样就加快了与客户之间的反馈环。
    轻松应对小变更，加速迭代。