艾伟也谈项目管理,利用简单的一元线性回归分析估计软件项目开发时间

  引言

      前两天一个朋友给我打电话,问我如何估计项目开发时间。对此我很诧异,问他以前他们是怎么估计的,他说以前基本都是大家开个会,大约都说说自己意见,最后负责人一拍脑袋,给出一个时间。不过这次遇到一个非常认真的客户,要求不但要估计出项目开发时间,还要明确说明具体的依据和估算方法,这下我这朋友有点犯难,才询问我。后来我翻阅了一些数理统计和项目估算方面的资料,告诉了他利用一元线性回归分析估计软件项目开发时间的方法。想到这种估算需要在一些开发团队很常见,所以在这里整理成文。

  问题的定义及数学模型

      这里我们仅考虑比较简单的一元回归问题,即通过单一的Proxy预测项目开发时间。这里先说一下什么叫Proxy。Proxy叫做代理变量,简单来说就是估计项目开发时间的数理依据。说白了,就是我们预测开发时间,总要有个根据,例如需求中用例个数、概要设计中的实体个数、数据库中的表的数量等等。

  设Proxy为x,项目开发时间为y,那么可以得到y=f(x),学过初等数学的都可以看懂,就是说开发时间是Proxy的一个函数,如果我们既知道了新项目的x,又知道函数f,那么y就出来了。可惜天下哪有这么好的事,我们现在既不知道f,又不知道x,别说x的值了,甚至我们都不知道该用哪个Proxy做x。

      不过也不必悲观,经过上面分析,我们至少明确了我们奋斗的方向:

  • 找出候选的Proxy。
  • 选择最合适的Proxy作为x。
  • 得到x的值。
  • 确定函数f。
  • 得出y。

      下面我们一步一步解决各个问题。

  找出候选的Proxy

      虽然一个项目的特征量很多,不过可不是随便一个特征量都可以当做Proxy的。要成为Proxy,至少要满足如下四个条件。

      1)Proxy的值应该和工作量紧密相关。

      这个不用多解释了吧,就是说Proxy的值和y的值要有相关性。关于“相关性”的概念这里先定性说一下,定量分析后续会讲到。

      2)Proxy应该是能明确得出值的,没有二义性。

      这是说Proxy应该对应一个明确数值,是一就是一,是二就是二,不能取“不错”、“挺多”这种值。

      3)Proxy应该在项目开始阶段可以得出或能较精确估计出。

      这个开始阶段最晚不能晚于概要设计,因为估算都是一开始进行,所以Proxy一定要在起始阶段就能得出,否则项目结束了谁还搞估算,实际值都出来了。

      4)Proxy对于不同的实施方案是敏感的。

      就是说当开发方法、开发过程等因素变化时,Proxy应该具有一定的敏感性。

      经过上述分析,我想选用什么作为Proxy大家心里都有点谱了。一般来说,在估算时常被作为Proxy的有需求分析中用例数量、需求分析中功能模块数量、概要设计中实体数量和数据库设计中表的数量。当然,各位也可以根据上述要求选择自己的Proxy。在本文中,我们暂且选择用例数量、实体数量和表数量三个Proxy作为候选。

  选择最合适的Proxy作为x

      这里所谓的“最合适”,在数学上的意义就是和开发时间y的相关性最强。那么什么是相关性呢,从直观意义上,两个变量的相关性是指两个变量关联的紧密程度,数学上可以用相关系数表示。相关系数计算公式如下:

      至于这个公式为什么能反映出两个变量的相关性,可以去参考高等数理统计相关资料,本文不再赘述,只是顺便说一下,r的范围在-1~1之间,绝对值越大代表相关性越强,如果为正值则表示两个变量正相关,否则为负相关。知道了这个,我们这一步骤的目的就是找出候选Proxy中与y相关系数最大的作为x。

      不过,这数据从哪里来呢?这就要从以前做过的项目中提取了。查阅朋友所在团队最近做过的5个项目的数据资料(这里当然历史项目越多越好,不过笔者这个朋友的团队只有5个项目的记录),得到如下数据:

      项目工期(y):     424     267     90     331     160     (人时)

      用例数量(x1):   37       20       6       18       12

      实体数量(x2):   15       9         4       11       14

      数据表数量(x3): 25      18       7       16       18

      下面就是计算各个相关系数了,计算相关系数是一项机械且乏味的活动,一般都会交由相应的工具去完成。不过您要是感兴趣,也可以自己代入上述公式手算。下图是我用Excel计算的结果:

      图1

      一般来说,|r|大于0.7就有很好的相关性了,而从计算结果可以看出,用例数量x1和工期y的相关系数达到0.93,最为优秀,而数据表数量x3也达到0.83,唯有实体数量x2的相关系数仅为0.65,质量较差。因为|r(x2,y)|<0.7,所以这里首先排除掉。

      到了这里似乎我们可以顺利成章选择x1作为最终Proxy,但是还有一点要考虑,就是显著性。所谓显著性就是在偶然情况下得到此结果的概率,如果显著性不足,说明这个结果不可靠。显著性t值的计算公式如下:

      因为n=5,这里自由度为3,然后查询t分布表,得到95%预测区间为3.182。因为一般显著性<0.05则认为显著性较好,所以如果t的值大于3.182,我们则可以接受。不过如果使用工具的话,一般可以用t检测直接得出显著性,这里我用Excel得到r(x1,y)的显著性为0.006,r(x3,y)的显著性为0.007(如图2所示),都远小于0.05,显著性均非常好。所以根据择优录取原则,我们选择x1:需求文档中用例数量作为预测Proxy。

图2

  得到x的值

      在上文中,我们通过相关性和显著性分析,最终决定使用需求文档中的用例数量作为x。下面就是要确定x的值,这个不必多说,直接从需求文档中得到相应的数量即可。

  确定相关函数f

      知道了x的值,下面就是要确定相关函数了。这一步是最艰难也是最有技术性的,因为相关函数不但和数理因素相关,还与开发团队、团队中的人以及管理方法有关。如果人员变动很大或管理方法做了很大的调整,历史数据可能就不具备参考价值了。不过如果团队的开发水平和管理方法没有重大变动,这个函数还是相对稳定的。

      在函数选型上,一般会选择线性函数,当然我个人对此是十分怀疑的,但是这里为了简单起见,我们姑且照例使用线性函数作为预测模型。这样可以建立一元线性回归模型如下:

      这个函数并不是简单的线性函数,而是包含了一个随机变量ε,这是一个服从正态分布的随机变量。上述模型的直观意义可以如下描述:a代表与x即用例数量无关的起始时间,b代表每一个用例所耗费的平均时间,而ε代表开发中的不确定性。在不同的团队中或不同的管理方法下,a,b和ε都是不一样的,但是当团队和管理方法相对稳定,可以认为a,b和ε是可通过历史数据估计的。而因为ε的期望为0,所以只要给出a和b的合理估计,就可以得到y的一个无偏估计。

      下面我们估计a和b的值。估计方法有很多,如曲线拟合法或最小二乘法。这里我们采用最小二乘法进行估计。

      最小二乘法估计的基本原理如下:

      求极值可以使用微积分中的求极值方法,首先令Q(a,b)对a和b分别求偏导,并令偏导为零,得如下方程组:

      经过一系列计算和推导,最终可得到:

      将以前的历史数据代入上述方程,就可以得到a和b的最小二乘估计。同样,这种机械而乏味的计算一般交由工具去完成。我用Excel得到a和b的估计分别为56.251和10.653。Excel分析结果如图3所示:

图3

      根据估计结果,我们可以得出相关函数为y=56.251+10.653。我们还可以证明,这个估计是一致最小方差无偏估计,证明过程从略。

      现在我们不但得到了相关函数,还得到了如下有用的数据结果:这个团队在目前的管理模式下,开发一个项目平均准备时间为56.251人时,而平均每个用例开发耗时为10.653人时。

  得出y

      有了上面的结果,我们可以很轻易得出新项目的计划工时。例如新项目有50个用例,代入可以得到y=56.251+10.653*50=588.901,约为589个人时,再假设团队中有3个开发人员,平均每周工作五天,每天工作8小时,就可以得到项目大约需要开发24.54个人日,开发周期约为5周。

  后面的话

      至此我们已经完成了利用一元线性回归模型对软件工期的估计。但是不得不承认,这个估计方法存在很多缺陷,如估计变量单一以及估计模型过于简单等等。实验证明,这种一元线性模型对中小型项目相对有效,如果团队比较大并且项目十分复杂,估计效果就不理想了。

  不过这篇文章给出了一种思路,就是如何利用数理统计模型以及历史经验数据来估计新项目的工期。对于文中的具体方法则可以进行诸多扩展,例如使用多个估计代理进行多元回归分析、细化估计方法等等。

  例如PSP中就给出一种非常精细的PROBE估计法,有兴趣的朋友可以参考。另外,除了求得估计值,还可以给出估值置信区间,甚至使用蒙特卡洛模拟技术进行更复杂的分析,都可以得到更理想的估值。但是其核心思想与本文是相通的。

  联系作者

  本文基于署名 2.5 中国大陆许可协议发布,欢迎转载,演绎或用于商业目的,但是必须保留本文的署名张洋(包含链接)。如您有任何疑问或者授权方面的协商,请给我留言

时间: 2024-11-05 20:26:29

艾伟也谈项目管理,利用简单的一元线性回归分析估计软件项目开发时间的相关文章

艾伟也谈项目管理,项目管理利刃之MSF

MSF,MicrosoftSolutionFramework,微软解决方案框架是一个在预算范围内按期创建一个业务解决方案需要一种经过检验的方法. 本文将结合MSF在项目管理中的实际应用进行讲解,如果您是软件项目的参与者,如项目经理.开发工程师.系统架构师.顾问.质量管理人员等,想找到项目管理中遇到问题的解决方案,相信本文会给您一定的帮助. MSF为成功地规划.设计.开发和部署IT解决方案提供了一套成熟的方法论.与具有固定框架的方法相反,MSF提供了一个可以伸缩的灵活框架,以满足任何规模的组织或者

艾伟也谈项目管理,敏捷实施中的常见错误

一些评论员写下了敏捷实施中一些常见错误和反模式.他们贴出了"Top X"列表,列出了需要避免的事项和他们曾在各种组织实现敏捷时见过的错误. Target Process的Michael Dubakov写了两篇博文:"10个敏捷实施中最常见的错误"(Part 1; Part 2 ).他认为"许多公司在敏捷实施中再三犯同样的错误." 他的常见错误列表如下: 1. 从一个工具开始敏捷开发是不同的.一个工具不会立刻产生影响,不会由于这一工具的存在而解决多

艾伟也谈项目管理,《播客》项目总结——项目管理方面

引言:如果标题改成<被管理总结>的话,我可以滔滔不绝的说上个半天,但是如果是管理项目的话,我实在肚里的货有限,因为到至今做过的最高职位不过是个"班长"而已. 但是这次<播客>项目在管理方面的确出了问题,而且是满严重的问题,以至于到后来项目差点失控,而且最终的交付作品质量的确让人汗颜.如何避免下面程序员很累,但效率却很低:上面不停的催,产品却一个bug接一个bug,完全没法交付:项目经理累的要死,项目却仍然处于失控状态这样的问题和局面?在一个差点失控的项目刚刚结束

艾伟也谈项目管理,项目管理一些体会

项目管理需要的知识,是一个体系的知识,包括项目管理本身的知识体系,以及项目管理要应用到的领域所需要的知识体系,然后就是管理的技能,当时最重要的,是软技能,也就是人际关系技能. 管理的核心:人. 管理的四大要素: 1. 选择正确的人 2. 为他们分配正确的工作 3. 保持他们的积极性 4. 帮助团队凝聚起来并保持团队的凝聚力. 1. 选择正确的人 首先要学会看人.虽然我不是人力资源专家,但是我清楚一个软件项目的成功所需要的成员素质,主要就是沟通能力和责任心. 由于工作需要,我面试过一些人,有毕业生

艾伟也谈项目管理,关于项目管理的一点体会

这段时间,一直在负责一个项目的管理与开发.在时间短.任务紧,而团队人员又大部分是没有经验的菜鸟的恶劣情况下,我带领接近40人的团队,终于在客户规定的时间范围内如期交付产品.这其中,经历了需求变更.人员变动(因为其它任务,先后有近10人离开团队)等诸多问题,项目仍然取得成功了,不能不说有几分侥幸,但此外也有一些经验与教训可以与大家分享. 一.项目开发方面 需求 项目应以需求为核心.一个项目是否能够成功,对需求的准确把握在成功因素中要占上60%的比例.不管系统的架构设计.团队管理有多么的成功,如果需

艾伟也谈项目管理,软件架构引言之项目管理的问题

软件架构引言之项目管理的问题   很多朋友都有过或者正在管理一个或者多个软件项目,那么我的文章就从这个问题开始:如果单纯从表象来说,软件项目管理过程中暴露的最大问题是什么?   不同的人的会有不同的答案,但是大致这样的答案我想大部分人都是会认可的,那就是"进度拖延".进度拖延当然是表象之一了,其他诸如质量不过关.功能不完整等等,我觉得都是和进度拖延密切相关的.很多项目经理都想去做那些认为是十分必要的事情,比如计划.测试等,但是"没有时间".为什么会没有时间?等到项目

艾伟也谈项目管理,项目经理成长日记(7)——说是细,做的粗

估计绝大部分的公司都在提倡一个口号:"注重细节."但是往往是口号容易喊,行动却是千辛万苦,何谓细节?也就是自身工作的每一个环节.每一道流程的琐碎小事,而这些小事又常常容易被人忽略.有很多人有雄才大志,内心中充斥着舍我其谁的非凡气魄,但其眼高手低,小事不屑,大事难成,最终只落得一事无成的悲哀. 软件开发亦是如此,提倡了许久的注重细节,更有甚者许多公司标榜自己的优势在于:"我们更注重细节."然而如果说我们要做到和自己提出的口号一致的时候,我们该如何去做?该做什么的事情才

艾伟也谈项目管理,Richard Durnall谈系统管理和从外向内的组织结构

InfoQ中文站:能给我们介绍一下"系统管理理论"(System Management Theory)么?能不能跟我们分享一下您在实际应用中的经验? Richard Durnall:系统管理理论是过去五十年里出现并逐步发展而来的.它与传统的那种基于管理和控制方式的科学管理理论有很大的不同.首先让我们回顾一下管理科学的历史来了解系统管理理论. 在19世纪工业革命之前,商业规模通常不大,从业人数十分有限.19世纪30年代的技术革命中出现了大规模的工业企业.与传统的村镇工业不同,这些企业开始

艾伟也谈项目管理,解读敏捷需求分析五大关键因素

大多数学计算机语言的人都会有过这样的感受,过去一直认为编程和架构是整个软件生命周期里最了不起的部分,但实际工作后才会发现在商业产品里,需求分析才是一个商业软件成功与否的关键. 放眼望去,在当今软件工程领域出现的许多问题,诸如缺陷及资源运用不当,都源于需求的不清晰,甚至有软件人戏称:"需求变更乃万恶之源",一时也获得了颇多响应.时至如今,业务IT间需求分析过程中存在的问题主要有哪些?什么是敏捷需求分析?产品级和项目级需求有何异同?敏捷需求分析方法论中的五大关键点是什么?就以上热点话题,雅