04. Estimate, Planning and Tracking

1. 估算 Estimate

TQM(全面的质量管理)

• 产品和服务的质量取决于他们的过程的质量

PSP 怎么会出来的?

• 在80年代Humphrey发现了，企业尽管已经达到了CMM的4级5级水平，但是真正出来的产品(质量方面等)不满意，工程师的能力(尤其是管理能力)太差。这样的出发点 Humphrey 为了补强这一些工程师的管理能力，设计了 PSP/TSP (CMM 只能去衡量这个软件组织在满足自己的业务目标方面的能力)

PSP 的作用?

• 个人级管理实践和过程估算和计划

• 帮助我们承诺和拒绝承诺

  因为根据团队动力学，鼓励承诺是很好的激励手段

PSP是什么?

• 包括策划、设计、编码、编译、单元测试以及总结等阶段
• 也包括过程操作指南 :就是指导每一个步骤怎么做的
• 每一个步骤生成日志，而且日志是总结的时候使用的。

PSP3.0 跟之前 PSP 比较

• 差异在于 PSP3.0 可以“自定义”

GQM

• G目标 Q问题 M度量
• 只要出现有数据度量的地方都应该有 GQM 分析
  • G — 你要实现的管理目标是什么?
  • Q — 围绕着 G(目标)你要回答的关键问题是什么?
  • M — 为了知道问题的答案需要获知什么数据?

GQM+

• 跟GQM几乎是整个体系是一样，只是考虑的范围是不一样
• 早期的时候，大家觉得 GQM 更多关注的是项目小组的度量。

PSP 基本度量

• 规模
• 时间 : 所属阶段、开始时间、结束时间、中断时间、净时间
• 缺陷 : 发现日期、注入阶段、消除阶段、消除时间、关联缺陷
• 日程 : (进入到 TSP)几号到几号来完成

为什么 PSP 基本度量当中这样来设计呢?

• 项目管理的三大目标 : 什么时候完成，成本怎么样，质量怎么样
• 成本信息 = 通过时间度量(每个任务时间)可以获得
• 质量信息 = 通过缺陷度量可以获得
• 工期信息 = 通过日程度量可以获得

那么为什么度量“规模”呢?

• 规模数据是连接时间，缺陷，日程的桥梁。没有规模数据，这些数据都不能用

PROBE 估算流程

应用PROBE 方法进行估算的优缺点

• 优点
  • PROBE方法通过定义的估算过程和数据收集以及使用的框架，使得估算结果可以尽可能一致，从而使得一些统计方法可以用来调整估算结果，增强用户对估算结果的信心。
• 缺点
  • 非常依赖高质量的历史数据，一旦数据不完整或者缺失，就可能导致估算结果有显著偏差。

计划框架

那些环节是必须要人工的，自动化的？这样的安排有什么好处？

• 人工 ： 需求定义，概要设计，团队资源水平
• 自动化 ： 规模估算，资源估算
• 好处 ：
  • 如果管理层否决一份计划，那么“人工做的环节 — 概要设计，团队资源水平”是的攻击点。
  • 但是这种方式做出来的计划很难攻击。对于团队来说一般在计划阶段更改项目范围包括开放的态度

为什么PSP里不需要生产效率？

• 生产效率是可以有的，此原因只和数据处理有关。
• 生产效率载计算的时候是分母（规模除效率）
• 而它本身是一个范围，使得范围被数学上的放大了
• 如果不用效率，回归算法可以容纳更多波动，应用场景更广

历史数据的处理方法：(生成相对大小矩阵)

• 简单方法的优缺点 ：计算简单，但是不稳定
• 正态分布法的优缺点 ：相对稳定，但是，VS出现负数
• 对数正态分布的优缺 ：更加符合人们对于程序的规模的直观感觉，因为大多数⼈习惯写很多规模很⼩的程序

PROBE方法

• Probe方法依赖历史数据，但是实际历史数据有可能历史数据少于3个数据点。
• 或者有时候有足够的历史数据，但是数据的质量不高。

“相关性” 和 “显著性”

• “相关性” 描述的是两组变化的数据之间相互关联的程度 👉 越大越好

• “显著性” 描述的是上述两组数据的相关关系出现的偶然性 👉 越小越好

• 为啥我们需要“相关性” 和 “显著性” 的例子

  

  💁🏻 页数跟所需要的时间之间的相关性太弱

  

  💁🏻 跟上面一样的数据。因为很远位置的一个点让相关性很低的数据变成极高的相关性。但是显著性一定是很高的

PROBE 估算规模

PROBE 估算时间

估算整理

• 估算是一个达成共识的过程，而不是获得正确结果的过程
• 估算改进的时候，你要改进，提升的是沟通能力，更加可信的，而不是判断力（判断力是提升不了）
• “开发经验”跟“估算的正确性”这两者没有联系。
• 估算结果对不对是不重要，提升这个结果没有任何价值

2. 计划 Planning

• 计划 : 如何制定⼀份让⼈无法拒绝的计划，请描述基本步骤和⼀些注意事项

WBS(工作分解结构)

• 是满足项目目标和开发交付产物的项目相关工作进行的分解
• 它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义

日程计划

• 日程计划 🆚 任务计划 :
  • 任务计划：一个任务的清单，你要做哪些事情，这些事情分别是谁来去来完成的， 这些事情需要多小资源
  • 日程计划：每一个任务几号到几号来完成
• 形成日程计划的时候，重点考虑的是
  1. 任务清单是否合理
  2. 有效的时间（资源）

质量计划

• 在质量计划中需要解决的关键的问题是该开展哪些活动，以及这些活动开展的程度，如时间、⼈数和目标分别是什么。

风险计划

• 风险识别
  • 识别与成本、进度及绩效相关的风险
  • 记录某一个风险的时候
    1. 记录这是一个什么风险？风险的来源是啥？
    2. 风险两个参数 ：风险发生的可能性，风险影响程度
• 风险应对
  • 应当制定相应的风险管理策略，以应对各类风险
  • 典型的策略：
    • 风险的转嫁 – 将部分的项目风险转嫁到其他的团队或者组织
    • 风险的解决 – 采取一些有效措施，使得风险的来源不再存在
    • 风险的缓解 – 允许风险的存在，但是需要缓解它，通过各种方式限制或者改变风险可能性和影响程度

3. 跟踪 Tracking

• 跟踪 : 目的在于了解项目进度，以便在项目实际进展与计划产有偏差时，可以采用适当的纠正措施

EVM(挣值管理方法)

• 在传统的项目（尤其是生产行业，建筑行业）管理方法当中，习惯于使用“关键路径”方法。

• 起源 ：

  • 是NASA提出来的
  • NASA不是只有软件项目，也包括多种学科。所以这种项目不能完全实现正确的预期

• 简单的原理：

  • 先分拆项目，每项服务实现附以一定价值
  • 对于任务有两种状态 ：
    • 未完成(1～99% 没有拿到价值)
    • 已完成(100% 拿到价值)

• 特点：

  • 适应动态的，变更的方式
  • 只适合大型的项目。小的项目有点浪费
  • 可以把一个项目的很关键的进度，成本这种信息展示出来

• 局限性：

  • 跟质量没有什么关系
  • 特别依赖准确的估算

• 挣值分析图 ：

  

  • 如果三根线合成一根线 ： 这意味着项目的进度跟计划一致，成本根计划一致
  • 简单实现 ：没有成本线。只有PV跟EV，然后看两者之间的进度偏差
  • 中级实现：在简单实现的基础上，加入日程偏差的计算
  • 高级实现 ：在中级实现的基础上，还需要考察项目的实际成本

纠正偏差活动关注

• 得有一个原因的分析 ：什么样的原因导致这种偏差
  • EVM容后原因1：估算上的偏差（这个时候，更改计划）
  • EVM容后原因2：投入资源上的偏差（比如说，计划每周投入80个小时，实际呢，每周根本投入不了这么多时间）
• 定义一下偏差的措施
• 对于纠正偏差的措施应该要跟踪，管理，确保真正的产生作用

项目总结

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

两种项目总结的方式

• 基于PMBOK的总结
  • 整合管理9大知识领域(范围，时间，成本，质量，人力资源，沟通等)
  • 这是为了做一个“系统”的项目总结
• TSP项目总结
  • 团队成员结合自己的角色，总结自己角色相关工作的得失，提出下一个开发周期的改进建议

---

《Reference》

1. 2020年(秋) 软件质量与管理 : 荣国平

---