请教工作量估算的问题

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

评论

12 楼 gurudk 2008-02-21  

banner 写道

首先感谢以上几位弟兄的回复，感觉自己很有必要系统学学项目管理。
当前情景是有需求和大部分代码（一个半成品），设计工作已大部分完成。也就是说当前要做的开发工作是改代码、加功能，要采用的技术、架构等都是既有的。下面是我的一个计划，大家看是否合理：
1、分析需求和当前功能，确定要修改、添加、删除的功能模块。
2、细化确定的功能模块，分成功能点，结合功能点难度、工期要求制定开发的task，以MD(人天)为单位。
3、采用持续构建模式，估计模模块集成工作可能出现的问题，粗略估计多次集成所需时间，包括集成后的BU修改功能量（以MD为单位）。
4、策略估计最可能产生的后续需求，与迭代所需工作量。
5、计算以上工作的总量，考虑到即将产生的开发团队会以新人为主，工作总量＝工作总量÷70％。
6、结合规定的时间点和工作量，构建开发团队.....
MD是以前公司里的度量单位，M按8小时算，暂时忽略必然的加班因素。

理一下：

估算单位：功能点

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

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

11 楼 抛出异常的爱 2008-02-21  

"估"
这个字说明了一些问题.

10 楼 bluefairy 2008-02-20  

Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别，这个技术，要求有多种软件相关经验人的参与，互相说服对方。
Delphi法的步骤是：
(1) 协调人向各专家(有软件相关经验的人) 提供项目规格和估计表格；
(2) 协调人召集小组会各专家讨论与规模相关的因素；
(3) 各专家填写估计表格；
(4) 协调人整理出一个估计总结，以迭代表的形式返回专家；
(5) 协调人召集小组会，讨论较大的估计差异；
(6) 专家复查估计总结并在迭代表上提交另一个估计；
(7) 重复第6步，直到达到一个最低和最高估计的一致

9 楼 celine 2008-02-20  

1）不要一个人估，但也不要太多人，要具备相关经验的人，多人之间偏差很大时多轮估算
2）估算前先将约束、假设、风险等列清楚
3）使用过去积累的经验数据作为参考
4）定期审视估算和实际的偏差，必要时重新估算

实际就是拍脑袋麽，我一般工期都能估准，其实不是估的准，而是工期是我的考核指标，我拼死拼活都要按时交付；工时偏差一般都不大，其实也不是估的准，而是。。。。。。；代码行估算越粗越准，越细越不准。。。

8 楼 banner 2008-02-20  

sg552 写道

感谢gigix回的好快！

我觉得LZ的这个想法实施起来是不是有难度？

引用

3、采用持续构建模式，估计模模块集成工作可能出现的问题，粗略估计多次集成所需时间，包括集成后的BU修改功能量（以MD为单位）。

持续构建说起来容易做起来难。尤其是当遗留代码没有单元测试的时候。想给它做补充的单元测试需要很大毅力……

如果遗留代码的单元测试做的非常完备，那就容易的多了。。。

等下我发表个帖子，说说目前遇到的，书本上却没有找到的问题。-_-!

是的，“持续构建....”那做起来很有难度，我们在应用持续构建时做的很累，构建周期一般为一天，紧张时bug须当天修改完....，这也是我以后要考虑改善的地方。
对于工作量估算，现在感觉的确是大多靠积累而来的，以后还要在开发过程与总结上多下些功夫

7 楼 ozzzzzz 2008-02-20  

项目规模的估算和项目管理其实没啥关系，而工作量的估算倒是和项目管理关系密切。
而根据我的经验，使用何种方法同估算的准确性没啥大的关联，而同项目结束后的总结和积累关系密切。
同时估算应该是一个过程，而不是一个短时间的行为。同时估算应该同计划严格区分，不应该为了计划而估算，也不能为了估算而计划。
再次强调gigix说的，估算的单位不要与时间有任何关系。但是请记住，在实际的操作中时间会对估算有巨大的影响。而只有将时间同估算单位完全的隔离，才是保证。
同时估算有几种粒度，适应不同的场景。

而真正合格的估算，应该是拍脑门想出来的——也就是应该仅仅建立在主观的直觉基础上的。所谓的估算方法，到最后你会发现，其实仅仅是一种给自己结论找的理由。而要完成你的设想，唯一的方法就是完成他们。也就是说，想看书或者参加什么培训提高估算的水平，几乎是不可能。不断的总结和积累，才是王道。

6 楼 sg552 2008-02-20  

感谢gigix回的好快！

我觉得LZ的这个想法实施起来是不是有难度？

引用

3、采用持续构建模式，估计模模块集成工作可能出现的问题，粗略估计多次集成所需时间，包括集成后的BU修改功能量（以MD为单位）。

持续构建说起来容易做起来难。尤其是当遗留代码没有单元测试的时候。想给它做补充的单元测试需要很大毅力……

如果遗留代码的单元测试做的非常完备，那就容易的多了。。。

等下我发表个帖子，说说目前遇到的，书本上却没有找到的问题。-_-!

5 楼 banner 2008-02-20  

gigix 写道

sg552 写道

1。实现进行非常详细的设计。把每个模糊的，大的概念，细分成非常明确的，小的子模块。然后估算时间就很容易。
2。考虑到人的工作效率。 一般人每天的有效工作时间不超过4小时。（结对编程，效率会高的多。这个请TW的朋友们现身说法下）所以，如果你是按100%效率估算时间的话，那么请将结果 x (1.5~ 3)。

1、INVEST
2、估算的单位不要和时间有任何关系

不知第二条是出于什么考虑呢？

4 楼 banner 2008-02-20  

首先感谢以上几位弟兄的回复，感觉自己很有必要系统学学项目管理。
当前情景是有需求和大部分代码（一个半成品），设计工作已大部分完成。也就是说当前要做的开发工作是改代码、加功能，要采用的技术、架构等都是既有的。下面是我的一个计划，大家看是否合理：
1、分析需求和当前功能，确定要修改、添加、删除的功能模块。
2、细化确定的功能模块，分成功能点，结合功能点难度、工期要求制定开发的task，以MD(人天)为单位。
3、采用持续构建模式，估计模模块集成工作可能出现的问题，粗略估计多次集成所需时间，包括集成后的BU修改功能量（以MD为单位）。
4、策略估计最可能产生的后续需求，与迭代所需工作量。
5、计算以上工作的总量，考虑到即将产生的开发团队会以新人为主，工作总量＝工作总量÷70％。
6、结合规定的时间点和工作量，构建开发团队.....
MD是以前公司里的度量单位，M按8小时算，暂时忽略必然的加班因素。

3 楼 yangzheng 2008-02-20  

web项目经理手册-开发时间估算

出处：http://blog.csdn.net/yzhz 
        项目经理制定项目时间表的时候，需要估算每个任务所需的时间，其中开发任务中模块的分配和时间估算是其中最主要的部分。本篇专门就这部分作一个阐述。

一、在分配模块和估算开发时间时，我们需要把握的原则和目标：
1、保证项目整体的进度。
2、有助于确保开发编码的质量。
3、有助于提高开发编码的速度。


二、每个公司都拥有自己的技术框架，开发人员主要的工作通常投入在具体的商业逻辑上。
通常每个模块所需的开发时间取决于以下三个因素：
1、该模块的商业逻辑的复杂程度。
2、开发人员的技术水平和对项目所在应用的熟悉程度（包括对框架和应用的熟悉程度）。
3、该模块技术实现上是否有技术难点。这里我把技术难点定义为：在现有系统中还未实现的有一定技术难点的问题。对于这样的难题，开发者没有相关的代码可以参考，需要投入一些时间研究解决。

三、模块分配和开发时间估算的步骤：
1、作为项目经理划分好模块后，我会自己先估算一下每个模块所需要的开发时间。

2、召集所有开发人员，讨论模块分配和开发时间估算。
      项目经理将划分好的模块，让开发人员从中挑选他们感兴趣的模块。这样做可以提高开发人员的主动性和参与性。
      项目经理在分配模块的时候还需从以下几方面考虑，以确保开发的速度和质量。
(1)相同类似的模块由同一人负责开发，比如文章的增删改由同一开发者负责。这样做的好处就是开发者对相关逻辑会更加熟悉，同时接口的定义也会比较明确，沟通的成本比较低。
(2)技术难度比较大的模块由技术水平比较高的人负责。
(3)业务逻辑比较复杂的由对这块逻辑比较了解的人负责。


3、模块分配完后，开发人员评估自己负责开发的模块所需要的时间。在此过程中我们会比较详细的讨论每个模块的技术实现，以便使时间的估算更加准确。

4、项目经理对开发人员估算的时间进行确认。
        在确认过程中作为项目经理我会参考以上提到的三个因素，同时将自己估算的时间和开发人员估算的时间进行比较。这其中的差异当然会存在的。对于那些差异比较大的，我会和技术人员探讨其中的缘由。
        对于时间周期比较长的任务，我通常会再细分一下，争取每个任务的最长时间不超过3天。时间周期越长的任务，不确定性越高，风险也越高，越有可能成为项目的瓶颈。


建议：
1、项目总结的时候，对项目中的一些数据做好统计比如单位UC所花的开发时间、测试时间等，这些数据统计可以作为以后开发的参考。
2、对技术难点，在项目开始前做好技术准备，提前安排人员研究。这样会节省以后项目时间，降低技术风险。

2 楼 gigix 2008-02-20  

sg552 写道

1。实现进行非常详细的设计。把每个模糊的，大的概念，细分成非常明确的，小的子模块。然后估算时间就很容易。
2。考虑到人的工作效率。 一般人每天的有效工作时间不超过4小时。（结对编程，效率会高的多。这个请TW的朋友们现身说法下）所以，如果你是按100%效率估算时间的话，那么请将结果 x (1.5~ 3)。

1、INVEST
2、估算的单位不要和时间有任何关系

1 楼 sg552 2008-02-20  

个人以为，在非要估算时间不可的时候，最好遵循以下原则：

1。实现进行非常详细的设计。把每个模糊的，大的概念，细分成非常明确的，小的子模块。然后估算时间就很容易。

比如，一个新的模块是“订单管理模块”，通过查看需求文档，跟需求人员进行口头沟通，之后，也许你会把它划分成如下小模块：
a. 查询订单  b. 订单的状态转换  c. 订单的历史记录  
再之后，对于各个模块再进行细分。对于a. 可以有不同的查询方式，如时间，关键字，状态等。对于  b. 可以有订单的增删查改，状态的比较，各种相关信息的保存，  对于c, 可以有 历史记录的保存， 查看， 版本比较。  这样再层层细分，估计用 7，8个小时，也就出来了。 然后再用个20，30个小时，把它们下分给开发人员， 把每个模块细分成单元测试的粒度，你再估算起来就非常容易了。

对于一个已经存在的BUG，也可以按照调试的步骤来估算时间，比如一个需要修改底层代码的BUG，由于是做修改工作，还不知道修改哪里，那么细分模块的方法可能不适用，也许可以这样估算：

1. 交互记录的时间显示
   1.1 重现并找到BUG： 1H
   1.2 分析代码：      0.5 H
   1.3 编写单元测试：  1H
   1.4 编写代码实现：  3H
   1.5 集成测试：      3H
   1.6 文档：          0.5 H

2。考虑到人的工作效率。 一般人每天的有效工作时间不超过4小时。（结对编程，效率会高的多。这个请TW的朋友们现身说法下）所以，如果你是按100%效率估算时间的话，那么请将结果 x (1.5~ 3)。

   PS。如果你的团队没人能有效使用JUnit，那么请将调试时间 = 开发时间 X 3。

3。楼下的哥们补充~