敏捷软件方法综述

一、敏捷方法的含义

敏捷:轻巧、机敏、迅捷、灵活、活力、高效……

 

敏捷开发是一种面临迅速变化的需求快速开发软件的能力

 

敏捷过程很容易适应变化并迅速做出自我调整,在保证质量的前提下,做到文档、度量适度

 

适用于各类软件企业

 

敏捷方法被称为轻量级方法(lightweight methodologies),这些新的方法尝试着在毫无过程和太多过程之间找到一个有效的平衡点,只提供必要的过程以得到一个合理的结果。

       表面上看,敏捷方法和重量级方法最大的不同是:不是以文档驱动,在很多方面,是以代码驱动的,最重要的文档是源代码。

 

Martin Fowler认为这不是敏捷方法的重点所在,较少的文档只是两种方法之间更深层次的不同点的一个症状。他认为敏捷方法的本质是:

 

1)敏捷方法强调适应,而非可预测。重量级方法花费大量的人力物力,试图制定一系列详细的庞大的计划来指导长期的工作,而一旦情况变化,计划就不再适应。因此本质上重量级方法是抵制变化的,而敏捷方法则强调适应变化。

         2)敏捷方法强调以人为中心而不是以过程为中心。在软件开发中,人的经验和创造力无法用制度和流程去控制。敏捷方法强调软件开发应顺乎人的本性(Work with people’s nature),软件开发应带来乐趣,激发人的积极性和创造力。

 

 

 

 

三、敏捷价值观

 

注重个人及互动胜于过程和工具

 

注重可用的软件胜于详尽的文档

 

注重客户协作胜于合同谈判

 

注重响应变化胜于恪守计划

四、敏捷开发的几种方法

1、极限编程(eXtreme  ProgrammingXP

            Kent Beck提出,是敏捷方法的中最富盛名的一个,是针对某种特定环境(需求不确定、变化快,小型项目、小型开发团队)的具体过程实施模型。现已成为小组开发方法的典型。

            该方法通过非常短的周期来对付需求的变化,首先开发软件最重要的特性,迅速向用户提供所需的功能,再通过重构来满足新的需求,从而降低风险。

XP方法的价值观(4个特性):

   • 改善沟通(communication)

              项目相关人员之间充分的多渠道的的沟通。

   • 寻求简单(simplicity

             选择最简单的设计和实现来处理客户的需要。

   • 获得反馈(feedback

             强调各种形式的反馈:小交付、短迭代、先考虑测试再编码。

   • 富有勇气(courage

              面对压力作正确的判断并敢于付诸行动,如尽早地和经常交付功能的承诺,敢于丢弃设计不良的代码等。

   

XP的有效实践:

    1)计划博弈 

            要求结合项目的进展来调整下一阶段的计划。计划不是一成不变的。

   2)小型发布

             短期内以增量式的方式发布可以工作的软件。

   3)系统隐喻

             通过一些可参照的模式来指导系统的开发,不需要事先进行详细的架构设计

   4)简单设计

              代码设计恰好满足当前功能的需要。

   5)测试驱动

             “先编写测试程序(测试的可执行组件,包括了测试用例),后编写源程序。以测试用例驱动设计与编码。   

    6)重构

            重构是以不改变软件外部行为而改进其内部结构的方式来修改软件系统的过程。为减少引入错误、减少冗余、提高性能等目的,随时调整、优化系统的结构。

    7)结队编程

            是一种加强开发人员沟通与评审的方式。两人共同负责解决同一问题的代码,一个人负责写编码,而另一个负责保证代码的质量,如编码标准、接口标准、代码的正确性与可读性等。

    8)代码全体拥有

            强调所有的人都对代码负责。如果一个开发人员的代码有错误,另外一个开发人员也可以进行BUG的修复。 
提高了代码的透明度,增进了团队的合作精神。一定要有严格的配置管理。

9)持续集成

            集成系统每日随时进行并不断的回归测试。要有良好的软件配置变更管理系统(如VSS)的有效支持。

 10)每周40小时工作制

             不过分加班,疲劳容易产生错误,要合理安排工作量和进度。

 11)现场客户

             提倡客户代表在开发现场,一起工作,随时和开发人员沟通信息。

 12)代码规范

             制定严格的编写代码的标准。

3、敏捷开发的其他方法

1SCRUM(并列争球法)

            该方法将工业控制中的概念应用到软件开发中来,认为软件开发过程更多的是经验性过程(empirical process),而不是确定性过程(defined process)。确定性过程是可明确描述的、可预测的过程,因而可重复执行并能产生预期的结果,并能通过科学理论对其最优化。经验性过程与之相反,把软件处理作为一个黑箱,对黑箱的输入输出进行度量,结合经验判断对黑箱进行调控,使其产生满意的输出。

            该方法将传统开发中的分析、设计、实施视为一个黑箱,认为应加强黑箱内部的混沌性,使项目组工作在混沌的边沿充分发挥人的创造力。如果将经验性过程按确定性过程(例如瀑布模型)来处理,必将使过程缺乏适应力。

         SCRUM的开发过程:

         • 计划与体系结构的设计(确定性过程)。

         • 若干个每30天一次的迭代(称为冲刺,sprint),即工作任务。(经验性过程)。

             每个sprint包含:开发、打包、评审、调整活动。

         • 交付与巩固(确定性过程)。

           该方法还包含了对开发过程的控制与管理技术。如在每个sprint其间的调控措施是:

          • 例会。每天在同一地点进行,15分钟,master对每个小组成员提问题:昨天的工作进展,今天的工作打算,困难和障碍。

         Sprint评审会议。根据每人的工作成绩进行激励。

            该方法特别强调开发队伍和管理层的交流协作。开发队伍每天都会向管理层汇报进度,如有问题,也会向管理层要求帮助解决。

 

2DSDM(动态系统开发方法)

             DSDM起源于1994年英国一个由17家公司发起的工业联盟。最初的目的是开发一种更好的面向领域的快速应用开发(RAD)方法。现会员已扩展到美国、印度等国,应用范围不再限于IT行业。

    基本思想:

            在时间进度和可用资源预先固定的情况下力求需求的最大化满足。具体做法是采用时间框(TimeBox)技术,每个时间框可被分解为2-6周的子时间框,并按用户需求的优先级原则(Must doshould doCould doWon’t do)进行开发。

            另外DSDM还通过工作间(Workshop )方法加强信息沟通,提高开发效率。

DSDM基本原则

  • 积极主动的用户参与。

  • 赋予项目组充分的决策权。

  • 强调经常性的产品提交。

  • 以是否适合商业目标作为工作确认的首要衡量标准。

  • 迭代和增量式的开发。

  • 开发中所有变化是可追溯的(reversible)。

  • 基于软件需求提出的开发计划作为宏观进度控制的基线。

  • 测试活动贯穿于软件开发周期的各个阶段。

  • 强调所有项目相关人员的合作。

    DSDM的开发过程

            一个周期2-6周,每个周期包括以下5个阶段。其中前两个阶段有顺序关系,是后续工作的基础和前提。后三个阶段可并行、交叉、重叠。

         • 可行性研究   

           项目实施的技术和管理条件是否满足。

         • 业务研究

             确定系统的范围,建立系统功能和信息的需求,根据需求设定开发进度基线,设计系统体系结构和可维护性目标。

         • 功能模型迭代

            开发一系列证明其功能的增量原型,通过使用原型获得反馈信息和额外需求。

         • 设计与构造迭代

           对原型进行增量开发,生成可用的系统。   

         • 实施

            移交到运行环境、评审、培训等。

             当增量没有全部完成或增量需要改变时,DSDM开发转向功能模型迭代继续进行。

             DSDM不但遵循了敏捷方法的原理,而且也适合那些对成熟的传统开发方法有坚实基础的软件组织。

 

3)自适应软件开发(Adaptive Software DevelopmentASD)

            基于复杂自适应系统理论,通常称为混沌理论(chaos theory)。通过提高组织的自适应力来应对当前极度变化、难以预测的快速软件开发要求。

            混沌理论提出的主要概念是在一定环境中的主体(agents)相互竞争和合作,导出系统产出的浮现(emergence)。ADS视开发组织为环境,组织中的成员为主体,产品为浮现。该方法提出了两个关键策略来建立自适应和协作的环境:

          • 管理人员要关注结果而非过程;

         • 管理人员要提供工具和技巧来培养自组织能力。

4)特征驱动开发(Feature Driven Development ,FDD

            是一个模型驱动、短迭代的开发方法。适用于变化周期短的应用开发。特征点(feature)意旨具有客户价值的功能项,在两周或更短的时间内被实施,产生可见的能运行的代码。

     FDD开发过程(5项任务)

          开发总体模型

            组建建模团队,领域分析,识别对象及其行为,生成非正式的特征点列表

        构造特征点列表

            将对象的行为转换成特征点,形成具体的、正式的、排序后的特征点列表,复杂的特征点分解成可在两周内实施的小块。

 

按特征点计划

           根据优先级制订各特征点和项目的完成日期,特征点集分配给主程序员,主程序员将类分配给类拥有者。

 • 按特征点设计

           本阶段开始了两周左右的迭代过程,将本次迭代需要完成的特征点进行分析、标识涉及到的类、建立行为模型、设计评审等。

 • 按特征点实施

           各类拥有者编码、单元测试,代码评审后提交配置管理,主程序员确认后,将类代码打包,形成可执行的产品。

           以上5项任务前3项在项目开始时完成,后2项在每次迭代周期中都要执行。

5)开放源码

              开放源码是一种完全基于Internet的开发方法,其典型的成功案例是Linux。大多数的敏捷方法都强调团队要本地合作,开放源码的开发过程允许一些地理位置相隔较远的团队来完成。

              开放源码项目一般设有一个或多个维护者,只有维护者才能将新的或修改过的源码段合并入源码库。其他人虽可以修改源码,但须将他们的修改提交给维护者,由维护者对这些改动进行审核并决定是否并入源码库。通常这些改动表现为补丁patch)文件的形式。维护者负责协调这些改动并保持设计的一致性。

             

         维护者的角色在不同的项目有不同的处理方式。有些项目只为整个项目指定一个维护者,有些则把项目分为多个模块并为每个模块指定一个维护者,有些是轮流做维护者,有些是同一个源码部分有多个维护者,有些则是这些方式的组合。

            开放源码的一个突出的特点是高度并行性的调试,因为很多人都能同时进行调试。如果他们发现了错误,就可将

 

 

 

 

原文地址:https://www.cnblogs.com/ls110220/p/3612284.html