敏捷开发方法的定义_敏捷开发定义 - CSDN
  • 定义:又称快速原型法,不属于敏捷开发。 根据需求用IDE实现基本功能,然后用户试用、补充和修改的重复过程,最后的版本再决定是demo还是正式版本。 分类 1. 抛弃型原型 - 此类原型在系统真正实现以后就抛弃不用了...

    原型法和敏捷开发


    [快速]原型法

    就是按照客户写的demo。


    分类
    1. 抛弃型原型 - demo的需求客户确认后就抛弃。

          a)探索性 - 为了确认需求;

          b)实验型 - 为了确认规格说明是否可靠。

    2. 进化型原型 - 先构造一个功能简单而且质量bugatti的模型作为核心,然后不断扩充修改,最后发展为最终系统。


    优点:

    1. 由于有用户的直接参与,系统更加贴近实际;

    2. 系统开发循序渐进,反复修改,确保较好的用户满意度;

    3. 开发周期短,费用相对少;


    缺点:

    1. 不适合大规模系统的开发;

    2. 开发过程管理要求高,整个开发过程要经过“修改—评价—再修改”的多次反复;

    3. 用户过早看到系统原型,误认为系统就是这个模样,易使用户失去信心;

    4. 开发人员易将原型取代系统分析;

    5. 缺乏规范化的文档资料


    适用范围:

    1. 用户需求不清,需求经常变化
    2. 规模小,不太复杂
    3. 用户界面

    、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

    敏捷开发的核心思想

    •以人为本
         敏捷方法认为,人是软件开发中最重要的因素。敏捷开发的理念是充分的信任开发团队能够很好的完成任务,这是管理的中心主题。

    •适应变化
         传统的软件开发强调的是,足够清晰的需求,制定详细的文档,按照预定的计划逐一进行开发、测试。这样的方式在制定好计划之后拒绝变化,无法应对客户对需求的实时更改,后续的维护必将会付出巨大的代价。
         而敏捷方法则是以最简的方式来迎接变化,客户在整个开发过程中都是参与者,开发团队能够在最短的时间内得到客户的反馈,不断适应需求的变更,从而使得最终的产品能够充分的符合客户的要求。

    、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

    敏捷开发 - XP极限编程

    极限编程(eXtreme Programming)。

    “Extreme”(极限)是指,对比传统的项目开发方式,XP强调把它列出的每个方法和思想做到极限、做到最好;其它XP所不提倡的,则一概忽略(如开发前期的整体设计等)。极限编程强调程序设计团队与业务专家之间的紧密协作、面对面的沟通(比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好的适应需求变化的代码编写和团队组织方法,更注重软件开发中人的作用。


    核心价值观
    •沟通(Communication)
         开发人员和设计人员、设计人员和客户的沟通。
    •简单(Simplicity)
         开发前期的整体设计、兼容等直接忽略,专注于最小化解决方案。
    •反馈(Feedback)
         尽快获得用户的反馈。
    •勇气(Courage)
         拥抱变化。


    12个实践原则
    规划策略
         以业务优先级和技术估计为基础,决定下一版本发布的范围。
    结对编程
         结对者是全职合作者,轮流执行键入和监视;这提供了持续的设计和代码评审。
    测试先行
         在编码开始之前,首先将测试写好,而后再进行编码,直至所有的测试都得以通过。
    重构
         改进软件的设计,重构帮助重新组织代码,重新清晰地体现结构和进一步改进设计。
    简单设计
         系统应设计得尽可能简单。
    代码集体所有权
         代码集体所有权强调的是整个团队,而非个人。
    持续集成
       持续集成的思想是任何时候只有一项任务完成,就集成新代码,构造系统并测试。
    现场客户
         客户是Team成员,在开发现场和开发人员一起工作。
    小型发布
         可以保证频繁地反馈和交流,保证客户有足够的依据调控开发过程,降低开发风险。 
    每周40小时工作制
        XP要求项目团队人员每周工作时间不能超过40小时,否则反而会影响生产率。
    编码规范
         编码规范代替不必要的文档。类型包括:格式、代码结构、命名约定、错误处理、注释。 
    系统隐喻
         系统隐喻是将整个系统联系起来的全局视图,每个迭代的隐喻都会演化扩展。


    适用范围
    XP适合规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题,以最大的灵活性和最小的 代价来满足用户未来的需求,XP在平衡短期和长期利益之间做了巧妙的选择。

    、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

    敏捷开发 - FDD特征驱动开发

    8个实践原则
    · 领域对象建模
    构造类图。系统设计提供了一种整体框架,把对象分解为类,使得系统可以按照特征迭代增量地进行开发。
    · 按照特征开发
    用户眼中最小的、有用的功能进行开发并跟踪过程。 
    · 类(代码)拥有权
    每一个类都有一个指定的人/角色负责类代码的一致性、性能和概念的完整性。
    · 特征小组
    特征分配给一个确定的开发者,一个特征的实现会涉及到多个类及其所有者,因此,特征的所有者(特征组长)需要协调多个开发人员的工作。特征小组与开发小组类似。但有一个重要的区别:特征小组的组长更像是教练而不是超级程序员。
    · 审查
    检查软件错误的复审方法,这是FDD确保软件设计和代码质量的一个关键技术。
    · 定期构建
    定期地取出已完成功能的代码,组成完整的可以运行的系统。可以使客户观察到系统开发的进度和实现的功能是否是需要的。
    · 配置管理
    最新版本的确认和历史追踪。
    · 可视性进度报告
    项目成员应该根据完成的工作向各级管理报告工作进度。

    XP极限模式和FDD驱动模式的区别

    · 隐寓和模型
    XP是隐喻,即每个人(设计人员,开发人员、客户)都能讲出系统如何工作的。
    FDD是模型,一个全面的领域对象模型,以便特征小组对每一组特征产生更好的设计。
    · 开发团队
    XP通常不超过10人;FDD的理想团队成员数在16~20人。
    · 代码拥有权
    XP任何人都拥有代码,任何人都可以在需要时添加或修改代码。
    FDD整个开发团队拥有代码,类所有者与特征小组修改。
    · 审查
    XP利用双人结对编程来不断地在设计和代码层执行走查和非形式化审查。
    FDD则提倡采用结构化的形式化审查技术。
    · 测试
    XP中的正确性是由运行单元和功能测试来定义的。
    FDD中单元测试是“按照功能构建”过程的一个部分,由主程序员决定做什么更适合。
    · 项目追踪
    XP让项目经理决定项目追踪方法,鼓励减少数据搜集的工作量,鼓励使用大型图表。
    FDD中的按特征追踪项目的方法,描述了工作量小、准确度量项目进度的手段,提供进度图表。

    、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

    敏捷开发 - Crystal水晶方法

    透明水晶方法,适合于一个小团队来进行敏捷开发,人数在6人以下为宜。


    七大体系特征
    · 经常交付
      项目主办者根据团队的工作进展获得重要反馈;用户有机会发现他们原来的需求是否是他们真正想要的,也有机会将观察结果反馈到开发当中。
    · 反思改进
      如果我们能够经常在迭代会中及时的反思和改进,技术难题应该是不会发生的,或者说发生了,也能够很快的找到解决方案去应对它。
    · 渗透式交流
      若其中一名成员提出问题,工作室内的其他成员可以选择关注或不关注的态度,可以加入到这个问题的讨论当中来,也可以继续忙自己的工作。
    · 个人安全
      个人安全指的是当您指出困扰您的问题时,您不用担心受到报复。个人安全非常重要,有了它,团队可以发现和改正自身的缺点。没有它,团队成员们知而不言,缺点则愈发严重以致于损害整个团队。个人安全是迈向信任的第一步。有了信任,团队协作才能真正的实施,开发效率也就会直线上升的。
    · 焦点
      所谓“焦点”,就是确定首先要做什么,然后安排时间,以平和的心态开展工作。
    · 与专家用户建立方便的联系
      与专家用户持续建立方便的联系能够给团队提供:对经常交付进行配置以及测试的地方,关于成品质量的快速反馈,关于设计理念的快速反馈,最新的(用户)需求。
    · 配有自动测试(auto-test)、配置管理(git)和经常集成功能的技术环境(git)
      自动测试:代码修改后自动测试,并反馈结果。提高效率。
      配置管理:提交的代码可选择某个节点发布和还原。
      经常集成:开发人员可以一天多次合入本地版本到服务器版本,加快发现错误。

    、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

    敏捷开发 - RUP统一软件开发过程

    RUP(Rational Unified Process),统一软件开发过程,统一软件过程)是一个面向对象且基于网络的程序开发方法论。根据Rational的说法,RUP就好像一个在线的指导者,他可以为所有方面和层次的程序开发提供指导方针、模板以及事例支持。


    六个特点
    · 迭代式开发
    迭代式开发允许在每次迭代过程中需求可能有变化,通过不断细化来加深对问题的理解。
    · 管理需求
    确定系统的需求是一个连续的过程,开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化,用例和脚本的使用以证明是捕获功能性需求的有效方法。
    · 基于组件的体系结构
    组件使重用性成为可能,系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性,提高重用率。RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。
    · 可视化建模
    RUP往往和UML联系在一起,对软件系统建立可视化模型,帮助人们提供管理软件复杂性的能力。RUP告诉我们如何可视化地对软件系统建模,获取有关体系结构和组件的结构和行为信息。
    · 验证软件质量
    在RUP中软件质量评估是内建于过程中的所有活动,这样可以及早发现软件中的缺陷。
    · 控制软件变更
    RUP通过软件开发过程中的制造出的产品,隔离来自其他工作空间的变更,以此为每个开发人员建立安全的工作空间。迭代式开发中如果没有严格的控制和协调,整个软件开发过程很快就陷入混乱之中,RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。


    、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

    敏捷开发 - SCRUM迭代式增量软件开发过程

    Scrum是一种灵活的软件管理过程,它可以帮助驾驭迭代、递增的软件开发过程,主要用于产品开发或工作管理。


    Sprint(迭代)
        Scrum的项目过程由一系列的Sprint组成
        Sprint的长度一般控制在2~4周
        通过固定的周期保持良好的节奏
        产品的设计、开发、测试都在Sprint期间完成
        Sprint结束时交付可以工作的软件
        在Sprint过程中不允许发生变更


    敏捷方法之极限编程(XP)和 Scrum区别
    区别之一: 迭代长度的不同
    XP的一个Sprint的迭代长度大致为1~2周;
    Scrum的迭代长度一般为 2~ 4周。
    区别之二: 在迭代中, 是否允许修改需求
    XP在一个迭代中,如果一个User Story(用户素材, 也就是一个需求)还没有实现, 则可以考虑用另外的需求将其替换, 替换的原则是需求实现的时间量是相等的。
    Scrum是不允许这样做的,一旦迭代开工会完毕, 任何需求都不允许添加进来,并有Scrum Master严格把关,不允许开发团队受到干扰。
    区别之三: 在迭代中,User Story是否严格按照优先级别来实现
    XP是务必要遵守优先级别的。
    但Scrum在这点做得很灵活,可以不按照优先级别来做。Scrum这样处理的理由是:(1)如果优先问题的解决者,由于其它事情耽搁,那么整个进度就耽误了。(2)如果按优先级排序的User Story #6和#10,虽然#6优先级高,但是如果#6的实现要依赖于#10,则不得不优先做#10。
    区别之四:软件的实施过程中,是否采用严格的工程方法,保证进度或者质量
    Scrum没有对软件的整个实施过程开出工程实践的处方,要求开发者自觉保证。
    XP对整个流程方法定义非常严格,规定需要采用TDD、自动测试、结对编程、简单设计、重构等约束团队的行为。


    参考链接:

    原型法

    敏捷开发



    展开全文
  • 本文将为你介绍敏捷开发方法框架的共同特征,理解与传统软件工程的联系和不同。短迭代的生命周期模型生命周期是事物发展的客观规律,软件同样存在生命周期。早期的软件生命周期往往是说“软件从计划、需求开始,经历...

    随着敏捷软件开发宣言的签署和发布,多个敏捷方法框架在全球得到传播和使用。因为各个敏捷方法框架由不同的专家组维护,所以各个方法有不同的表述方式,有不同的着眼点和侧重点。本文将为你介绍敏捷开发方法框架的共同特征,理解与传统软件工程的联系和不同。

    短迭代的生命周期模型

    生命周期是事物发展的客观规律,软件同样存在生命周期。早期的软件生命周期往往是说“软件从计划、需求开始,经历分析设计、实现、部署、维护,直到最后逐渐消亡的”。这是受到了第一个软件生命周期模型—瀑布型生命周期影响,上述语句实质上简要的描述了瀑布型生命周期。现在的软件生命周期不再只考虑瀑布型生命周期,另外常见的软件生命周期模型有原型模型、螺旋模型、迭代模型。所以现在的软件生命周期说明应当不再包括瀑布型生命周期中的典型阶段。本书对软件生命周期及软件生命周期模型采用如下定义:

    软件生命周期是指软件的产生直到报废的全部过程。

    软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。

    敏捷软件开发明确对生命周期模型提出了要求:短迭代开发。迭代模型的历史可以追溯到上世纪50年代,但以往的迭代模型并没有对迭代周期长度提出要求。而在敏捷软件开发中,迭代周期长度一般不超过2个月,而常见的迭代周期是2周到4周,因此可以称之为“短迭代”。

    有些敏捷软件开发在主开发过程前安排有预研或计划或架构或需求阶段等等,在主开发过程后安排有系统集成测试或验收测试或试运行等等,这样做并不违反敏捷开发原则,但其主开发过程应当采用短迭代开发,而且主开发过程的工期应当占有显著的比例,形成多个短迭代。

    敏捷开发讲究固定的节奏,建议按照固定的节奏开发,所以短迭代的周期长度在开始选定之后,一般不作改变。同样的原因,敏捷迭代与迭代之间一般不安排缓冲期,上个迭代未完成的内容放到下个迭代中进行处理。

    敏捷开发迭代与瀑布生命周期的阶段是不同的。瀑布型中需求分析阶段的产物一般是需求规格说明书,不同阶段的产物是不同的;而敏捷开发迭代的产物是软件本身,前期迭代的产物也许不完整,但各个敏捷开发迭代的产物是一致的、逐步改进完善的软件本身。

    开发中可运行的软件

    软件最终是需要运行的,而正在开发中的软件往往是难以运行的。在瀑布型生命周期和衍生于瀑布型的其他多个生命周期模型中,为了保证最终运行的软件满足用户的需要,安排了多个对于文档的里程碑评审。而敏捷软件开发则是尽快的把软件运行起来,主要根据可运行的软件来判断软件是否满足用户需要。显然的,通过软件本身来判断比起通过文档来判断,更加直接,更加准确。

    为了让开发中的软件可运行,敏捷软件开发在这方面的基本要求是敏捷开发迭代的产物可以运行,也即是每个迭代至少得到一次可运行的软件。

    而敏捷软件开发推荐更加快速更高频度的获得可运行的软件,这样带来更大的好处。极限的,每次代码修改都能得到可运行的软件,这样的做法叫做“持续集成”(下文将详细说明)。按照得到可运行软件频率从高到低,得到下列排序:

    1, 持续集成— 一天之内可能集成多次

    2, 每日集成

    3, 每周或每双周集成

    4, 每迭代集成

    为了判断可运行的软件满足用户需要并得到高质量产出,敏捷软件开发在得到可运行软件的同时还常常采用如下方法:

    1, 静态代码检查

    2, 自动化测试

    3, 产品展示

    4, 用户试用

    短线沟通和快速反馈

    现代管理学的研究表明管理者在沟通方面花费了大量的时间,参与方数量的线性增长将带来沟通工作量的指数增长。敏捷软件开发讲究短线沟通和快速反馈,在这方面的基本要求是安排用户检查每个迭代的可运行产物。推荐面对面的交流,为了密切交流,办公环境值得为此进行改变,让团队的沟通更加便捷,比如整个团队在相同的房间里,位置接近,大会议桌式分布。

    快速反馈的范围包括了客户、领导、同伴,希望客户能够快速的告诉团队“这个样子不是我想要的”,XP推荐现场客户,这样反馈更加及时。

    变化的需求和架构

    瀑布型生命周期假设在需求里程碑之后,需求可以冻结;而敏捷开发不做需求可以冻结的假设。瀑布型生命周期假设在设计里程碑之后,设计可以冻结,而敏捷开发也不做设计可以冻结的假设。

    相反的,敏捷开发认为需求变更和设计变化是正常的,为此利用短迭代的机会,不断的澄清需求,设计尽量不做超前设计,将设计浓缩到架构,而架构也不是不变的,架构在每个迭代中将会演进。

    展开全文
  • 7种敏捷开发方法

    2019-05-10 09:19:07
    XP极限编程 SCRUM迭代增量化过程 Cystal Methods水晶方法族 FDD特性驱动开发 ASD自适应软件开发 DSDM动态系统开发方法 轻量型RHRUP
    展开全文
  • 敏捷开发,瀑布式开发,XP,TDD,SCRUM,Lean,FDD,DSDM你了解多少?本篇文章是有关敏捷软件开发方法学及应用的基础知识。敏捷开发是有关团队怎么样合作去实现一个常规目标。敏捷开发并不仅仅适用于软件开发者,也...

    敏捷开发方法学及应用


    简介


    本篇文章是有关敏捷软件开发方法学及应用的基础知识。敏捷开发是有关团队怎么样合作去实现一个常规目标。敏捷开发并不仅仅适用于软件开发者,也适用于团队领导人,项目经理,产品经理,开发经理,测试人员,质量保证经理,质量保证工程师,技术作者,用户体验设计者,以及任何与制做发布软件相关的人员。本文着重于技术团队怎么很好的合作去计划,开发并发布软件。本文不着重于编码,技术细节或微软工具。希望本文能改善你的专业生活和团队效率。


    背景

    下图是Winston Royce的瀑布式开发模型:

    ( "Managing the Development of Large Software Systems",1970 IEE paper)


    无论项目有多大有多复杂,有两个关键的步骤常用于所有的计算机程序开发:1) 分析 2) 编码。

    接下来,Winston Royce介绍了最重要的五步:

    第一步:程序设计


    分配任务处理流程,功能,数据库处理,明确数据库流程,分配执行时间,明确操作系统间的接口与处理流程模块,描述输入与输出流程,并且明确初步的操作流程。撰写容易理解的,信息量大的,当前时新的概要文档。

    第二步:撰写设计文档


    管理软件开发的第一条规则就是无条件服从的执行文档需求。

    第三步:重复两次


    第二个非常重要的成功标准以产品是否完全原始为重中之重。如果把还有疑问的计算机程序开发为第一版,考虑到严格的设计/操作领域,那么给客户正式部署的版本实际上是第二版本。

    第四步:计划,控制,监控测试


    在成本和计划方面上,这是最有风险的一步。当备选方案几乎或一点不可用时,它会出现在日程安排的最近时间点上。

    第五步:让客户参与


    让客户参与到项目中是非常重要的,因为客户可能在最终发布之前较早的认可项目工作。



    仔细阅读Royce的文章后发现:
    1. 每一阶段都应该迭代式地传递到下一阶段。
    2. 软件发布前对软件整体流程实践两次。
    3. 简单单一的阶段传递会造成项目失败。

    不幸地是,上面列出的步骤当中,设计迭代从来没被限制成连续的步骤。



    下面这些东西都是什么?



    答案是:





    敏捷开发并不意味着只是一种方法。上面雨伞下的术语代表着不同的敏捷开发方法。

    敏捷软件开发宣言


    我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观:


    • 个人与交互 高于 流程和工具
    • 可用软件 高于 详尽的文档
    • 客户合作 高于 合同谈判
    • 响应变化 高于 遵循计划


    也就是说,上面右侧(蓝色字体)内容有其价值,但我们更重视左侧(红色字体)产生的价值。

    敏捷宣言的十二条原则


    我们遵循以下原则:

    1. 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
    2. 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
    3. 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
    4. 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
    5. 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
    6. 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
    7. 可工作的软件是进度的首要度量标准。
    8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
    9. 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
    10. 以简洁为本,它是极力减少不必要工作量的艺术。
    11. 最好的架构、需求和设计出自自组织团队。
    12. 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

    很多开发者都经过这样的噩梦:没有任何实践可以辅佐的项目。由于缺乏有效的实践,项目变得不可预测,重复出现错误,还有白白浪费的辛苦。计划延期,超出预算,质量低下使客户感到失望。开发者也由于更长时间的工作而换来更糟糕的软件而心灰意冷。

    DSDM


    DSDM(Dynamic Software Development Method),动态软件开发方法,通过提供一个负责整体开发周期的框架来弥补RAD(Rapid Application Development)快速程序开发的不足。下面是DSDM的主要功能:
    1. 用户参与
    2. 迭代和递增开发
    3. 提高了发布频率
    4. 集成测式于每一阶段
    5. 已发布产品的可接受程度直接取决于需求的实现

    FDD

    FDD(Feature Driven Development),功能驱动开发,是一种包装方法学。它允许你在非常高的级别上应用一个方法来管理项目,但它也允许你在较低的级别上应用其它方法学。FDD的着重点是能够把估算,日程计划,项目状态汇报作为一个整体或放到颗粒级别上,但是FDD不会规定一个非常细节化的方法让你应用去创建日程计划,相反FDD让你去觉决定该用什么方法。FDD的观点是你可以查看一下你的项目,陈术一下项目的确切状态,如项目进度是否及时,延时或过早等等。

    Lean


    Lean思想是一种进行系统优化的途径,它关注于减少浪费,提高整个系统总体流程。Lean在制造业上有着丰富的历史,近几年在在软件开发行业也越来越流行。Lean来源于制造业中的Lean(Lean Manufacturing: http://www.mindtools.com/pages/article/newSTR_44.htm),它是一组为满足质量,速度和客户需求而定制的原则。

    七大Lean软件开发原则:

    1. 估算浪费
    2. 构建质量
    3. 创建知识
    4. 延迟承诺
    5. 快速交付
    6. 尊重人
    7. 优化整体

    软件产品的交付工作应用这些原则并不是我们的最终目的。我们并不是说让我们用Lean吧,而是把Lean原则做为决策的向导或参考去选择可以改善整体系统的技术。比如,TDD测试驱动开发,通过在每一个功能点上创建功能自我测试从而构建软件的完整性和完善性。

    Plan(译外话:指瀑布式开发Waterfall Development)


    在计划驱动开发中,如果一个项目确切的按照计划执行,那么它就是成功的。因此,在软件开发中计划驱动开发依赖于需求的稳定性,明确性和固定性。你或许知道这些奢侈的性质是在大多数软件项目中不存在的。

    计划驱动方法学,在初期的设计阶段的需求变更中成本花费较低,但是一旦到了开发阶段需求变更将会花费昂贵的代价。所以,很多的工作被要求在初期计划设计阶段完成。然而,软件开发不同于普通的项目,我们不能保证将来的开发阶段会完全按照初期的设计进行,无论你的设计有多么出色。

    "Walking on water and developing software from a specification are easy if both are frozen."- Edward V. Berard
    在水上行走和开发软件都只有当它们被冻结时才会变得容易。

    敏捷开发打破了对需求稳定性的依赖,它有一个专门的流程用于负责需求变化,主要体现在它的自适应计划和进化式设计。

    自适应计划,意思是多次的仔细检查整体项目流程,经常会再次制定计划并再次适应。
    进化式设计,有一些实践对它很有帮助,如自我测试代码,持续集成,重构,简易设计等。

    敏捷开发是价值驱动,传统的瀑布式开发是计划驱动。这并不是说计划驱动就没有价值,在特定的实际情况下它们都有各自的有优缺点。关键是怎么平衡使用两种方法,在特定情况下采取它们的长处而回避它们的短处。

    Plan VS Agile

    计划驱动开发模式和敏捷驱动开发模式在基本原理差异上有两大不同。
    第一大不同:计划驱动模型中只能在项目完成时才能部署一个新模块,而且是较大的模块。敏捷驱动模型中可以频繁的部署新模块,甚至较小的模块。
    第二大不同:计划驱动是序列化的,敏捷驱动是并发的。在计划驱动模型中,一个流程的开始必须在前一个流程完全成功结束的前提下进行。在敏捷驱动模型中,任何时候都可能在做计划,流程是并发的或互相穿插的。


    “Plan your work, then work your Plan” by Martin Fowler and Neal Ford
    先计划你的工作,后工作你的计划。
         

          


    敏捷开发和计划驱动开发(瀑布式开发):
    • 都提供了操作流程,操作工具和操作技术。
    • 都需要严格的有条不紊的方法进行软件开发。
    • 都各自有优缺点。
    • 敏捷开发适合的情况,计划驱动模型不一定适应。
    • 敏捷开发强调流程上的不同。
    • 计划驱动模型强调正式的沟通与控制。
    • 敏捷开发强调连续的沟通和处理变化的能力
    • 计划驱动模型是关卡式控制质量,敏捷开发是高迭代式开发确保质量。
    • 计划驱动模型仅在产品最终完成后进检查,敏捷开发每完成一小块工作就进行检查。
    • 计划驱动模型以预估什么将被交付为起点,敏捷开发以完成一个需求为目标做为起点
    适应变化能力(Y轴)                            时间(X轴)



    可见性(Y轴)                               时间(X轴)








    在敏捷开发中:
    客户满意度是以迅速,持续的交付可用软件为导向。
    强调人和互动要高于强调流程和工具。
    客户,开发者,还有测试人员一直保持互动。
    可用软件频繁的被交付使用(按周交付高于按月交付)
    面对面交流是最好的沟通形式。
    业务人员和开发者保持近距离的,日常的协作。
    持续关注出色的技术和设计。
    适应易变情况。
    需求中较晚的改动也受欢迎。

    善于使用计划驱动模型的管理团队同样也能够善于使用敏捷开发方法。

    缺乏能力使用计划驱动模型的管理团队也没有能力使用敏捷开发方法。


    敏捷开发Agile


    敏捷软件开发的原理和价值用于帮助团队打破流程循环膨胀,着重于用简单的技术去实现目标。目标?什么是目标?

    每一个软件开发者,开发团队的主要目标是为老板和客户制造尽可能高的价值。

    敏捷开发的核心是把传统的软件开发方法(瀑布式开发)的五个步骤压缩成一个一周的开发周期。用敏捷开发方法去开发一个系统时,项目中会不断贯穿着重复的周期开发和较小模块的开发,并在开发过程中允许开发者测试和检查。高速度,低成本,灵活性是敏捷开发的主要优势。


    敏捷开发发展极为迅速,从2001年的只有1%的开发者使用敏捷开发到现在的60-80%的开发者在使用敏捷开发。更大的吸引力是因为敏捷开发提供:
    • 改善的质量
    • 在项目过程中有更多的机会做出修改更正
    • 提高客户或商业满意度
    • 使业务和IT更好的组合在一起
    • 更优化的面向市场的时间


    敏捷开发使用者从来不会害怕变化。他们把需求变化看作是好事,因为这些变化意味着团队又收获了更多关于怎样满足客户的经验。敏捷开发团队成员一起协作项目的方方面面。每一个成员都允许为项目整体提出意见或做贡献。没有一个团队成员是单一的负责架构或者需求或者测试。团队分享这些责任,同时每个成员都会对它们产生影响。

    我们有很多的敏捷开发流程:Scrum,crystal,BDD(Behavior-Driven Development行为驱动开发),TDD(Test-Driven Development测试驱动开发),FDD(Feature-Driven Development功能驱动开发),ADP(Adaptive Software Development自适应软件开发),XP(Extreme Programming极限编程),等等等等。然而,大量成功的敏捷开发团队从所有这些方法中吸取经验与知识,进而调整生成他们自己特有的敏捷开发方式。这些改编后的方法通常与SCRUM还有XP组合在一起,SCRUM实践用来管理使用极限编程XP的团队。


    极限编程XP


    As developers we need to remember that XP is not the only game in town.- Pete McBreen
    作为开发者,我们需要记住极限编程并不是城里唯一的游戏。

    极限编程强调团队合作(经理,客户,开发者)。它从五个关键点改善软件项目:沟通,简明,反馈,尊重,还有勇气


    维基百科对极限编程的定义:极限编程XP是一种软件开发方法,它的意图是提搞软件质量及对用户需求变化的响应能力。作为一种敏捷软件开发方法,它提倡在短开发周期中频繁地发布,从而提高软件生产力并提出新客户需求能够被采纳的检查点。


    极限编程是一系列嵌入到敏捷开发中的简易并坚实的实践。极限编程是一个非常好的通用软件开发方法。许多项目团队都采用它,同时更多的团队通过添加或修改实践来把它变得更适用。
    • 它是大多数敏捷开发方法的始祖
    • 在90年代末期和21世纪初期,Kent Beck提出了热门的话题
    • 协调流程与实践
     Kent Beck 的基本观念:
    • 采取已关注过的有效团队实践
    • 迫使它们走向极端

    “迫使它们走向极端”是什么意思呢?是不是如下图一样?

    或者下图


    不,这不是极限编程。让我们看看它的真正意思:


    出色的实践       迫使它走向极端
    代码复查 结对编程
    测试 TDD测试驱动开发和常数回归
    软件设计 不停地重构
    简单 最简单的事会有意想不到的效果
    集成测试 不断的集成/整合
    短迭代 把制定计划当作游戏

    极限编程是一系列遵循敏捷开发原则和价值的实践。极限编程是离散的方法,而敏捷开发是一类方法。有很多的敏捷开发方法,极限编程只是其中一种。
    极限编程在敏捷开发方法中是范围宽阔,出类拔萃的。Scrum有些类似极限编程,拥有极限编程的大多数特征。但是在细节是它们有很多的不同,公平的说Scrum是是极限编程的子集。甚至,许多Scrum团队争论着要把极限编程实践加入Scrum流程中,如满意度测试,结对编程,持续集成,以及测试驱动开发。
     

    在所有敏捷开发方法当中,极限编程是唯一的一种方法为开发者的日常工作提供深度的,意义深远的开发准则。在这些准则中,测试驱动开发是最革命性的。下图中都是一些出色的极限编程实践。


    Scrum


    Scrum是和种迭代式及递增式的敏捷软件开发框架,它用于管理软件项目,产品,或程序的开发。它的着重点是一个灵活的,全面的产品开发策略,它把一个开发团队通常作为一个单位进而实现一个常规目的。相反,它不着重于传递的序列化式的方法。Scrum会问传统瀑布式开发“为什么我们要花费这么长时间,这么多努力去做一件事?为什么我们不能衡量出做一件事所需时间和人力?” Scrum拥抱变化和创造力,因为这是人们的工作方式。Scrum有一个流程学习结构,能够让团队评估他们做了什么以及他们怎样做的。
    • 1986年,Scrum第一次被定义成一个灵活的全面的产品开发策略。--Hirotaka Takeuchi,Ikujiro Nonaka
    • 1995年,Sutherland和Schwaber共同地发表了一篇关于Scrum方法学的论文。



    Scrum角色


    三个核心角色:
    1. 产品持有人 Product Owner
    2. 开发团队 Development Team
    3. Scrum领导人 ScrumMaster

    产品持有人 Product Owner


    • 产品持有人代表着公司或股东的权益并传递客户的声音。
    • 专门负责确保商业价值
    • 制定以客户为中心的一些工作条目,排序后放到产品待处理列表(Product backlog)中。
    • Scrum团队应该有一个产品持有人,他/她也可以是开发团队中的一员。
    • 产品持有人不是Scrum领导者(ScrumMaster)。

    开发团队 Development Team



    • 在每一个Sprint周期结束后,负责交付将来需要发布的产品的模块。
    • 由3到9人组成并拥有各种所需技能(分析,设计,开发,测试,技术沟通,文档,等等)。
    • 自我组织,有可能需要与更高级的项目管理部门交流。


    Scrum领导人 ScrumMaster



    • 专门负责扫清团队在交付Sprint目标或产品中遇到的障碍。
    • 不是团队领导人,但是扮演着团队与可能分散团队注意力的影响之间的缓冲区。
    • 确保Scrum流程的使用在计划中。
    • 规则强制执行人。团队保护者,以保持团队专注于他们手中的工作。
    • 也会被看作一个人民公仆去加强这些双重观点。
    • 不同于一个项目经理,没有与ScrumMaster不相关的人员管理职责
    • 没有任何额外的员工责任。

    Backlog未完成项列表


    产品的待完成项列表是一个需求的排列列表,我们维护这个列表是为了更好的开发产品。它的组成有功能,BUG修复,非功能需求等任何为了成功发布可用软件系统的所必须的内容。在Scrum中,开始一个项目不必先开发一个冗长文档去记录所有的需求。这个敏捷产品backlog对于第一个Sprint足够了。当有更多产品需求时和客户需求时,Scrum产品backlog允许变更和增加。

    Sprint backlog是开发团队下个Sprint需要处理的工作列表。这个列表是产品backlog最上面的需求项衍生出来的,直到开发团队在这个Sprint中有足够的工作去做。开发团队通过问一些问题来完成backlog的选择,如“我们是不是也能做这个?”。



    从概念上讲,团队从优先级最高的Scrum backlog开始画一条线划分出优先级较低的项,同时线上面的backlog也是团队认为他们可以完成的项。在实践中,团队通常不会去选择优先级最高的五项再选择优先级较低的两项组合在一起即使它们是互相关联的。


    敏捷开发调查

    这项调查发起于2012年8月9日至2012年11月1日之间,由VersionOne赞助的。调查从软件开发社团的不同渠道中选择了4048人。数据由Analysis.Net Research分析并总结成报告。

    谁知道敏捷开发?


    一般情况下,相比业务人员,越接近开发团队角色的人了解敏捷开发的越多

    敏捷开发失败原因


    进一步使用敏捷开发的障碍物


    使用敏捷开发最大的担心




    总结


    一个好的敏捷团队会选择最适合他们的管理与技术实践。当试着去使用敏捷开发时,会有一万个借口为什么这行不通。只有那些真正理解敏捷开发优势并真心实意地想要使用敏捷开发的人们才会有可能成功。那些正在搜索为什么Agile会失败的人们,他们可能最终会找到答案也可能放弃之前所做的一切努力不再使用敏捷开发。Elisabeth Hendrickson称这种行为“假敏捷开发”。



    为了支持一下我的结论,让我们引用一些名言(从Robert C. Martin收集):
    "In preparing for battle I have always found that plans are useless, but planning is indispensable." - General Dwight David Eisenhower 
    在战斗准备中,我总是发现那些计划是鸡肋,但是制定计划是不可缺少的。

    局限于别人的方法世界里不是可取的,因为公司需求,公司情况,项目都有可能一直在变化着。如果你想你的项目成功,你一定要灵活地应用这些现成的方法去管理项目。任何单一的方法都不是一把尚方宝剑,因此关键是看哪种方法适合你并能协调你的方法去满足你的个人需求。

    记住,Scrum和Agile不是一个死产品 ,它是在持续改进的基础上不断进行中的一门哲学。


    翻译:http://www.codeproject.com/Articles/604417/Agile-software-development-methodologies-and-how-t
    展开全文
  • DoD“完成”的定义 ...为了避免这个问题,在敏捷软件开发中,常用Definition of Done“完成的定义”来表示工作是否已完成,不同的活动有不同的完成定义。 典型的是迭代DoD,这也是最初DoD应用的地方。
  • 主要敏捷开发方法

    2009-09-24 17:01:00
    主要的敏捷方法极限编程(XP) 极限编程(XP)的主要目的是降低需求变化的成本。它引入一系列优秀的软件开发方法,并将它们发挥到极致。比如,为了能及时得到用户的反馈,XP要求客户代表每天都必须与开发团队在一起...
  • 敏捷估算方法 无论是团队研发一款产品或者开发某一个项目,我们都需要回答“我们大概什么时间能够完成?”, 或者到某一个时间点,我们能够做到什么程度, 因此和传统的开发模式一样,我们在故事拆分之后需要对我们...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 敏捷开发 模型讲解

    2017-03-01 16:56:54
    CSDN:在你的工作生涯中,前期是在创业公司,后来是大公司,有着一套自己的敏捷开发模式,能够谈谈在你现在使用的敏捷开发工具或方法? 黄勇:敏捷这个话题大家一直都在谈论,也有很多关于敏捷的工具或方法,我...
  • 开发方法---敏捷方法

    2018-08-28 21:24:22
    敏捷方法  2001 年 2 月,在美国的犹他州,17 位“无政府主义者”共同发表了《敏捷软件开发宣言》,在宣言中指出: 尽早地、持续地向客户交付有价值的软件对开发人员来说是最重要的。 拥抱变化,即使...
  • 敏捷开发

    2018-08-28 18:09:25
    定义敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,...
  • 1,提要 软件开发是一个系统工程,包括最初的可行性分析、再到设计、开发、测试、维护等整个生命周期。在这个过程中某些阶段的失误或说是变化,都可能增加...传统瀑布模式和新型的敏捷开发就是其中最常用的方法,后
  • 敏捷开发与迭代开发

    2018-04-22 23:09:48
    2.敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。二、区别:1.性质不同:迭代开发是软件开发的生命周期模型,是一种开发过程;敏捷开发是多种软件开发项目管理方法的集合,是一...
  • 在诸多方法中,敏捷开发以其能持续满足不断变化的用户需求正在受到越来越多人的重视,从中小项目开始进入大型开发项目,近几年来上升势头明显。那么,敏捷开发有什么好处呢?    在软件工业界,敏捷开发已成为众多...
  • 敏捷开发之道

    2012-07-22 19:15:41
    敏捷开发(agile development)是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目...
  • 什么是敏捷开发流程

    2019-05-11 19:34:29
    【什么是敏捷开发流程 】 这个词猛一听起来感觉很高大上,其实现在已经是主流的团队开发流程 了。 一. 先说一下官方的定义: 敏捷不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。符合敏捷价值观....
  • 敏捷开发小结

    2017-01-05 20:46:21
    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中, 软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。 换言之,...
  • 在诸多方法中,敏捷开发以其能持续满足不断变化的用户需求正在受到越来越多人的重视,从中小项目开始进入大型开发项目,近几年来上升势头明显。   在软件工业界,敏捷开发已成为众多高效开发团队的制胜之道。在欧美...
  • 敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流,往小了说是改进了开发方法,往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。我们使用 tapd 写 feature,流转、跟踪任务...
  • 敏捷软件开发最近几年越来越火。跟传统软件开发相比有什么优点呢。今天我们就来聊一聊。 首先我们来看下什么叫做敏捷敏捷软件开发过程 软件开发过程是指设计软件开发过程中涉及的一系列活动,指导开发组一步...
1 2 3 4 5 ... 20
收藏数 51,463
精华内容 20,585
关键字:

敏捷开发方法的定义