一个项目在前期调研的时候就要估计一下项目开发的周期大约有多长。有很多不同的估计方法，适合不同的项目类型。我平时设计 LabVIEW 编写的应用程序中用到过三种估计方法：代码量度量（Size-Based Metrics）、工作量估计（Effort Estimation）和专家估计（Wideband Delphi Estimation）。

    代码量度量的估计方法就相当于使用其它文本编程语言时的代码行估计法。一个软件需要多商行代码、每行代码要花多少时间，是相对来说比较容易统计的。所以代码行估计法是最流行的估计项目工时的方法之一。LabVIEW 的代码不是按行来计算的，它以节点数为计量单位。
    在 LabVIEW 的菜单上选择 Tools->Profile->VI Metrics 就可以调出如下的面板。这个 VI 度量面板可以帮你统计的的 LabVIEW 代码中总共有多少个节点。

图1：VI度量工具

    利用代码量度量方法估算工时的具体实施步骤大致如下：
    首先，先把项目拆分成小的模块。功能单一的小模块更容易进行准确估算。然后估计实现每个小模块需要多少 LabVIEW 代码（节点个数）。所有模块节点数的和就是整个项目所需的节点数，每个节点所需工时是已知的，所以整个项目的工时也就估计出来的。

    利用代码量度量方法估算工时，是需要有一些历史经验才行的。比如某种规模的功能模块到底需要多少节点，只有有过项目经验，统计过，才能心里有谱；写一个节点需要多少时间，对于不同类型的公司，不同经验的程序员，这一数值都是不同的。自己公司的每节点编程耗时，也只有做过之后才有数。

    如果缺少历史统计数据，可以使用精确度稍差一些的工作量估计法来估算项目工时。工作量估计法与代码量度量方法是很类似的。首先要把项目拆分成便于估算的小模块。但是，由于不便于对程序节点数进行估算，就只能评直觉，估计每个模块所需的工时，然后累加出项目总工时。

    Wideband Delphi Estimation 方法也可以用于缺少历史统计数据的情况，并且它的结论比工作量估计法要精确。只是这种方法实时起来比较麻烦，一般只有比较重要的项目，我们才会用此方法。
    Wideband Delphi 方法的实时过程大致如下。首先组织一个十人左右的团队，队员是来自不同部门但与此项目紧密相关的人，比如开发者、文档人员、测试人员等等。
    让所有队员各自估计一下项目所需的时间。
    把所有人凑到一起，把估计的结果汇总，让大家看看估计值的分布情况。然后由每个队员讲一下影响自己做估计的因素，包括有利的因素和不利的因素。比如有人会提出，我们的项目与某某项目很类似，可以借用那个项目中的很多代码。另一个人说，我们的项目用到一个什么非常难掌握的技术，可能会花费很多时间等等。
    等大家讨论过后，再各自重新估计项目的工时。
    然后在汇总，在讨论……
    经过几轮讨论估计后，大家估计出来的工时的差距就比较小了。取大家的平均值作为最终结果即可。

《我和 LabVIEW》