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.    风险级别—工作量

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

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

2.2.2.    里程碑—权重

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

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

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

2.3.    项目级参数

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

2.3.1. 三个时间

2.3.2. 四个风险因子

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

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

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

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

2.3.3. 三个进度

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

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

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

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

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

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

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

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

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

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

2.3.4. 三个优先级别

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

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非常重要，数据采集不上来，监控和分析就无从谈起。那么经过讨论之后得出了如下结果：

运用公式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计划完成需求走查，开发者只要在这一天的任何时候完成都不算延迟。这样设计的原因在本文开篇已有叙述：智力活动无法精确度量。其初衷是为了不使进度计划变得太过于死板而失去可执行性。

Relax中的量化管理相关推荐

1. IT项目量化管理：细化、量化与图形化 与 中国IT项目实施困惑

   IT项目开发和实施的组织先后在组织中引入项目管理模型的管理制度.流程和方法,但收入甚微.大量的IT项目依然面临着无休止的需求蔓延与频繁加班.项目工期失控.质量低下等典型的项目失控现象.对项目引入量化意 ...

2. 深度学习中的内存管理问题研究综述

   点击上方蓝字关注我们 深度学习中的内存管理问题研究综述 马玮良1,2, 彭轩1,2, 熊倩1,2, 石宣化1,2, 金海1,2 1 华中科技大学计算机科学与技术学院,湖北 武汉 430074 2 华中 ...

3. 数据化管理洞悉零售及电子商务——零售策略中的数据化管理

   零售策略中的数据化管理 渠道策略的数据化管理 渠道分类 按代理-批发-零售三级渠道标准分类 代理商 按区域划分 国代 省代 区域代理 按渠道功能划分 KA渠道代理 餐饮渠道代理 特殊通路代理 按重要性 ...

4. 用数据管理过程（3）——可预测级别的量化管理（麦当劳的管理方式）

   摘要: 用数据说话,这是当前很流行的话题,本文将数据管理过程划分成4个层次,并阐述企业如何达到这四个层次. 1．初级量化管理:以数据"感知"项目的状况(相当于CMMI2级) 2．中 ...

5. 软件项目量化管理（QPM）及根因分析实践总结（CMMI高成熟度访谈）

   1.前言 软件项目量化管理是CMMI高成熟度的标志,也是项目管理及软件工程的难点.本人做为项目经理,在CMMI4和5的试点和实施过程中,体会到量化管理是上述高成熟度项目管理的核心.本文重点是量化管理应 ...

6. C# 实现 rtc_RTC人力资源量化管理分析师培训，在北京开课啦

   4月18.19日,RTC人才发展商学院北京总院,为期两天的"人力资源量化管理分析师培训"课程,在RtCatch中国区总部资深讲师:杨侑蓁女士,热情洋溢的讲解下,圆满结束. RTC( ...

7. 功能点方法论助力南京银行信息科技量化管理能力提升

   由南京银行股份有限公司供稿的"功能点方法论助力南京银行信息科技量化管理能力提升" 一文,被<金融电子化>采稿并于2019年8月刊(总287期刊)上发表,于2019年8月 ...

8. 从转换率开始网络营销的量化管理

   从转换率开始网络营销的量化管理 纲要: .关于"转换率" .如何定义各项"转换率"指标 .通过提高各项"转换率"指标来从整体上提高营销投入回 ...

9. 有效制定年度经营计划-王磊老师企业量化管理1

   企业必须学会如何制订计划.如何执行计划,从而实现从经营机会到经营能力的转变.从经营产品到经营品牌的转变.从经营个体到经营组织的转变. 1. 什么是年度经营计划 常见年度计划的方式(切蛋糕方式): 假设 ...

最新文章

1. 如何通过域服务器推送安装文件,域环境推送exe程序并自动安装教程域环境推送exe程序并自动安装教程.pdf...
2. 【转】css行高line-height的一些深入理解及应用
3. 指定hdfs中namenode的地址_HDFS文件上传下载步骤
4. vary渲染图没了_云渲染哪个好用？云渲染平台对比
5. Mysql基础运维及复制架构——实验文档
6. CentOS 6.3下源码安装LAMP(Linux+Apache+Mysql+Php)环境
7. Spring5 - 向IOC容器中添加组件的4种方式
8. [bzoj2743]采花
9. Android布局属性详解之RelativeLayout
10. python寻找字符串中的英文字符,python如何解析字符串中出现的英文人名？
11. 为什么年事已高的我还在编程？
12. switch VS if else
13. 面向对象的编程-类和实例
14. 我只是追个直播，结果被拉进大咖们的群面对面群聊……
15. 初窥JQuery-Jquery简介
16. 学习笔记 : 表达式目录树相关问题参照该demo expression拼接与拆解 expression转sql...
17. CAN FD实战之CAN FD应用领域及CAN迁移至CAN FD的策略
18. dotnet OpenXML PPT 动画框架入门
19. 华三交换机升级的ipe文件_H3C S5830V2[S5820V2]系列以太网交换机 配置指导-Release 2108-6W101...
20. 蒙特卡洛之布丰投针（python实现）

热门文章

1. python制作数据增长动图_请问一下这种数据动图是如何做出来的？
2. mongoose简单了解
3. c# chart缩放，局部放大
4. og聚流行未能链接到服务器,OG 聚流行：建设一个完善的潮流购买平台
5. 联合省选2022游记
6. STM32 SWD 只能下载一次的问题
7. 智信分销拼团拍卖商城v3.38.6直播商城小程序
8. 使用 C# 将数字转换成大写人民币
9. [积水成渊]asp.net中HiddenField的使用
10. 全国青少年编程等级考试scratch三级真题2021年9月（含题库答题软件账号）