CMM实施手记之二：以项目形式管理SPI

CMM实施手记之二：以项目形式管理SPI

北京SPIN 雅行

(本文曾于2002年7月刊载于《计算机世界》周报第25期F5、F6版)

国外的一项有关SPI的调查表明，没有很好的对过程改进进行管理造成了至少70%以上的改进失败或挫折！当我们问自己如下问题的时候，能否迅速给出满意的答案——
SPI强调管理，自身是如何管理的？
SPI提供方法论，自己的方法论如何？
SPI说做事要有计划性，自身计划性如何？
SPI倡导风险管理，自身的风险被很好的识别了吗？
本文试图给出一种对SPI自身进行管理的方法：“以项目形式管理SPI”。

以项目形式管理SPI通常分为如下五步骤：

第一步 体系诊断
第二步 方案设计
第三步 项目策划
第四步 过程管理
第五步 项目验收总结


第一步 体系诊断

诊断是一切过程改进和管理咨询的前奏，对于不以取证为目的的软件过程改进来说，这一步尤其重要。
我们常讲“理论联系实际”，诊断就是实现此种联系的必要步骤。
“过程诊断”和“过程审计”有着某种程度的相似性，通常的方式为面谈、文档查阅、检查表填写等形式。
典型的基于CMM的检查表举例如下：

等级二 可重复级提问单
软件项目跟踪和监督




典型的SPI诊断开销大约为2-3人日，这和组织的成熟度，组织的历史长短，管理和业务的复杂度都有关系。
对诊断过程的漠视是自顶向下改进策略的最大弊端。

第二步 方案设计

在了解了组织、项目的实际状态以后，就可以有针对性的提出解决方案了，这一步骤称为方案设计。
面向中小企业解决方案范例之一：

在以上方案中，我们可以看到主要的元素来自于CMM、SEBOK（软件工程）、good practice (最佳实践)。这种结果是与该企业的如下现状相适应的：
首先，该企业没有形成基本的软件工程流程；
其次，项目没有生命周期的概念，无明确启动和验收点，正如其项目经理所言“我们的项目结束点要等到下一起项目已经开始，本期项目不得不结束了，才会出现”；
再次，该企业整体管理基础薄弱，资源提供不充分，这种情况下，在大企业顺理成章的事情可能在这里都是问题，所以需要大量的变通和折衷策略，这些都被归纳在GOOD PRACTICE 中。
诸如此类的方案设计，存在两个裁减特征，一是横向裁减，可以在打破现有知识体系的基础上，创造性的构建新体系；其二是纵向裁减，比如对于CMM的具体KPA，也可以分两步或更多步来达到要求。所有这些裁减都会带来更多的灵活性。

SPI方案的编制需要涵盖如下内容：
〉本组织软件过程改进的历史

〉过程诊断
诊断方法
诊断结果和差距分析
〉改进方案
总体目标
总体工程化管理系统设计
详细改进措施
〉资源需求预测
〉计划进度概要
前提和承诺
资源需求预测
〉风险
〉里程碑
附录：过程诊断提问单和原始数据

第三步 项目策划

方案得到认可后，可启动项目策划。SPI的项目策划要求与其它项目的策划要求并无多少差异，主要是编制一份项目计划，有如下内容：
〉项目目标 
整体目标
本阶段目标
〉假定和约束
〉项目组织
组织结构
接口关系
报告关系
责任矩阵
〉项目进度跟踪方式
〉项目里程碑
〉交付物
文档编制
人员培训
〉风险管理
〉项目激励
〉项目验收

值得一提的SPI风险管理，SPI典型风险及化解策略如下：

计划进度则使用诸如MSP之类的工具进行计划和跟踪：

第四步、过程管理

计划制定好以后，还要对 SPI的的实施过程进行定期和不定期的过程跟踪，才能确保及时纠正和预防计划执行中的偏差，最终达成项目的成功。
一般可通过“周”和“里程碑”两种周期进行跟踪，周跟踪的内容为进度、完成量、问题、风险，通过周报和周会的形式进行；里程碑跟踪的内容为进度、工作量、人力开销、风险等，还要对项目管理的经验和教训进行总结，里程碑也是识别典型案例和收集最佳实践的良好时机。里程碑跟踪活动通常包括“里程碑总结报告编制”和“里程碑总结会”两种形式。


第五步、项目验收总结

对于自底向上的软件过程改进，并没有标准的验收准则可利用，这要求组织根据自身裁减的体系编制自己的验收准则，验收准则有定性和定量的不同形式，定量适合于有一定管理基础的组织，需要有足够的、可信的、可比的历史数据。但多数中小软件企业可能在起步阶段只能选择定性验收的方式，这种定性验收方式常常是“先僵化、在固化、后优化”理念的一种体现。
定性的检查表可能会由如下问题组成：
项目是否有明确的启动点？
项目启动后是否对项目进行了策划？
项目计划是否被周期性维护？
是否在策划阶段识别了项目的配置项？
集成测试通过后是否对代码进行了标定？
修订后的配置项是否被重新审核？
SQA是否按照规定的周期对项目组进行过程审计？
等等

项目验收后，进行SPI项目的最后一项活动——项目总结，需要提交书面报告并召开总结会，项目总结中要统计汇总SPI本身数据、进度、开销、偏差及分析，还要识别和共享经验教训。这一阶段的工作将为以后的SPI持续改进打下良好的基础。SPI将进入下一个改进循环。

总之，以项目形式管理软件过程改进，特别有利于提高团队凝聚力、规避风险、明确目标、提供效率，而且由于SPI项目组与其它项目组形成了一种矩阵式组织结构，可以有效促进组间交流。所以对于SPI这样一件比较复杂的工程来说，以项目形式进行管理将是成功的重要保证。


下两期预告：
“之三：软件过程改进利益分析”
“之四：管理体系设计三步曲”

[说明：本系列文章由作者在“北京软件过程改进沙龙”的演讲整理而成]

原文转自：http://www.ltesting.net