敏捷开发方法综述

Posted 2020-06-29 L养一只猫

       先来了解一下什么是敏捷软件开发，并且它到底是怎么来的。

       敏捷软件开发是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

       敏捷，顾名思义，就是轻巧、机敏、迅捷、灵活、活力、高效。。。。，敏捷过程很容易适应变化并迅速做出自我调整，在保证质量的前提下，做到文档、度量适度。敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。

       敏捷建模（Agile Modeling，AM）的价值观包括了XP（Extreme Programming：极限编程）的四个价值观：沟通、简单、反馈、勇气，此外，还扩展了第五个价值观：谦逊。

       Scrum和XP就是敏捷开发的具体方式。

       Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的。

       Scrum是指一种迭代式增量软件开发过程，通常用于敏捷软件开发。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法。Scrum之间的合作称为“Scrum of Scrums”。

       敏捷开发由几种轻量级的软件开发方法组成。他们包括：极限编程（XP）、Scrum、精益开发（Lean Development）、动态系统开发方法（DSDM）、特征驱动开发（Feature Driver Development）、水晶开发等等。

       敏捷开发的价值观是1.人与人的交互 优先于过程和工具2.可以工作的软件优于求全责备的文档3.客户协作优于合同谈判4.随时应对变化优于循规蹈矩。下面浅谈一下敏捷开发的方法： （1）极限编程xp

      Extreme Programming（极限编程，简称XP）是由KentBeck在1996年提出的。XP是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

      与传统的软件工程方法相比较，极限编程具有以下优点：（1）重视客户的参与；（2）重视团队合作和沟通；（3）制定计划前做出合理预测；（4）让编程人员参与软件功能的管理；（5）重视质量；（6）简单设计；（7）高频率的重新设计和重构；（8）高频率及全面的测试；（9）递增开发；（10）连续的过程评估；（11）对过去的工作持续不断的检查。但是也有它的缺点：（1）以代码为中心，忽略了设计；（2）缺乏设计文档，局限于小规模项目；（3）对已完成工作的检查步骤缺乏清晰的结构；（4）质量保证依赖于测试；（5）缺乏质量规划；（6）没有提供数据的收集和使用的指导；（7）开发过程不详细；（8）全新的管理手法带来的认同度问题；（9）缺乏过渡时的必要支持。

（2） Scrum

      Scrum是一种迭代式增量软件开发过程。Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。

     Scrum是一个包括了一系列实践和预定义角色的过程骨架。

     Scrum 框架      三个角色：产品负责人，Scrum Master，团队      四个仪式：Sprint 计划会议，每日站会，Sprint 评审会议，Sprint 回顾会议      三个物件：产品 Backlog，Sprint Backlog，燃尽图（在冲刺长度上显示每天进展的图。）

敏捷方法之极限编程(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, 自动测试， 结对编程，简单设计，重构等约束团队的行为。

角色：

      “猪"角色是全身投入项目和Scrum过程的人

　　产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。产品负责人编写用户故事，排出优先级，并放入产品订单。Scrum主管（或促进者）Scrum主管促进Scrum过程，他的主要工作是去除那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导（由于他们是自我组织的），而是负责屏蔽外界对开发团队的干扰。Scrum主管确保Scrum过程按照初衷使用。Scrum主管是规则的执行者。开发团队负责交付产品的团队。由5至9名具有跨职能技能的人（设计者，开发者等）组成的小团队完成实际的开发工作。

      ”鸡”角色并不是实际Scrum过程的一部分，但是必须考虑他们。敏捷方法的一个重要方面是使得用户和利益相关者参与到过程中的时间。参与每一个冲刺的评审和计划，并提供反馈对于这些人来说是非常重要的。

　　用户软件是为了某些人而创建！就像“假如森林里有一棵树倒下了，但没有人听到，那么它算发出了声音吗”，“假如软件没有被使用，那么它算是被开发出来了么？”利益所有者（客户，提供商）影响项目成功的人，但只直接参与冲刺评审过程。经理为产品开发团体架起环境的那个人。

（3）精益软件开发

     精益思想：

     1.尊重一线人员（工作在一线的人最了解实际情况，他们知道现在发生了什么，知道当前情况下的最佳应对方法）

     2.消除浪费（要求团队识别出软件开发过程中的“浪费”，采取改进措施消除产生这些浪费的行为和流程。）

     3.增强学习（在代码完成后马上进行测试可以避免缺陷的累积。不是去做成更多的文档或详细设计，而是对各种各样的想法进行实际的编码尝试）

     4.尽量延迟决定（尽可能的延迟决定，直到能够基于事实而不是不确定的假定和预测来做出决定。）    

     5.嵌入质量（质量是在过程中产生的；如果在开发流程的每一个阶段，都能保证产出物的质量，最终产品的质量就能以最低的代价实现；过程中保证质量能大量减少浪费，质量是过程的一部分；）

     6.快速交付 （快速交付的好处数不胜数，譬如能够使客户更早地得到产品价值，能使产品更快地投入市场）   

     7.整体优化（局部的优化，若不能带来整体的改善，将是没有价值的；构造一个完整的产品）

      在人的方面，精益思想强调如何将每个员工的能力发挥到极限，认为不应该只是简单的管理人，而应该去培训人。如果不能将管理的重点放在员工的培养上，就不能理解精益生产的真理。同时，精益生产的另一个精髓是管理过程，精益思想不是着眼于结果，而是强调过程。“只对结果管理”的管理思路的结果是员工对找借口、为结果辩护很在行，对数据、报告很在行，但软件项目成果的质量只有在全过程都有效控制下才能得到根本的保证。

（4）动态系统开发

      动态系统开发方法（Dynamic System Development Method，DSDM）是一种敏捷软件开发方法，该方法提供一种框架，使其“通过在可控项目环境中使用增量原型开发模式完全满足对时间有约束的系统的构建和维护”。

     DSDM使用迭代软件过程，每一个迭代都遵循80%原则，即每个增量只完成能够保证顺利进入下一增量的工作，剩余的细节则可以在知道更多业务需求或者提出并同意变更之后完成。

      DSDM的基本原则 DSDM方法建立在9条原则之上，而且在实施过程中，这9条缺一不可。

　　原则1：用户必须持续参与 

　　原则2：必须授予DSDM团队制定决策的权利

　　原则3：注重产品的经常交付 

　　原则4：满足业务用户用途是接受交付品的主要依据 

　　开发人员不必沉溺于完美的解决方案之中，耽误项目时间。在受限的时间内，实现业务利益最大化的交付品才是最重要的。

　　原则5：迭代和增量式开发对得到正确的业务解决方案是必不可少的 

　　采用迭代开发的方法，能够使业务流程逐步进化，使系统不断朝着满足业务需求的方向前进。

　　原则6：开发过程的所有变化可逆 

　　采用迭代和增量式开发过程中，很可能会碰到走错的情况，此时需要回退到一个已知的可靠的点上。

　　原则7：在高层次上制定需求的基线

　　在业务研究中所得出的需求必须在高层次上达成一致。接下来在迭代过程中再得到详细的需求。

　　原则8：测试自始至终贯穿于开发周期之中 

　　开发人员完成一个模块的开发后，自己会进行单元测试。当模块集成到现有系统后，测试人员需要执行集成测试。另外，回归测试在DSDM中占有很重 要的地位。

　　原则9：所有项目涉众间的通力合作是不可获缺的 

（5） 特性驱动开发

      特征驱动开发（FDD-Feature Driven Development）方法是敏捷软件开发过程中的一种，它强调特性驱动，快速迭代，即能保证快速开发，又能保证适当文档和质量，非常适合中小型团队开发管理。它提出的每个功能开发时间不超过两周，为每个用例user case限定了粒度，具有良好可执行性，也可以对项目的开发进程进行精确及时地监控。它抓住了软件开发的核心问题领域，即正确和及时地构造软件。FDD还打破了传统的将领域和业务专家/分析师与设计者和实现者隔离开来的壁垒。分析师被从抽象的工作中解脱出来，直接参与到开发人员和用户所从事的系统构造工作中。

      FDD过程：   

      FDD是一个模型驱动( model-driven)、短期迭代(short-iteration)的过程。 注意，FDD是一个开发过程，过程总是有起点和终点，FDD的起点是起源于创建一个全局的模型轮廓（不要求很精确，大概模样就可以），然后是周期低于两周的一系列的"design by feature, build by feature"的迭代，逐渐丰富模型功能内容。一个FDD开发过程如附件1图所示。

其由5个活动组成：

1. 开发一个全局的模型 （Develop an Overall Model）

2. 建立特征列表

在此采用下述格式进行描述：

- 针对功能： <action>the<result><by | for | of | to>a(n)<object>

- 针对功能集：<action><-ing>a(n)<object>

- 针对主功能集：<object>management

3. 依据特征规划(Plan by Feature)    

4. 依据特征设计(Design By Feature)

5. 依据特征构建(Build By Feature)

（6） 水晶开发

      Crystal Methods（水晶方法族）由Alistair Cockburn在20实际90年代末提出。之所以是个系列，是因为他相信不同类型的项目需要不同的方法。虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。其目的是发展一种提倡“机动性的”方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。

水晶项目开发核心特征: 　   --经常交付; 　　--项目主办者根据团队的工作进展获得重要反馈; 　　--用户有机会发现他们原来的需求是否是他们真正想要的, 有机会将观察结果反馈到开发当中 　　--团队得以调整开发和配置的过程, 并且可以鼓舞士气 　　--规定Timing Box确定最终的迭代交付时间点

        在我看来，这六种方法的共同点是：  迭代式开发 、增量交付、开发团队和用户反馈推广、产品开发 、持续集成 、开发团队自我管理。总之，这种软件开发能力是我们现在所缺少并且值得我们去学习的

内容纯属个人理解，仅供参考。