敏捷开发的方法_敏捷开发方法 - CSDN
  • 常用敏捷开发方法

    千次阅读 2014-07-16 15:52:14
    摘自《轻松Scrum之旅》

    摘自《轻松Scrum之旅》


    1、极限编程(eXtreme Programming,XP) 


    极限编程的思想源自 Kent Beck 和 Ward Cunningham 在软件项目中的合作经历。在这里,“eXtreme”的意思是希望将软件开发过程中一些好的方法发挥到极致。XP 注重的核心在于“沟通、简明、反馈和勇气”,用一句话来概括 XP 的这 4 个核心价值观就是:通过充分的交流和沟通,使产品的设计尽可能简单明了;同时通过客户经常性的反馈,生产出符合客户要求的软件产品,并且有勇气迎接需求的改变。
     
    另外,极限编程者还总结出一系列经典的实践,形成了 XP 的 12 个主要实践方法,这些方法对极限编程具有指导性的意义,分别是:客户计划的制定、小版本发布、隐喻、结对编程、测试驱动开发、重构、稳定的进度、代码共享、编码规范、简单的设计、持续集成、现场客户。 



    2、RUP(Rational Unify Process,Ratioanl 统一过程) 


    RUP 试图总结现代软件开发过程中所有好的实践经验,形成一种有很强适应性的软件开发过程。它包括了软件开发中的 6 大经验,分别是:迭代式开发、管理需求、可视化建模、使用基于组件的软件体系结构、验证软件质量、控制软件变更。
    RUP 将软件开发周期按时间和 RUP 的核心工作流划分为一个二维空间,如下图
    所示。

    从图中的横轴来看,RUP 把软件开发的生命周期划分为多个循环迭代,每个迭代生成产品的一个新版本,每个迭代由 4 个连续的阶段组成,分别是:初始阶段,了解项目的大致需求,建立业务模型,确定系统范围;细化阶段,设计、确定系统的体系结构,制定工作计划;构造阶段,构造产品并继续演进需求、体系结构、计划直至产品提交;移交阶段,完成产品的最终版本并交付给用户使用。 

    从图纵轴来看,RUP 的 9 个核心工作流分别是:业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理、环境。 
    RUP 的基本原理是:以满足客户需求、为客户创造价值为最终目标;尽可能早且不断地化解重大风险;把注意力放在可工作的软件上;在项目执行过程中尽可能早地适应变化;在项目早期设计、实现并测试一个可执行的架构;使用组件来构造系统;建立高效、协作的团队;要始终重视产品质量,否则追悔莫及。 

    以上 RUP 的基本原理构成了 RUP 的灵魂,在这些指导原则下,RUP 又给出了其他一些最佳实践,比如:为了化解业务风险,它始终以用例为中心;不是逃避变化,而是直面变化;为了化解时间风险,它采取迭代开发,尽量在早期探知到时间的延迟,以便采取更灵活的策略;为了化解技术风险,它强调架构设计;为了化解质量风险,它强调测试优先。而这些也恰好是 RUP 的主要特点。在这些最佳实践之后,才是具体的过程组织形式:具体由哪几个阶段组成?而每个阶段又包括哪些工作流,要产出哪些产品?而且这些形式不是固化的。RUP 只是提供一个模板,可以在开发过程中进行裁减。



    3、Lean(精益软件开发方法)

      
    精益生产的概念首先出现在制造业中,由日本的丰田公司提出。大规模制造理论认为,一定程度的浪费、一定程度的废品是正常的和被允许的。而在软件开发中,资源浪费、成本居高不下也同样成为软件开发的一大障碍。处于变革的十字路口的软件开发行业,总是能不断地从其他行业中寻找可借鉴的理论。这种借鉴来的思路就被称为精益编程(Lean Programming)。

    Lean 方法的主要思路有:消除浪费,将所有的时间花在能够增加客户价值的事情上;延迟决策,在一个复杂多变的环境中进行软件开发,需要根据实际情况保持可选方案的开放性,但时间不能过长;尽早交付,软件交付的周期越快,用户的需求就会越清晰,软件应对需求变化的灵活性就越高,让客户的需求来推动工作的进展;加强学习,承认变化的存在及其不可预见性,加强反馈和交流,在实践中发现问题、解决问题,并最终形成解决方案;授权给团队,正确的决策取决于准确的信息,让开发团队参与决策,让团队成员充分发挥自己的潜力。 

    无数的经验和教训都已经证明,软件开发中一个巨大的浪费源头就是不注重质量而导致的返工。人们常常为了追赶工期而降低对质量的要求,殊不知这会带来更大的损失。

    Lean 强调消除浪费,这正是为了避免低质量和返工造成的浪费。尽管这样做一开始看起来似乎有些麻烦,但它所带来的收益是实实在在的。如果采用 Lean 方法,还要注意不要钻牛角尖。消除浪费并不意味着扔掉所有的文档;尽量推迟决策并不意味着拖延决策,不能晚到错过了时机、耽误了工作才作出决策;尽快交付并不意味着匆忙交付和马虎行事,否则会为日后的系统维护带来更多的麻烦和浪费,这恰恰是与消除浪费的原则背道而驰的;授权给团队也并不意味着放弃领导。



    4、Scrum


    Scrum是一种灵活的敏捷软件开发管理过程,这个名词来源于英式橄榄球。Scrum 方法由 Ken  Schwaber 和 Jeff  Sutherland 提出,它将软件开发团队比作橄榄球队,全队有明确的最高目标——发布产品的重要性高于一切,团队高度自治,成员们熟悉开发过程中涉及到的各种技术,紧密合作,确保每个迭代都朝着最高目标推进,而且每隔 2~4 周,每个团队成员都能看到能实际工作的软件,并且据此决定是发
    布这个版本还是继续开发以加强它的功能。 

    对于那些功能需求可能经常发生变化的项目来说,Scrum 是最为理想的选择之一。

    在一个采用 Scrum 的项目中,首先要将所有需要完成的工作列在一个 Product Backlog中,项目开发过程中需求的改变也要写进去。在每个 Sprint 开始之前,要召开一个 Sprint计划会议。在这个会上,产品责任人(Product  Owner)为 Product  Backlog 中的各项功能需求确定优先级。随后,Scrum 开发团队按照优先级,从 Product Backlog 中挑选出他们认为能在这个 Sprint 中完成的任务,并把这些任务从 Product  Backlog 中挪到Sprint Backlog 中去。在 Sprint 的进行过程中,Scrum 团队每天都要举行一个简短的每日 Scrum 会议,以便团队成员了解开发进度。一个 Sprint 结束之后,需要召开 Sprint评审会议和 Sprint 回顾会议。开发团队在 Sprint 评审会议上把这个 Sprint 的开发成果展示给大家。而在 Sprint 回顾会议上,团队成员们会回顾刚刚过去的这个 Sprint,从中总结经验和教训。
    Scrum 的总体结构如图所示



    展开全文
  • 敏捷开发方法总结

    2018-10-23 10:10:39
    敏捷开发方法 极限编程XP 是一种轻量级,高效,低风险,不能使编码速度加快 水晶法 每个不同的项目都要一套不同的开发策略,约定和方法论 并列争球法 运用了“迭代”的方法,把每段时间(例如30天)一...

    在备战软考做题的过程中,发现敏捷软件开发方法考的还算比较多,而自己也一直没弄明白!

    敏捷开发方法

    极限编程XP 是一种轻量级,高效,低风险,不能使编码速度加快
    水晶法 每个不同的项目都要一套不同的开发策略,约定和方法论
    并列争球法 运用了“迭代”的方法,把每段时间(例如30天)一次的迭代成为一个冲刺,并按需求的优先级别来实现产品,有多个自治组织和自治小组并行的递增来实现产品。
    自适应软件开发  

     

     

     

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

    千次阅读 2019-05-10 09:19:07
    XP极限编程 SCRUM迭代增量化过程 Cystal Methods水晶方法族 FDD特性驱动开发 ASD自适应软件开发 DSDM动态系统开发方法 轻量型RHRUP
    展开全文
  • 大厂是如何开发软件项目的呢?其实大厂做项目也无特别之处,也就是工程中常见的“分而治之”策略:大项目拆成小项目,大服务拆成小服务,大团队拆成小团队。 服务之间通过约定好的标准协议进行通信,架构上将大...

     大厂是如何开发软件项目的呢?其实大厂做项目也无特别之处,也就是工程中常见的“分而治之”策略:大项目拆成小项目,大服务拆成小服务,大团队拆成小团队。

        服务之间通过约定好的标准协议进行通信,架构上将大服务拆分隔离成微服务,大团队按照业务或者服务拆分成小组,按照流程规范保障协作。最终,各个小组负责的内容其实就不错了。

        所以归功于现在微服务、容器等新技术,可以将负责的业务主机拆分,让很多公司能真正敏捷起来。

        我们知道,团队要实施敏捷,不仅要小,组织还要扁平化,相对来说,美国互联网大企业做的很好,组织架构扁平,工程师地位很高。

        下面我们一起来学习一下大厂具体应用敏捷的方法。

    和敏捷相关的主要流程规范

     

    • 一切工作任务围绕Ticket开展

      早些年的项目开发,都是围绕项目计划开展的,把甘特图打印贴到墙上,方便团队成员看项目进展到什么地步了,敏捷开发后,就变成了看板。

          所谓的看板,就是把白板分成几个栏,每一栏为一类,分别写着“To Do”、“In Process”、“Done”等,再把工作任务变成一个个五颜六色的即时贴,根据状态贴在不同的栏下面。

      https://static001.geekbang.org/resource/image/a2/3b/a20b59edb20f60ec5c7c1ea1ee83bf3b.jpg

      慢慢的物理看板变成了电子看板,通过各种项目管理软件来管理跟踪这些任务,即时贴也变成了Ticket(也叫Issue).逐渐的,所有的开发任务也就和Ticket挂钩了:

    • 汇报一个Bug,提交一个Ticket;
    • 提交一条需求,提交一个Ticket;
    • 要重构一下代码,提交一个Ticket;
    • 看板这种基于Ticket来管理跟踪任务的方式,看起来繁琐,其实是一种特别高效的方式。

    • 每一个任务的状态都可以被跟踪:什么时候开始做的,谁在做,昨晚没有
    • 整个团队的进度一目了然
    • Ticket和敏捷开发中的Backlog(任务清单)结合,通过Ticket可以收集管理整个项目的Backlog和当前Sprint(迭代)的Backlog.
    • 有了看板,大家每天上班来的第一件事就是打开看板,看看当前Sprint还有哪些Ticket没有完成,哪些已经完成,哪些还在进行中,非常直观。

          作为项目组成员,就无需在手头的任务完成后问项目经理接下来做什么了,从“To Do”一栏里挑选一个Ticket继续做就可以;对于项目经理,从“To Do”就能看到还有哪些Ticket没有做,“In Process”里还有哪些正在进行,如果发现哪一栏的Ticket好久没有动,比较多,就需要注意风险管控了。

      基于Git和CI的开发流程

          如果团队用瀑布模型来开发,最头疼的事情就是代码不稳定和部署太困难。

          早些年的源代码管理,大家都是在Master(主干)上进行开发,所以master分支的代码极其不稳定,一不小心就会被合入不稳定代码。所以一般在版本发布前都有一段代码分支锁定期,这段时间代码合入是严格受控的。

          测试环境的部署也是难题,服务一多,编译时的各种依赖和环境的配置就要格外注意,更新测试环境就是一个大工程,需要专门有人负责测试环境。

          对于“代码冻结”和“专人部署”方案,一点不敏捷,好在基于Git的开发流程和结合CI的自动测试部署很好了解决了这两大难题。

      Git本来只是源代码管理工具,但是其有强大的分支管理和灵活的权限控制,配合一定的开发流程,可以帮助我们很好的控制代码质量。

          我们现在假设master的代码是稳定的,那如何保证新加入的代码也稳定呢?答案就是代码审查(Code Review)和自动化测试。如果代码有严格的审查,并且所有自动化测试都能测试通过,可以认为代码质量是可靠的,当然前提是自动化测试代码要有一定的覆盖率。

          每次往master合入内容前,不是直接提交代码到master,而是基于当前稳定的master,克隆一个branch分支出来,基于branch去开发,开发完成后提交一个PR(Pull Request请求)。

      https://static001.geekbang.org/resource/image/dc/f8/dc610641d65152e561fcc704e8797af8.png

      PR提交后,我们可以清楚的看到代码哪里改动了,其他人可以针对每一行代码写评论提出修改意见,确认代码没问题了就可以通过代码审查。

          接下来剩下自动化测试问题,就该CI(持续集成)登场了。

          CI就类似一个机器人,每次你提交一个PR(严格来说是Commit)到源代码服务器,CI立刻就知道了,然后它创建一个纯净的运行环境,download我们提交的代码,下载安装所有的依赖库,然后运行我们的测试代码,运行完毕后把测试结果报告给我们,测试结果只管的反馈在PR上,绿色表示通过,红色表示不通过。

      https://static001.geekbang.org/resource/image/50/b9/50b61f8062a99658b26c86e1b42fe3b9.png

      代码审查和自动测试问题都解决了后,就可以合并到master了,我们可以认为合并到master的代码是稳定的。

          https://static001.geekbang.org/resource/image/9a/53/9a4523bb43cd64d12155e90607732153.jpg

      下面以一个开发任务为例,大致讲解一下应用敏捷开发方法的基本开发流程:

    • 把要开发的Ticket从“To Do”栏移动到“In Process”栏
    • 从主干master创建一个分支branch,基于分支去开发功能或修复Bug
    • 编写单元测试代码和集成测试代码,是否TDD不重要
    • 持续提交代码更新到分支,直到完成
    • 创建PR,邀请别人Review代码,根据Review结果,可能还需要更新几次
    • CI在每一次提交代码到代码库时都会自动运行,运行的目的如下:
    • 代码格式是不是符合规范
    • 运行单元测试代码
    • 运行集成测试
    • 最终CI把执行结果显示在PR上,绿色通过红色不通过
    • PR能合并到master需要满足两个条件:CI变绿+代码Review通过
    • PR合并后,CI自动构建Docket Image,讲Image部署到开发环境
    • 响应的Ticket从看板上的“In Process”栏移动到“Done”栏
    • https://static001.geekbang.org/resource/image/96/78/963f6a02614892e09ef936ac54dc8178.png

      正常来说,我们是需要严格遵守开发流程的,但偶尔有紧急任务,来不及写测试代码,我们针对这种情况,一定要再创建一条Ticket跟踪,确保后续补上测试代码,不要欠下技术债务。

      部署上线流程

          最早的时候,程序员自己管服务器,但是这过于随意,导致出现很多问题,于是出现了专门的运维团队,讲开发好的程序编译好,数据生成脚本写好,然后写成部署文档,交给运维去手动部署,过程繁琐慎重,遇到打补丁还要延迟。

          这些年随着随着容器化、微服务、DevOps技术和概念的兴起,部署变得高效,以前是运维人员按照文档部署,现在是DevOps写自动化部署工具,开发人员自己去部署生产环境,大厂的部署也都实现了自动化,但是流程受到控制:

    • 部署的不再是程序代码,而是Docker的Image,每次代码合并后CI会自动生成Image,测试也是基于Image
    • 部署生产环境之前,现在内部的测试环境充分测试
    • 部署生产环境前,需要审批确认,有Ticket跟踪
    • 部署是部分部署监测OK后再全量部署
    • 整个过程都有监控报警,出现问题及时回滚
    • 如果一切顺利,整个生产环境的服务部署过程通常只要几分钟就完成了,这以前简直是不敢想象的事情。

      每日站立会议

      敏捷开发中,每日站会是非常有名的,但凡实施敏捷开发的小组,每天上班第一件事情,就是一起开一个站会,沟通一下项目的基本情况和进展,开完会全身心去干活。

      是不是站着开会其实不重要,重点是要高效沟通反馈

      开会时间控制在半个小时内,半小时内不能完成的应该另外组织会议。

      在敏捷的Scrum中,有一个角色Scrum Master(敏捷教练,敏捷大师),主要任务就是保证各种敏捷流程的,他来主持会议,控制好会议节奏,主要有如下三个话题

    • 成员轮流发言
    • 每个人轮流介绍一下,昨天干了什么事情,今天计划做什么事情,工作上有无障碍无法推进。通过这样的形式,项目成员可以相互了解任务进展,有困难可以互相支援,及时发现问题和风险,当然每个人对自己提出的目标需要信守承诺,努力完成。

    • 检查最新的Ticket
    • 每天理会需要检查一下新增的Ticket,甄别一下优先级,然后决定是放到当前Sprint,还是放到Backlog任务清单,这个阶段要注意不能发散,不要针对Ticket的细节过多讨论,有需要讨论的收集放到“问题停车场”。

    • 停车场问题
    • 总结

          在敏捷开发中的概念有Backlog、持续交付、每日站会等,这些概念最终要变成实践的话,必须通过一定的流程规范来保障这些概念的实施。

          这就是为什么公司要写自动化测试代码,用Jira、禅道项目管理软件来管理任务,每天开站立会议,代码审查,都是为了保障敏捷的正常实施。

          我们在实施敏捷开发的项目工作时可以多观察和敏捷相关的流程规范,再结合敏捷开发中的知识点,就能很好的帮助我们理解敏捷开发,理解流程规范背后的理论依据。

      此环节,大家可以针对之前来不及讨论的问题进行讨论,能在会议时间内解决的问题,立马解决,不能解决的私下讨论或者再组织会议。

    展开全文
  • 敏捷开发方法学及应用

    千次阅读 多人点赞 2013-12-13 00:20:54
    本篇文章是有关敏捷软件开发方法学及应用的基础知识。敏捷开发是有关团队怎么样合作去实现一个常规目标。敏捷开发并不仅仅适用于软件开发者,也适用于团队领导人,项目经理,产品经理,开发经理,测试人员,质量保证...
  • 试论敏捷开发方法的共同特征

    千次阅读 2016-06-21 21:15:58
    本文将为你介绍敏捷开发方法框架的共同特征,理解与传统软件工程的联系和不同。短迭代的生命周期模型生命周期是事物发展的客观规律,软件同样存在生命周期。早期的软件生命周期往往是说“软件从计划、需求开始,经历...
  • 敏捷开发实践(一)--谈谈我对敏捷开发的理解

    万次阅读 热门讨论 2015-05-31 09:58:51
    随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。
  • 软件开发模式之敏捷开发(scrum)

    万次阅读 多人点赞 2018-08-08 19:25:59
    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 作者:TechExcel CEO兼首席架构师 周铁人博士   敏捷已成为当今使用最广泛的开发方法。... SpecDD是由周铁人博士创立的一种以需求为核心的混合敏捷开发方法。它基于同时支持敏捷开发和非敏捷开发
  • 敏捷开发方法Scrum最佳实践

    千次阅读 2009-11-09 22:03:00
    首先强调一些Scrum的基本概念本文只想为那些不断实验敏捷开发方法、追寻快速交付产品的IT管理者提供全套经过验证的实践经验,供之参考。我首先假设你已经理解了Scrum这种敏捷开发方法的基本概念并认同之,但是仍然,...
  • 什么是敏捷开发

    万次阅读 多人点赞 2019-05-31 10:49:56
    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美...
  • 敏捷开发方法XP的12个最佳实践

    万次阅读 多人点赞 2012-05-21 20:24:49
    极限编程(eXtreme Programming,简称XP)是一种轻量级、高效、低风险、柔性、可预测的、科学的软件开发方法,其特性包含在12个最佳实践中。 1. 计划游戏 ( Planning Game )  (1)快速制定计划、随着细节的...
  • 随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。
  • 敏捷流派众多,在此做一个简单的整理与分享。 一、极限编程 极限编程(ExtremeProgramming,简称XP)是由KentBeck在1996年提出的。极限编程是一个轻量级的、灵巧的软件开发方法;同时也是一个非常严谨和周密的...
  • 上一站,我们简单的谈了谈FDD,了解了什么是特征驱动开发,以及它核心的整体模型,在我看来,它是一种有效但有一些复杂的敏捷开发方法,对于小团队来说,实施起来有些困难。然而,今天我们要认识的是一种新的开发...
  • 主要敏捷开发方法

    千次阅读 2009-09-24 17:01:00
    它引入一系列优秀的软件开发方法,并将它们发挥到极致。比如,为了能及时得到用户的反馈,XP要求客户代表每天都必须与开发团队在一起。同时,XP要求所有的编程都采用结对编程(pair-programming)的方式。这种方式是...
  • 敏捷开发工具:禅道

    2018-11-12 10:03:57
    之前看了很多敏捷开发方法论等知识,都觉得是无从下手,如之前的领歌当时觉得不错,就一直尝试多种敏捷开发工具的使用。 最近,BOSS推荐了一个敏捷开发工具,禅道。 首先,附上一些禅道界面。 目前,使用的开源...
  • 过去,几乎所有的软件开发项目都采用瀑布模型。这种编程方法酷似工厂装配线,要求开发人员完成一个开发阶段,之后才能进入到下一个阶段。这种方法高度结构化,但是...我们在本文中介绍了十种最流行的软件开发方法的功
  • ThoughtWorks的敏捷开发

    千次阅读 2018-07-23 11:19:45
    ThoughtWorks的敏捷开发方法一直是一种神秘存在。在敏捷开发还没有主流化的年代,为了让外界理解ThoughtWorks全球团队怎么做敏捷,我们商定了一个“60% Scrum + 40% XP”的经典答案。当然其实ThoughtWorks的敏捷开发...
  • 敏捷测试流程

    千次阅读 2015-11-16 17:51:18
    针对敏捷开发方法的敏捷测试不同于以往针对传统开发模式的测试,在敏捷团队中,测试是整个项目组的“车头灯”,它告诉大家现在到哪了,正在往哪个方向走。测试员为项目组提供丰富的信息,使得项目组基于这些可靠的信息...
1 2 3 4 5 ... 20
收藏数 88,347
精华内容 35,338
关键字:

敏捷开发的方法