Relax中的量化管理

目  录

1                 概述... 3

1.1.        量化管理的必要性... 3

2                 Relax™的量化模型... 4

2.1.        基础概念... 4

2.1.1.       里程碑... 4

2.1.2.       风险系数... 4

2.1.3.       风险因子... 5

2.1.4.       迭代周期... 5

2.1.5.       风险缓冲... 5

2.2.        组织级参数... 5

2.2.1.       风险级别—工作量... 5

2.2.2.       里程碑—权重... 6

2.3.        项目级参数... 6

2.3.1.       三个时间... 6

2.3.2.       四个风险因子... 7

2.3.3.       三个进度... 8

2.3.4.       三个优先级别... 9

2.4.        算法描述... 9

2.4.1.       风险评估方法... 9

2.4.2.       Relax™中的算法... 9

2.4.3.       举例... 10

2.5.        进度计划... 11

 

1       概述

1.1.   量化管理的必要性

如果我们承认软件开发行为是一种工程活动，那么，在管理上它与传统工程项目定然有相似之处。我们回头考察下盖楼、架桥、铺路、冶金、开矿等传统工程领域，也考察下诸如生物、电子等等与“软件”一样年轻的工程领域，我们会发觉一个事实：项目管理本质上是一种技术管理和微观管理，而其每个环节都离不开量化。

但是，作为智力活动，软件开发自有其特殊性。我们无法用建模来说明投入多少思想然后就会会产出多少可工作的代码。但半个世纪以来，软件工程思想家们进行了深入的探索，如Barry Boehm、Fred Brooks、温伯格等人的论述；软件开发业界也积累了大量的工程实践，比如用什么模式，解决什么类型的问题；什么样的项目，要用何种平台和技术；我们也从生产管理领域吸取了好的经验，如从丰田生产方式(TPS)中学到了精益生产的理念。如此等等，这些探索和实践总结出了软件开发活动的一些基本规律，为估算和量化提供了基础。

要使软件开发成为一种可控的活动，我们必须将软件开发中的“工程行为”的比例尽量提高到，将“艺术行为”的比例尽量降低。也就是说，软件开发要告别混沌和不稳定的状态，走向可控和可量化的工程化方向。提到软件量化，反对的声音大抵可以分为两类：

1.       默认了软件开发活动本质上就是混沌的，认为智力活动无法量化；

2.       对敏捷一知半解，惯性地认为量化就是重型过程的做法或瀑布思维；

对于第一种声音，我们可以理解为并坦承软件开发活动无法做到精确量化；对于第二类反对者不做批驳，事实上，量化管理与敏捷毫无冲突，相反地在管理中要运用诸多敏捷的最佳实践才能得到有效的量化结果。

如同萨缪尔森将数理方法引入到经济学研究中一样，现在用数理方法研究经济学已经理论经济学家的共识。用量化的方式管理软件项目，相信也将会成为软件项目管理者和开发者的共识。

       本文之后的部分会涉及到FDD(Feature-Driven Development)的相关基础知识，请读者朋友们参看《An Introduction to Feature Driven Development》一文。

 

2       Relax™的量化模型

众所周知的、智力活动无法通过缜密的数学建模和工程计算以获得精确的结果。那么软件量化管理本质上是基于统计方法和经验方法进行的，准确度要视开发/业务经验和量化方法而定。下面的内容详细阐述在Relax™中是如何做的。

2.1.    基础概念

为了下文叙述的方便，我们先将一些概念性的知识作个解释。

2.1.1. 里程碑

为了深入到细节对软件开发过程进行控制，Relax™中对每个Feature的开发定义了6个里程碑，贯穿了需求到构造的整个过程。如下表所示：

里程碑( 阶段)

对应的英文名

需求走查

Walk Through

设计

Design

设计审查

Design Inspection

编码

Coding

代码复查和单元测试

Code Review & Unit Test

提交构造

Promote to Construction

 

每个里程碑的名称都能见名知义，无须再做解释。6个里程碑看起来类似于一个小瀑布流程，但本质上这不是瀑布模型，而是为了采样开发中的进度和质量信息而设置的若干个控制点，这也体现了FDD的严谨性。

2.1.2. 风险系数

风险系数是用以确定某个Feature风险高低的一种分类方法，在Relax™中，我们将风险系数分为5级，分别用数字1～5表示。至于为什么是5级而不是4级或6级，这是认知学中的一个理论：人们对于超过5个以上的分类会感觉到过于复杂而理解困难。Jeff De Luca认为软件开发80%是心理学，我们在采用一些量化手段时也需要充分顾及到软件开发者的心理反应。

2.1.3. 风险因子

风险因子(Risk Factors)也称之为风险指标，是用以衡量某一种因素为项目所带来的风险的量化体现。Relax™中定义了4种风险因子，被分为两组。

2.1.4. 迭代周期

大多数软件过程模型都给出一个建议的迭代周期长度。比如RUP建议每个迭代为3个月、FDD中的标准迭代周期是2星期。即单个Feature的工作量不超过2星期；一个主程序员工作包的工作量不超过主程序员小组全体成员工作2星期。这是一种控制粒度非常细、交付非常频繁的迭代方式，体现了FDD的高度敏捷性。

2.1.5.    风险缓冲

所谓风险缓冲就是一种用以化解不确定性、规避风险的额外资源，通常是时间或者人工(Relax™中用工作量体现，通过调整进度参数实现)。

2.2.    组织级参数

所谓组织级参数，即这些数值在整个开发组织范围内是一致的，它表示一种政策性的规定或者根据统计而得到的具备较高置信度的一组数据。

2.2.1.    风险级别—工作量

风险级别

工作量(人日)

说明

Level 1

0.5

表明此级别的任务只需一个开发者半工作日即可完成。

Level 2

1.0

 

Level 3

3.0

 

Level 4

5.0

 

Level 5

8.0

最高风险级别，表示一个开发者需要8 – 10个工作日.

上表中所给出的数值是Relax™所提供的参考值，各软件开发组织需要根据以往的经验进行修正。如果没有既往数据可以参考，则可先制定一个标准，尔后再做微调。

如果一个Feature被评估后工作量高于2星期，则意味着我们还需要对这个Feature作进一步的分解以获得更细粒度的Feature。当然分解的依据是“最小的具有业务价值的”单位。

2.2.2.    里程碑—权重

Relax™通过为每个里程碑赋予一个权值以计算当前进度信息。推荐值如下表所示：

里程碑( 阶段)

权重(%)

需求走查

3

设计

35

设计审查

5

编码

50

代码复查和单元测试

5

提交构造

2

同样地，软件开发组织可以根据自己的经验对权重进行调整，但请注意：权重之和应该等于100%。上表所给出的数据源自于FDD文献中所推荐值并根据我们多年的实践经验加以修正而得到。

通常而言，风险级别—工作量对应关系可以是“行政”性质的规定，各项目照章遵循即可。而里程碑—权重对应关系则应来源于统计数据，否则可能与实际开发场景不吻合。

2.3.    项目级参数

项目级参数是根据每个项目的特定情况而设置的，只适用于该项目范围。

2.3.1. 三个时间

时间

说明

项目开始时间

项目什么时候开始，这是个商务问题

项目结束时间

项目什么时间必须交付，这也是个商务问题

开发开始时间

项目启动至正式开始开发，中间会有一段准备时间，比如签订合同、开项目启动会、熟悉客户、筹建团队、调研需求等等。这一段时间不是有效的开发时间，为了降低不确定性对项目的负面影响，Relax™将其排除在外，并用此事件计算进度。

2.3.2. 四个风险因子

下表所定义的4个风险因子是Relax™进行量化管理的核心要素，我们会加以详细的解释说明。

风险因子(指标)

说明

业务复杂度(f1)

1～5之间的一个数值，用以衡量业务的复杂程度。1表示最低，5表示最复杂。请详细分析业务后作出一个判断。

技术难度(f2)

1～5之间的一个数值，从技术的角度评判其复杂度。

业务重要性(f3)

1～5之间的一个数值，请从商业角度与客户一起分析该Feature的重要性。如果无法与客户一起工作，也请站在客户的立场/角度考虑。

客户排斥程度(f4)

1～5之间的一个数值，如果软件不包含此Feature，客户的负面反应激烈程度。与“业务重要性”指标配合使用，此指标从反面刺激客户，以更真实地评判该Feature的重要性。

事实上，上表的4个指标可分为两组：f1和f2是性质相同的一组；f3和f4是性质相同的一组。“业务复杂度”和“技术难度”是用以估算工作量的主要指标；“业务重要性”和“客户排斥程度”是用以确定优先级并配置风险缓冲的指标。请注意，后一组指标本身也是整体风险中的一分子，而不是补偿性的，因此4个指标共同分担整体风险(100%)。

每个风险因子的重要程度是不同的，因此，还需要在项目的层面上为每个风险因子确定一个权重，以便于Relax™计算工作量：

风险因子(指标)

权重(%)

说明

业务复杂度(f1)

45

至于是I1比重高还是I2比重高，视项目情况而定。如果是一个纯技术型的项目，那么I2就高；如果是一个业务复杂的ERP系统，则I1就高。

技术难度(f2)

40

业务重要性(f3)

10

这一组指标对工作量的影响程度较弱，因此给出一个较低的权值。

客户排斥程度(f4)

5

上标中所列的数值不具有参考意义，只用于示范说明。项目管理人员应根据项目具体情况为每个指标分配恰当的权值。请注意以上四个值之和为100%。

2.3.3. 三个进度

Relax引入了三个进度参数，这些参数将被用在进度控制和PERT分析中。下面我们将对这些参数逐一详细解释。

悲观进度：考虑到各种风险因素，商业的和技术的，完成项目所需要的时间；

乐观进度：在最理想的状态下，完成项目所需要的时间；

最可能进度：介于悲观与乐观之间，在积极应对风险的情况下完成项目所需的时间。

以上三个进度参数都是通过对所有特征逐一进行风险评估所得到的实际的值为基础并乘以一个系数而得出的。我们可以这样理解：悲观进度是用来向客户和领导层报告的，这样能为项目争取到抵御风险的缓冲期；乐观进度是用来激励开发团队的，通过我们高效努力的工作，有可能在这个时间内完成项目；最可能进度则是项目执行过程中用以衡量实际进度的，Relax™的自动计划功能就是以最可能进度(TM)作为基础的。

如何确定项目所需的缓冲区？这要根据开发团队对项目状况的信心而定。需求质量极其糟糕的项目，缓冲区可能高达300%。我们建议即便是置信度为100%的项目，缓冲区也不能少于15%，因此在项目执行过程中有很多无法实现预测到的影响因素。

我们的经验表明，正常情况下通过FDD和Relax™通常能将项目进度偏差控制在预期的-15%~20%之间，也就是说可能提前15%的时间完成，也可能延迟20%的时间完成。因此我们采用了下表的缺省值，当然你也可以根据实际情况予以调整。

进度参数

比值(%)

说明

悲观进度(TP)

130

建议缓冲区不要低于15%的最低安全线

乐观进度(TO)

84

这是在正负一个标准差范围内可如期完成项目的可能性

最可能进度(TM)

110

Relax将以此作为项目自动计划的时间基础

期望进度(TE)

PERT计算

统计学公式为：(TO + TP + 4TM) / 6

根据您对风险因子的评值，Relax™计算得到一个工作量值。再用这个工作量乘以最可能进度，这就是Relax™中考虑了风险缓冲的进度控制机制的基础。请注意，Relax™ 中有双重的风险缓冲保护：

首先，风险因子f3和f4提供了一个额外的缓冲用以化解重要性带来的风险；

其次，调整最可能进度的比值，再提供一重缓冲保护以降低其它不确定性带来的风险。

2.3.4. 三个优先级别

与上文所述，风险因子f3和f4联合起来用以确定Feature的重要性。重要性的作用之一是用以判断Feature优先级。为了简单起见，Relax™将优先级分为三类：

优先级范围

优先级

说明

2.0～5.0

雪中送炭

必须要提供的

1.0 ~2.0

锦上添花

最好能提供的

< 1.0

可有可无

没有也无所谓，有当然也行

2.4.    算法描述

2.4.1. 风险评估方法

所有的评估都是针对Feature进行的(关于Feature的定义请参考《Relax™的需求模型》)。评估的方式Relax™不做限定，比如可以采用Delphi法。我们推荐的方法是项目组主要成员(最起码是主程序员)与客户方的领域专家集体参与评估，较之由项目经理拍脑袋，这样得到的结果更具价值。

详细分析每个Feature，请为四个风险因子分别赋以一个1～5之间的数值。当然也可以是小数。

2.4.2. Relax™中的算法

A.    RC(Risk-Coefficient)  

上面的公式中，Fk代表第k个风险因子的值,FWk代表第K个风险因子的权重

B.    Workload = Fuzzy（RC, Risk-Level→Workloads）

C.       Workload-With-Buffer = Workload  T_most-likely

D.    Priority = (F3*FW3/FW4 + F4) / (FW3/FW4 + 1)

如果RC的值是一个整数，就正好能对应到某个风险级别上。否则如果其值是小数，无法准确对应到某个风险级别上，则采用公式B的模糊算法进行处理。举例说明：风险系数为3.7，应该对应Level3还是Level4？答案是无论你对应到Level3还是4都不准确。那么，我们可以认为，3.7属于Level4的概率是70%，属于Level3的概率是30%，即结果为3.7 x 0.7 x 5 + 3.7 * 0.3 x 3，通过这样的模糊算法处理之后，置信度更高一些。

请注意，评估后能看到的结果是公式B所计算出的Workload的值，某个Feature工作量是3.5人日、某Feature工作量是7.2人日，诸如此类。

但在实际进度控制中，采用的是公式C的计算结果，其中包含了一段风险缓冲。虽然上面的计算结果可以精确到小时或者分钟，但如此细微的粒度在实际开发活动中是不具备可行性的。因此Relax™的自动计划和进度控制都是以“人/日”为粒度的，只要在自然日历的天的范围内，则不认为是延迟。

2.4.3. 举例

下面我们用一个小例子来说明在实际项目环境下如何采用上述方法量化。除了特殊说明外，组织和项目级参数采用上面相关表中的数值。

假设某个实时生产系统具有下面文字所表述的这个Feature:

EXA-00002: 接收从风电机组上采集到的实时数据，频率为5秒

首先我们需要采用Delphi一类的方式给4个风险因子评值。评价之前，我们应该对这个Feature有个最基本的印象：这是一个技术性很强，但业务相对简单的功能。加入机组采用的是OPC协议，我们就需要具备OPC相关的技术；如果风场采用了SCADA，又该如何处理……反正都是技术性的细节。并且这个Feature非常重要，数据采集不上来，监控和分析就无从谈起。那么经过讨论之后得出了如下结果：

风险因子

权重(%)

值(1.0~5.0)

说明

业务复杂度(F1)

35

3.5

这是一个技术型的项目，因此F2的比重设置得相对较高。

技术难度(F2)

55

5.0

业务重要性(F3)

7

5.0

 

客户排斥程度(F4)

3

4.5

运用公式A，计算的风险系数为：3.90875

这是一个小数，运用公式B计算的工作量为：4.8175人日

再运用公式C，计算出带风险缓冲的工作量为：5.3人日

运用公式D，优先级为：4.85，雪中送炭型

而在实际进度控制时不以小时/分为单位，则其基本上被扩展为5.5至6个人日的工作量。

如果项目组之前没有OPC、PI或者SCADA等相关的经验或技术储备，那么项目的风险就非常高，需要调整公式C中的T_most-likely的值，比如调整为150%甚至更高，都是合理的。那么此Feature的最终工作量也随之发生变化。如果最终结果超过了2星期(10人日)，则需要对其进一步分解。

2.5.    进度计划

前文预设的“里程碑—权重”该派上用场了。因为单个Feature粒度很小，通常推荐的做法是将一组相关的Feature分配给某位开发者，然后再针对这一组Feature制订开发计划。

一组Feature带风险缓冲的工作量之和是N个人日，那么Relax™会根据权重将工作量分配到每个里程碑上，再根据您输入的开始日期计算出每个里程碑的计划完成日期。如图：

Relax™自动计划算法有两个前提:

A.     每天按8小时计算、每周按40小时计算；

B.      为了保证开发者工作效率，分配一段连续的时间。

请注意，每个里程碑的粒度是人日，不是人时。比如上图中，09/06/2010计划完成需求走查，开发者只要在这一天的任何时候完成都不算延迟。这样设计的原因在本文开篇已有叙述：智力活动无法精确度量。其初衷是为了不使进度计划变得太过于死板而失去可执行性。