第 第 9 9 讲 软件项目监控 讲 软件项目监控
内容 内容
项目监控的内容
项目监控框架
项目监控方法与工具
变更控制
项目修复项目监控的内容 项目监控的内容
监控项目的进展
比较实际进度与计划的差别
修改计划使项目能够返回预定“轨道”项目监控框架：过程
项目监控框架：过程
项目监控框架：责任（
项目监控框架：责任（ 1 1 ） ）
项目指导委员会（ Project Steering Committee， Project Board ）负责整个项目进度
报告项目情况的组织结构项目监控框架：责任（
项目监控框架：责任（ 2 2 ） ）
项目情况报告的内容项目监控框架：进度评估 项目监控框架：进度评估
基础：定期信息收集或者发生的特定事件
这些信息必须是客观的和可度量的
但是并非每一次都能够得到符合要求的信息，因 而通常需要项目成员进行主观判断项目进度监控：检查点设置 项目进度监控：检查点设置
检查点 (Checkpoints) 包括： 定期的（如一星期一次，一月一次）
与特定的事件绑定的，如生成一份报告或者交付部分 产品
项目监控框架：监测频率 项目监控框架：监测频率
监测的频率依赖于项目的大小和风险情况 团队领导，可能需要每天都了解一下进度
项目经理需要每星期或每月了解情况
管理层次越高，频率越低，信息越抽象
许多公司利用星期一早晨的短会来激励员工实现 短期目标数据收集 数据收集
尽管整个过程被分成了容易管理的活动，但是项 目执行中仍然需要在活动中对任务完成的比例进 行评估，这种评估通常是困难的。
思考：某一软件开发者完成了一个需要 500 行 代码的软件的 250 行，请解释一下为什么不能 认为他的工作已经完成了一半？答案 答案
许多因素决定了不能用完成的代码行的比例来衡 量进度： 对整个软件的代码行的估计可能不准确
写完的代码可能相对容易，或者相对容易
一个软件如果没有通过测试就不能算完成，因而即使 代码全部写完了，如果没有测试也不能算完成。
对所需完成内容的深入的了解有助于判断进度，如将整个工作细分为子任务，如设计，编码，单 元测试等。
部分完成报告 部分完成报告
许多组织采用财务系统中的每周时刻表来记录每 个职员在每项工作中花费的时间，但是该表无法 告诉项目经理目前产出了什么，进度是否满足要 求。
因而可以对每周时刻表进行扩展，以包含完成的 工作内容风险报告 风险报告
询问小组成员完成计划的可能性
交通灯方法：
识别评价某项工作中的关键元素
将这些关键元素分解为组成元素
对于每一元素： 如果符合计划要求：绿灯
目前已经拖后，但是可以恢复，黄灯
已经拖后，恢复很困难，红灯
进度可视化 进度可视化
Gantt 图进度可视化 进度可视化
滑动图 (slip chart)弯曲的越厉害，
说明偏离计划越 明显
进度可视化 进度可视化
球图：计划开始，计划结束作为两个球，每次计 划改变后，日期添加到球中，如果时间是按计划 的，球被填为绿色，否则被填为红色。
每次更新后，图不需重画。进度可视化 进度可视化
前面的方法不能表示出项目生命周期中偏离计划 的情况。
对计划偏离的趋势分析能够避免将来的项目偏离。
时间线图（ timeline ）进度可视化 进度可视化
实际的时间 计划的时间
第二个星期评估时发现
，任务 2 需要延期，其 它任务也相应延期
第四个星期评估时发现
，任务 4 需要延期，任 务 5 也相应延期
第五个星期评估时 发现，任务 3 需要
延期
成本监控 成本监控
监控的意义 成本本身是项目中的重要元素
成本监控也能展示已经花费了多少劳力
简单的监控方法：累积消耗图不能说明项目进展 情况
累积消耗图 累积消耗图
对普通的累积消耗图上加上项目时间信息盈余量 盈余量
盈余量（ Earned Value): 建立在对每个任务或工 作包的消耗预测的基础上。
对每一项内容的原始预算成本被称为预算基线或 计划工作的预算成本（ budgeted cost of work s cheduled, 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 wor k performed, ACWP)预算变动
调度变动（成本）
调度变动
成本变动
盈余量监控 盈余量监控
性能比例： 成本性能指数： CPI ＝ BCWP （盈余量） /ACWP
（真正的成本消耗）
调度性能指数： SPI=BCWP/BCWS( 预算成本 )
值越大，工作完成得越好
例子 例子
你被指定负责一个软件项目，此项目由四个部分（ A, B, C, D ）组成，项 目总预算为 53000 元，其中 A 任务预算为 26000 ， B 任务预算为 1200 0 ， 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
任务 BCWS（计划费用）：
元
ACWP（实际花费）
：元
A 26， 000 25， 500
B 9， 000 5， 400
C 4， 800 4， 100
截至到 8 月 31 日的计划成本和实际成本
关键：计算 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 0 0 0
截至到 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 Contro Change Contro l) l)
用户的需求可能变化，项目内部可能变化……
变更需要仔细考虑，因为一个部分的变化可能会 对另外部分的造成影响
问题：对程序描述的改变将引起软件的设计和代 码的改变，还有什么其它产品可能需要修改？
答案：测试数据，期待结果和用户手册等变更管理员角色 变更管理员角色
Configuration Librarian
责任： 识别所有需要变更控制的内容
建立一个保存所有项目文档和代码的中央库
建立一套管理变更的正式过程
维护读取库中内容的记录和库中每一项的状态
变更控制过程 变更控制过程
用户意识到需要对系统进行修改，考虑将修改请 求提交给开发人员
用户端的管理者考虑是否将该修改请求提交给项 目承担者
项目承担端的管理者将该任务指派给一个成员，该成员将判断该修改的成本以及修改的影响，并 提交一个报告
该报告被提交给用户，用户将考虑是否能够承受变更控制过程 变更控制过程
用户同意后，一个获多个开发者被授权从主产品 上取出要修改的部分的拷贝
拷贝被修改。
新版本开发出来后，将通知用户，用户进行接受 测试
当用户满意后，产品的配置项被新版本所代替。项目修复 项目修复
需要修复的项目 没有人对项目何时结束有一点点概念
产品满目疮痍。
开发组人员工作超时，每周多于 60 小时
管理层已经无法控制进度，而评估项目状态的准确性 丧失殆尽
客户对开发组能否按承诺交付软件不再抱有信心
开发人员，市场人员，项目经理，客户之间关系紧张
开发组士气低落
修复方案 修复方案
问题：如何挽救项目 缩减项目规模，以便在计划的时间与工作量内完成项 目
把注意力放在短期的改善上，以提高过程的生产率
面对现实，放弃计划
有没有其它方法？重新获取控制权 重新获取控制权
修复计划 修复计划
第一步
评估你的处境
应用 W- 理论分析
作好修复项目的思想准备
向开发组成员探问拯救项目的方法
变得现实一些项目修复：人员 项目修复：人员
采取一切措施恢复开发组的士气 采取一个象征性的行动，如给他们特许的条件（允许 他们上班晚些，提供更好的工作环境），也可以放一 次假
确保为开发组创造了条件 如去掉了过多的进度压力，改善了恶劣的工作条件，
剔除了管理上的不当做法
消除重大的人员问题 勇敢地面对问题，该调整的要调整
项目修复：人员 项目修复：人员
消除重大领导问题 更换子项目经理
为经理配备助手
增加新手一定要慎重
充分利用开发人员的时间 减轻他们其它的负担
为他们处理一些日常工作
允许开发组人员各有不同 绝不允许破坏士气
观察开发人员的节奏项目修复：过程 项目修复：过程
修正软件开发过程中出问题的环节 出问题的环节必然是项目有意或无意忽略了软件开发 的基本原则
创建详细的小型里程碑 小型的（一、两天规模的）
二元性（要么完成，要么没有完成）
彻底性（所有里程碑完成，项目就完成了）
依据里程碑的完成来安排进度 为每个里程碑设置完成的时间，里程碑的设置必然是 考虑了人员正常的工作时间
项目修复 项目修复 : : 过程 过程
细致地最终进度进展情况 每天检查小型里程碑的完成情况
误了某个里程碑，就要求他加班加点完成
记录里程碑未完成的原因
短期后再调整——一周或两周
慎重提交进度计划 经过一两周的实际检验
严格的风险管理项目修复：产品 项目修复：产品
稳定需求
修正特性集
删除优先级低的需求
评估你的政治地位 是否本身产品就是不重要的？
目前比产品更重要的是什么？
