扫码阅读
手机扫码阅读
在估算时为什么要分解估算对象?

我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。


麦哲思科技任甲林
扫码关注公众号

在项目管理过程中,精确估算规模与工作量具有重要意义。然而,许多项目经理在估算时常常不对被估算对象进行拆分,导致估算出现较大偏差。例如,一个模块估计有1万行代码,若以10%的标准差进行估算,根据切比雪夫不等式,实际代码行数可能落在7000到13000行之间的概率为89%。若偏差率符合正态分布,则该概率升高到99.73%。
相对地,如果将模块细拆分为50个小程序,每个程序约200行代码,保持10%的标准差不变,通过计算可知,实际代码行数的区间为(9576,10424),精度更高。对比两个估算区间:
- (7000,13000)
- (9576,10424)
显而易见,细拆分后的估算结果更为精确,所以在进行估算时应该尽可能细化估算对象。
此外,可使用水晶球软件模拟估算结果,以直观比较细拆分与未拆分的差异。模拟假设两种方法均估算出1万行代码,模拟1000次实际结果显示,在未细拆分情况下,实际代码行数落在区间(9576,10424)的概率仅为34.97%,而细拆分后,这一概率大幅提升至99.81%。
想要了解更多内容?


麦哲思科技任甲林
扫码关注公众号

麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 241.5K
麦哲思科技任甲林的其他文章
需求与设计人员如何配合工作?
在软件开发的过程中 ,经常出现需求与设计脱节的现象,如设计人员按照自己的理解去设计,没有遵从需求去设计系统;需求人员做完需求定义后,交给设计人员去设计,撒手不管了等等,为了使需求与设计人员更好的协作,建议采取如下的措施:Ø 需求人员与设计人员一定要分离,否则无法解决需求文档化的问题,但是文档并不能解决所有的沟通的问题,还需要面对面的沟通。Ø 需求评审设计人员一定要参加,设计评审需求
COSMIC规模度量方法v4.0度量手册中文版正式发布了!
COSMIC是通用软件度量国际联盟的简写,它成立于1998年,是一个由全球软件度量专家组成的非盈利自愿性组织,致力于软件规模度量方法的研究与推广。2002年1月COSMIC所推出的全功能点规模度量方法成为了ISO的标准,最新标准为ISO/IEC 19761:2011“软件工程—COSMIC—功能规模度量方法”。COSMIC规模度量方法相对于传统的规模度量方法简单实用,学习周期短,易于上手。一经推出
白话SCRUM 之四:燃尽图
Burn down chart翻译为燃尽图或燃烧图,很形象,是Scrum中展示项目进展的一个指示器。我一直认为用户故事、每日站立会议、燃尽图、sprint review、sprint retrospective真是越琢磨越有味道的好东西,也因此很喜欢scrum这种方法,这些实践简单有效、经典! 燃尽图的样例如下: 横坐标为工作日期,纵坐标估计剩余的工作量,每个点代表了在那一天估计剩
项目进度跟踪的最佳实践:每日站立会议
项目进度跟踪的最佳实践:每日站立会议1 每日站立会议的具体做法每日站立会议是Scrum方法中的一条关键实践,看似很简单的一个活动,其实内涵丰富,站立会议通过每天面对面的沟通,可以: (1)快速同步进展,让项目组内部的员工互相了解彼此的进展,从而了解本项目的整体进展。 (2)给每个人一种精神压力,信守承诺。这是一种面对面的精神压力,直面项目进展。 (3)培养团队的文化,让每个人意识到:我不是一
理论与实践的完美结合:《软件项目估算》译者序
这本书需要仔细读。 没有哪一本书能够替代此书在如何建立生产率模型方面的严谨性与实用性,它讲的不是经验法估算工作量,而是模型法估算工作量。 它理论完备、严谨,并给出了工程化的软件工作量估算方法和大量的经验教训。 在给客户咨询的过程中,我帮客户识别、建立了大量的过程性能模型,积累了丰富的经验,但是,当我读到Alain的这本书时,我深...
加入社区微信群
与行业大咖零距离交流学习


PMO实践白皮书
白皮书上线
白皮书上线