项目中期的团队长阶段工作量估算

工作量估算原理：
进入实施阶段之后，随着需求的不断明确，项目团队人员的不断充实，原来前期的风险逐渐不存在，工作量估算的意义大大加强。
又可以分为：个人工作量估算、团队工作量估算两个方面，从时间尺度上来又可分为短阶段工作量估算和长阶段工作量估算。
本文主要讲团队长阶段工作量估算（一般在一个月以上），它和很多因素有很密切的关系，我通常将它划分为以前几点：
1、所采用的过程。
在瀑布式过程下，风险会不断积累，应对变化的能力较弱，往往按计划发布了第一个版本，但是之后又由于需求或设计变更的幅度出现了大量工作量。相当多的团队就在这时失去了对工作量的控制。
在迭代式过程下，风险会较早的暴露以便针对性的解决，应对变化的能力较强，工作量投入相对比较平均，根据需求或设计变更的情况需要考虑部分甚至整体重构的工作量。
需求或设计变更幅度越大，则瀑布式比迭代式耗费的工作量越多。
需求或设计变更的幅度越小， 则瀑布式比迭代式耗费的工作量越少。
2、团队成员的个人能力。
将代码完善、测试的因素、可维护性等一并考虑在内，则一个优秀的开发人员的工作效率很可能是一个一般性的开发人员的工作效率的十倍
3、项目的计划以及任务的分配
在团队成员保持稳定的前提下，合理的人员结构、有节奏的计划、合理的任务分配将大大提升单位时间内的有效工作量，从而加快项目进度。
4、有效工作比率。
即在单位时间内的有效工作量，和人员士气、任务安排、工作的复杂度和难度等密切相关。
好的团队的有效工作量可以达到60-70%甚至再多一些，但是根据一个项目管理培训老师的说法，如果一个团队的有效工作量长期超过80%，那就要小心了。
5、风险预防。
包括需求变更、设计变更、人员变更等都会影响到实际的工作量，尤其是人员变更，往往无法由团队本身加以控制。

工作量估算模型：
该模型本质上是一个经验模型，主要针对业务复杂型且已有较成熟框架的项目，不知道是否适用于技术复杂型或者协调复杂型。
基于如下假设：
1、宏观上以迭代式（或阶段式）为主，每个迭代（或阶段）包含一个比较完整的需求、设计、开发、测试、发布的流程，各个迭代（或阶段）之间有交叉。
   总的来说是类似于rup的一个过程。
2、项目团队的结构、个人能力、参与度是一个典型的业务复杂型团队。其人员呈较为合理的纺锤型结构，允许部分人员较为薄弱。
项目管理：需求分析：设计：开发：测试：实施支持=0.5：1：1：2：1：0.5
注意：以上比例仅代表工作量比例，不代表团队成员比例，团队成员可以兼不同角色，
3、在每个阶段中，又分为以下几类工作：
1）初始细化。其主要目的是针对性的解决或预防风险，也包括技术架构甚至部分公共模块的开发。该部分工作量取决于风险的高低，通常占一个阶段的10—30%。
2）构造开发。以功能模块（或功能点）为基准单位，按比例分配需求、设计、开发、测试的工作量，参考比例为1：1：2：1。如果该模块包括数据迁移，则额外增加1份工作量。
3）实施支持培训。占一个阶段的5—10%
4）管理沟通协调成本，占一个阶段的10%左右。
4、功能模块（或功能点）工作量估算。
1个基准功能模块通常包含1-2个业务对象，每个业务对象中带业务逻辑的属性大约10个不到，包括该业务对象的简单行为：增、删、改、查。但不包括该业务对象的复杂行为。
在采用成熟框架的情况下下，该基准模块的工作量估算为15人天（取有一定经验的人员），包含初次开发及后续完善的工作量。此时有效工作比率为60%。
复杂行为视为简单行为的4倍。
特别复杂的功能点（包含有特定算法的）需要单独估算，在早期以5-10倍估算。
5、风险预防。此部分完全取决于对项目的评估，并综合各方面因素由各估算成员凭借经验得出。（德尔塔法）

其模型如下：
T=[（N*P）/S]*(1+X)
T：总工作量，单位为人天
N：基准功能模块数目，根据需求按经验评估，可按功能模块细化估算。
P：基准功能模块的工作量，通常取15人天。
S：构造开发工作量占整个阶段的百分比，在50%—75%之间
X：项目风险预防，根据经验取值，低的为10%，高的可以超过100%
注意：此工作量和进度并没有必然的联系，破坏项目结构的人员追加并不能带来进度上的利益。

请问 这样的方式你有实际运作过吗？

看着像第一版式的监理说明书(如果是第一版就是瞎写的)
又少又太理想了

楼下的如果有运作过的人
分享一下经验吧

是对我所了解的过往项目的经验总结，我基本是按这个思路来评估的，至于具体参数主要是靠参与人员的经验。

我经常被迫要预测一个月、三个月乃至更长时间的工作量估算，因此对这个问题是一直在思考之中的……

这份东西只是一个相对比较成熟的中间版本，拿出来和有类似经验的人讨论一下而已，呵呵。

长阶段估算很重要的一点在风险控制.
风险控制工具 可见另帖.
http://www.iteye.com/topic/30218

讲的很不错，不过在软件公司中有几家真正这样操作过的啊？项目经理中学习过《项目管理》的更别说有几个了！

大牛翻倍估算法：
“老大，象您这样的高手两个月就出来了吧？”
“这玩意？我看看……大概得三个月吧……”
“好！就报六个月！”

扯皮估算法
“老板，这真的不行，12个人月绝对够呛……”
“不不，咱们就这么多人，要不我给你从大学要几个学生来？”
（◎＃￥％※％……培训学生的成本恐怕还不只俩人月）
“或者总之我先按照最快的办法先干着，不行到时候再说……”

-------------------
以上不是原创，早年看过一个台湾人写的东西，但细节忘了……

同意楼上，现实中真的有很多如此例子.

开发技术稳定以及人员稳定的情况下，估个大概，还是有可能的，但实际情况很难。

在前期制定项目时间表，我们不得不评估时间，这是一个基础。

另外常常出现的问题，就是我们对风险的估计不足，不知如何给风险留出合适的时间。风险如何控制也是对风险有效评估的前提。

在这其中所使用的评估公式，经常要在项目过程中不断修正，因为这个公式毕竟是个经验公式，你经验积累的过程，也是个校正的过程。

常常遇到的情况，就是在项目开始的时候估一下之后，就对工作的估算的原理和模型不管不顾了，而是陷入解决项目的细节问题当中。