9.项目管理方面的工作。

项目管理工作主要有编制项目计划、持续更新项目计划、跟踪计划执行、各种工作协调、指导项目组成员完成工作等等。

项目管理工作量一般占整个项目工作量的10-20%，项目不明确的东西越多、项目组成员水平越不足、项目组成员之间工作磨合度越不好，管理工作量越大。

项目管理在项目进行整个过程都需要持续进行，一般来说前期工作量会比较大，版本发布前后阶段工作量也会比较大。项目管理前期工作抓得紧抓得好，会大大减轻后期的工作量。

10配置管理方面的工作。

什么叫配置管理？简单说是对工作产品的管理，包括对各类文档、各种记录、代码、数据库、脚本、安装程序、组件等等的管理。

软件生产过程的工作产品可分为两类：中间产物和终产物。

中间产物有：

1）工程类：需求文档、设计文档、测试方案、代码、数据库脚本、数据库、测试脚本等。

2）管理类：开发计划、测试计划、培训计划、采购计划、实施计划等。

3）记录类：会议记录、邮件、缺陷等。

终产物是指终会交付给客户的东西，一般有：组件、安装程序、数据库、用户手册、管理员手册等。

针对不同的工作产品应采取不同的针对性管理办法，很多公司会制定单独的配置管理计划。

11.质量保证方面的工作。

严格来说，质量保证是靠项目组全体来保证的，这里所说的质量保证是“狭义”的质量保证，是指：要确保项目组按照既定的规定、过程、标准来工作，需按照既定的格式要求产出相应工作产品。

对于以上十一点，实际项目估算中往往出现这样的问题：

1.忘记包含项目前期工作的工作量。

2.没有考虑商务、维护、配置管理、质量保证方面的工作。

3.需求调研、软件设计、编码、测试、实施方面的工作估计过少。

4.项目管理方面的工作量估计不足。

估算如何做出来？

这里开始所说的估算，全部都是指项目组对项目的估算，这个估算的目的是用来指导项目的具体工作。

有很多种估算办法，大致可以分为两类：

1.先得到软件规模，然后根据公司实际的生产率由软件规模导出工作量。

2.直接得到工作量。

第一类的常见方法有：功能点法、代码行法，第二类的常见方法有Delphi估算法、微软的由底而上估算法。

什么是软件规模？我们先看看一个搬砖头的估算。

假设有1000块砖头，它们的大小和重量一样，每名工人每天能搬100块砖头，于是我们可以估算到需要10人日来搬完。10人日的意思是1名工人需要10天完成，而10名工人只需要1天搞定了。

这个1000块代表了工作的规模，而生产率是100块/日，这样可以推算出工作量为10人日。建筑工程可以得到土石方量、混凝土量、钢筋量等代表工作规模的数据，这样比较容易推算出完成这些工作需要的工作量。

而软件工程估算也希望能做到类似的效果，但用什么来代表软件项目的工作规模呢？功能点和代码行是常见的两种软件规模表示方式。

软件规模是与软件具体生产技术、项目管理办法、项目组人员水平等无关的东西，软件规模只和软件项目本身的性质相关，如果我们能找到合适的统一的标准来度量每个项目的规模，这样每个软件项目之间可以进行横向比较了。功能点法和代码行法都希望能达致这样的效果。

功能点法的基本思路是将复杂的软件分解为一个一个独立的粒度一致的功能点，附加一些调整系数，得到软件规模。

我们的项目大部分是数据库四轮马车的操作（查询、增加、修改、删除），功能点法从比较高的层次对这些工作进行抽象，有一套严密的规则可以让你将需求分解成一个一个的功能点。代码行法思路也类似，不过分解的结果是代码行而已。但一般来说代码行与软件的实现技术相关度太大，大家会更加偏爱功能点法。

功能点法和代码行法有比较长的历史，也有很多详细资料，大家可以去查阅一下。这方法理论上很理想，但实践效果很差，我还没有见到一家能成熟应用并且取得比较好效果的公司。功能点法和代码行法有这样的一些难以解决的问题：

1.只适用于数据库四轮马车的操作的项目，高技术含量、创造性高的软件不适用，如游戏软件、计算机负责计算与决策软件等。

2.我们绝大部分项目是需求不明确、设计不明确，并且工期很赶的，这两个方法都无法适应这样的现实条件。需求不明确基本上无法得到软件规模，建筑工程为什么能做到，是因为需求和设计都十分明确了。

3.两个方法的规则都很详细，要花大量时间学习和实战才能掌握。

4.由工作规模导出工作量这样的思考方式，难以适用于软件项目。项目组还是习惯列出具体的任务，逐条任务估计时间，而且只有这样的工作方式才能让项目组感觉更加踏实。

Dephi估算法是比较符合大家实际工作习惯，也是比较容易掌握的估算办法。

Delphi法的大致方法如下：

1.找几名专家，一起对项目进行WBS，把项目的工作分解为十几条多二三十条的工作项。

2.全部专家各自估计每条工作项的工作量，并向其他专家阐述自己的理由。

3.第一次各专家估出来的结果可能差异比较大，每位专家听取别人的意见后，重新估算。

4.按照上述办法，各专家反复估算几次，一般次数是2-4次，各专家估计的工作量会越来越趋近，这个时候取全部专家的平均值。

普遍认为各专家的经验与知识水平会严重影响结果的准确性，而我的实践经验是：应该让项目组每个人自己来估算，也是让大家来当专家，在这个基础上可以再增加一两名来自项目组外部的专家。

有时候觉得估算这个问题搞得太复杂了，各式各样的方法是不是太夸张了？其实简单的方法是让负责该项工作的人自己来估计工作量，微软的由底而上的估算方法是这样做的，可谓返璞归真啊！