敏捷开发适合外包项目_软件开发项目外包 - CSDN
  • 同时也适合软件外包公司在本公司推行敏捷开发时参考。 定义这里的“外包”指广义的外包,包含了传统的欧美外包、对日外包,也包含国内以销售合同驱动的项目外包,如政府、银行、电信项目。由于整体上外包工程属于...

    本文是敏捷外包工程系列的第一篇。(之一之二之三之四

    本系列是中科院研究生院《软件工程硕士-外包方向》的《敏捷外包工程》课程的课外扩展阅读材料(本人是此课程讲师)。同时也适合软件外包公司在本公司推行敏捷开发时参考。

    定义

    这里的“外包”指广义的外包,包含了传统的欧美外包、对日外包,也包含国内以销售合同驱动的项目型外包,如政府、银行、电信项目。

    由于整体上外包工程属于管理活动,除了需求开发部分会借鉴XP的实践之外,本文所提到的“敏捷开发”一词多指Scrum方法。

    “敏捷外包工程”整体上包含两个部分:交易过程和交付过程,本系列中两者均有涉及,当前以后者为主,前者会较晚推出。

    前者包含市场宣传,客户接洽,合同商谈,计划制定,交付过程,交付后的培训,长期客户关系维护等内容。与产品研发相比,软件外包的交易过程尤为突出和重要,而由于敏捷开发本身不涉及这一过程的管理,因此需要配合其他方法来弥补。

    后者包括需求开发,需求管理,项目管理,变更管理,质量管理,交付管理等若干内容。与产品研发相比,两者的核心差异在于需求来源和变更管理。在产品研发中拥抱变化代表着更高的客户价值,而在外包项目中,拥抱变化或被变化拥抱,极可能导致项目成本加剧乃至项目无法按合同完成(虽然这并不代表“拥抱变化”彻底失去价值)。

    CMMI与敏捷

    软件外包公司一般规模较大,多数已经采用了各种管理方法,尤其以CMMI居多。

    与敏捷开发相比,CMMI是更专业的外包管理模型,因为它的初衷就是“为美国国防部选择和管理供应商设定标准”。此标准具有法律效力,按照国防部规定只有3级以上企业才可称为承包商。但也正因为有了“美国”“国防部”“标准”这些定语和中心词,导致我们在一般外包中使用CMMI会感到困难。

    但与此相比,敏捷开发无论从定语和中心词都相差更远,尽管这不会导致敏捷开发完全不适用,但实践者应充分理解外包开发环境中对敏捷提出的要求。

    管理和技术永远要服从于业务,从这一点上CMMI整体覆盖了部分业务和大多数管理和技术,而敏捷覆盖了部分管理和部分技术。笔者推荐以CMMI为整体模型,内部配合敏捷开发实践,而不是“用敏捷开发代替CMMI”

    本文今后系列中会较多提到CMMI与敏捷的平衡。本人在两个领域均有4年以上咨询经验,将力求适当、可行地将两者结合在一起。

    系列内容预告

    本文将大致包含以下内容,随着开发过程将有增减:

    团队结构,需求开发,变更管理,定额定期合同实施(可能稀释到各章节中),人才与微观活动管理等。

    中间可能邀请其他相关人士编写某些笔者缺少实际经验的章节,本人进行转贴或翻译,以保证系列的完整性。如IIOM(国际外包管理学院)中国总裁Chris Jiang的外包交易内容,曾在NASA从事测试管理工作的Jerry Durant的敏捷外包测试文章等。他们均同时具备敏捷、外包两个领域的深入知识和实际经验,以及其篇章中所涉及的专业知识。

     

    点击下载免费的敏捷开发教材:《火星人敏捷开发手册

     

    展开全文
  • Agile,敏捷开发被越来越多的开发企业和团队所接受。敏捷恰当,可以显著提高开发效率和产品的开发周期。问题是,“敏捷”方法是否能适用到软件外包行业,这个争论由来已久,各有说辞。最典型的争论就是,作为外包的...

    真么多装备还搞不定外包吗? Agile,敏捷开发被越来越多的开发企业和团队所接受。敏捷恰当,可以显著提高开发效率和产品的开发周期。问题是,“敏捷”方法是否能适用到软件外包行业,这个争论由来已久,各有说辞。最典型的争论就是,作为外包的一个显著特点,用户和开发团队是相对远程,甚至开发团队内部也存在远程的问题。如果一个团队不能身处一室,其中强调的沟通和互动是否能够得到有效的执行,是一个大问题。
    这个问题也是Taskcity一直致力于解决的课题。下面是我们的一些理解。
    传统的外包商业环境,是客户和服务提供方达成一个长期的合同,基于一个相对较长的阶段,提供稳定的外包服务支持。现在,越来越多的企业客户开始考虑将外包项目划分为小的可执行单位。风险可控,操作灵活。而服务提供方相对也达成了这个共识。其实,这两种情况,如果通过敏捷的开发模式,在一个长期的合作过程中,大家会发现,Agile不仅可行,而且的确能形成一个双赢的局面。一起来看看我们的发现吧。
     
    方法恰到好处
    如果我们追求看到一个项目完成的效率和效果,敏捷开发其实优于传统的开发模式,即便对于初次接触这个概念的发包客户亦如此。我们大家都知道,在很多情况下,发包客户和服务提供方在涉足将项目外包出去开发之前,都拥有自己比较熟悉的开发模式和方法。敏捷开发或者说增量开发,可以让双方很轻易的统一到一个接口。传统的开发方法基本上都是基于一个反复推敲的合同,合同中对于功能设计以及权利义务定义原则上都进行了仔细的定义。但是,根本的问题是,很多用户在项目开始前,甚至开始的初期都没有一个明确的,或者说准确的描述。这样,很多时候,客户为了保护自己的利益,会尽可能多的添加功能到这个项目书中。而开发服务提供方考虑的是如何在自己的成本控制内得到尽可能多的盈利。在一开始,其实就为双方日后的纠纷埋下了种子。我们能看到,在传统的开发外包中,相当比例的项目最后,即便完成交付,完成支付,最后双方的心情都是不太好。敏捷开发强调了阶段性交付,增量开发,用户互动。最后的交付物有时和原始的设计已经有了很大的出入,但是客户贯穿了整个开发的周期,了解了所有的变动以及缘由,其满意度甚至超过一个100%吻合的交付结果。用户的满意度和开发完成的代码量不是直接的因果关系。而在软件外包行业中的同行们都知道,一个满意的客户意味着可能的后续项目,而这也是服务提供方最希望看到的结果。
     
    沟通的威力
    肖伯纳有一句名言“England and America are two countries divided by a common language。”意思是英国和美国是被一个相同的语言所分隔的两个国家。这里不是指的地理上的分隔,而是文化沟通上的差异,即便他们都说一种语言。英美尚如此,何况作为一个典型东方文化代表的中国和我们的欧美客户呢?不同的时区,不同的文化,不同的工作方法和原则,导致沟通成为了我们进行海外外包的一个瓶颈。敏捷开发既强调了沟通,又为顺畅的沟通提供了方法和指导。其中持续的交付实际是在用实实在在的形式进行了项目的沟通,从而降低了最后的交付风险。想想吧,作为传统开发模式,比如一个瀑布式的开发,六个月后,客户才能第一眼看到自己想要的产品,这里面能产生错愕的概率有多大,大家可以想象一下。
     
    迭代是趋于完美的过程
    罗马不是一天建成的。不要尝试对完美的一步到位,除非你的用户愿意牺牲宝贵的进入市场的时机。外包开发不象是一个公司内部的开发团队的管理模式,对于离岸外包而言,双方远隔万里。所以我们的建议就是,只用尽最大可能不断地从客户那里得到进程中的反馈,进而对开发加以修正,才不会出现最终和用户意愿的大偏差。在双方可以接受的情况下,定义一个一个短促有效的迭代过程,第一时间发现问题,放到下一个迭代中去解决。一个典型的迭代包括计划-设计-反馈-执行(PDCA)。
     
    勇于面对改变
    需求变更在整个软件开发的生命周期中是一个永恒的话题。也是客户与服务提供方最纠缠不清之所在。改变的导火索可以来自方方面面,既有可能是一觉醒来后的灵光一现,也有可能是来自客户外部商业环境的改变。既然是现实,就接受它吧。当然,处理得当,这种变化可能协助双方得到一个更优秀的软件,也能让客户对你的快速应变产生好感。否则,如果固守原始的设计稿件,或者永远作为一个新功能要求追加资金,有可能得到一个Case,却失去一个用户。另外,我们总是陷在一个自己预设的陷阱里,客户的要求改变永远是对功能的增加。其实,一个过程中的再设计,有可能会降低开发的成本。
     
    质量保证,真的吗?
    听起来像是玩笑。敏捷开发这种快速交付,还能保证质量,象是天方夜谭。其实不然。快速交付,让用户能够尽快试用你的功能,尽快发现问题,就整个开发周期而言,整体质量一定会得到提升。在传统开发模式中,我们都会或多或少遇到这样的情况,因为开发时间的拖延(总是会拖延,这不可是玩笑!),测试时间永远是第一个被压缩的阶段。结果可想而知。更多的迭代引入了更多的测试周期和时间。
     
    和Taskcity一起来“敏捷”吧!
    当然,在具体执行的技巧中,在外包行业或国际外包项目中引入敏捷的开发思想,还有一些需要注意的地方。但是,远隔重洋的地理分离,如果再加上在开发流程中的用户与开发方的长期“分居”,结果就会是这样 :没有一方会满意。所以在Taskcity(给个链接)平台,我们从一开始就确定了在我们的在线项目管理工具和协同工作工具中引入敏捷的思想和原则。我们的海外Buyer用户到目前在项目的评价中都保持了一个惊人高的满意度,首先是Taskcity平台Provider用户的用心,从我们的反馈看,和我们的在线敏捷项目管理工具也是密不可分的。

     

    原文地址 http://blog.taskcity.com/?p=40

     

    展开全文
  • 先说明一点:这里的“敏捷”是指甲乙双方配合的“敏捷”,而不是说外包项目本身内部不合适“敏捷”。 先说一下背景,项目时间太紧,工期是由商业谈判决定的,没有及时评估工作量,做着做着产生delay,先试图简单...

    前几个月尝试做了PM(这次是Project不是Product了),亲身经历了一个项目是怎样一步步不顺下去的。先说明一点:这里的“敏捷”是指甲乙双方配合的“敏捷”,而不是说外包项目本身内部不合适“敏捷”。

    先说一下背景,项目时间太紧,工期是由商业谈判决定的,没有及时评估工作量,做着做着产生delay,先试图简单的用加班的方法赶上进度,后来被迫注入“敏捷”项目方法,但事后发现“项目外包”模式不适合敏捷。

    首先,项目外包使得甲方不愿意砍需求。为了敏捷灵活,公司内部的项目需求在很大程度上是可以砍的,是“保质不保量”,这是符合敏捷的原则的。但是项目外包,甲方在提需求的时候不愿把任何一个功能像平时那样推到2期做,因为项目结束后2期在哪里都不知道,所以“保质保量”变成了“不保质保量”。

    其次,敏捷必然导致文档工作不细致,甲方游离于项目之外的“验收测试”模式难以适应。敏捷从模式上会导致提交测试的产品和最初的需求之间必然有很多变化,并且文档很难跟上,而这种敏捷在公司内部之所以运行的很好,是因为PD、开发、tester在项目过程中可以充分交流,testerTCTest Case)评审的时候会叫上PD和开发,有些属于详细设计的细节是在评审的时候与开发直接确认,在测试执行过程中也会协助确认需求细节并迭代测试。而项目外包的时候,甲方会从一份颗粒度过粗的需求文档上派生出“验收测试”的TC,又因为验收有“考试”的性质,所以不允许乙方的开发参加甲方的TC评审,导致只能和甲方需求人员确认细节,而需求人员对如此细节又没有要求,无奈之下只能按照自己的想法说,必然导致两边对需求的理解有鸿沟。另一方面,验收测试是一次性的,只有passfalse的结论,没有迭代的过程,不符合敏捷的思想。

    最后,乙方没有“敏捷”的经验和意识。一般甲方没有独立软件研发能力才选择项目外包(否则多用开发外包),职业性质/国内的项目管理现状决定了外包工程师的习惯是按照详细的设计文档开发/测试,抗拒需求改变,所以强行“敏捷”会导致失控。因为没有一份完整的详细设计文档,开发人员会按照自己的想法编码,测试人员也照自己的想法测试,没有做TC评审的意识,加之没有和需求人员即时沟通反馈的习惯,没有一个迭代的过程,再为了工期的死命令削减测试强度,结果就是发现做的与需求不符的时候已经晚了。

    很多原因共同造成不好的结果,还有些没说,总结下来就是不能再这么做了,对敏捷的理解很粗浅,欢迎指正。

    展开全文
  • 敏捷外包的14条原则

    千次阅读 2009-05-06 16:18:00
    本文将基于实际项目经验以及丰田公司的制造过程,讨论如何把外包变成一种成功的模式,我们将这种方法论称为 “精益敏捷外包”。 我们的目标是利用当地的广阔人力资源,更加高效、迅速地交付软件。鉴于Scrum和

    文/Vikas Hazrati 译/金欣亮

    虽然软件项目的外包趋势已经是一个不争的事实,但是还是有很多项目由于错误的外包而失败了。抛开诸多优势不谈,软件外包确实带来了额外的复杂性、风险以及消耗。本文将基于实际项目经验以及丰田公司的制造过程,讨论如何把外包变成一种成功的模式,我们将这种方法论称为 精益敏捷外包”。

    我们的目标是利用当地的广阔人力资源,更加高效、迅速地交付软件。鉴于Scrum和丰田模式在开发新产品上的成功表现,我们决定采用它们来进行外包项目管理。丰田原则可以很好地被应用到任何软件开发项目中。我们将在下面讨论丰田模式,以及如何使用这些原则让我们的外包过程“精益”起来。 这种保留了Scrum和丰田模式的工作方法,帮助我们每天都在提高。

    采用此方法开发的项目,是一个中心社会保障机构的批处理系统。系统的工作流程是从税务部门获取老板和雇员的数据,校验这些数据,然后生成某人某一个阶段的收入申报资料。系统每个月要处理1600万条数据记录,每秒钟大约50条数据。

    原则1:制定一个长远的价值观,并且坚持下去

    我们开始外包项目的时候,心中存在一个信念:我们不仅仅是为了这一个外包项目而工作,而是心中有一个长远目标:通过努力,让我们成为最好的敏捷公司,并且拥有稳定的、可重用的外包模式。这种模式可以使得整个软件行业受益。我们不会采取任何危及项目质量的捷径。 我们会积极创新,改进工作方式,提高整个行业的敏捷外包项目成功率。

    原则2:创建连续的工作流程,使问题浮出水面

    我们决定全面采纳敏捷实践,并且不遵从任何以计划驱动的方法论。然而,没有计划很容易迷失方向,因此频繁的交流和持续集成就变得至关重要。我们定期派遣专员进行跨越地域的旅行,让业务知识和上下文不受地域的限制,通过电话和网络进行指导,并建立和加强信任关系。 沟通不是问题,因为我们的通讯工具时刻在线,拿起麦克风就可以跟远方的团队交流了。 对于多个地点的开发,我们都采用统一的代码库并进行持续集成。这样问题很快就能浮出表面,并很快得到妥善的解决。

    原则3:使用模式来避免过度生产

    依照上面的原则,我们决定采用利益相关者来“拉”的模式,而不是让团队去“推”。毕竟我们的意图是编写具有商业价值的代码,而不是为了完善代码库。如果“拉力”不是很强,我们就减少迭代的大小,或者利用剩余的时间进行重构,以提升开发过程和交付的质量,确保我们高质量地满足客户的需求。

    原则4:平准化(heijunka

    丰田提出要减少资源的浪费(muda)、人员的过劳(muri)和分工的不均(mura)。 在外包项目中,它们的表现形式为:不必要的功能、过度的需求、在客户和团队间额外的抽象层;寻找不相关的信息;测试没能找出缺陷;与客户低效率的沟通。我们要谨记这些,它们是外包项目中最大的浪费。

    在实际项目中,为了去除浪费,我们只开发本次迭代的用户故事,使用的故事卡片上也仅仅记录了足够开发使用的信息;我们根据用户故事进行编程,为了澄清业务细节,即使是离岸团队也可以直接跟客户取得联系;不管是开发人员测试还是客户测试,我们都秉承测试优先的做法。为了确保工作的平准化,我们总是根据团队的速度来衡量工作,并确保完成的用户故事数量没有不平衡的趋势。在软件项目中,使团队成员精疲力竭是最有害的行为!团队的速度决定了团队的工作量以及每个人的工作内容。

    原则5:建立停下来解决问题的文化(自动化)

    我们文化的提倡:如果产生了影响交付质量的问题,团队就要停下手中其他的工作并解决这些问题。

    如果客户处的离岸团队觉得沟通效率低下,那么我们就用专门的机器来安装skype,并保持一直在线。使用skype提供的语音和在线视频聊天功能来相互沟通。一旦团队觉得sprint评估效率太低,没有达到当初预期的目标,那么我们会中止评估,进行头脑风暴,讨论如何才能做的更好,并按照一个既定的日程来指导我们减少在代码审查上花费的时间。 如果在持续集成或者性能测试环境设置上有问题,那么我们就要停下来修复它们,然后再进行其他用户故事的开发。 如果我们完成了很多用户故事,但是功能测试人员没有来得及进行测试,那么我们就等所有已开发的用户故事得到测试团队认可,然后再来开发新的用户故事。

    所有这些这不仅仅是对策,也是预防措施。

    原则6:标准化过程

    标准化是支撑持续改进、雇员授权、规章制度和过程的基础,同时是支持组织学习的架构。我们创建的标准流程包括:使用TDD的开发、问题跟踪和解决、构建和测试等等。这并不是说这些流程都是一成不变的,它们一样是灵活且敏捷的。这些标准可以确保我们拥有稳定的平台,而且这个平台可以被团队不断完善。

    原则7:使用可视化的管理来避免隐藏的问题

    我们的格言是:每一件事情对团队成员都应该是可视的,当然对客户也是如此。

    我们在Jira里面为客户现场和离岸团队创建了公用的产品功能清单,公用的燃尽图和问题日志。客户可以使用它来了解产品的问题,甚至查看我们每天的详细状态。使用Cruise Control可以让我们方便地了解构建的状态。每次构建结束,一个小兔子玩具会报告构建的成功与否。

    墙和白板可以向客户展示足够的信息。他们可以走到墙或者白板面前,10分钟的时间,他们就能获得足够的信息。

    我们还在wiki上创建了一个虚拟的团队公告板,把所有的可视化信息都保存进去。之后把有用的打印出来,贴到团队的墙上。

    原则8:采用适合团队成员和过程的技术

    正的精益项目有2个关键特性:其一,它传递给开发人员最大数量的任务和职责,从而生产出有业务价值的产品。其二,它有着一个缺陷跟踪流程,保证在缺陷发生时立即处理。

    一个敏捷团队最重要的资产是团队成员,我们应该让团队成员采用最适合的技术而不是听从某些技术鼓吹者的最佳实践。例如,我们把整个表现逻辑从Struts迁移到Spring MVC,是因为后者在当前的背景下更加实用,并且这个迁移的决定是由整个团队共同提出的。当团队拥有自主权的时候,也是他们能够做出最好的决定和承诺的时候。自组织的团队知道如何采用适合的技术和流程来适应每一个成员。

    原则9:从团队内部发掘领导者

    人比体制更重要已经是广为人知的概念。 我们致力于从团队内部来提拔外包项目的领导者。我们会让客户现场或者离岸团队中的一部分人去参加Scrum master培训,而不是从其他地方请来Scrum master。毋庸置疑,这些人肯定是最了解团队的人。

    原则10:发掘杰出的团队成员

    障碍的沟通、高效的团队协作、形式追随功能的团队、良好的收入、顶级的工具、舒适的工作环境、劳逸结合的生活、持续的进步、岗位的轮换。 所有的这些在正确的精神指导下,将会创建明星团队。

    对于一个高效的跨地区团队而言,健康的交流是核心。为此,我们在项目早期会有很多探访,目的是创建良好的关系,然后用定期的探访来维持这种关系。

    提出问题、谈论困难、担心无法按期限完成工作,或者对于来自上级的指令给出不同的解决方法。人们经常因为这些行为遭到责难。使团队变得更加积极主动是一场艰苦的战斗,需要花费很多的时间。因此我们鼓励多问问题 一旦人们意识到他们有自由,同时也有责任来做决定的时候,他们会进一步做出贡献,并因此成为杰出的团队成员。

    原则11:与合作伙伴和供应商建立长期的合作关系

    公平和互相尊重的商业关系,是和合作伙伴和供应商长期合作的关键。 我们根据这个精神对客户公开wikiJira,同时也对负责该项目其他模块的软件商公开。 这可以使我们清楚了解谁在做什么,并且能够同利益相关者和供应商一起来制定明确的期望。 这样做的好处是:我们建立了信任关系,保持了透明度,而且没有隐瞒任何事情。

    这不仅仅提升了我们外包的可信度,从长远来看,能为软件行业提供一个扩大合作伙伴的成功实践,对软件行业来说也是有积极帮助的。通过燃尽图Sprint迭代的记录,我们与合作伙伴互相了解和学习。

    原则12:身体力行

    亲临现场是了解真实的情况的最佳方式。所以我们团队中没有只说空话的设计师和架构师。无论他曾经担任过什么其他的角色,每个人都要写代码,这没什么可商量的。 这有助于我们条理分明地为自己和他人分派任务,根据实际的资料请教专家,分析并理解当前的形势以及解决方案。

    原则13:充分评估各种方案,达成共识之后迅速执行

    们积极地遵循一条原则:在充分考虑各种方案之前,不会选定任何方向。但是一旦我们选择了正确的道路,我们就加速并且持续地走下去。

    好几次我们都试图对各种各样的issues寻求替代解决方案,比如如何使外包团队理解荷兰语文档。我们应该手动翻译还是使用一个能翻译60%内容的工具?最后我们决定让荷兰团队根据他们的文档在Jira上创建一些issue,离岸团队来研究这些issue,并且对此进行提问。这种方法非常迅速并有效。

    原则14:通过深刻的反思和持续的改进,成为好学的组织

    正是这条最重要的原则帮助我们达到了今日的高度。我们执行严格的迭代评价,深刻反思,对好的方面进行坚持,对可以提高的地方进行改善,从而使得迭代越来越好。我们渴求不断地且及时地征求客户和团队的反馈,从而高效地达到软件的最终目标。 除此之外,当遇到任何问题的时候,我们会一直询问“为什么”5次,直到弄清了问题的根源为止。

    总结

    在本文的最后,我想说:“我们仍然还在学习”。“精益生产”已经被成功地应用于软件外包行业,但是仍然可以改善。丰田原则一旦应用于软件外包,将会给现有的软件外包模式带来显著的变化。我们将会通过不断的改进,最终达成我们的目标——白盒精益敏捷外包。这种模式下外包的透明度和质量都将会达到极致。

    最后对外包行业提一个建议:在遵循Scrum和丰田原则的时候,不要试图稀释其中的“精华”,把它们应用到你的工作上去,然后等着奇迹发生吧。

    展开全文
  • 需求的不可预见性 每一个我项目都会听到这样的小插曲,开发人员“项目最大的问题就是需求总是变化”,让人感到惊异的是任何人对此都表示不适应;在开发商业软件的过程中,变更是正常的,问题是我们如何面对它。 一...
  • 转载至:http://developer.51cto.com/art/200909/151058.htm
  • 传统认为敏捷开发是面向产品研发的,在外包项目里边比较难用,因为需求由客户牵制,而“拥抱变化”极有可能导致项目延期超支,等等。本文提及了敏捷开发外包项目的帮助,以及如何利用功能点估算和度量防止出现超支...
  • 同时也适合软件外包公司在本公司推行敏捷开发时参考。 定义这里的“外包”指广义的外包,包含了传统的欧美外包、对日外包,也包含国内以销售合同驱动的项目外包,如政府、银行、电信项目。由于整体上外包工程属于...
  • 敏捷给产品开发带来的价值已经日益被软件开发业界所认可,从几个人的创业公司到几十万人的跨国企业,...在11月7日召开的Agile Singapore大会上,来自挪威PROMIS公司的Trond Åsheim展示了一种适合敏捷开发的合同模式...
  • 在诸多方法中,敏捷开发以其能持续满足不断变化的用户需求正在受到越来越多人的重视,从中小项目开始进入大型开发项目,近几年来上升势头明显。那么,敏捷开发有什么好处呢?    在软件工业界,敏捷开发已成为众多...
  • 先说明一点:这里的“敏捷”是指甲乙双方配合的“敏捷”,而不是说外包项目本身内部的开发过程不合适“敏捷”。 先说一下背景,项目时间太紧,工期是由商业谈判决定的,没有及时评估工作量,做着做着产生delay,先...
  • 所谓敏捷开发与瀑布开发0.写在前面1.常见的开发模式2.什么是敏捷开发?2.1 敏捷开发宣言:2.2优点:2.3 确点:3.什么是瀑布开发?3.1 优点:3.2 缺点: 0.写在前面 项目管理者面临的一个大BUG是:程序员开发的是客户...
  • 外包合同常常是固定价格固定工期固定需求(一般称为定额合同),这个时候“拥抱变化”的敏捷感觉意义不大,那么敏捷开发是否就无用武之地了呢?其实不然。下面的一些用法,是利用敏捷开发来促进这种固定合同的达成。...
  • 项目流程之敏捷开发

    千次阅读 2018-07-20 10:41:17
    大家好,我是IT修真院深圳分院第8期的学员,一枚正直纯洁善良的PM,今天给大家分享以下知识点是修真院pm任务十一中的项目流程之敏捷开发的小技巧 正常产品项目流程: 可以是产品经理创造需求;可以是“灵光一现”;...
  • 敏捷开发有什么好处?

    万次阅读 2013-08-19 18:17:04
    在诸多方法中,敏捷开发以其能持续满足不断变化的用户需求正在受到越来越多人的重视,从中小项目开始进入大型开发项目,近几年来上升势头明显。   在软件工业界,敏捷开发已成为众多高效开发团队的制胜之道。在欧美...
  • 敏捷开发 以人为核心、迭代、循序渐进的开发方式 简化文档,提取文档重点,主要在于人与人之间的沟通, 对开发产品进行迭代,最终完成开发。 迭代:迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小...
1 2 3 4 5 ... 20
收藏数 4,890
精华内容 1,956
关键字:

敏捷开发适合外包项目