软件项目工作量评估方法

工作量评估
1概述
我们认真地阅读了软件的相关需求文档和设计文档后，对软件的功能进行了归纳和整理，并根据以往的经验对每个功能模块所需的编码工作量进行估算，再进一步地以此为依据，推算出整个软件生命期的工作量。

工作量推算后组织主要项目干系人和相关专家进行工作量评审。

2常见的估算方法
2.1Ad-hoc方法
这种方法下的测试工作量不基于任何确定的期限。

工作一直继续直到达到一些由管理或市场人员预先定下的时间表。

或者，一直到用完了预算的经费。

这种情况普遍存在于非常不成熟的组织，并且时常有100%的错误差数。

2.2开发时间的百分比法Percentage of development time。

这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。

首先，开发工作量使用例如LOC或FP方法被估算出来，然后使用一些探索性的方法来限制测试的工作量。

这种方法变化比较大而且通常基于以前的经验。

通常预留项目的总花费时间的35%给测试, 5-7%给组件和集成测试,18-20%给系统测试, 10%给接收测试（或回归测试等）
2.4类比法（经验值法或历史数据法）
根据以前或相似项目（主要在项目性质，领域，规模上有相似）所积累的经验或历史数据来估算工作量。

类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。

需要收集以下相关的历史数据：在设计和实现阶段花费的时间，测试工作的规模，例如用户需求的数量，页面数，
功能点，数据样式，例如实体，字段的数量, 屏幕或字段数量,测试对象的规模，例如KLOC
2.5 WBS（work breakdown structure）估算法
将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和得出项目或产品的测试工作量/时间。

2.6 Delphi法
Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。

Delphi法鼓励参加者就问题相互讨论。

这个技术，要求有多种相关经验人的参与，互相说服对方。

Delphi法的步骤是：1、协调人向各专家提供项目规格和估计表格；2、协调人召集小组会各专家讨论与规模相关的因素；3、各专家匿名填写迭代表格；4、协调人整理出一个估计总结，以迭代表的形式返回专家；5、协调人召集小组会，讨论较大的估计差异；6、专家复查估计总结并在迭代表上提交另一个匿名估计；7、重复4-6，直到达到一个最低和最高估计的一致。

2.7 PERT估计法
PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。

用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计。

Pert 估计可得到代码行的期望值E，和标准偏差SD
3.估算前准备
针对以上方法，我司综合了以上多种评估方法，总结出了适合我司的评估方法：
1）对工作进行WBS分解，尽量将任务分配到半天为工作单位的粒度，分解时需要考虑deadline、技术难点、需求变更风险等等因素。

2）尽量寻找和本项目相近项目做参考，参考历史相近项目的实际工作量和项目进度情况。

3）尽量邀请有历史经验或者对项目熟悉的专家，参与项目工作量的评估，以提高工作量评估的有效性。

4）整理工作任务的关系和客户需求的优先级，寻找项目任务的关键路径，以保证项目周期的合理性和周期最短。

5）确定项目评估工作的基线，以一名2年工作经验的开发人员为评估对象，选择了一个有10个字段的比较有代表性的业务表单，从开始到结束，精确统计了每个步骤需要的消耗的工时数。

采用四舍五入法最终制作了如下的工时估算表：
6）确定技能系数，由于标准工时是按2年经验的工程师能力为基准，所以需要那工程师能力设置能力系数，工作3到6年的工程师，每增加1年工作经验则工时=标准工时*(1-0.1),6年以上一般按6年算。

3.1 WBS分解原则
3.1.1 WBS的定义
WBS（工作分解结构）是Work Breakdown Structure的英文缩写，是项目管理重要的专业术语之一。

WBS的基本定义：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。

无论在项目管理实践中，还是在PMP，IPMP考试中，工作分解结构(WBS)都是最重要的内容之一。

WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。

WBS同时也是控制项目变更的重要基础。

项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。

WBS是由3个关键元素构成的名词：工作（work)--可以产生有形结果的工作任务；分解(breakdown)--是一种逐步细分和分类的层级结构；结构(structure)--按照一定的模式组织各部分。

根据这些概念，WBS有相应的构成因子与其对应：
（１）结构化编码
编码是最显著和最关键的WBS构成因子，首先编码用于将WBS彻底的结构化。

通过编码体系，我们可以很容易识别WBS元素的层级关系、分组类别和特性。

并且由于近代计算机技术的发展，编码实际上使WBS信息与组织结构信息、成本数据、进度数据、合同信息、产品数据、报告信息等紧密地联系起来。

（２）工作包
工作包（work package）是WBS的最底层元素，一般的工作包是最小的“可交付成果”，这些可交付成果很容易识别出完成它的活动、成本和组织以及资源信息。

例如：管道安装工作包可能含有管道支架制作和安装、管道连接与安装、严密性检验等几项活动；包含运输/焊接/管道制作人工费用、管道/金属附件材料费等成本；过程中产生的报告/检验结果等等文档；以及被分配的工班组等责任包干信息等等。

正是上述这些组织/成本/进度/绩效信息使工作包乃至WBS成为了项目管理的基础。

基于上述观点，一个用于项目管理的WBS必须被分解到工作包层次才能够使其成为一个有效的管理工具。

（３）WBS元素
WBS元素实际上就是WBS结构上的一个个“节点”，通俗的理解就是“组织机构图”上的一个个“方框”，这些方框代表了独立的、具有隶属关系/汇总关系的“可交付成果”。

经过数十年的总结大多数组织都倾向于WBS结构必须与项目目标有关，必须面向最终产品或可交付成果的，因此WBS元素更适于描述输出产品的名词组成（effictive WBS，Gregory T. Haugan）。

其中的道理很明显，不同组织、文化等为完成同一工作所使用的方法、程序和资源不同，但是他们的结果必须相同，必须满足规定的要求。

只有抓住最核心的可交付结果才能最有效的控制和管理项目；另一方面，只有识别出可交付结果才能识别内部/外部组织完成此工作所使用的方法、程序和资源。

工作包是最底层的WBS元素。

（４）WBS字典
管理的规范化、标准化一直是众多公司追求的目标，WBS字典就是这样一种工具。

它用于描述和定义WBS元素中的工作的文档。

字典相当于对某一WBS元素的规范，即WBS元素必须完成的工作以及对工作的详细描述；工作成果的描述和相应规范标准；元素上下级关系以及元素成果输入输出关系等。

同时WBS字典对于清晰的定义项目范围也有着巨大的规范作用，它使得WBS易于理解和被组织以外的参与
者（如承包商）接受。

在建筑业，工程量清单规范就是典型的工作包级别的WBS字典。

3.1.2 WBS的主要用途
WBS是一个描述思路的规划和设计工具。

它帮助项目经理和项目团队确定和有效地管理项目的工作。

● WBS是一个清晰地表示各项目工作之间的相互联系的结构设计工具。

● WBS是一个展现项目全貌，详细说明为完成项目所必须完成的各项工作的计划工具。

● WBS定义了里程碑事件，可以向高级管理层和客户报告项目完成情况，作为项目状况的报告工具。

● WBS防止遗漏项目的可交付成果。

● WBS帮助项目经理关注项目目标和澄清职责。

● WBS建立可视化的项目可交付成果，以便估算工作量和分配工作。

● WBS帮助改进时间、成本和资源估计的准确度。

● WBS帮助项目团队的建立和获得项目人员的承诺。

● WBS为绩效测量和项目控制定义一个基准。

● WBS辅助沟通清晰的工作责任。

● WBS为其他项目计划的制定建立框架。

● WBS帮助分析项目的最初风险。

3.1.3WBS的创建方法
创建WBS是指将复杂的项目分解为一系列明确定义的项目工作并作为随后计划活动的指导文档。

WBS的创建方法主要有以下两种：
● 类比方法。

参考类似项目的WBS创建新项目的WBS。

● 自上而下的方法。

从项目的目标开始，逐级分解项目工作，直到参与者满意地认为项目工作已经充分地得到定义。

该方法由于可以将项目工作定义在适当的细节水平，对于项目工期、成本和资源需求的估计可以比较准确。

创建WBS时需要满足以下几点基本要求：
● 某项任务应该在WBS中的一个地方且只应该在WBS中的一个地方出现。

● WBS中某项任务的内容是其下所有WBS项的总和。

● 一个WBS项只能由一个人负责，即使许多人都可能在其上工作，也只能由一个人负责，其他人只能是参与者。

● WBS必须与实际工作中的执行方式一致。

● 应让项目团队成员积极参与创建WBS，以确保WBS的一致性。

● 每个WBS项都必须文档化，以确保准确理解已包括和未包括的工作范围。

● WBS必须在根据范围说明书正常地维护项目工作内容的同时，也能适应无法避免的变更。

● WBS的工作包的定义不超过40小时，建议在4-8小时。

● WBS的层次不超过10层，建议在4-6层。

3.1.4WBS的表示方式
WBS可以由树形的层次结构图或者行首缩进的表格表示。

在实际应用中，表格形式的WBS应用比较普遍，特别是在项目管理软件中，具体的模版样式参见WBS 模版样式。

3.1.5 WBS的分解方式
WBS的分解可以采用以下三种方式进行：
● 按产品的物理结构分解。

● 按产品或项目的功能分解。

● 按照实施过程分解。

3.1.6 项目组内创建WBS的过程
项目组内创建WBS的过程非常重要，因为在项目分解过程中，项目经理、项目成员和所有参与项目的部门主任都必须考虑该项目的所有方面。

项目组内创建WBS的过程是：
● 得到范围说明书(ScopeStatement)或工作说明书(StatementofWok，承包子项目时)。

● 召集有关人员，集体讨论所有主要项目工作，确定项目工作分解的方式。

● 分解项目工作。

如果有现成的模板，应该尽量利用。

● 画出WBS的层次结构图。

WBS较高层次上的一些工作可以定义为子项目或子生命周期阶段。

● 将主要项目可交付成果细分为更小的、易于管理的组分或工作包。

工作包必须详细到可以对该工作包进行估算(成本和历时)、安排进度、做出预算、分配负责人员或组织单位。

● 验证上述分解的正确性。

如果发现较低层次的项没有必要，则修改组成成分。

● 建立一个编号系统。

● 随着其他计划活动的进行，不断地对WBS更新或修正，直到覆盖所有工作。

3.1.7 WBS的检验标准
检验WBS是否定义完全、项目的所有任务是否都被完全分解主要依据以下标准：
● 每个任务的状态和完成情况是可以量化的。

● 明确定义了每个任务的开始和结束。

● 每个任务都有一个可交付成果。

● 工期易于估算且在可接受期限内。

● 容易估算成本。

● 各项任务是独立的。

3.1.8 WBS的使用
对WBS需要建立WBS词典(WBSDictionary)来描述各个工作部分。

WBS词典通常包括工作包描述、进度日期、成本预算和人员分配等信息。

对于每个工作包，应
尽可能地包括有关工作包的必要的、尽量多的信息。

当WBS与OBS综合使用时，要建立账目编码(Code ofAccount)。

账目编码是用于惟一确定项目工作分解结构每一个单元的编码系统。

成本和资源被分配到这一编码结构中。

3.1.9WBS的实践经验
最多使用20个层次，多于20层是过度的。

对于一些较小的项目4－6层一般就足够了。

WBS中的支路没有必要全都分解到同一层次，即不必把结构强制做成对称的。

在任意支路，当达到一个层次时，可以作出所要求准确性的估算，就可以停止了。

编辑本段WBS推广模式
W：即Web网站，企业用于在互联网上展示自身形象和产品宣传的一个平台，凭借网站企业可以让互联网上更多的用户和浏览者了解和认识企业，以便达到更好的宣传，主要面向客户、业界人士或者普通浏览者，以介绍企业的基本资料、帮助树立企业形象为主；也可以适当提供行业内的新闻或者知识信息。

这种类型网站通常也被形象的比喻为企业的"WEB Catalog"。

是每一个外贸公司对外贸易不可缺少的形象代言。

B：即B2B电子商务平台，主要面向供应商、客户或者企业产品（服务）的消费群体，以提供某种直属于企业业务范围的服务或交易、或者为业务服务的服务或者交易为主；中国最权威的互联网信息中心统计，目前有20%左右的企业已经意识到电子商务的重要性，其中2007年做推广的企业有80%左右的都是通过B2B推广的。

Alibaba、Tradett、GlobalSource、Made-in-China、Tradekey、ECVV、
EC21、Worldbid等国际知名B2B是大多企业主要推广平台。

对于外贸来说,B2B是一个强有力的工具,毕竞并不是所有的人都能碰到一个能让你参加广交会,参加法兰克福展的老板或公司的. 那么, 使用/利用B2B就将是公司动作过程中一个很重要的部分。

S：即SEO，搜索引擎优化，为近年来较为流行的网络营销方式，企业网站经过特定的方式进行SEO之后，可以增加特定关键字的曝光率以增加网站的能见度，提高企业网站在搜索引擎中的排名，从而提高网站访问量，最终提升网站的销售能力或宣传能力的技术。

3.2 deadline的使用
Deadline是在期限，软件领域deadline的概念就是从传统的印刷媒体中得来。

然而，不能仅因为目前在软件领域尚无通用的deadline概念，就以为该摒弃这个概念，或以为它没有价值。

就工作的规划和并行处理来说，deadline是极其重要的。

如果没有预计的完工期限，所有团队都必须连轴工作，同时也会大大减少交付次数。

而且如果不明白deadline的真正含义，那么deadline可能会让人感到沮丧，甚至产生相反的效果。

问题及解决方案
以下是根据我司的经验总结出来的，在公司中与deadline最为相关的问题，以及最有可能解决问题的办法。

1）对deadline的理解因人而异
A：“下周才是deadline，我还有大把的闲余时间！”
B：“为什么要担心这个？没关系的，deadline什么的当不得真。

”
A：“但我不想被炒鱿鱼啊！”
这组对话就很形象地展示了对同一个deadline，A和B两人在理解上有着巨大的差异，这也会导致整个团队在努力实现deadline时出现困惑与挫败感。

事实上，deadline必须要有号召力，每个人都得知道deadline重要的原因，他们必须明白错过deadline会对整个圈子有什么样的影响，包括对其他团队的、对客户的或者对公司整体的影响。

更重要的是，那些达成的deadline需要热烈的庆祝，而这一点常被忽视掉。

比起责备那些错过deadline的员工，建立起为达成deadline庆祝的企业文化才是上上之策。

2）在项目的生命周期中过早设定deadline
向一个各方面都属于未知状态的项目要求一个deadline简直后患无穷，也让项目涉及到的员工压力很大，为项目立起了失败flag。

所以，先深呼吸，耐心等两天，让大家完成探索工作。

虽然搜集信息花费了时间，但之后我们却能给出有意义的评估，这些信息会帮助我们设定更加准确的deadline。

3）deadline更新频度不够
在新问题出现时，开发人员并未调整或重新评估deadline，某个开发人员没能立即提出问题，而是等到deadline才告知他人，于是其他开发人员也受此牵连，而整个团队也会因为要赶工另一个deadline而倍感压力。

设定deadline不应当是为了强迫员工超额负荷，把人当牲口用，而应用以设定外部对项目的预期，让计划呈现可预期性。

Deadline必须尽可能准确地反映现实情况，否则一旦出现信任危机，这个概念也就失去了传递可预期性的功能。

当然，我不提倡每小时或每天更新deadline的行为，但也许每周更新，或至少按标准计划的节奏来更新是个不错的主意。

更新deadline并不拘于延长时间，也可以缩短周期。

至于具体怎么做，又或
者兼而有之，都得工程师和产品团队商榷后确定。

4）未将所有“已知工作”都纳入考虑范围，仅考虑到了有趣的那些
在设定这个deadline时，相关人员对要完成的工作以及要投入的时间缺乏完
整的理解。

在设定deadline时，我们应当确保将所有已知的挑战都涵盖在内，是否会因
某个已知原因而浪费一些时间，比如说度假、公司断网、因为生日派对宿醉而迟到.
另外我们是否可能遗忘了某些不起眼的任务？这个项目打算写多少测试？如
何将这玩意儿发布到生产环境中？跟着这些问题放慢脚步，仔细思考下整个过程以及可用的资源。

这样做会让设定deadline简单得多，同时这样设定出的deadline
也更经得起考验。

关于评估：令人不适，但却是必要的
工程师所设定的deadline很大程度上是通过评估形成的，也就是说团队中的
每个人都要习惯犯错，犯很多错——将自己知道不对或是没信息的地方说出来，可能会很困难。

我们必须达成共识，尽可能准确地作出评估，并随着时间评估地越来越准
确。

评估是一项技能，反复使用会熟能生巧。

初期可能会让人不适，但这是我们需要做到的。

评估任务
在定下大型项目的交付时间前，我们应当将整个项目拆分成小的任务，每个
任务应当能在约五个工作日内完成。

以下问题对评估任务十分有用：
● 这个项目是新建的，还是之前就有的？
● 这部分代码质量如何？
● 我对这部分代码的熟悉程度如何？
● 对涉及的编程语言熟悉程度如何？
● 与其他代码段在哪里有接触或集成点？
● 现有的测试覆盖率如何？
● 这项工作是否涉及关键业务（写入路径、计费、负载均衡器、注册）？
● 之前是否有人参与过这项工作？他们有何想法？
● 有哪些问题需要做出权衡？
● 这项任务的目标是什么？
● 这项任务究竟是否需要完成？
评估工程项目
工程项目通常被视为一个较大的任务，可以让多人并行完成。

下面这些问题有助于评估项目：
● 我们实际要在这个项目上花费多久时间？
● 这个工程项目的目标是什么？
● 是否有已知会安排的休息时间？
● 所有要完成的任务有哪些？
● 是否对其他团队有依赖，还是障碍性的？
● 项目中是否有任务对其它任务产生障碍？
● 该项目是否需要新的基础设施或硬件？
● 该项目的完工标准是什么？
完工标准
即便要知道某项工作是否完工都是很困难的，团队中不同角色可能会有不同的“完工”标准，因此我们需要指定某个项目的具体完工标准。

下面是典型完工标准的一些样例：
● 部署到生产环境；
● 全自动化测试；
● 与公司内部或第三方人员沟通；
● 在公司内部或外部进行了一定量的测试；
● 为生产环境编制文档；
● 完成对销售或推广团队的讲解；
● 发布登录页面；
● 分析并追踪；
● 操作运行手册与系统可观测性。

3.3需求变更管理
变更是无法避免的，作为一个合格的项目经理，我们应该有有效的方法来管理项目变更。

当项目的某些基准发生变化时，项目的质量、成本和范围等随之发生变化，为了保证项目目标实现，就必须对项目发生的各种变化采取必要的应变措施，这种行为就是项目变更。

项目变更产生的原因是多样的。

以下是一些常见原因：
（1）项目外部环境发生变化；
（2）项目总体设计，项目需求分析不够周密详细；
（3）新技术的出现、设计人员提出新的设计方案或者新的实现手段；
（4）建设单位由于业务变化、机构重组等原因造成业务流程变化。

（5）其它原因
我们再来仔细分析一下，上面的案例中的做法，会出现怎么样的问题
开发人员在听到用户的口头抱怨后，就直接对系统软件进行了修改，解决用户的问题，显然是不符合流程的。

下面列举三条不合理的地方：
首先，开发人员没有书面记录用户的变更需求，可能会导致对系统软件变更的历史无法追溯；
其次，没有认真评估用户的变更需求是否合理，这样可能会导致与项目现有的工作可能不一致，导致影响成本、进度或者项目质量；
再次，进行变更时，没有与其他项目相关成员进行沟通，可能会导致其他项目成员的工作不一致。

那么我们应该怎样来处理项目中出现的变更需求呢？最好的办法是建立一套正规的程序对项目的变更进行有效的控制。

简单地说，管理变更的程序包括以下几个步骤：
（1）识别变更：分析项目中出现的问题是否属于变更需求，区分是否为变更需求的标准就是，某项工作是否不在项目工作基准中；
（2）评价变更对项目的影响：如果属于变更需求，进行分析，变更会对项目成本、进度、质量等因素产生哪些影响；
（3）设计变更的备选方案：列出几种可能的变更处理方案，比如说非常紧急的变更需求马上批准，而对项目影响较少的变更可以稍后再处理；
（4）提出变更申请：正式提出书面的变更申请需求；
（5）征求项目干系人的意见:所有与变更有关的项目干系人（注：项目干系人指所有与项目有正面与负责利益的人之和）都应该参与项目变更；
（6）批准或否决变更:提交相关项目管理人员，批准或者否则项目变更；
（7）追踪变更的实施情况:变更批准后，我们需求跟踪变更的执行情况，并且要记录在案。

3.4 寻找项目关键路径
3.4.1 项目关键路径定义
项目关键路径，在项目管理中，关键路径是指网络终端元素的元素的序列，该序列具有最长的总工期并决定了整个项目的最短完成时间。

关键路径的工期决定了整个项目的工期。

任何关键路径上的终端元素的延迟将直接影响项目的预期完成时间（例如在关键路径上没有浮动时间）。

2.4.2 如何寻找关键路径
活动定义、活动排序以及资源和历时估算的结果就构成了制定项目进度计划的基础。

项目的进度计划既是回答每个活动的进度安排，而更重要的是得到有关项目整体的进度信息。

制定项目进度计划的工具和方法有：甘特图，关键路径分析和PERT估计。

这是一种用日历形式来列出项目活动及其活动起止时间的项目图示方法。

由于这种图形表示方法最初是由泰勒的同事亨利.干特所发明，所以又被称作甘特图。

现在大多数项目管理软件都可以自动生成甘特图。

在项目的甘特图中，有几个特殊的符号需要关注：
任务（Task），用带状的水平横道来代表一个任务，所以有的时候甘特图又叫横道图。

横道的起点和终点就代表了任务的起止时间，横道的长度就代表了任务的持续时间。

里程碑（Milestone），具有零历时的重要事件。

在图中用菱形符号代表。

依赖关系（Dependency），指各个任务之间存在着一定的依赖关系，例如：结束－开始，开始－开始，结束－结束，开始－结束关系。

概要任务（Summary Task），是指的一些任务集合成一个更大的任务，通常代表了任务的不同层级。