2008-02-20

请教工作量估算的问题

本人开发人员出身，做开发小组长有一两年了，对工作量的评估一直头疼。刚接到一个开发任务，要对一个demo根据需求改造以达到为某省上线应用的目的，现在项目组还没组建，只有demo+需求（部分需求已完成设计），不知这种情况下：如何更好的估算工作量，并根据估算结果组件团队，在合同规定时间内完成开发任务?
刚看到china-pub上有本书：软件估算--黑匣子揭秘(《代码大全》作者Steve McConnell又一力作)。不知这本书如何？
评论
ziggler 2008-06-23
可参考WIDE-DELPHI方法。
xwhoyeah 2008-04-29
一般都是在前期规划时大概估算一个值.

在需求确定后,再进行比较准确的估算.
通常是将需求分解,细化.
细化的程度是,你认为这个点你可以知道大约有多少规模.
然后求和.

这样算出来的肯定要比实际的少. 因为有些可能想不到.
再加上个 10% 到 20% 的偏差.
基本上差不多.

这也只是我的经验.
10% 到 20%, 也可以是 30% 到 40%.
依情况而定了.
xwhoyeah 2008-04-29
abang 写道
估算工作量是我最头疼的事情之一，每次估算完了，领导总是一副非常惊讶的表情：“这个竟然要这么多天！”，然后就会要求减少时间。


1.那是领导怕有水分, 让你把水分给挤出来.
2.故意压缩你的工作量, 将来说:"看你把活干的,比估算的多多了!".
abang 2008-04-23
估算工作量是我最头疼的事情之一，每次估算完了，领导总是一副非常惊讶的表情：“这个竟然要这么多天！”，然后就会要求减少时间。
liu.jun 2008-03-27
yiding_he 写道
我也是开发组长。我们这里是，客户给我们一个上级提出来的规范（只是一个规范说明文档，连需求都算不上），要我们算工作量。我们项目经理竟然给算出来了。


难道不可能跟客户沟通么？现场会议，电话，邮件，IM...
还是根本不想和客户沟通？
younggun 2008-03-27
1.参照其他team的timeline
2.实际考虑自己team的能力和其他情况
bluemeteor 2008-03-25
魔力猫咪 写道
如果你只是拍脑门就估算完成了，那么我觉得你最好准备好拍屁股。软件估算其实和建筑工程预算一样。是门严谨的科学。
你看到的那本书我买了，很不错。你可以看看。不过国内的情况就那样。没多少预算却偏要高规格的事太多了。建筑行业里也很常见。不然怎么那么多烂尾楼和新建危房。


强人连脑袋都不用拍，换个土鳖PM拍出脑白金也没戏……
抛出异常的爱 2008-03-25
ozzzzzz 写道
rabbitbug 写道
建筑工程的还不是简单拍脑子得出来的
人家有各种国家标准的
当然标的有所不同
预算结果却会相差万里
一同学就因为这亏大发了

gigix 写道
魔力猫咪 写道
如果你只是拍脑门就估算完成了，那么我觉得你最好准备好拍屁股。软件估算其实和建筑工程预算一样。是门严谨的科学。
你看到的那本书我买了，很不错。你可以看看。不过国内的情况就那样。没多少预算却偏要高规格的事太多了。建筑行业里也很常见。不然怎么那么多烂尾楼和新建危房。

这个……建筑工程预算其实就是拍脑袋啊


其实就是拍脑袋，只不过脑袋和脑袋水平不同罢了。
所谓的做预算其实就是把脑袋给找点理由说明一下罢了。
而就预估这个事情来说，本身就应该是拍脑袋。但是拍完了，您要去实际的厕所里面测算测算。纯粹的依靠提起的测算，想推导出一个所谓的合理结果，基本上是缘木求鱼。因此需要先拍脑袋画一个道道出来。

预算只是算算预见的钱可以产生出多高的档次
而不是说多高的档次用多少钱......
产生的缝隙之处(就是不用预见的部分)
可以弥补总价的差....
工程预算,工程设计,工程造价,工程制标,工程监理.
yiding_he 写道
我也是开发组长。我们这里是，客户给我们一个上级提出来的规范（只是一个规范说明文档，连需求都算不上），要我们算工作量。我们项目经理竟然给算出来了。

承诺而已
yiding_he 2008-03-24
我也是开发组长。我们这里是，客户给我们一个上级提出来的规范（只是一个规范说明文档，连需求都算不上），要我们算工作量。我们项目经理竟然给算出来了。
ozzzzzz 2008-03-24
rabbitbug 写道
建筑工程的还不是简单拍脑子得出来的
人家有各种国家标准的
当然标的有所不同
预算结果却会相差万里
一同学就因为这亏大发了

gigix 写道
魔力猫咪 写道
如果你只是拍脑门就估算完成了，那么我觉得你最好准备好拍屁股。软件估算其实和建筑工程预算一样。是门严谨的科学。
你看到的那本书我买了，很不错。你可以看看。不过国内的情况就那样。没多少预算却偏要高规格的事太多了。建筑行业里也很常见。不然怎么那么多烂尾楼和新建危房。

这个……建筑工程预算其实就是拍脑袋啊


其实就是拍脑袋，只不过脑袋和脑袋水平不同罢了。
所谓的做预算其实就是把脑袋给找点理由说明一下罢了。
而就预估这个事情来说，本身就应该是拍脑袋。但是拍完了，您要去实际的厕所里面测算测算。纯粹的依靠提起的测算，想推导出一个所谓的合理结果，基本上是缘木求鱼。因此需要先拍脑袋画一个道道出来。
rabbitbug 2008-03-24
建筑工程的还不是简单拍脑子得出来的
人家有各种国家标准的
当然标的有所不同
预算结果却会相差万里
一同学就因为这亏大发了

gigix 写道
魔力猫咪 写道
如果你只是拍脑门就估算完成了，那么我觉得你最好准备好拍屁股。软件估算其实和建筑工程预算一样。是门严谨的科学。
你看到的那本书我买了，很不错。你可以看看。不过国内的情况就那样。没多少预算却偏要高规格的事太多了。建筑行业里也很常见。不然怎么那么多烂尾楼和新建危房。

这个……建筑工程预算其实就是拍脑袋啊
gigix 2008-03-11
魔力猫咪 写道
如果你只是拍脑门就估算完成了，那么我觉得你最好准备好拍屁股。软件估算其实和建筑工程预算一样。是门严谨的科学。
你看到的那本书我买了，很不错。你可以看看。不过国内的情况就那样。没多少预算却偏要高规格的事太多了。建筑行业里也很常见。不然怎么那么多烂尾楼和新建危房。

这个……建筑工程预算其实就是拍脑袋啊
魔力猫咪 2008-03-11
如果你只是拍脑门就估算完成了，那么我觉得你最好准备好拍屁股。软件估算其实和建筑工程预算一样。是门严谨的科学。
你看到的那本书我买了，很不错。你可以看看。不过国内的情况就那样。没多少预算却偏要高规格的事太多了。建筑行业里也很常见。不然怎么那么多烂尾楼和新建危房。
rocwon 2008-03-10
ozzzzzz 写道

而真正合格的估算，应该是拍脑门想出来的——也就是应该仅仅建立在主观的直觉基础上的。


玄哦
tomas_z 2008-03-10
在项目管理中，评估最难的地方不是开始时的细化和需求的分析。我认为最难的是关于风险的评估。
如果做过类似的项目，可以从历史数据中借鉴经验，一般10%-15%左右。如果是新的项目，则一般要30%左右。尤其是有新手参加的时候，还要有一个buffer。并且对于风险，也要进行细化工作。
nickevin 2008-03-10
误差可能比较大
ltian 2008-03-07
首先 作WBS分解，分解到项目组成员根据历史经验可以估计出大概多久能做完的程度，然后采用delphi法估算。当然只是估算吗，有些变数是无法估算的
yecllsl 2008-02-25
如果你们有比较完善的配置系统，有以前的项目信息，类比法是个不错的选择。其次，专家评估（Delphi）法前面有人介绍。如果都不成熟，请采用开发人员最擅长的方法，自底向上，把工作分解以后，可以分解成用例、用户故事或者功能点（这个的确困难），然后估算，简单一点先不要考虑其他影响，估算结束后直接乘一个经验参数，建议你最少乘1.5。还有，有条件的话，还是采用两种方法来估算，再调整。我的宗旨，按自己的情况调整。
banner 2008-02-23
这两天看了些资料。由于副总催的紧，今天刚把工作量估算和开发计划报上去。
唉，各位好像都不在，俺们周六正常上班， ：（
感觉对于我们的项目（java开发的通信应用系统），很难做到代码行估算（自己能力有限），功能点估算应该是较快捷的方式，不知我的想法对不对。
对于估算中的人员，不好把握，要招不少新人，业务知识培训会花费较长时间。
gurudk 2008-02-21
banner 写道
首先感谢以上几位弟兄的回复，感觉自己很有必要系统学学项目管理。
当前情景是有需求和大部分代码（一个半成品），设计工作已大部分完成。也就是说当前要做的开发工作是改代码、加功能，要采用的技术、架构等都是既有的。下面是我的一个计划，大家看是否合理：
1、分析需求和当前功能，确定要修改、添加、删除的功能模块。
2、细化确定的功能模块，分成功能点，结合功能点难度、工期要求制定开发的task，以MD(人天)为单位。
3、采用持续构建模式，估计模模块集成工作可能出现的问题，粗略估计多次集成所需时间，包括集成后的BU修改功能量（以MD为单位）。
4、策略估计最可能产生的后续需求，与迭代所需工作量。
5、计算以上工作的总量，考虑到即将产生的开发团队会以新人为主，工作总量＝工作总量÷70％。
6、结合规定的时间点和工作量，构建开发团队.....
MD是以前公司里的度量单位，M按8小时算，暂时忽略必然的加班因素。


理一下：

估算单位：功能点

估算因素：而业务逻辑复杂程度，实现难度，开发人员水平，当前大部分代码的适用程度，可重用技术组件复用程度，客户期望和对质量的要求。集成工作工作量可以按照上面估算的一定比例计算。

估算策略：先实验，在根据统计数据更改。
估算方法越简单越好，因为软件开发是一个系统工程，涉及因素太多，模型再复杂，也不见得有用。
技术架构稳定了，需求也有了，应该说估计准确性还是比较高的。不过人的因素变化太大了，新人是你目前面对的最不稳定的因素了。
发表评论

提醒: 该博客已发表在公共论坛，博客所有留言会成为论坛回贴，留言请注意遵守论坛发贴规则

您还没有登录，请登录后发表评论

banner
搜索本博客
博客分类
最近加入圈子
存档
最新评论