敏捷开发 适合于项目类型_敏捷开发适合于什么项目 - CSDN
  • 哪种项目适合敏捷开发?  (2011-07-29 15:47:18) 转载▼ 标签:  敏捷开发   agile   scrum   适合程度   it 分类: IT翻译  译者:高小皋 作者:...

    哪种项目最适合敏捷开发?

     (2011-07-29 15:47:18)
    标签: 

    敏捷开发

     

    agile

     

    scrum

     

    适合程度

     

    it

    分类: IT翻译

            译者:高小皋   作者:迈克科恩

    最近有人问我,哪种项目最适合敏捷开发。我将在本文给出答案。在我看来,那些期限紧迫、具有高度复杂性和新颖性的项目最适合敏捷开发。

    当我们开发一个新项目、起码对开发团队而言是个新项目的时候,我们愿意采用敏捷开发。如果之前团队已屡次开发过此类项目,那么基本不会采用敏捷开发的方式。我认为,这跟某些制造业很类似。比如我们生产轿车,日复一日,自然就会非常迅速地掌握所有生产轿车的奥妙之处。这种情况下,对创新的要求很低,就用不着敏捷开发。

    单有对创新的要求,并不意味着就要采用敏捷开发。今天,我去了自己最爱的中餐馆吃午饭,点了一个“超级辣味胡椒”开胃菜。很可能是饭店首次用这种方式烧这道特色菜,具有一定的创新性或者说独特性。厨师虽然做了充分的准备,但因为我能看到厨房里面,我确信他们不需要每日即时讨论甚至是TDD(技术资料文摘)来准备我的午餐。(也许我应该注意到那里有个看板。)因此除了有新颖性的要求,项目还需要有一定的复杂程度。 

        适合敏捷开发的项目,其最后一个必要因素我认为是紧迫性。敏捷开发的时间限制和迭代性用来确保对项目的集中强度。如果项目不紧急,就用不着时间限制和迭代性。

    那么我们先了解一下这三个因素——紧迫性、复杂性和新颖性——是如何交织在各种项目中的。当然是先以软件项目为例,没有其他更合适的了。软件项目的复杂性众所周知。每个软件项目基本上都是一次新的冒险。而且,在当今世界常常有一种紧迫感。

    让我们再看看另外一种通常会用到Scrum(专业术语)的情况:结婚。我在一年内起码有两三次听到有情侣用Scrum敏捷开发策划了婚礼。婚礼前总是会积压一大堆事情——买蛋糕、接摄影师、发邀请函、拿礼服,等等。策划婚礼跟我所提议的三个因素是如何关联的呢,紧迫感?对,婚礼一般会有个最后期限,而且通常是确定好的日期。复杂性?嗯,虽然它没有软件项目那么复杂,但也因为一些非功能性要求而提高了其复杂程度。比如,它有固定的预算、坐席的安排、供餐的类型、让Cousin Ira乐队在接待会表演,等等。要别出心裁、有所创新?当然。大多数人应该不会结很多次婚、每次又都大张旗鼓地举办婚礼吧!婚礼当然不能与他人雷同了。

    因此,敏捷开发最适合复杂程度高、要求新颖的紧急项目,包括软件开发和婚礼的策划。它确实会碰到这样的问题,比如结婚新人是否要在庆典结束时以初吻作为压轴戏,或者作为整个项目的部分评价标准。

    展开全文
  • 我最近被问到关于什么样的项目才是最适合于敏捷方法,在此关于这方面进行一个探讨。 在我看来,最适合敏捷方法的项目是那些有着激进的时间期限限制,那些有着高度的复杂程度,以及那些有着高度新颖性(独特性)的...

    我最近被问到关于什么样的项目才是最适合于敏捷方法,在此关于这方面进行一个探讨。

    在我看来,最适合敏捷方法的项目是那些有着激进的时间期限限制,那些有着高度的复杂程度,以及那些有着高度新颖性(独特性)的项目。

    当我们在做一些新的事情,到少是对于开发团队是新的事情,的时候我们会比较愿意使用敏捷方法。如果这是一件团队以前曾经重复做过很多次的事情,他们很可能就不需要用敏捷的方法来做了。对我来来说,这种时候就应该考虑引入类比制造的方法了。如果我们每天建造同一种车,我们很快就会了解到造车中的每一个细微差别。我们不需要一个敏捷的方法因为在这种情况下新颖性非常低。


    但是单独的新颖性本身并不一定就意味着必须 使用敏捷流程。我今天去了我最喜欢的一家中国餐厅吃午餐。我点了一道“三倍辣外加墨西哥胡椒”的主菜。这也许是他们第一次这样做这道菜,而且这是一个少见的或者独一无二的点餐。但是厨师做得非常好。而且我确定(因为我能看到厨房里面)他们不需要站会或者测试驱动的方法来做这个午餐(然而,我好像看到他们背后有一个看板, ).所以说除了新颖性,使用敏捷的项目也需要有一定程度的复杂性


    一个我认为在决定一个项目是否适合于使用敏捷方法的最终因素是紧急性。敏捷方法中的时间箱和迭代就是为了保持项目中的紧张度和专注度。如果项目没有紧急性,这些就是不需要的。让我们一起看一下这三个因素-紧急性,复杂性和新颖性-在不同的项目中是如何组合的。当然,从软件项目开始来看。没有比软件项目更适合的了。软件项目是出了名的复杂。每一个新的软件项目中的大部分内容都是新的尝试。而且在当今社会,软件项目总是很急的。


    但是让我们再看看另一个我们大家都听过的适用于Scrum的情形:婚礼筹备。我每年至少有好几次听说人们用Scrum方法来筹备婚礼。人们会准备一份婚礼的backlog–买蛋糕, 找摄影师, 发邀请, 准备服装等等. 那么筹备婚礼与我所说的三个因素什么关系呢?紧急性?看一看。总是有一个限期在那里而且通常是不能改的。 复杂性? 哈,它与软件项目不太一样但是有它自的复杂度,通常由非功能性的需求带来,比如固定的预算,谁应该坐谁的旁边,提供什么类型的食物,是否要让艾拉表妹乐队做迎宾演出等等。新颖性, 是的。大部分人都不会有太多次举办这种大型庆典活动,所以筹备活动对他们都是有很强的新颖性的。


    所以,敏捷特别适合于那些很紧急并且非常复杂及比较新颖的项目,可以是软件项目,也可以是婚礼。当然,夫妇俩是否要在庆典的结尾有第一个吻,这是否应该属于backlog的一部分,还是应该算产品完成标准的一部分,这样的问题是必须要搞清楚的。


    原文地址:http://blog.mountaingoatsoftware.com/deciding-what-kind-of-projects-are-most-suited-for-agile

    展开全文
  • 我最近被问到关于什么样的项目才是最适合于敏捷方法,在此关于这方面进行一个探讨。在我看来,最适合敏捷方法的项目是那些有着激进的时间期限限制,那些有着高度的复杂程度,以及那些有着高度新颖性(独特性)的项目...

     

    本文转自:Scrum中文网

    文章链接:http://www.scrumcn.com/agile/scrum/4936.html

     

    我最近被问到关于什么样的项目才是最适合于敏捷方法,在此关于这方面进行一个探讨。在我看来,最适合敏捷方法的项目是那些有着激进的时间期限限制,那些有着高度的复杂程度,以及那些有着高度新颖性(独特性)的项目。

    当我们在做一些新的事情,到少是对于开发团队是新的事情的时候我们会比较愿意使用敏捷方法。如果这是一件团队以前曾经重复做过很多次的事情,他们很可能就不需要用敏捷的方法来做了。对我来来说,这种时候就应该考虑引入类比制造的方法了。如果我们每天建造同一种车,我们很快就会了解到造车中的每一个细微差别。我们不需要一个敏捷的方法因为在这种情况下新颖性非常低。

    但是单独的新颖性本身并不一定就意味着必须 使用敏捷流程。我今天去了我最喜欢的一家中国餐厅吃午餐。我点了一道“三倍辣外加墨西哥胡椒”的主菜。这也许是他们第一次这样做这道菜,而且这是一个少见的或者独一无二的点餐。但是厨师做得非常好。而且我确定(因为我能看到厨房里面)他们不需要站会或者测试驱动的方法来做这个午餐(然而,我好像看到他们背后有一个看板).所以说除了新颖性,使用敏捷的项目也需要有一定程度的复杂性。

    一个我认为在决定一个项目是否适合于使用敏捷方法的最终因素是紧急性。敏捷方法中的时间箱和迭代就是为了保持项目中的紧张度和专注度。如果项目没有紧急性,这些就是不需要的。

    让我们一起看一下这三个因素-紧急性,复杂性和新颖性-在不同的项目中是如何组合的。当然,从软件项目开始来看。没有比软件项目更适合的了。软件项目是出了名的复杂。每一个新的软件项目中的大部分内容都是新的尝试。而且在当今社会,软件项目总是很急的。

    但是让我们再看看另一个我们大家都听过的适用于Scrum的情形:婚礼筹备。我每年至少有好几次听说人们用Scrum方法来筹备婚礼。人们会准备一份婚礼的backlog–买蛋糕, 找摄影师, 发邀请, 准备服装等等. 那么筹备婚礼与我所说的三个因素什么关系呢?紧急性?看一看。总是有一个限期在那里而且通常是不能改的。 复杂性? 哈,它与软件项目不太一样但是有它自的复杂度,通常由非功能性的需求带来,比如固定的预算,谁应该坐谁的旁边,提供什么类型的食物,是否要让艾拉表妹乐队做迎宾演出等等。新颖性, 是的。大部分人都不会有太多次举办这种大型庆典活动,所以筹备活动对他们都是有很强的新颖性的。

    所以,敏捷特别适合于那些很紧急并且非常复杂及比较新颖的项目,可以是软件项目,也可以是婚礼。当然,夫妇俩是否要在庆典的结尾有第一个吻,这是否应该属于backlog的一部分,还是应该算产品完成标准的一部分,这样的问题是必须要搞清楚的。

    展开全文
  • 原来问题是这么写的:“一家企业既要过CMMI,又要过ISO,还要实施敏捷,应该怎样做?” 之所以改成“哪个好”,是因为如果要多头并存,就要有主次关系。 那么,到底哪个好,应该以哪个为主呢? [b]分析[/b]...
    [size=medium]
    [b]问题[/b]
    原来问题是这么写的:“一家企业既要过CMMI,又要过ISO,还要实施敏捷,应该怎样做?”

    之所以改成“哪个好”,是因为如果要多头并存,就要有主次关系。

    那么,到底哪个好,应该以哪个为主呢?

    [b]分析[/b]
    每次说到这个问题,都会有不同的角度可以分析。

    一个常见的角度是说:CMMI比较完整“大气”,可以做整个公司的管理框架,而敏捷更适合团队级别的管理。

    另外一个角度是说:两个是可以共存的,可以用敏捷开发的实践来满足CMMI的要求。

    那么,到底哪个角度是优先考虑的呢?

    [b]商业目标是优先考虑的角度。[/b]

    这是一个经常被廉价贩卖以至于不太引起重视的角度了,大致说的是:要理解自己的现状和目标,以便决策自己的研发方法。

    有时候过程改进人员或质量人员也常常研究这个目标,但常常仅限于研究个别度量数据的目标,而极少有人有足够的高度来看整体框架的目标(本人当年也是如此)。

    基于这一点,下面方案中分为几个场景一一描述。

    [b]方案
    方案1:军工、航空航天——生命攸关和潜在重大损失的——CMMI为主[/b]

    在敏捷与CMMI系列之一http://blog.csdn.net/cheny_com/article/details/6423463 中曾经提到,CMMI的本质是美国国防部(DOD)用于筛选供应商的标准,其核心价值观是利用需求、计划的可追溯性、一致性,来达成对生命攸关和潜在重大损失项目的保障。

    这一要求可以令其基本忽略我们常常引以为豪的“创新”“激励”这些因素,或至少坚定地把这些因素排在一致性、可追溯性之后。

    [b]方案2:银行、证券——潜在重大损失的——CMMI为主,辅以RUP[/b]

    IBM是CMMI的重要推手之一,此外他们还是军工和制造业软件研发管理工具的提供者——Rational系列产品及后来收购的Telelogic DOORs、SA等产品,广泛应用于军工、航空航天、制造业,但IBM最喜欢的,不是瀑布模型,而是RUP。

    RUP可以理解为瀑布被迭代化了,允许业务的“不断精进”,而不是最初把需求就要一次定好。

    RUP也可以理解为迭代被瀑布化了,允许迭代的目标不完全是“生产可运行软件”,或者虽然如此,但比重不同;比如开始做“可运行软件”的目的,不是交付,而是用作需求沟通的原型。

    RUP是IBM这个与银行业打交道由来已久的老牌供应商的工作方式,无疑是这个行业的代表方法。

    [b]方案3:一般外包——CMMI为框架,辅以敏捷[/b]

    为什么以CMMI为框架?

    因为CMMI除了有军工、国防部这些标签外,还有几个标签:外包,供应商,供应商筛选。甚至可以说CMMI整体就是为外包双方准备的。而敏捷开发中,就无法直接看到有直接相关的内容。

    [b]方案4:互联网,网络游戏——Scrum为主[/b]

    这个行业建议一点都不要看CMMI。

    不是说CMMI完全无用,而是说有比CMMI适合地多的东西值得去做,比如产品创新,用户体验。

    这就有点像多数人都学点英语,但不学日语,不是学日语无用,而是对自己的职业生涯影响不很直接。

    [b]方案5:创新产品,移动互联小程序,网络游戏的初期——XP,“原始的”原型法,乃至混沌[/b]

    各种神奇的创业公司在初期的时候几乎都没有任何管理体系,然而其生产率估计到后来“正规化管理”后也无法超越,难道“管理”“开发方法”这些东西起的是反作用吗?

    不是。

    各种管理及方法,整体上有两个大的目标:

    1. 保证正在做一个正确的产品,需求符合用户的需要。

    2. 保证人员在正确地做事(包括正确的技术,被激励的工作态度等),确保产品被及时完成。

    在创业团队中,虽然没有“正规管理”,但却有其他的方法在保证这两件事情。换言之,如果“正规管理”没有聚焦于这两点,或没有充分做到这两点,那么就显得用处不大。

    在方案5涉及的语境中,“正规管理”能起到的作用是很小的,或者说无需正规管理,1和2应该也是能做到的(否则只能说找错了人,比如“我们用严格管理进行创新”就是错误的,应该是“我们找到一群激情的人进行创新”),因此过程应该尽量轻量化,去完成真正应该完成的创新工作。

    [b]方案6:随时随地按实际情况决策[/b]

    并非所有行业都是一成不变的,也不是所有行业的所有产品都符合行业特征。

    为什么CMMI中开始出现了敏捷的内容?很多人会想:“敏捷开发过于热火,CMMI不得不考虑一下广大程序员的心情。”其实不然,美国国防部是不会基于程序员的心情或业界的呼声而改变自己选择供应商的标准的,除非行业自身发生了变化。随着设备小型化,原来主要用于大型航空航天载具、指挥管控系统的软件已经逐渐走向单兵或单个小型器械,如果经常看《未来武器》系列纪录片,就会意识到这一点。这些产品很多对“一致的、可追溯的”需求没有太大的追求,反而是快速响应变化变成了一个看得见的价值。

    为什么IBM也开始做RTC了呢?(RTC是IBM Rational开发的敏捷开发管理工具)因为原来银行业的业务一直变化很慢,就是存取款贷款之类,但最近大家应该能感受到,银行队伍的长度,和股市、基金、理财、黄金的关系更大,这些业务的需求变化很快,敏捷开发变得势在必行。

    [b]因此应该理解自己的行业,也要理解自己正在面对的具体产品,才能决定那种方法更适合,哪种方法为主。[/b]
    [/size]

    ref:http://blog.csdn.net/cheny_com/article/details/7496322
    展开全文
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 敏捷开发其实是对由于在长期的软件开发的实践中形成的一种方法论体系,现在的敏捷开发的理论体系包括了很多种方法论的。到目前为止最常用的方法有Scrum,Kanban,XP和Crystal 等等。 在很多时候,有些朋友会问敏捷...
  • 敏捷给产品开发带来的价值已经日益被软件开发业界所认可,从几个人的创业公司到几十万人的跨国企业,...在11月7日召开的Agile Singapore大会上,来自挪威PROMIS公司的Trond Åsheim展示了一种适合敏捷开发的合同模式...
  • 敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于...
  • 敏捷开发之道

    2012-07-22 19:15:41
    敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于...
  • 敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流,往小了说是改进了开发方法,往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。我们使用 tapd 写 feature,流转、跟踪任务...
  • 敏捷开发原则及方法

    2020-03-10 11:46:37
    敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于...
  • 增量交付开发 敏捷开发 当操纵金属和塑料而不是一和零时,是否有可能进行敏捷开发过程? 还是敏捷开发硬件的想法是错误的? 事实是,越来越多的组织给了瀑布式的支持,并转向基于scrum , lean和看板的模型,因为...
  • 敏捷开发思想谈  敏捷的原则   敏捷开发其实并没有标准型的流程。SCRUM也只是众多衍生体中的一个。实际上就算是SCRUM的实际使用也情况千差万别。所以首先,请大家有这么个概念:    敏捷开发绝对不是...
  • 在 Quora 上有人提出了 " 为什么像谷歌这种公司的开发人员认为敏捷开发是无稽之谈?" 的问题,关于此,作为一名前谷歌工程总监,David Jeske 提供了一些个人见解,以下是 David Jeske 的回答。 对很多人来说,敏捷...
  • 什么是敏捷开发

    2017-09-27 21:38:16
     不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。   第一部分:敏捷软件开发...
  • 原型法和敏捷开发 原型法 定义:又称快速原型法,不属于敏捷开发。 根据需求用IDE实现基本功能,然后用户试用、补充和修改的重复过程,最后的版本再决定是demo还是正式版本。 分类 1. 抛弃型原型 - 此类原型在...
  • 敏捷开发包括一系列的方法,主流的有如下七种: XP XP(极限编程)的思想源自 Kent Beck和Ward Cunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化,XP无需开发...
  • 在十年前,没有人会想到互联网会发展成今天这个样子,同样,也没有人料到软件开发行业也会经历如此大的巨变,在开发这一行业,停下学习就等于死亡并不是危言耸听,不关注行业未来发展趋势的人可能错过了第一个十年...
  • [探讨]敏捷开发原则

    2012-07-17 11:38:55
    [探讨]敏捷开发原则 最近,“敏捷”、“敏捷开发”这类...一群开发经验丰富和才华横溢的开发人员通过关注其他公司和别的开发团队并且结合自身的项目经验,创建了敏捷开发宣言,让软件开发工作变的更容易更轻松:
  • 什么是敏捷开发1.1 敏捷开发的定义1.2 敏捷开发的原则1.3 敏捷开发的特点1.4 传统的开发模式和敏捷开发模式的对比1.5 敏捷开发的分类1.5 Scrum 一. 什么是敏捷开发 1.1 敏捷开发的定义 2001年,由Martin Fowler,...
1 2 3 4 5 ... 20
收藏数 13,310
精华内容 5,324
关键字:

敏捷开发 适合于项目类型