敏捷开发方法_敏捷开发方法综述 - CSDN
精华内容
参与话题
  • 7种敏捷开发方法

    千次阅读 2019-05-10 09:19:07
    XP极限编程 SCRUM迭代增量化过程 Cystal Methods水晶方法族 FDD特性驱动开发 ASD自适应软件开发 DSDM动态系统开发方法 轻量型RHRUP
    展开全文
  • 常用敏捷开发方法

    千次阅读 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天)一次的迭代成为一个冲刺,并按需求的优先级别来实现产品,有多个自治组织和自治小组并行的递增来实现产品。
    自适应软件开发  

     

     

     

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

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

    敏捷开发方法学及应用


    简介


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


    背景

    下图是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
    展开全文
  • 原文地址:https://www.zhihu.com/question/54626462管理工具:1.需求管理工具confluence 是一个基于...2.基于敏捷管理的sprint、backlog、开发task、bug管理工具jira 是一个基于java的issue(问题、事项)管理器,...
  • 什么是敏捷开发

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

    万次阅读 多人点赞 2018-08-08 19:25:59
    简介 这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发... 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。 在敏捷开发中,软件项目在构建初期被...
  • 主要敏捷开发方法

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

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

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

    万次阅读 多人点赞 2012-05-21 20:24:49
    极限编程(eXtreme Programming,简称XP)是一种轻量级、高效、低风险、柔性、可预测的、科学的软件开发方法,其特性包含在12个最佳实践中。 1. 计划游戏 ( Planning Game )  (1)快速制定计划、随着细节的...
  • 敏捷开发方法Scrum经验总结

    千次阅读 2010-08-04 17:58:00
    经过实践证明,Scrum 方法用于开发要求快速、灵活,且生命周期短的需求还是很给力的。 关于启动 Scrum 方法的套路就不再赘述了,都是经典的东西。下面总结一下独特的经验(大家鼓掌): 在 sprint planning meeting ...
  • 敏捷开发

    千次阅读 2008-02-08 10:07:00
    敏捷开发(agile development)是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目...
  • 敏捷估算方法 无论是团队研发一款产品或者开发某一个项目,我们都需要回答“我们大概什么时间能够完成?”, 或者到某一个时间点,我们能够做到什么程度, 因此和传统的开发模式一样,我们在故事拆分之后需要对我们...
  • 混合的敏捷开发方法SpecDD模型

    千次阅读 2013-01-28 10:38:39
    敏捷开发用短短十年时间发展为当今最为广泛使用的开发方法,其原因在于它简单且有效地提高了开发团队的生产率。敏捷方法指导团队将产品需求置于Product Backlog中管理,并按照优先级对每个产品需求进行必要的排列;...
  • 敏捷开发实践(一)--谈谈我对敏捷开发的理解

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

    千次阅读 2018-08-28 21:24:22
    敏捷方法  2001 年 2 月,在美国的犹他州,17 位“无政府主义者”共同发表了《敏捷软件开发宣言》,在宣言中指出: 尽早地、持续地向客户交付有价值的软件对开发人员来说是最重要的。 拥抱变化,即使...
  • 过去,几乎所有的软件开发项目都采用瀑布模型。这种编程方法酷似工厂装配线,要求开发人员完成一个开发阶段,之后才能进入到下一个阶段。这种方法高度结构化,但是...我们在本文中介绍了十种最流行的软件开发方法的功
  • 什么是敏捷开发流程

    千次阅读 2019-05-11 19:34:29
    【什么是敏捷开发流程 】 这个词猛一听起来感觉很高大上,其实现在已经是主流的团队开发流程 了。 一. 先说一下官方的定义: 敏捷不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。符合敏捷价值观....
  • 敏捷开发包括一系列的方法,主流的有如下七种:XPXP(极限编程)的思想源自Kent Beck和Ward Cunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化,XP无需开发人员...
1 2 3 4 5 ... 20
收藏数 89,730
精华内容 35,892
关键字:

敏捷开发方法