第9讲 软件项目监控

内容 项目监控的内容 项目监控框架 项目监控方法与工具 变更控制 项目修复

项目监控的内容 监控项目的进展 比较实际进度与计划的差别 修改计划使项目能够返回预定“轨道”

项目监控框架：过程

项目监控框架：责任（1） 项目指导委员会（Project Steering Committee， Project Board）负责整个项目进度 报告项目情况的组织结构

项目监控框架：责任（2） 项目情况报告的内容

项目监控框架：进度评估 基础：定期信息收集或者发生的特定事件 这些信息必须是客观的和可度量的 但是并非每一次都能够得到符合要求的信息，因而通常需要项目成员进行主观判断

项目进度监控：检查点设置 检查点(Checkpoints)包括： 定期的（如一星期一次，一月一次） 与特定的事件绑定的，如生成一份报告或者交付部分产品

项目监控框架：监测频率 监测的频率依赖于项目的大小和风险情况 管理层次越高，频率越低，信息越抽象 团队领导，可能需要每天都了解一下进度 项目经理需要每星期或每月了解情况 管理层次越高，频率越低，信息越抽象 许多公司利用星期一早晨的短会来激励员工实现短期目标

数据收集 尽管整个过程被分成了容易管理的活动，但是项目执行中仍然需要在活动中对任务完成的比例进行评估，这种评估通常是困难的。 思考：某一软件开发者完成了一个需要500行代码的软件的250行，请解释一下为什么不能认为他的工作已经完成了一半？

答案 许多因素决定了不能用完成的代码行的比例来衡量进度： 对整个软件的代码行的估计可能不准确 写完的代码可能相对容易，或者相对容易 一个软件如果没有通过测试就不能算完成，因而即使代码全部写完了，如果没有测试也不能算完成。 对所需完成内容的深入的了解有助于判断进度，如将整个工作细分为子任务，如设计，编码，单元测试等。

部分完成报告 许多组织采用财务系统中的每周时刻表来记录每个职员在每项工作中花费的时间，但是该表无法告诉项目经理目前产出了什么，进度是否满足要求。 因而可以对每周时刻表进行扩展，以包含完成的工作内容

风险报告 询问小组成员完成计划的可能性 交通灯方法： 识别评价某项工作中的关键元素 将这些关键元素分解为组成元素 对于每一元素： 如果符合计划要求：绿灯 目前已经拖后，但是可以恢复，黄灯 已经拖后，恢复很困难，红灯

进度可视化 Gantt图

进度可视化 滑动图(slip chart) 弯曲的越厉害，说明偏离计划越明显

进度可视化 球图：计划开始，计划结束作为两个球，每次计划改变后，日期添加到球中，如果时间是按计划的，球被填为绿色，否则被填为红色。 每次更新后，图不需重画。

进度可视化 前面的方法不能表示出项目生命周期中偏离计划的情况。 对计划偏离的趋势分析能够避免将来的项目偏离。 时间线图（timeline）

进度可视化 计划的时间 实际的时间 第四个星期评估时发现，任务4需要延期，任务5也相应延期 第二个星期评估时发现，任务2需要延期，其它任务也相应延期 第五个星期评估时发现，任务3需要延期

成本监控 监控的意义 成本本身是项目中的重要元素 成本监控也能展示已经花费了多少劳力 简单的监控方法：累积消耗图 不能说明项目进展情况

累积消耗图 对普通的累积消耗图上加上项目时间信息

盈余量 盈余量（Earned Value):建立在对每个任务或工作包的消耗预测的基础上。 对每一项内容的原始预算成本被称为预算基线或计划工作的预算成本（budgeted cost of work scheduled, BCWS)。 未开始的任务被赋予值0，当它被完成后，将被赋值。在项目中的一点上，全部的值将被成为盈余量或完成工作的预算成本（budgeted cost of work performed, BCWP)

盈余量 当任务未完成时，需要分配一个盈余量给该任务，方法为： 0/100技术：任务被分配值0直到任务完成后，被分配预算值的100％ 50/50技术：任务一开始后，就赋予50%,直到项目结束后赋值100% 里程碑方法：对任务中的一系列里程碑赋予特定值。 建议用0/100方法，因为50/50方法由于活动开始后报告的值过高，容易给人一种错误的安全感，而里程碑方法最好将该任务细分为多个子任务。

预算基线 建立盈余量分析的第一步是为项目建立一个预算基线(baseline budget) 预算基线是建立在项目计划的基础上的，它是根据时间对盈余量值的预测。 盈余量可以用货币单位来衡量，也可以用人员工作量来衡量。

例子 采用了0/100方法

？通过分析该图是否可以判定项目中发生的情况 盈余量监控 随着项目的进行，可以不断进行盈余量监控，判断项目的进度。 ？通过分析该图是否可以判定项目中发生的情况

盈余量监控 每一项任务的真正成本消耗为（Actual Cost work performed, ACWP) 预算变动 成本变动 调度变动（成本） 调度变动（时间）

盈余量监控 性能比例： 成本性能指数：CPI＝BCWP（盈余量）/ACWP（真正的成本消耗） 调度性能指数：SPI=BCWP/BCWS(预算成本) 值越大，工作完成得越好

例子

采用50/50规则计算截至到8月31日的CV, SV, CPI, SPI CV=BCWP-ACWP SV=BCWP-BCWS 你被指定负责一个软件项目，此项目由四个部分（A, B, C, D）组成，项目总预算为53000元，其中A任务预算为26000，B任务预算为12000， C任务预算为10，000，D任务预算为5000，截至到8月31日，A已经全部完成，B过半，C刚开始，D还没有开始 采用50/50规则计算截至到8月31日的CV, SV, CPI, SPI CV=BCWP-ACWP SV=BCWP-BCWS CPI=BCWP/ACWP SPI=BCWP/BCWS 截至到8月31日的计划成本和实际成本 任务 BCWS（计划费用）： 元 ACWP（实际花费）：元 A 26，000 25，500 B 9，000 5，400 C 4，800 4，100 D

关键：计算BCWP 采用50/50原则 B任务过半， BCWP=6,000 C任务开始，BCWP=5,000 D任务未开始，BCWP＝0 BCWS（计划费用）： 元 ACWP（实际花费）：元 BCWP（盈余量）：元 A 26，000 25，500 26,000 B 9，000 5，400 6,000 C 4，800 4，100 5,000 D Total 39,800 35,000 37,000

SPI小于1说明截至到8月31日没有完成计划的工作量，即进度落后 BCWS=39,800 ACWP=35,000 BCWP=37,000 CV=37,000-35,000=2,000 SV=37,000-39,800=-2800 SPI=93% CPI=106% SPI小于1说明截至到8月31日没有完成计划的工作量，即进度落后 CPI大于1说明截至到8月31日费用节省了，完成工作量的价值大于实际花费的价值

盈余量监控 盈余量概念还没有被软件界全面接受，原因可能在于建了一半的房屋可以有反映人力和材料消耗的记录，而完成一半的软件项目却没有任何数据。这是对盈余量分析的误解。实际上盈余量分析是一项跟踪项目进度的方法。

项目评审 通过一定的方式对项目进行评价和审核 评审活动的类型 评审时间 商务评审 技术评审 管理评审 质量评审 产品评审 定期评审 阶段评审 事件评审

定期评审 准备评审要素 到达定期 评审时间 确定评审方式 依据采集数据统计项目性能 评审管理/质量/技术等问题 计划修改 对评审作出结论

阶段评审 准备评审要素 组织相关评审 评审本阶段关键任务完成情况 确认产品提交情况 统计报告数据 对下阶段计划调整 阶段评语 到达阶段 评审时间 组织相关评审 评审本阶段关键任务完成情况 确认产品提交情况 统计报告数据 对下阶段计划调整 阶段评语

事件评审 按评审过程组织评审 事件报告被批准 报告事件的情况 对事件处理方案的讨论 确定事件影响的范围 对评审做出结论 计划修改

监控的优先级 关键路径活动 没有自由浮动的活动 小自由浮动时间活动的监控 高风险的活动 使用关键资源的活动

使项目回到正规 几乎所有的项目都会遇到延误和意外事件。项目经理的一项任务就是识别这些事件发生的时间，在最小延迟时间和对项目团队有最小的影响的情况下，消除问题的影响。

缩短关键路径 要求项目组人员“Work harder”有一些效果，但是不能轻易使用。 分配额外的资源可以加快进度，但是并不总是奏效，例如分配给某一人员的小模块，再增加一个人员并不一定能够缩短时间。 将非关键路径上的资源调整到关键路径上 注意：缩短关键路径可能使其它路径成为关键路径。

重新考虑任务优先关系 网络计划考虑的是理想情况和普通工作情况，因而在无法缩短关键路径时，可以重新考虑任务优先关系。 另一种方法是将活动再进行划分，从而一部分可以与其它活动并行。 重新考虑任务优先关系可能带来风险或者质量上的影响。

变更控制（Change Control) 用户的需求可能变化，项目内部可能变化…… 变更需要仔细考虑，因为一个部分的变化可能会对另外部分的造成影响 问题：对程序描述的改变将引起软件的设计和代码的改变，还有什么其它产品可能需要修改？ 答案：测试数据，期待结果和用户手册等

变更管理员角色 Configuration Librarian 责任： 识别所有需要变更控制的内容 建立一个保存所有项目文档和代码的中央库 建立一套管理变更的正式过程 维护读取库中内容的记录和库中每一项的状态

变更控制过程 用户意识到需要对系统进行修改，考虑将修改请求提交给开发人员 用户端的管理者考虑是否将该修改请求提交给项目承担者 项目承担端的管理者将该任务指派给一个成员，该成员将判断该修改的成本以及修改的影响，并提交一个报告 该报告被提交给用户，用户将考虑是否能够承受额外的成本

变更控制过程 用户同意后，一个获多个开发者被授权从主产品上取出要修改的部分的拷贝 拷贝被修改。 新版本开发出来后，将通知用户，用户进行接受测试 当用户满意后，产品的配置项被新版本所代替。

项目修复 需要修复的项目 没有人对项目何时结束有一点点概念 产品满目疮痍。 开发组人员工作超时，每周多于60小时 管理层已经无法控制进度，而评估项目状态的准确性丧失殆尽 客户对开发组能否按承诺交付软件不再抱有信心 开发人员，市场人员，项目经理，客户之间关系紧张 开发组士气低落 ……

修复方案 问题：如何挽救项目 有没有其它方法？ 缩减项目规模，以便在计划的时间与工作量内完成项目 把注意力放在短期的改善上，以提高过程的生产率 面对现实，放弃计划 有没有其它方法？ 重新获取控制权

修复计划 第一步 评估你的处境 应用W-理论分析 作好修复项目的思想准备 向开发组成员探问拯救项目的方法 变得现实一些

项目修复：人员 采取一切措施恢复开发组的士气 确保为开发组创造了条件 消除重大的人员问题 采取一个象征性的行动，如给他们特许的条件（允许他们上班晚些，提供更好的工作环境），也可以放一次假 确保为开发组创造了条件 如去掉了过多的进度压力，改善了恶劣的工作条件，剔除了管理上的不当做法 消除重大的人员问题 勇敢地面对问题，该调整的要调整

项目修复：人员 消除重大领导问题 增加新手一定要慎重 充分利用开发人员的时间 允许开发组人员各有不同 观察开发人员的节奏 更换子项目经理 为经理配备助手 增加新手一定要慎重 充分利用开发人员的时间 减轻他们其它的负担 为他们处理一些日常工作 允许开发组人员各有不同 绝不允许破坏士气 观察开发人员的节奏 不断根据修复的情况来调整安排

项目修复：过程 修正软件开发过程中出问题的环节 创建详细的小型里程碑 依据里程碑的完成来安排进度 出问题的环节必然是项目有意或无意忽略了软件开发的基本原则 创建详细的小型里程碑 小型的（一、两天规模的） 二元性（要么完成，要么没有完成） 彻底性（所有里程碑完成，项目就完成了） 依据里程碑的完成来安排进度 为每个里程碑设置完成的时间，里程碑的设置必然是考虑了人员正常的工作时间

项目修复:过程 细致地最终进度进展情况 记录里程碑未完成的原因 短期后再调整——一周或两周 慎重提交进度计划 严格的风险管理 每天检查小型里程碑的完成情况 误了某个里程碑，就要求他加班加点完成 记录里程碑未完成的原因 短期后再调整——一周或两周 慎重提交进度计划 经过一两周的实际检验 严格的风险管理

项目修复：产品 稳定需求 修正特性集 删除优先级低的需求 评估你的政治地位 去除产品中没用的“垃圾” 降低缺陷数目，并要持续降低 是否本身产品就是不重要的？ 目前比产品更重要的是什么？ 去除产品中没用的“垃圾” 降低缺陷数目，并要持续降低 公开缺陷图

小结 项目监控的内容 项目监控框架 项目监控方法与工具 项目评审 变更控制 项目修复