定期项目现状评审

定期项目现状评审

软件项目现状评审（有时候称为管理评估）可以为项目相关各方提供必要的信息，以便进一步针对情况做出决策或者批复，同时能跟踪之前评审所做决策的执行情况。对于被拯救后重启的项目而言，项目现状评审作为EWS的一部分，也具有同样的目的。这种评审能够提供关于项目状况的信息，识别并监控目前存在的问题及其解决途径，并确保关键的问题得到解决。

项目评审主要是基于数据的，这可以解释针对开发度量指标收集数据工作的重要性。如果缺少了数据收集工作，那么项目评估就变得毫无价值。这一点从12.1节所举案例中的第一次评估可以看出来（这次评估的唯一价值在于确保了下一次可以做得更好）。

项目评估应该周期性地进行，通常每个月举行一次。但特殊情况下可以增加频率（例如每两周举行一次）或者偶尔降低频率（每两个月或者三个月举行一次）。过多的项目评估会带来额外的负担（每次评估及其准备工作都要投入相当的时间和精力），但评估频率太低的话则会导致问题积压得不到有效的解决。

评估应该如何进行？这方面存在很多相关的标准，其中的一个例子就是IEEE Std 1028，该标准涵盖了一个广义范围内的项目评估（包括管理评估，技术评估等）。虽然这些不同类型的评估都是可以根据情况灵活定制的，但对于一个只具备有限的软件开发过程的开发机构而言，若把各种不同类型的评估都引入进来，那么将是相当沉重的负担。幸运的是，经历过灾难拯救过程并重启后的项目的EWS系统不需要IEEE标准中所规定的全部评估内容。

在前一小节中，我们已经讨论过如何在一个陷入灾难的项目中引进度量指标，评审技术的引进与此类此：只需引进一个评审过程中的那些对于被拯救项目的成功完成来说必不可少的元素即可（当然，如果当前开发机构已经在使用某种有效且更全面的评估技术，那么继续使用它们）。

接下来，我们将讨论如何将一个通用的项目评估标准（例如IEEE项目评估标准）修改成符合陷入灾难的项目所需要的版本（其他的标准，例如ISO项目评估标准也可以同样进行定制修改）。

1．项目现状（管理）评审

IEEE标准涵盖了多种类型的软件项目评审：管理评估、技术评估、审查、走查和审计。对于陷入灾难的项目而言，其EWS系统的最小所需是管理评估。该标准中明确了管理评估的目的在于：“监控软件开发的进程，明确当前计划实施的状况，确认需求及为它们配置的资源，评估当前管理方法的有效性。管理评估能够有效支持关于校正行动、资源配置变更或者项目范围变更等的决策工作。”这一目标完全符合陷入灾难的项目的EWS系统的需要。

2．评审参与者

项目现状评审需要以下各方共同参与。

—  关键的管理决策者

—  评审领导人（主持评审过程的人）

—  记录员（记录评审过程中的主要事件和决定）

—  项目经理

—  技术人员

—  其他项目成员

—  客户或顾客代表（可选）

根据实际情况的需要，也可以邀请其他个体参与有关问题的讨论。

3．评估的时长

根据项目的规模和状况，评估应花费两个小时到一天的时间。

一个大型的项目或者问题比较多的项目可能需要一整天的时间来完成评估，但对于小型的项目（少于15人/年）或者没有什么大问题的项目而言，评估可能只需两个小时左右的时间。

4．评估的议程安排

IEEE标准涵盖了评估中各方面的主题，对于一个被拯救后重启的项目而言，这些主题可以缩减为下面几个。

1．总体介绍：包括评估的概述、范围和目标。

2．之前的评估所确定下来的行动的进展情况汇报。

3．对当前存在的紧急问题的讨论。

4．项目现状及进展情况介绍，包括：

—  进度

—  预算

—  人员配备

—  开发进展

—  软件缺陷

—  其他相关问题

5．项目管理存在的问题和解决方案，包括风险状况。

6．决议和批复。

7．应对的措施（包括行动、执行人以及完成的时间期限）。

5．准备

IEEE软件评估标准1028既是一个标准，也是一个指南。它包括了评估前的准备（例如应提供合适的场所来举行评估）、评估计划（例如日程安排和会议宣传，分发相关材料等），以及评估执行（例如确立一个评估领导，对评估过程进行记录等）。

 

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

[美]Bennatan（本拿塔） 著

侯艳飞，侯玉芳，李萌 译

图书详细信息:http://blog.chinaunix.net/space.php?uid=13164110&do=blog&id=3264681