《A++ 敏捷开发》- 5 量化管理从个人开始_a++编程每周一次需多长时间

如何降低项目进度偏差

从以上对话可以看到，敏捷开发不一定能帮助团队按期交付，开发人员也不清楚自己的生产率是多少。要减少项目的延误，首先取决于估算是否准确。但如果只是依赖个人经验、头脑风暴去估计，很可能低估，因为可能没有考虑开发以外的一些因素，比如缺陷问题、需求问题等。在同一个冲刺里，不能交付所有计划的模块，等同于延误。要做好估算，就需要有数据。数据需要从个人收集的历史数据作为参考。IT公司是否有注意这方面？我们可以从他们的新员工入职培训探索一下。

从量化培训开始

从以上对话可以看出很多公司都没有与量化软件开发项目管理相关的培训，这样如何能希望他们在项目中做好量化管理？入职不仅需要培训开发的技巧、怎么写好程序、做好面向对象设计，也应该学到要一直度量自己的开发过程，包括所花的工时、过程中发现的缺陷数等。
培训师会问：在新员工培训时，如何可以加入这些量化的元素呢？
很简单。首先，在先培训质量相关的技术指标，比如什么叫质量成本、什么叫排除率等，然后做实战练习时，要求他们除了写程序，还需要记录一下所花的工时，自己项目检查时发现的缺陷数、测试的缺陷数、评审所花的时间等。也要求开发人员除了提交程序以外，提交一个开发计划报告，内容包括实际所花工时、本来预估的工时、过程里发现的缺陷数、在哪一类过程等。帮助他们一进入公司就培养一些量化度量的习惯，以避免过了试用期，开发的习惯已经养成，后面是很难改变的。

从估算、策划到监控

挣值分析(Earned Value，EV)是常用的项目监控技巧，如果简单用百分比监控项目的进度或工作量偏差，因缺乏明确定义，难以比较，挣值分析把计划、实际等都统一用成本来计算，没有项目管理工具也可以简单手工计算（EV公式与示例，详见附件）。Humphrey先生出版了不少书，他也用EV分析来监控进度，他在PSP书中以此为实例，介绍如何用挣值分析策划与监控。我也试过用同样思路来监控本书的进度（详见附件案例）。下图是PSP估算与监控的流程：

可以把敏捷的燃烧图方法看成挣值分析法的简化版，挣值分析也可以按现在的速度来预计完成的时间，但因为它要适合各种类型的项目（燃烧图假定每一轮迭代的速度不变）。
传统大型项目每个时间段，投入元素、工作量都会有变化，挣值分析法可以按当前的进展和投入预计完成的情况。但无论是挣值分析法或者燃烧图都是单点估算。想了解如何使用高中低三点估算和PERT方程式估算总工作量与范围，详见附件里的案例。

很多软件开发项目延误的原因是以前没有收集历史数据，导致估计所需人时都很理想。我也有同样问题：从我的挣值分析实例看到，因我是第一次写书，之前也没有养成统计章节所花的实际工时的习惯，所以在11月初做估算时，理想地认为最多花一个月完成，但过了3周就发现，实际比本来计划延误很多，原因包括：

• 实际可用工时没有想象这么理想，有很多意外事情都要处理。
• 低估了完成一章节所需时间：
  • 例如第一个章节TDD实际所花的工时与估计差不多，原因是这个章节是现有的，只是做了一些调整，所花时间不多。
  • 但到第二个章节MGR就不一样了，全部内容都重新写；如何从实际客户现场的场景总结，与理论结合也很花心思。

所以下次当你遇到一些团队项目延误，可以问项目经理以下问题：

1. 如何估算项目工期
2. 如何估算每一项任务所需的工时，依据是什么？
3. 如何收集实际工作量？
4. 如何监控累计到现在的完成情况？
5. 有没有统计以往的历史数据？如何用来帮助做好估算？

你可能会发现类似我用挣值分析估算和监控暴露出的问题。

应如何改善

软件开发和工业生产不同，工作量数据必须靠个人自己收集，量化管理依赖个人习惯，所以Humphrey先生在90年代推出了PSP个体软件过程，教导开发人员如何一步步自己收集数据、自己估算、自己监控。例如记录花了多少工时、发现多少缺陷、完成多少代码（从最基础开始，逐步改善），尽量减少缺陷返工，提升开发效率。(详见附件PSP简介。)

也正因为大部分的团队都没有收集数据的良好习惯，没有PSP的基础，所以就很难要求他们在冲刺回顾时拿出数据，分析根因、在下一轮迭代改善，从定性提升到量化管理。当开发人员养成好习惯，就会更清楚知道自己的速度和质量水平，不会出现本章开头的场景，开发人员对自己的质量水平或生产率一无所知。

有些企业深知量化管理对企业发展很重要，所以在新员工培训时，不仅仅教他们技术技能，也教他开始自己每天记录工时、缺陷数等习惯。 因为工作习惯养成后，便难以改变。反之，如果周边的人都有记录数据，自己也觉得应做记录，逐渐形成公司文化。

PSP 要求评审代码，分析每个发现的缺陷，讨论原因，然后改进。有些管理者听过PSP，但认为PSP成本太高，只适用于高价值、高质量要求的项目。如果他们理解PSP能最终帮团队把缺陷返工减半，能降低开发成本20%，便不会再觉得PSP不适用于公司。（后面会有相关例子。）

估算很重要，要做好，不仅仅要参考历史数据, 也需要对需求有共同的理解。功能点方法是估算软件规模的一种标准，下一章会用实例介绍。

附件

挣值分析法（Earned Value）

用最简单的例子，来说明挣值分析中PV、EV、与AC的意义。

PV：计划完成多少？

AC：完成工作的实际成本是多少？

EV：实际完成了多少工作？

公式：

进度偏差 SV = EV - PV , SPI = EV / PV 完成占计划完成的百分比

成本偏差 CV = EV - AC , CPI = EV / AC 完成的价值占实际已花成本的百分比

本文实例主要关心进度偏差，所以没有计算 AC

以下面“使用挣值分析监控案例”为例：
截止到22.11.20 ， PV 累加本应是 27.5，EV 只有 3.1

所以 进度偏差 SV = EV - PV = 3.1 - 27.5 = -24.4 工时

SPI = 3.1 / 27.5 = 11.27%

用PERT公式估算头三周任务累积工时的95%区间（工时）：
不用MonteCarlo模拟，直接把12(=1+4+7)章节任务 的ExpectedValue 加起来

计算12步总方差：（方差 =  )

总方差 = 每步方差的总和

总方差=1.69（  = 总方差的平方(Sq.Root)）

EXCEL 公式为：SQRT(SUM(所有方差范围)) = SQRT(SUM(H3:H15))

95%范围下限(=55.8)

EXCEL 公式为：SUM(所有Expected范围)-2×总方差 = SUM(F3:F15)-2×I15

95%范围上限(=62.5)

EXCEL 公式为: SUM(所有Expected范围)+2×总方差 = SUM(F3:F15)+2×I15

如何简单记录工时

如前面“克服拖延症”里提到，每人根据自己的习惯，采用每日ToDoList的方式，然后在开始前，简单记一下时间，结束时也记下时间。然后每日/每周统计每任务总工时:

如只是个人，不一定需要项目管理工具；如果是团队，可把自己手工记录上传到项目管理工具，方便团队记录与监控。

个体软件过程 Personal Software Process（PSP） 简介

PSP跟CMMI成熟度模型类似，也是按部就班一步步，帮助软件工程师利用度量改进自我的开发过程。

PSP 0.1

第一步PSP先估计写某个模块所需要的时间和实际花的时间，记录所有的缺陷，包括因为需求、设计或者实现引起的问题，记录修复时间，从开始发现问题直到缺陷被解决，提升到PSP0.1策划不仅仅是估计所需时间，加入了规模的概念，本来PSP是用代码行数来估计规模，也可以使用简化功能点方式估计规模大小。
在PSP0.1的阶段还没有用规模做策划、估算，只是记录实际的规模，里面包括基本规模，就是在开发之前软件系统本来有多大。也记录删除、改变、增加、复用的规模数等。最后总的规模数应该是等于基本、新增、删除、复用相加。

PSP1

下一步，PSP1就有规模计划的概念，跟依据0.1的规模定义一样，我们在做开发之前，先估计刚才的所有规模数，并用回归方程估算对应的工作量或者进度，包括偏差的范围。
在 PSP0.1增加了一个过程改进建议的环节，依据上一次迭代的数据，发掘下一轮可以完善的改进过程。也加入了编码标准，这个跟我们前面章节提到代码规范的概念相同。所以在PSP0.1，除了计划，也需要有一个叫过程改进经验教训的部分，每一轮都应该有复盘回顾的概念，来提升个人个人的开发过程。

PSP1.1

PSP1.1基于的PSP1的基础，加入挣值分析法去监控实际的项目进展，加入了PV和累加的PV，计划多少和EV挣值和累计的挣值，反应实际完成多少。从那些系数也可以算出一个叫CPI成本性能指数，来反应完成与计划怎么比较，是否有延误，预计什么时候可以完成。详细可以看用挣值分析法估计写书完成时间的实例。

PSP2

到PSP2就开始增加评审的概念，包括设计评审、代码评审。这些同行评审是很有效的方式，避免缺陷等到出事才暴露、出现问题，因为如果只依赖测试暴露缺陷的话，只是告诉你这个程序跑不通，你还是要看代码才知道问题在哪里，怎么修正？但评审就直接看代码，首先它可以让很多缺陷在评审就发现，不用等到测试才暴露问题。评审也可以找出一些不一定测得出来的问题，例如有些银行对系统质量要求很高，核心的算法不能有任何错误，他们都会要求核心模块必须走专家评审，因为他们也知道很多核心算法的问题不能单靠测试来发现和处理。 也是这个原因，很多公司也会要求代码必须走静态扫描，利用扫描机器人评审代码，预先发现一些明显代码违规的语句问题，弥补单靠人手去评审的不足。
有了基础，再加入缺陷密度的概念，即缺陷数除以模块的规模大小，本来PSP是使用代码行的，我们也可以用功能点取代代码行，因为单看缺陷数无法比较，无论个人或者整个团队或者团队之间，所以必须除以规模大小，才可以把系数归一，变成一个项目组之间，人之间可以比较的系数。也引入了排除率的概念，如果我们只是做了评审，但是都是0发现，你的缺陷排除率就是零了，一点效果都没有，所以排除率可以看成是当前评审发现的缺陷数除以当前系统内总共引入的缺陷数，比率越高越好。也有阶段或者过程的排除率，就是这个阶段开始时总共有多少缺陷，然后在这个阶段里我们找出多少，作为分子的一个比例。还有一个就是缺陷排除的速度，按每小时评审的时间找出多少缺陷来判断评审中，可以找出缺陷的速度有多快，评审的效率有多高。

评审质量是PSP2.1 的概念，2.1 也增加质量成本（COQ）概念，与前面敏捷回顾篇里强调软件开发缺陷越后发现，返工量越会以几何式上升的思路一致。

PSP3

接近敏捷迭代的思路，把程序分成不超过几百行的模块，然后把模块按优先级分到不同的迭代 ，但还需要有需求与设计。敏捷增加了精益的思路，因为需求可能会有变，所以可以暂时不做后面迭代的估算，只先针对当前的迭代去做策划、估算。 敏捷里面的迭代回顾跟PSP的回顾如出一辙。

大家可以参考PSP书里面的教材和练习，比如在书中要求学员自己编写程序，自己记录时间。虽然现在开发语言统计方法跟90年代有差异，但原理还是共通的。如果对新员工难以安排学校式的一周课程，也可以考虑用自学的形式，按要求去记录学习、写报告。

使用挣值分析监控案例

今天11月8日，离年底要交付全部初稿的时间不到2个月，书的内容也完成了超过一半，但剩下的时间因为年底密密麻麻很多评估，而且评估就是早上9点开始到下午5、6点结束，只有中间一些空档时间和周末可以自由安排，所以我就用同样思路来策划估算是否能在年底完成要求。 第一步算出现在到年底可以用在写书的时间，按每周估计:

第二步从历史的数据估算剩下的章节，每个章节需要多少小时，写出计划的完成顺序，然后依据原计划可以使用的时间，按最佳使用算出每个章节可以在哪周完成，写在表格的右面空白处，从而估算何时可以完成所有章节，如果确实不能在12月底完成，就可能要重新调整、策划，是否有一些章节优先级比较低，暂时不放在第一版。
因觉得单点估算很难定一个点数，便用三点估算法。每一行估计都有3点：最差、最佳、最可能，用PERT方程式估计预计(Expected)和标准差(Sigma)。
挣值分析法里的 EV、PV、AC 都是用钱来结算（这个例子我们用所花工时），例如我们估计了每个章节所需要的工时，利用三点估算计算出每个章节预计的工时，加起来得出预计总工时是80.33工时（用PERT公式计算）。例如第一个章节TDD，预期工时是2.5，除以80.33就得出0.031，我们就用3.1作为TDD的PV（所有任务完成的总PV大概是100）。同样方式算出MGR章节的PV是6.6。得出每一个章节对应的PV后，我们就可以计算累计的PV数:

估计哪一周可以完成哪些章节，得出总体的进度计划。例如第三周累积有66工时，应可完成总共12(=1+4+7)个章节，因用PERT三点估算，累积工时95%范围是（55.8 ~ 62.5）。

监控

按实际完成的情况就可以填EV挣值，挣值的算法很简单，必须整个章节完成才算有挣值，不接受部分完成。比如第一周虽然TDD章节已完成九成，但实际是到第二周开始才完成，所以第一周的挣值为0。到了第二周才把本来的第一章节完成，所以里面才放上它的PV(=3.1)。监控的好处，好比要准备半年后的马拉松，开始长距离慢跑（LSD）锻炼，再进一步做连续马拉松配速训练，每周3天，每次5-15公里，速度是多少？比如平均每公里花费6.25分钟。有了数字才知道现状与标准的差距，才有动力对自己说现在离比赛不到12周，必须加强锻炼才能赶上。
要让项目有更大的机会按期完成，便需要监控，这样可以预计自己离最后交付差距是多少，如果按现在的进展要到哪一周才可以完成，都可以从数字预计出来。但是我们写书也靠灵感，跟写程序类似，可能顺序不一定能按本来的执行，怎么办？
其实道理也一样，你可以按新的顺序更新一下本来的计划，把实际的填上。如果你是用简单的Excel表，这个改变可能只花几分钟，很快就能调整好顺序。例如现在看到的第二章节，本来计划放在后面才写，但因刚好与客户接触后产生了灵感，便放在前面写了。

要估算任务工时便要依赖以往类似活动的历史记录，如果不是每天记录，过后无法记住。每周依据个人的习惯，每天记录实际所花小时数，然后统计每周累计数。

参考 References

1. Humphrey, Watts S. A Discipline for Software Engineering.
2. Humphrey, Watts S. PSP: A Self-Improvement Process for Software Engineers. (2005)