项目报警机制

项目报警机制

如何判断一个项目正在向这个方向发展（但尚未陷入灾难之中）呢？如何在拯救措施的成本变高之前判断出需要对软件项目采取一定的措施？这些问题的答案在于EWS系统的报警机制。

出于讨论的目的，我们将问题划分为项目管理相关（例如行政、管理、过程、环境等问题）和产品相关（例如软件的bug）两类。项目和产品问题根据其所处的严重程度，分为下面几类：

1．危急类

危急类产品问题：造成产品不可用或者接近不可用的产品缺陷。

危急类项目问题：若不将之克服项目就无法取得成功的、与项目有关的问题。

2．严重类

严重类产品问题：致使一个主要的产品功能不可用但整个产品尚可使用的产品缺陷。

严重类项目问题：如果不及时改正，将导致下面与项目有关的问题：

—  极大影响用户的满意度。有证据显示预期会使用或购买产品的用户中有20%或者更多将不会使用或购买该产品。

—  导致项目的经费预算超支20%。

—  导致项目的时间预算超出20%。

3．轻微类

轻微类产品问题：导致产品难用的缺陷，但产品的其他主要功能仍然能有效运行。该类别中还包括其他不危急也不严重的产品缺陷。

轻微类项目问题：指那些既不危急也不严重的与项目有关的问题。

危急类和严重类问题能够触发警报，具体来说，依据危急类和严重类问题的数量、清空问题列表所需要的时间以及解决问题的进展情况等属性，判断是否触发警报。例如，在一个战略软件系统或生命支持软件系统中，只要有一个危急类问题在项目中存在的时间超过了一个评审周期，就可能会响起警报。在针对非紧急事务的软件系统项目中（如一个考勤管理系统），报警机制可能会较为复杂。

报警机制中经常会考虑到时效因素，也就是说，如果不对危急类和严重类问题加以解决，那么随着时间的流逝，它们的严重性会不断增加。下面是一个报警机制示例（括号中是参数值样例）：

1．对于一个新出现的危急类问题，赋予它X点值（例如，5）；

2．对于一个停留在问题列表里的危急类问题，每过去一个汇报周期（例如，1周为一个汇报周期），为其增加Y点值（例如，2）；

3．对于一个新出现的严重类问题，赋予它Z点值（例如，1）；

4．对于一个停留在问题列表里的严重类问题，每过去一个汇报周期（例如，1周为一个汇报周期），为其增加U点值（例如，1）；

5．将问题列表中所有危急类和严重类问题的值相加，计算出总和；

6．如果总和大于报警临界值V（例如，20）那么，就拉响警报。

X、Y、Z、U、V的值取决于项目、开发中的产品、开发机构、产品客户和用户、开发机构的历史（以前的项目中问题解决情况如何）等方面的特征。有两条约束X、Y、Z、U、V值的规则：

1．必须在项目重启前预先设定这些值；

2．在项目开发过程中，对这些值的更改应受到限制，不应频繁改动。

这两条规则确保了报警机制不会被轻率地改动。

大体来说，好的项目报警方法会以对项目的较全面审视（而不是仅以一个问题）为报警依据。不过，当一个问题具有压倒性的影响（即由于该问题，项目失败的可能性很明显）时，警报也可能会被拉响。

我们在前面提到过，如果开发机构已经有一个有效的EWS，那么在被拯救的项目重启时，应使用那个EWS。对于其他机构来说，可以以前面例子中示例的X、Y、Z、U、V值开始，然后在项目推进过程中对这些值进行改进，通过这样建立起一种简单但有效的报警机制。不过，需要注意的一点是，不应频繁地对这些值进行改动（X、Y、Z、U、V规则已对这一点做了规定）。

 

本文节选自《灾难拯救——让软件项目重回轨道》一书

[美]Bennatan（本拿塔） 著

侯艳飞，侯玉芳，李萌 译

图书详细信息:

http://www.cnblogs.com/broadview/archive/2012/07/05/2578340.html