2011-07-21 12:59:25 cheny_com 阅读数 12604
  • 软考项目管理知识实战(下)

    软考的高项和中项的学习课程,课程避免枯燥的理论,注重项目实践,将会有很多“书本外”的知识。下部内容有:成本管理、质量管理、人力资源管理、沟通管理、采购管理、外包管理、合同管理、配置管理、法律法规、职业道德和专业英语。

    26069 人正在学习 去看看 张传波

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

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

定义

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

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

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

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

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

CMMI与敏捷

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

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

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

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

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

系列内容预告

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

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

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

 

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

 

2019-02-24 09:58:38 hdfyhf 阅读数 88
  • 软考项目管理知识实战(下)

    软考的高项和中项的学习课程,课程避免枯燥的理论,注重项目实践,将会有很多“书本外”的知识。下部内容有:成本管理、质量管理、人力资源管理、沟通管理、采购管理、外包管理、合同管理、配置管理、法律法规、职业道德和专业英语。

    26069 人正在学习 去看看 张传波

分享一下我老师大神的人工智能教程。零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到我们人工智能的队伍中来!https://blog.csdn.net/jiangjunshow

               

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

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

定义

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

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

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

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

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

CMMI与敏捷

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

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

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

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

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

系列内容预告

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

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

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

 

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

 

           

分享一下我老师大神的人工智能教程。零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到我们人工智能的队伍中来!https://blog.csdn.net/jiangjunshow

2012-06-25 18:21:54 iteye_14109 阅读数 319
  • 软考项目管理知识实战(下)

    软考的高项和中项的学习课程,课程避免枯燥的理论,注重项目实践,将会有很多“书本外”的知识。下部内容有:成本管理、质量管理、人力资源管理、沟通管理、采购管理、外包管理、合同管理、配置管理、法律法规、职业道德和专业英语。

    26069 人正在学习 去看看 张传波

     软件开发方法一直处在不断发展过程中。在诸多方法中,敏捷开发以其能持续满足不断变化的用户需求正在受到越来越多人的重视,从中小项目开始进入大型开发项目,近几年来上升势头明显。那么,敏捷开发有什么好处呢?

 

    在软件工业界,敏捷开发已成为众多高效开发团队的制胜之道。在欧美软件企业中,有近半数企业已采用敏捷方法进行开发,而近几年受软件外包和外企的带动,敏捷开发在中国也出现了日渐普及的态势,如腾讯内部几乎所有的开发团队都在实施敏捷方法。敏捷开发的流行绝非偶然,其最大的推动力是采用这种方法所能带来的受益。相关统计表明,敏捷开发可以将效率提高3~10倍,软件的质量也有更加可靠的保证; 同时,还给团队内的每个成员提供了良好的发展机会,技术和合作水平都能得到相应提高。当然,敏捷的成功前提是其方法本身的适用性和团队对它的深入理解和合理运用。
 
    敏捷开发由几种轻量级的软件开发方法组成,包括极限编程、Scrum、精益开发(Lean Development)、动态系统开发方法、特征驱动开发(Feature Driver Development)、水晶开发(Cristal Clear)等等。所有这些方法都具有以下共同特征,它们也是敏捷开发的原则:

    1. 迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期持续的时间一般较短,通常为1到6周。

    2. 增量交付。产品是在每个迭代周期结束时被逐步交付使用,每次交付的都是可以被部署、能给用户带来即时效益和价值的产品。

    3. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。

    4. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。有些是在每个迭代周期结束的时候集成, 有些则每天都在这么做。

    5. 开发团队自我管理。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。
 
    敏捷开发的优势:

    满足用户不断变化的需求是软件开发的长期无法解决的难题之一,经典的瀑布模式在一个迭代周期内表现优异,但一旦需求变化,瀑布模式却显得无能为力。敏捷方法满足需求的办法主要通过迭代。在每一次迭代周期结束时,都能交付用户一个可用的、可部署的系统,用户使用并体验该系统并反馈意见,在随后的迭代周期这些意见和需求的其他变化一起在产品中实现和集成。每次迭代周期应尽可能短,以便能及时地处理需求变化和用户反馈。
 
    敏捷开发方式能给企业和用户带来以下好处:

    1. 精确。瀑布模式通常会在产品起点与最终结果之间规划出一条直线,然后沿着直线不断往前走。然而当项目到达终点时,用户通常会发现那已经不是他们想去的地方。而敏捷方法则采用小步快跑,每走完一步再调整并为下一步确定方向,直到真正的终点。

    2. 质量。敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如极限编程等,甚至使用测试驱动开发(test-driven development),即在正式开发功能代码之前先开发该功能的测试代码。这些都为敏捷项目的整个开发周期提供了可靠的质量保证。

    3. 速度。敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外,较短的迭代周期使团队成员能迅速进入开发状态。

    4. 丰厚的投资回报率。在敏捷开发过程中,最具价值的功能总是被优先开发,这样能给客户带来最大的投资回报率。

    5. 高效的自我管理团队。敏捷开发要求团队成员必须积极主动,自我管理。在这样的团队中工作,每个团队成员的技术能力、交流、社交、表达和领导能力也都能得以提高。
 
    主要的敏捷方法:

    敏捷开发方法是一组开发方法的统称,主要包括以下几种:

    极限编程其主要目的是降低需求变化的成本。它引入一系列优秀的软件开发方法,并将它们发挥到极致,结对编程(pair-programming)就是其中比较知名的方法之一。除此之外, 其核心做法还有小规模、频繁的版本发布、短迭代周期、测试驱动开发、持续集成、每日站立会议、共同拥有代码、系统隐喻等。

    Scrum Scrum是一个敏捷开发框架,它由一个开发过程、几种角色以及一套规范的实施方法组成。在Scrum中,产品需求被定义为产品需求积压(product backlogs)。所有的产品需求积压都是从一个简单的想法开始,并逐步被细化,直到可以被开发的程度。Scrum将开发过程分为多个Sprint周期,每个Sprint代表一个2~4周的开发周期,有固定的时间长度。

    精益开发精益开发的核心思想是查明和消除浪费。在软件开发过程中bug、没用的功能、等待以及其他任何对实现结果没有益处的东西都是浪费。浪费及其源头必须被分析查明,然后设法消除。精益开发的其他原则包括强调学习、在最后时刻做决定、用最快的速度交付用户等。

    其他敏捷方法还包括动态系统开发方法(DSDM)、特征驱动开发(FDD)、Crystal Clear等,各种敏捷方法的区别在于它们对敏捷的不同阐释和不同侧重。理解这些方法可以帮助我们从多个角度理解敏捷开发,并且了解更多的最佳应用。
 
 
如何选择一种敏捷方法:

    选择一种合适的软件开发方法取决于多种因素。在做出决定之前,我们需要充分考虑以下这些方面:

    1. 方法的复杂度。确保你的团队或组织能够应付这种复杂度。

    2. 社区和业界支持。有较多的社区及行业支持可以使你受益匪浅。

    3. 实用工具。一个良好的软件工具可以帮助团队有效地处理日常工作,促进团队协作,并减少管理成本。

    4. 对敏捷方法的认识程度。选择一些与你当前开发方式比较接近的敏捷方法将有助于推动该方法的实施。

    5. 你的团队规模。较小规模的团队最好从简单的方式入手。

    6. 你不需要只遵从一种方法。你可以为团队选择一个主要的方法(如Scrum),然后借鉴其他方法。

 

2012-05-13 15:08:02 cheny_com 阅读数 8370
  • 软考项目管理知识实战(下)

    软考的高项和中项的学习课程,课程避免枯燥的理论,注重项目实践,将会有很多“书本外”的知识。下部内容有:成本管理、质量管理、人力资源管理、沟通管理、采购管理、外包管理、合同管理、配置管理、法律法规、职业道德和专业英语。

    26069 人正在学习 去看看 张传波

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

本文是2012年05月初IIOM(国际外包管理学院)的专访。传统认为敏捷开发是面向产品研发的,在外包项目里边比较难用,因为需求由客户牵制,而“拥抱变化”极有可能导致项目延期超支,等等。

本文提及了敏捷开发对外包项目的帮助,以及如何利用功能点估算和度量防止出现超支。

原文位置:http://www.int-iom.cn/int/members-area/2011-11-23-02-00-48/item/328-cy-zf

欢迎报名参加2012-06-01的相关研讨会,联系方式在上述链接的末尾。

原文拷贝:

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

陈勇:外包与敏捷开发专访(IIOM独家专访) 推荐

iiom-cy陈勇老师作为国内外包与敏捷开发专家,具有丰富的工程技术与项目管理实践经验,擅长在各种实际场景中灵活运用各种实践,并可提供敏捷开发、早期软件成本估算等公开课、扩展咨询和实践指导活动;曾参与多种模型的实践/咨询和培训工作,如CMM/CMMI、敏捷(Scrum)、功能点FPA、早期软件成本估算等,并能将多种模型融会贯通。

日前IIOM独家专访国内外包与敏捷开发专家陈勇老师,以下为采访内容:(问:IIOM记者 答:陈勇老师)

问:最近越来越多的海外发包商在在招标时要求供应商具备敏捷开发的能力,您怎样理解这一趋势?

答:这一趋势,首先表明海外发包商在寻找新的供应商的时候更加谨慎,希望利用敏捷开发的短期迭代来及早判断供应商的能力;其次表明他们对于利用敏捷开发中的尽早交付来保证项目不会中途被取消;最后还应该归于越来越多的外包应用发生在互联网、移动应用领域,其固有的特性要求快速交付产品。

问:为什么之前的发包商更看重CMMI,而最近则很倾向于敏捷开发?

答:在大约10年前的外包中,主要的发包商是类似美国国防部之类的大型政府企业、制造业,而开发的软件也比较大,因此出现了一批与之对应的大型外包企业如印度的InfoSys等,而这些企业凭借CMMI来证明自己的实力,也就不足为奇,因为CMMI本质上说是美国国防部对供应商的招标的资质标准。

而最近的业界趋势,则是移动互联网、SNS等应用,这些应用的价值观不是“有序地开发”,而是“迅速、创新地开发”,业务上的差异造成了更加追求短周期、持续交付这些敏捷开发的价值观。

问:上面说的都是甲方的需求,作为乙方,尤其是中国的乙方,能从敏捷开发中获得什么呢?

答:首先是机遇。以往有印度、菲律宾这些外包大国围绕,中国的外包很难开头,因为很多发包商都觉得中国是个“陌生的市场”,与其承担巨大的风险,不如继续与传统外包国家打交道,尽管其成本在不断上升。敏捷开发的快速短期迭代,使得发包商的“试水”工作变得不再那么可怕,这是我们打开外包渠道的一次机遇。

其次是更丰厚而合理的利润。在以往,由于中国本国的发包方多数比较强势,中间追加需求而不增加金额的情况非常普遍,而国外的发包商相对通融。比如我就去过有一家欧美外包企业,他们曾经因为甲方变更负责人而发生了很多的需求变化,但最后双方核实后,追加了相应的金额。

问:追加价格的时候,如何核实数额呢?

答:这个就要谈到报价模式。

在国外用功能点报价已经逐渐是一个常态了,澳大利亚、芬兰、荷兰、意大利、日本、韩国等国的政府招标,很多都是采用功能点报价。尽管在中国鲜为人知,但在全球有多达6000人的CFPS(认证的功能点专家),在从事各种报价和度量活动。

功能点方法迄今为止已经形成了5个ISO国际标准,其核心思路是:利用一个公认的方法来衡量软件的规模,然后再乘以单价,来测算项目的报价。这个可能不符合国内外包中甲方先有预算后招标的习惯,但是却很符合海外发包商的相对单纯的“商品交易”的心理。

比如就曾经有海外发包商要求接包方报价,并必须说明报价的依据,结果国内无一企业能做到。失利的原因是多方面的,其中一个方面是当时没有可行的方法能在项目早期快速从有限的客户文档中判断项目的规模。

针对这类问题,后来我主笔编写了造价估算的行业协会标准,引入了NESMA(荷兰的功能点组织,同时也是世界第二大功能点组织)的快速功能点估算方法,在国内发包的项目中做的测算是每一人年左右的工作量仅需一张A4纸即可描述清楚,培训后每人天可完成4000~6000功能点需求的估算(大约合20~30人年的开发量),20多个历史项目的回归数据表明其精度在15~20%左右(大于和小于此数据的项目数各占一半)。

问:敏捷开发与这种造价管理有何关系呢?

答:尽管在项目初期只凭借几十页纸能完成20~30人年开发量的估算已属难得,但15~20%的误差对于固定单价合同还是有点粗糙。最佳方法,是与客户签署固定单价的合同,然后在几个短周期迭代后,定期实际计数一下功能点的数量,与用户结帐,这样非常适合长期项目的阶段性结帐。

尽管听起用 单价×实际功能点数 = 总价 结帐很不可思议,但实际上澳大利亚政府就是用这种方法,只是他们并不要求迭代交付;芬兰政府的一些项目也采用类似的方法结帐。北欧最近一直在推行Northen Scope方法和工具,目的就是为了推进按规模估价、结算的方法。

如果配合敏捷开发方法,在一个或多个短周期迭代后,按交付的功能数量进行结算,则无论对甲方乙方都是有利的。对甲方而言,可以按照乙方实际完成的功能结算,因而无需事先定义完整的需求(在移动互联网行业几乎是不可能的),而可以中途提出新需求;对乙方而言,新需求也是付费的,“拥抱变化”成为一件有利可图而非避之不及的事情。

在这种新语境下,合作从僵硬地“履行合同”变成双方一起思考:哪些需求是值得开发的?有什么新需求胜过之前的计划因而能提升市场竞争力?这些正是甲方的利益所在,而乙方通过对甲方这种利益的满足,自己也能赢得客户。

陈勇老师6月1日将在北京进行敏捷技术的专题分享培训课程,敬请关注!http://edu.int-iom.cn/yanxiuban/

报名联系方式:

0510-81010237

本文为IIOM中国(官网:http://www.int-iom.cn)独家专访,转载请注明文章来源,违者将被追究法律责任。

2012-05-08 10:55:00 valzepingtang 阅读数 6045
  • 软考项目管理知识实战(下)

    软考的高项和中项的学习课程,课程避免枯燥的理论,注重项目实践,将会有很多“书本外”的知识。下部内容有:成本管理、质量管理、人力资源管理、沟通管理、采购管理、外包管理、合同管理、配置管理、法律法规、职业道德和专业英语。

    26069 人正在学习 去看看 张传波

陈勇老师作为国内外包与敏捷开发专家,具有丰富的工程技术与项目管理实践经验,擅长在各种实际场景中灵活运用各种实践,并可提供敏捷开发、早期软件成本估算等公开课、扩展咨询和实践指导活动;曾参与多种模型的实践/咨询和培训工作,如CMM/CMMI、敏捷(Scrum)、功能点FPA、早期软件成本估算等,并能将多种模型融会贯通。

日前IIOM独家专访国内外包与敏捷开发专家陈勇老师,以下为采访内容:(问:IIOM记者  答:陈勇老师)

问:最近越来越多的海外发包商在在招标时要求供应商具备敏捷开发的能力,您怎样理解这一趋势?

答:这一趋势,首先表明海外发包商在寻找新的供应商的时候更加谨慎,希望利用敏捷开发的短期迭代来及早判断供应商的能力;其次表明他们对于利用敏捷开发中的尽早交付来保证项目不会中途被取消;最后还应该归于越来越多的外包应用发生在互联网、移动应用领域,其固有的特性要求快速交付产品。

问:为什么之前的发包商更看重CMMI,而最近则很倾向于敏捷开发?

答:在大约10年前的外包中,主要的发包商是类似美国国防部之类的大型政府企业、制造业,而开发的软件也比较大,因此出现了一批与之对应的大型外包企业如印度的InfoSys等,而这些企业凭借CMMI来证明自己的实力,也就不足为奇,因为CMMI本质上说是美国国防部对供应商的招标的资质标准。

而最近的业界趋势,则是移动互联网、SNS等应用,这些应用的价值观不是“有序地开发”,而是“迅速、创新地开发”,业务上的差异造成了更加追求短周期、持续交付这些敏捷开发的价值观。

问:上面说的都是甲方的需求,作为乙方,尤其是中国的乙方,能从敏捷开发中获得什么呢?

答:首先是机遇。以往有印度、菲律宾这些外包大国围绕,中国的外包很难开头,因为很多发包商都觉得中国是个“陌生的市场”,与其承担巨大的风险,不如继续与传统外包国家打交道,尽管其成本在不断上升。敏捷开发的快速短期迭代,使得发包商的“试水”工作变得不再那么可怕,这是我们打开外包渠道的一次机遇。

其次是更丰厚而合理的利润。在以往,由于中国本国的发包方多数比较强势,中间追加需求而不增加金额的情况非常普遍,而国外的发包商相对通融。比如我就去过有一家欧美外包企业,他们曾经因为甲方变更负责人而发生了很多的需求变化,但最后双方核实后,追加了相应的金额。

问:追加价格的时候,如何核实数额呢?

答:这个就要谈到报价模式。

在国外用功能点报价已经逐渐是一个常态了,澳大利亚、芬兰、荷兰、意大利、日本、韩国等国的政府招标,很多都是采用功能点报价。尽管在中国鲜为人知,但在全球有多达6000人的CFPS(认证的功能点专家),在从事各种报价和度量活动。

功能点方法迄今为止已经形成了5个ISO国际标准,其核心思路是:利用一个公认的方法来衡量软件的规模,然后再乘以单价,来测算项目的报价。这个可能不符合国内外包中甲方先有预算后招标的习惯,但是却很符合海外发包商的相对单纯的“商品交易”的心理。

比如就曾经有海外发包商要求接包方报价,并必须说明报价的依据,结果国内无一企业能做到。失利的原因是多方面的,其中一个方面是当时没有可行的方法能在项目早期快速从有限的客户文档中判断项目的规模。

针对这类问题,后来我主笔编写了造价估算的行业协会标准,引入了NESMA(荷兰的功能点组织,同时也是世界第二大功能点组织)的快速功能点估算方法,在国内发包的项目中做的测算是每一人年左右的工作量仅需一张A4纸即可描述清楚,培训后每人天可完成4000~6000功能点需求的估算(大约合20~30人年的开发量),20多个历史项目的回归数据表明其精度在15~20%左右(大于和小于此数据的项目数各占一半)。

问:敏捷开发与这种造价管理有何关系呢?

答:尽管在项目初期只凭借几十页纸能完成20~30人年开发量的估算已属难得,但15~20%的误差对于固定单价合同还是有点粗糙。最佳方法,是与客户签署固定单价的合同,然后在几个短周期迭代后,定期实际计数一下功能点的数量,与用户结帐,这样非常适合长期项目的阶段性结帐。

    尽管听起用 单价×实际功能点数 = 总价 结帐很不可思议,但实际上澳大利亚政府就是用这种方法,只是他们并不要求迭代交付;芬兰政府的一些项目也采用类似的方法结帐。北欧最近一直在推行Northen Scope方法和工具,目的就是为了推进按规模估价、结算的方法。

     如果配合敏捷开发方法,在一个或多个短周期迭代后,按交付的功能数量进行结算,则无论对甲方乙方都是有利的。对甲方而言,可以按照乙方实际完成的功能结算,因而无需事先定义完整的需求(在移动互联网行业几乎是不可能的),而可以中途提出新需求;对乙方而言,新需求也是付费的,“拥抱变化”成为一件有利可图而非避之不及的事情。
     在这种新语境下,合作从僵硬地“履行合同”变成双方一起思考:哪些需求是值得开发的?有什么新需求胜过之前的计划因而能提升市场竞争力?这些正是甲方的利益所在,而乙方通过对甲方这种利益的满足,自己也能赢得客户。

本文来源于IIOM中国(官网:http://www.int-iom.cn),转载请注明文章来源,违者将被追究法律责任。
编辑:IIOM中国 

敏捷开发简介

阅读数 5082

没有更多推荐了,返回首页