1. 估算

1.1. 概述

目的：给各类计划提供决策依据
对象：规模，时间，日程
常见问题：
1. 人月是资源/时间的单位，而不是规模单位。人和月不能互换
2. 项目交互日期、团队都确定了，估算的意义在哪里？
3. 哪种估算方法？
4. 哪种估算结果更好？

估算只能给自己估算，给别人估算没有意义

1.2. 关于估算的事实

估算是主观猜测
估算能力很难提升
没有任何人知道准确的数字是什么
实验表明，是否使用估算模型，并没有显著提示

1.3. PROBE估算方法

规模度量/估算的困境
- 以LOC vs. FP为例
  1. 精确度量往往不便于早期规划的估算
  2. 有助于早期规划/估算的度量往往难以产生精确度量结果
PROBE(PROxy Based)
- 可以给出相对精确的估算
- 作用：精确度量和早期规划之间的桥梁
原理：
1. 设立合理的代理作为精确度量和早期规划需要之间的桥梁
2. 使用相对大小，而非绝对大小
流程
1. 概要设计
2. 代理识别和代理规模(E)->相对大小矩阵

1.3.1. 概要设计

需要确定产品功能，以及产生这些功能所需的程序组件/模块
将这些程序组件/模块与你以前写的程序相比较，估算它们的规模
将程序组件/模块估算综合给出总规模

1.3.2. 整合多个估算结果

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

估算要点1：估算时尽可能划分详细一些
- 当估算多个部件时，总的误差会比各个部件误差的综合要小

1.3.3. 例子

1.4. SCRUM中的Story point

度量实现一个故事（Story）需要付出的工作量
1. 抽象：混合了对于开发特性（feature）所要付出的努力，开发复杂度，各种风险以及类似东西
2. 相对：设定标准之后，考虑其他特性（feature）与标准之间的相对大小关系
  - 拆分

团队需要定义单位故事点：规模、优先级等，抽象

估算要点2：目标是建立在对结果的信心上的
估算要点3：尽量依赖数据

1.5. 估算方法的反思

估算目标
- 规模估算S比较稳定，时间估算T=S/P。但生产力P可能有1~~26倍的偏差。1~~26倍的P算出来的时间都可以接受。
- 实际生产中让大家认可估算结果，反过来提高生产效率P
到底怎么做估算：
1. 达成共识
2. 建立信心
  1. 足够详细
  2. 依赖数据
  3. 最好的猜测，注意检验假设条件的合理性

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

1.6. 估算要点

估算要点1：估算时尽可能划分详细一些
- 当估算多个部件时，总的误差会比各个部件误差的综合要小
估算要点2：目标是建立在对结果的信心上的
估算要点3：尽量依赖数据
估算要点4：估算要的是过程，而非结果；估算的过程是相关干系人达成一致共识的过程。
- 团队达成共识，提高生产力
- 如果估算结果有问题，应该去和管理层或客户沟通，而不是提高估算结果

1.7. 度量–历史数据的获取

关于度量的争议：度量体现着决策者对试图要实现的目标的关切程度
- 是否需要度量取决于是否在意结果
度量体系
- GQM(Goal Question Metric)：数据治理
  - 从目标出发，只关心单个项目组
- GQM+：关心整个组织，

实际上估算可能要在项目启动之前就开始，而不是等到需求完成

1.8. PSP基本度量项

规模
时间
缺陷
日程TSP

1.8.1. 时间度量（时间日志）

日志内容	注释
序号	记录序号
所属阶段	记录所属的PSP阶段，如策划、设计、编码、编译、单元测试、总结等
开始时间	精确到分钟
结束时间	精确到分钟
中断时间	记录的计时过程中，需要中断的时间，精确到分钟，如中断打电话
净时间	结束-开始-中断，表示该阶段纯工作时间
备注信息	记录中断事件

1.8.2. 缺陷度量（缺陷日志）

日志内容	注释
序号	-
发现日期	-
注入阶段	经过分析，确定该缺陷被引入的阶段，典型引入阶段如涉及、编码、编译、单元测试等
消除缺陷	该缺陷被消除的阶段，在引入阶段之后
消除时间	为修正该缺陷所消耗的时间
关联缺陷	如果缺陷的引入阶段是编译或者单元测试等通常用以消除缺陷的节点，那往往意味着该缺陷是在消除其他缺陷时被引入的，需要建立关联
简要描述	产生的根本原因

2. 计划和跟踪

为什么要跟踪：跟踪的目的在于了解项目的进度，以便在项目实际进度与计划产生严重偏离时，可采取适当的纠正措施；

项目进度滞后与否需要参照物，即项目计划

项目跟踪需要管理针对偏差而采取的纠偏措施

2.1. 工作分解结构（WBS）

将复杂的项目逐步分解为一系列明确定义的工作任务并作为随后计划活动的指导文档。
最底层的元素不能重复。

2.1.1. 创建WBS方法

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

WBS提供范围基线（确保项目做且只成功完成项目所需的全部工作），不遗漏可交付物，明确各个角色的责任，作出工作包定义，是估算和计划的基础，有助于理解工作，分析风险

2.1.2. WBS范围管理

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

2.2. 过程框架-生命周期模型

指导开发的是软件过程，而不是生命周期模型，所以至少要把里面一些部分展开

2.3. 通用计划框架

倒推式估算不准确

要先做估算，然后正推
管理层和估算值都知道“估算不准确”这一前提

上述框架中哪些步骤是人为的：
1. 定义需求
2. 概要设计：规模划分好之后，估算可以自动进行
3. 日程计划
PROBE在框架中充当的角色：用来完成规模和资源的评估
这样做的好处：反驳别人对估算的质疑。
- 攻击点：规模估算代码行数太多，资源估算不需要那没多资源
- 反驳：PROBE只讨论需求不讨论具体数字，而需求到具体数字是自动计算的过程（基于相对大小矩阵和历史数据）

2.4. 风险识别

头脑风暴是因为无法系统识别风险

风险是可能性还未发生，问题是已经发生的。但如果风险超过某些阈值，也可以认为变成了问题。

2.5. 风险应对

识别风险之后，就应当制定响应的风险管理策略，以及应对各类风险
策略
1. 风险转嫁：付费给另一个团队，让他们帮你解决风险，但是你的收益会降低
2. 风险解决：比较困难，很难彻底解决风险
3. 风险缓解：共存，容忍

2.6. 挣值管理方法

2.6.1. 概念

挣值管理(Earnd Value Management，EVM)是用来客观度量项目进度的一种项目管理方法。
- 每项任务实现附以一定价值(credit)
- 100%完成该项任务，才能获取相应价值
- 非常保守的策略，只承认100%完成的任务，适合知识工作。
支持动态随时变化
采用进度计划、成本预算和实际成本相关联的三个独立变量，进行项目绩效测量

2.6.2. 规则

获取挣值规则：
1. 0-100，完成了就是100，差一行代码都是0
2. 50-50：打算做这件事就拿到50，全部做完了再给50
解释：提早给出反馈，可以让进度数据更好看，利于激励团队
例子：
- 价值是百分比，经常省略%

2.6.3. 图示

PV：计划值
EV：挣值，从计划来，与实际投入时间无关
SV：进度差异，EV-PV

AC：实际成本，工时
BAC：项目总预算，表示按照PV值的曲线，当项目完成的时候所需预算或者时间
CV：成本差异， EV-AC

成本差异指数CPI = EV/AC
日程偏差指数SPI = EV/PV

预计完成成本EAC = AC+(BAC-EV)/CPI = BAC/CPI

画延长线可以预测项目进度
如果项目进度预期会延期，加人提高未来的EV，或砍功能提高已经完成的EV

2.6.4. 实现等级

初级实现：只分析到现在为止的PV，EV
中级实现：根据PV,EV做预测分析
高级实现：加入成本线

2.6.5. 变形-燃尽图

Ideal
Actual

2.6.6. EVM局限性

只能跟踪进度、成本，而无法跟踪质量等目标，EVM一般不能应用软件项目的质量管理
需要定量化的管理机制，在探索型项目以及部分敏捷开发方法中的应用受到限制
完全依赖于项目的准确估算（价值体系），然而在项目早期，很难对项目进行非常准确的估算

2.7. 里程碑评审

2.7.1. 概念

往往指的是某个时间点，用以标记某项工作的完成或阶段的结束
内容
1. 项目相关的承诺，如日期、规格、质量
2. 项目计划的执行情况
3. 项目目前的状态讨论
4. 项目面临的风险讨论

比周会等进度评审更加正式，需要高层、客户参与

回答项目能不能进入下一个阶段，如需求完成但是质量很差被高层否决

2.8. 其他计划跟踪

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

2.9. 纠偏活动管理

典型活动
1. 偏差原因分析
2. 纠偏措施定义
3. 纠偏措施管理

3. 项目总结

软件项目的特点决定了持续改善对于软件工程师的重要性
提供一个系统化方法总计

3.1. 过程

准备阶段
总结阶段

3.2. 基于PMBOK的总结

9大知识领域

Charlie's Blog

04-估算、计划和跟踪