估算、计划和跟踪

估算

估算概述

估算目的是给各类计划提供决策依据。

估算对象：

  • 规模
  • 时间
  • 日程

关于估算的一些事实：

  • 估算是主观猜测
  • 估算能力很难提升
  • 没有任何人知道准确的数字究竟是什么
  • 多项实证研究表明，是否使用估算模型（例如 COCOMO）并没有显著差异

TSP / PSP 和 PROBE

规模度量 / 估算的困境

以 LOC vs FP 为例：

  • 精确度量方式往往不便于早期规划 / 估算
  • 有助于早期规划 / 估算的度量往往难以产生精确度量结果

PROBE 的作用：

  • 精确度量和早期规划之间的桥梁
英文 全称 / 含义 中文解释
PSP Personal Software Process 个体软件过程。强调个人开发者记录自己的规模、时间、缺陷等数据，用历史数据改进估算和计划。
TSP Team Software Process 团队软件过程。强调团队层面的计划、角色分工、质量管理和过程跟踪。
PROBE PROxy Based Estimation 基于代理的估算方法。用“代理对象”来估算规模，比如先判断模块类型和相对大小，再换算成 LOC。
LOC Lines of Code 代码行数。用代码行数度量软件规模。
FP Function Point 功能点。根据软件功能复杂度度量规模。

PROBE

PROBE 的基本思想：

先找到一个容易在早期判断的“代理对象”，再根据历史数据把它转换为较精确的规模估算。

PROBE估算流程

截屏2026-06-06 01.27.39

概要设计

  • 估算的第一步

    • 与已有产品/组件相关联

    • 定义能够产生期望功能的产品元素

    • 估算你计划构造之物的规模

  • 为了做出概要设计，需要

    • 确定产品功能，以及产生这些功能所需的程序组件/模块

    • 然后，将这些程序组件/模块与之前写的程序相比较，估算它们的规模
    • 最后，将程序组件/模块估算综合给出总规模

如果你对产品的理解还不足以产出一个概要设计，那么你所知道的还不足以做出一个计划

整合多个估算结果

整合一个开发人员做的多个估算：

  • 累积各个部分的估算
  • 进行一次线性回归计算
  • 计算一个预测区间

多个开发人员可以整合独立进行的估算：

  • 进行单独的线性回归预测
  • 将计划的规模或者时间相加
  • 将个人范围的平方相加，再对其计算平方根获得预测区间

估算误差

当估算多个部件时，总的误差会比各个部件误差的总和要小

  • 误差趋于抵消
  • 假设没有共同的偏差

估算要点之一：尽可能划分详细一些

Scrum 和故事点

Story Point

Story Point 用来：

度量实现一个故事（Story）需要付出的工作量。

特点

  • 抽象的
    • 混合了开发特性所要付出的努力、开发复杂度、风险以及类似因素
  • 相对的
    • 设定标准之后，考虑其他特性与标准之间的相对大小关系

常用 Fibonacci 数列：

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89

比如先选一个功能 A 作为标准，认为它是 3 点。然后看其他功能：

  • 功能 B 比 A 简单很多 → 可能是 1 点
  • 功能 C 和 A 差不多 → 可能是 3 点
  • 功能 D 明显更复杂 → 可能是 8 点
  • 功能 E 特别复杂、不确定 → 可能是 13 点或更高

故事点估算强调相对大小，不强调绝对工时。

估算要点之二：建立对结果的信心

估算要点之三：依赖数据

关于估算方法的反思

估算的目标：

  • 规模估算
  • 时间估算

怎么做估算：

  • 达成共识
  • 建立信心
    • 足够详细
    • 依赖数据
    • 最好的猜测（注意检验猜测所依据的假设）

估算要点之四：估算要的是过程，而非结果；估算的过程是相关干系人达成一致共识的过程

历史数据的获取——度量

关于度量

  • 度量体现着决策者对试图要实现的目标的关切程度。

相关方法：

  • GQM
    • 中文：目标-问题-度量 含义：先明确度量目标，再提出问题，最后设计指标来回答这些问题
  • GQM+ 度量体系构建

PSP 基本度项：

  • 规模
  • 时间
  • 缺陷
  • 日程（TSP）

PSP 时间度量：时间日志

时间日志记录内容：

日志内容 注释
序号 该条记录的序号
所属阶段 如策划、设计、编码、编译、单元测试、总结等
开始时间 该条记录的开始时间，精确到分钟
结束时间 该条记录的结束时间，精确到分钟
中断时间 计时过程中需要中断的时间，精确到分钟
净时间 结束时间 - 开始时间 - 中断时间
备注信息 记录中断原因或其他说明

时间日志用于记录实际工作时间

PSP 缺陷度量：缺陷日志

缺陷日志记录内容：

日志内容 注释
序号 该条记录的序号
发现日期 缺陷被发现的日期
注入阶段 分析确定缺陷被引入的阶段
消除阶段 缺陷被消除的阶段
消除时间 修正缺陷所消耗的时间
关联缺陷 如果缺陷是在修复其他缺陷时引入，需要建立关联关系
简要描述 对缺陷根本原因的简要描述

缺陷日志用于分析缺陷来源

计划和跟踪

团队项目规划

工作分解结构 WBS

WBS：Work Breakdown Structure，工作分解结构

工作分解结构是以可交付成果为导向对满足项目目标和开发交付产物的项目相关工作进行的分解

它归纳和定义了项目的整个工作范围：每下降一层代表对项目工作的更详细定义。

WBS 的作用：

  • 提供范围基线
  • 提供整体观
  • 防止遗漏可交付物
  • 明确各个角色的责任
  • 提供工作包定义
  • 估算和计划的基础
  • 帮助理解工作，分析风险

创建 WBS 的方法：

  • 识别和分析可交付成果及相关工作
  • 确定工作分解结构的结构与编排方法
  • 自上而下逐层细化分解
  • 为工作分解结构组成部分制定和分配标志编码
  • 核实工作分解的程度是必要且充分的

好的 WBS 检查标准：

  • 最底层要素不能重复
    • 任何一个工作包应该在 WBS 中的一个地方且只应该在一个地方出现
  • 所有要素必须清晰完整定义
    • 相应的数据词典必须完整定义
  • 最底层要素必须有定义清晰的责任人
    • 可以支持成本估算和进度安排
  • 最底层要素是实现目标的成分必要条件
    • 项目的工作范围得到完整体现

WBS 主要用途：范围管理

范围管理包括：

确保项目做且只做成功完成项目所需的全部工作的各过程

WBS 为范围管理提供基准

范围管理过程：

  • 收集需求
  • 定义范围
  • 创建 WBS
  • 核实范围
  • 控制范围变更

开发策略与计划

开发策略

在产品组件需求基础之上，明确每个产品组件的获得方式与顺序，从而在项目团队内部建立起大家都理解的产品开发策略。

注意事项：

  • WBS 的使用
  • 产品组件开发顺序的考虑
  • 产品组件获得方式的考虑

过程框架——生命周期模型

截屏2026-06-06 14.46.27

通用计划框架

截屏2026-06-06 14.48.46

日程计划原理和方法

任务计划和日程计划

任务计划描述：

  • 项目所有的任务清单
  • 任务之间的先后顺序
  • 每个任务所需时间资源

日程计划描述：

  • 各个任务在日程上的安排

典型计划流程：

  • 估算规模
  • 估算资源
  • 规划日程

质量计划原理和方法

项目的质量计划中应当确定需要开展的质量保证活动

  • 典型的质量保证活动包括个人评审、团队评审、单元测试、集成测试、系统测试以及验收测试等

质量计划中需要解决的关键问题：

  • 该开展哪些活动
  • 这些活动开展的程度，比如时间、人数、目标

风险计划

风险管理的目的是：

在风险发生前，识别出潜在的问题，以便在产品或项目的生命周期中规划和实施风险管理活动，以消除潜在问题对项目产生的负面影响。

风险管理大致分成两部分：

  • 风险识别
  • 风险应对

风险管理是一个持续的、前瞻的过程。

早期及积极的风险侦测很重要，因为：

在项目初期进行变更或修正的工作负荷，通常比在项目后期更容易、花费较低且较不具破坏性。

风险识别

风险识别包括：

  • 识别与成本、进度及绩效相关的风险
  • 审查可能影响项目的环境因素
  • 审查工作分解结构的所有组件
  • 审查项目计划的所有组件
  • 记录风险的内容、条件及可能的结果
  • 识别每一风险相关的干系人
  • 利用已定义的风险参数评估风险
  • 将风险按风险类别分类并分组
  • 排列降低风险的优先级

风险应对

识别风险之后，应制定相应的风险管理策略。

典型策略包括：

  • 风险转嫁

    • 通过某种安排，在放弃部分利益的同时，将部分项目风险转嫁到其他团队或者组织。

      例子：

      • 把一部分有技术风险的产品组件外包给其他公司开发

  • 风险解决

  • 风险缓解

计划评审和各方承诺

项目各项计划完成之后，需要与相关干系人开展评审工作。

目的：

  • 解决计划中相互矛盾与不一致的地方
  • 获得参与项目的各方对项目计划的承诺

具体要求：

  • 识别每一项计划所需支持，并与相关干系人协商承诺
  • 记录所有承诺，包括完整承诺和临时承诺，确保由适当层次的人员签署
  • 适时与资深管理人员一起审查承诺

项目跟踪意义

  • 项目进展过程中开展跟踪活动的目的在于了解项目进度，以便在项目实际进展与计划产生严重偏离时，可采取适当的纠正措施

  • 项目进度滞后与否需要参照物，即项目计划
  • 项目跟踪需要管理针对偏差而采取的纠偏措施

挣值管理方法 EVM

EVM 定义

EVM：Earned Value Management，挣值管理。

定义：

项目的挣值管理方法是用来客观度量项目进度的一种项目管理方法。

基本思想：

  • 每项任务实现附以一定价值（credit）
  • 100% 完成该项任务，就获得相应价值

EVM 采用三个独立变量进行项目绩效测量：

  • 进度计划
  • 成本预算
  • 实际成本

常用 EVM 度量

缩写 含义 公式 / 解释
PV Planned Value 计划价值
EV Earned Value 挣值，已完成工作对应的计划价值
AC Actual Cost 实际成本
BAC Budget at Completion 项目完成时所需预算或时间
CV Cost Variance 成本差异，CV = EV - AC
CPI Cost Performance Index 成本差异指数，CPI = EV / AC
SV Schedule Variance 日程偏差，SV = EV - PV
SPI Schedule Performance Index 日程偏差指数，SPI = EV / PV
EAC Estimate at Completion 预计完成成本，EAC = AC + (BAC - EV) / CPI = BAC / CPI
  • 简单实现这种方式仅仅关注进度信息
    • 在实现时，首先需要建立WBS，定义工作范围；其次为WBS中每一项工作定义一个价值（PV）；最后按照一定的规则将某一数值赋给已经完成的工作或者正在进行的工作。常用规则分别为0-100规则和50-50规则，前者只有当某项任务完成时，该任务的PV值将转化成EV值；后者只需要开始某项任务，即可以赋原PV值的50%作为EV值，完成时，再加上另外的50%。而实际完成的工作所需成本AC不对EV值产生任何影响
  • 中级实现在简单实现的基础上，加入日程偏差的计算
    • 典型计算方式有：日程偏差SV = EV – PV;日程偏差指数SPI = EV/PV
  • 高级实现在中级实现的基础上，还需要考察项目的实际成本

EVM 的变形

燃尽图可以看作 EVM 的一种变形。

燃尽图强调：

  • 剩余工作量
  • 进度趋势
  • 是否可能按期完成

EVM 的局限性

EVM 的局限性：

  • EVM 一般不能应用软件项目的质量管理
  • EVM 需要定量化的管理机制
    • 因而在探索型项目和常用敏捷开发方法中的应用受到限制
  • EVM 完全依赖项目的准确估算
    • 然而在项目早期，很难对项目进行非常准确的估算

里程碑评审

软件项目的里程碑往往是指：

某个时间点，用以标记某项工作的完成或者阶段的结束。

里程碑评审内容包括：

  • 项目相关承诺，如日期、规格、质量等
  • 项目各项计划的执行状况
  • 项目当前状态讨论
  • 项目面临风险讨论

其他计划跟踪

其他计划跟踪包括：

  • 日程计划跟踪
  • 承诺计划跟踪
  • 风险计划跟踪
  • 数据收集计划跟踪
  • 沟通计划跟踪

纠偏活动的管理

典型纠偏活动包括：

  • 偏差原因分析
  • 纠偏措施定义
  • 纠偏措施管理

项目总结

项目总结的意义

  • 软件项目的特点决定了持续改善对于软件工程师的重要性

  • 提供一个系统化的方式来总结经验教训、防止犯同样的错误、评估项目团队绩效、积累过程数据等。提供给项目团队成员持续学习和改进的机会

项目总结过程

项目总结需要系统化、有条理地进行，避免遗漏重要内容。

一般包括：

  • 准备阶段
  • 总结阶段
  • 报告阶段

基于 PMBOK 的总结

Project Management Body of Knowledge 项目管理知识体系

基于 PMBOK 的总结可围绕 9 大知识领域展开：

  • 范围管理
  • 时间管理
  • 成本管理
  • 质量管理
  • 人力资源管理
  • 沟通管理
  • 风险管理
  • 采购管理
  • 整合管理

范围管理

项目范围包括：

  • 产品范围
  • 项目范围

产品范围：

产品或服务所包含的特性和功能。

项目范围：

为交付具有规定特性和功能的产品或服务所必须完成的工作。

范围管理总结关注：

  • 需求开发过程与变更管理中的得失
  • 需求管理实际执行情况的差距
  • 改进机会

典型问题：

  • 是否有未被识别的需求？
  • 是否有没有得到响应的需求变更？
  • 需求是否出现蔓延现象？

时间管理

时间管理关注：

  • 项目日程计划
  • 日程计划的跟踪和管理状况

主要考察：

  • 计划准确程度
  • 各个里程碑偏差情况

典型问题：

  • 估算偏差有多大？
  • 日程计划准确程度如何？
  • 里程碑偏差有多大？
  • 日程计划有什么变更？为什么？

成本管理

成本管理包括：

对成本进行估算、预算和控制的各个过程，从而确保项目在批准的预算内完工。

典型问题：

  • 项目计划投入总时间是多少？实际是多少？
  • 各个阶段计划投入时间是多少？实际是多少？
  • 偏差的原因是什么？

质量管理

质量管理包括：

执行组织确定质量政策、目标与职责的各过程和活动，从而使项目满足其预定的需求。

典型问题：

  • 项目整体质量状况如何？
  • 验收测试缺陷率是多少？
  • 有没有办法在前期消除这些缺陷？

人力资源管理

项目人力资源管理包括：

组织、管理与领导项目团队的各个过程。

典型问题：

  • 项目的生产效率如何？
  • 每个人的生产效率如何？
  • 每个人对项目的满意程度如何？
  • 有没有提升的办法？

沟通管理

项目沟通管理包括：

为确保项目信息及时且恰当地生成、收集、发布、存储、调用并最终处置所需的各个过程。

典型问题：

  • 项目有没有因为沟通不够导致问题？
  • 各个项目干系人沟通手段有哪些？有没有需要总结的经验教训？
  • 什么样的沟通方法最为有效？

风险管理

项目风险管理包括

风险管理规划、风险识别、风险分析、风险应对规划和风险监控等各个过程

典型问题：

  • 哪些问题在前期没有预料到相应风险？为什么？
  • 哪些风险应对措施比较有效？
  • 组织层面哪些风险发生频度较高？
  • 整个风险管理有哪些经验教训？

采购管理

项目采购管理包括：

从项目组织外部采购或获得所需产品、服务或成果的各个过程。

典型问题：

  • 项目方案是否合理？
  • 各类采购而得的工具是否合用？
  • 供应商服务的评价？
  • 采购相应的成本和风险考虑？
  • 项目合同管理的经验教训有哪些？

整合管理

项目整合管理包括：

为识别、定义、组合、统一与协调项目管理过程组的各过程及项目管理活动而进行的各种过程和活动。

典型问题：

  • 各类计划之间是否协调一致？
  • 团队章程的执行状况怎样？
  • 项目变更的处理流程是否有效？
  • 项目完成之后相应产物是否得到妥善保存？
  • 有没有对组织过程资产的更新？

TSP 项目总结

TSP 也提供了一种项目总结方式：

团队成员结合自己的角色，总结自己角色相关工作的得失，提出下一个开发周期的改进建议。

典型角色包括项目组长、计划经理、开发经理、质量经理、过程经理和支持经理等

TSP 总结过程阶段

TSP 总结过程包括：

  • 准备阶段
  • 过程数据评审阶段
  • 人员角色评价阶段
  • 总结报告撰写阶段

准备阶段

在准备阶段，TSP 教练将向整个开发团队详细解释总结过程的各个步骤，强调过程数据的重要性，解释总结报告的格式和内容等

过程数据评审阶段

  • 该阶段往往由过程经理或质量经理带领整个团队分析过程数据，识别过程改进机会。
    • 可以结合典型TSP团队角色，逐个讨论改进领域。如团队领导力、计划准确性、过程优劣、质量管理能力、开发环境以及配置管理等
    • 也可以就 TSP 教练的作用进行评价
    • 开发团队所有成员都需要整理过程改进提案 PIP

PIP Process Improvement Proposal 过程改进提案

PIP 是 TSP 过程中供开发人员在日常工作中记录改进想法的工具。

基本思想：

积累小的改进，慢慢形成大的改进

人员角色评审

项目组长

  • 项目组长的角色评审应当从领导力角度考察团队表现

  • 重点关注团队激励和团队承诺方面的问题

  • 项目会议组织情况需要总结
  • 就下一周期如何做得更好提出改进建议

计划经理

计划经理主要关注项目进度，需要就估算、生产效率、里程碑等话题进行总结

总结话题包括：

  • 项目产品规模估算值和实际值有多大偏差？为什么？
  • 项目计划开发时间与实际开发时间有没有偏差？原因是什么？
  • 项目整体生产效率是多少？
  • 人均资源水平有多少？
  • 项目 PV 与 EV 趋势是什么？为什么有偏差？
  • 与以前开发周期相比，生产效率有没有提升？为什么？
  • 下一个开发周期需要如何提升？

开发经理

开发经理应当从开发内容和开发策略角度总结得失，也应当就质量话题提出见解

典型问题：

  • 实际开发结果与计划开发内容相比，是否完全实现需求？
  • 事先定义的开发策略是否有效？如何改进？
  • 现有设计和实现步骤是否有助于质量目标实现？
  • 对可用性、性能、兼容性等高层次质量要求，现有设计方法和实现平台是否可以支持？
  • 现有质量度量方式效果如何？未来怎样改进？

质量经理

质量经理应从项目整体质量状况出发，总结质量目标实现过程，并找出改进机会。

典型问题：

  • 项目整体质量状况如何？质量目标实现了吗？为什么？
  • 是否所有预定的质量管理活动都开展了？如果没有，为什么？
  • 项目进展过程中，质量趋势是什么？
  • 每个阶段的 yield 分别是什么？为什么有的过低？
  • 测试开始之后有多少缺陷？哪些缺陷可以通过什么方式在前期排除？
  • 现有质量管理手段效果如何？有哪些需要改进？

过程经理

过程经理关注团队遵循过程的程度和过程改进方案

典型问题：

  • 是否所有人都如实记录数据？
  • 团队成员对过程遵循状况如何？为什么？
  • 记录的过程数据说明了什么？
  • 现有过程有哪些不足？
  • 所有 PIP 都提交了吗？
  • 哪些 PIP 值得在下个周期实现？如果要实现，对现有过程需要做什么调整？

支持经理

支持经理主要关注配置管理状况、问题和风险跟踪机制以及复用策略的支持等话题

典型问题：

  • 项目团队开发环境是否合用？
  • 项目过程中配置项出现几次变更？原因是什么？未来如何改进？
  • 配置管理活动开展情况如何？是否有未经授权的配置项修改？
  • 风险和问题跟踪机制是否有效？是否所有问题都得到处理？
  • 风险有没有导致项目负面影响？
  • 哪些风险一开始没有被识别出来？
  • 复用策略是否有效？
  • 对比上一阶段，复用比例是否上升？为什么？怎么改进？

工程师

工程师重点关注的就是个人的绩效（生产效率、质量水平等）

典型问题：

  • 个人计划绩效与实际绩效有没有差别？为什么有偏差？
  • 对比上个周期有没有进步？为什么？
  • 下个开发周期将如何改进？
  • 根据个人总结的 PIP，最值得改进的有哪些内容？

练习题

练习 1：WBS

题干：

下述关于 WBS 的描述中，哪些说法不正确的？

  • WBS 应该对应 OBS
  • WBS 提供了范围管理的基础
  • WBS 工作分解最底层的要素是实现目标的成分必要条件
  • WBS 分解的时候，同一层不能应用不同标准

答案：

  • WBS 应该对应 OBS

解析：

WBS 是以可交付成果为导向的工作分解结构，核心是定义项目工作范围和工作包；OBS 是组织分解结构，强调组织或人员结构。WBS 可以与 OBS 配合用于责任分配，但 WBS 本身不等于 OBS，也不要求直接对应 OBS。

缩写 全称 关注点
WBS Work Breakdown Structure 项目要做哪些工作
OBS Organizational Breakdown Structure 谁来做、哪个组织/部门/角色负责

练习 2：EVM

题干：

下述关于 EVM 的描述中，哪些说法不正确的？

  • EVM 不适用于质量管理
  • EVM 的中级实现中引入成本信息
  • EVM 高度依赖估算准确
  • EVM 可以适应需求变更

答案：

  • EVM 的中级实现中引入成本信息
  • EVM 可以适应需求变更

解析：

EVM 的中级实现是在简单实现基础上加入日程偏差计算，如 SV = EV - PV 和 SPI = EV / PV；实际成本信息是在高级实现中进一步考虑的。PPT 也指出，EVM 完全依赖项目的准确估算，而项目早期很难准确估算，因此它对需求频繁变化和探索型项目并不友好。