形形式式的度量陷阱

　　N年前，老板对我们过程改进工作曾指示：能量化的工作尽量量化，不能量化的就不要勉强。当时觉得这个指示非常好，我也相信这个观点很多人都会认同。实际上应该是这样吗?软件度量就必须用数字来说明问题吗?量化的结果一定比非量化的结果更准确客观吗?

　　没有一套好的度量工具，很难做好度量工作!这是很多人的认识。而一些度量工具的生产厂商，更加是大力渲染，目的还不是为了更容易从软件企业的口袋里面掏钱呗!要做好度量工作，真的需要一套强大的度量工具吗?

　　处于手工作坊的软件公司，难以进行软件度量，软件度量只能在有一定过程基础的公司进行。另外，对于小公司、小项目没有度量的必要，度量更适用于大公司、大项目。是这样吗?难道小公司、不规范的公司、小项目就不能利用软件度量来改善生产力吗?

　　软件生产活动是智力活动，要客观度量是很难的，要做好将会是很花成本的事情，而且开始阶段要忍受比较高的成本，软件度量所带来的效果，需要长时间才能体现。软件度量难道就没有立竿见影的效果吗?难道软件度量是大公司、有钱公司才能玩得起吗?

　　形形式式的度量陷阱，还远不止以上这些呢!

　　什么是度量?

　　我一直想搞清楚度量的定义，在网上查了一大轮，只能找到一些让人看了还不如不看的“学院派”的定义。搞清楚什么是软件度量，非常重要，将会让我们少走弯路，直接发挥度量的价值。看看下面我对度量的定义：

　　度量是这样的一种活动：基于一定的目的，采用一定的办法或者标准，对目标事物进行观察，得到客观的评价结果，根据评价结果，采取适当的行动。

　　这个定义，反应了度量活动的四个要素：

　　1.基于一定的目的。

　　2.采用一定的办法或者标准。

　　3.得到客观的评价结果。

　　4.采取适当的行动。

　　下面我们以度量水的温度为例来体会一下度量的定义。

　　如果有人给你一个度量任务，要求你度量水的温度，你会怎样做?

　　你会不会马上想到用温度计?

　　不好意思，如果是这样，你就落入了度量的其中一个陷阱了。你应该先问，为什么要度量水的温度?不同的目的，做法是不一样的。

　　如果度量的目的是为了判断煲水的时候水是不是开了。你还会用温度计吗?当然你可以用能测量一百摄氏度的温度计来度量水的温度，但我们更多的会用肉眼观察水的形态，来判断是否水开了，如果想更简单一点的，买一个水开的时候会响的水壶或者是搞个饮水机就可以搞定了。

　　如果度量水的温度，目的是希望水温合适，好帮BB洗澡呢?有些妈妈会用温度计，有些妈妈会用自己的手直接去感觉水温，两种办法都可以。

　　一个小小的度量水温的问题，都很有学问，大家发现，不同的目的下，做法是不一样的。有些做法很简单实用，不需要什么专门的工具，直接用手感觉温度，或者肉眼观察就可以了。相反，如果我们搞不清目的，就很可能杀鸡用牛刀，甚至是受到伤害，一个不小心，你就可能直接用手去感觉开水的温度了。

　　另外我们也发现，度量的结果不一定都是数字来的，只要满足目的，越简单越好。水是否开的问题，我们只需要知道水是否开了就可以了，度量结果只有两个：是或者否，我们不需要知道这水是摄氏多少度。度量并不需要很精确，满足目的就好!

　　度量的目的不是光为了得到一个结果，而是要根据度量的结果采取行动。如果妈妈发现水温不够，她会加入一些热水，如果觉得太热，就会加入冷水。这些行动的目的就是为了让BB有适合的水温洗澡。

　　首先应该度量的指标——公司的效益指标

　　如果要做度量工作，最开始应该度量什么呢?我建议应该首先度量公司的效益，度量效益的目的是对公司生产力状况有一个准确的认识，更准确地分析出问题所在，为决策提供更准确的依据。

　　那么公司的效益该如何度量呢?

　　公司有两大生产力指标，成本与收入。公司近一年的总体成本，包括人工、采购、水电费、房租费等全部费用加起来，财务肯定会有这样的一个数字。公司近一年所有人员的工作时间，所有人员包括开发、测试、行政、财务等，凡在公司的工作的所有人，这些人上了多少天的班，一定也会知道，每个公司都有考勤请假的记录吗，就算没有也可以大概估算。这样我们可以得到公司全部人员一年的总体工作时间，单位是小时。这样我们有这样的一个指标：

　　成本指数 = 公司总费用/总工作时间，单位：元/小时

　　这个数字表明，在这个公司工作的每一位员工，每工作一个小时，其实是需要这样的一个成本的。没有算的公司尽快算算，你可能会发现，原来这个数字还相当大呢，远远超过这个人的时薪。

　　关于收入，我们有这样的一个指标：

　　收入指数 = 公司总收入/总工作时间，单位: 元/小时

　　这个数字表明，在这个公司工作的每一位员工，每工作一个小时，为公司带来多少的价值。

　　如果收入指数大于成本指数，说明公司是在赚钱的。公司的生产力就可以看这两个数字了，我们希望尽量降低成本指数，尽量提高收入指数，于是我们会得到下面这个指标：

　　效益指数= 收入指数:成本指数

　　企业最终追求的是提高效益指数，成本大没关系，效益指数高就没问题了。这些指标都可以继续细化，如：可把成本分类，成本会分成人工成本、非人工成本，人工成本有可以分为工程类人员人工成本、支持类人员人工成本等，经过细分，可以发现自己的成本构成不合理的地方，进行相应的改善。如：把收入细分，看看收入的组成，收入都是由哪些部门哪些人产生的，这些都能帮助企业提高收入。

　　公司的效益指标的度量是任何公司都可以做的，而且应该是第一时间就要做的度量，并且要持续地做的。公司所做的任何工作，市场活动、过程改进工作、度量工作等等，最终目的还是为了提高效益指数!

　　每个软件公司都可以并且应该做好的度量——缺陷度量

　　就算一个开发极不规范公司，我想总会对缺陷有一定的管理办法吧?至少缺陷会被记录下来(哪怕是各种方式)，而不会只是口头说而毫无记录吧?

　　大多数软件公司都会有一套管理缺陷的系统，我们应该如何把缺陷度量做得更好呢?

　　我们需要目标驱动地把度量工作做好，首先有两个最基本的要求：

　　1.缺陷被准确的记录和跟踪。

　　2.客观地依据缺陷状况对软件发布进行决策。

　　根据这两个要求，我们需要详细定义缺陷的属性，这些缺陷的属性就是我们要度量的内容。很多公司都会定义缺陷的描述、严重程度等属性，另外也会规定发布的时候，什么严重级别的缺陷不能超过多少个等要求。

　　以上两个目标只是缺陷度量的两个基本目标，如果更深入一点，我们希望能预防缺陷的再次发生，最简单有效的办法就是：直接让项目组成员一起来分析缺陷的原因，让大家避免重犯。

　　如果想做更系统更深入的分析，就需要考虑在组织层面来做这个分析工作。这时有必要增加缺陷一个属性，叫做“缺陷来源”，就是说产生这个缺陷的源头是在哪里，是需求没有分析到位，还是设计没有做好，还是编码出问题?按“缺陷来源”来分析公司不同类型的项目的缺陷情况，您就会发现公司的软件开发过程最有问题的是哪个过程?哪些过程做得比较好?这些分析结果会很好的指引过程改进的方向。

　　缺陷度量有很多可以发掘的地方，这是每一个公司都应该做好也是最有条件做好的一种度量。

　　成功的基础——软件规模度量

　　最近有这样的一个辩论，功能点VS代码行，辩论的焦点就是用哪一种来代表软件规模更好一点。项目规模的度量大有学问，如果您想去听听专业的软件功能点法课程，您可能要付上高昂的学费，并且有可能学了后还不知道如何用上这个办法。这里不详细谈论这两种办法，这两种办法实施难度颇高，我们看看有什么更简单适用的办法。

　　我们为什么要进行软件规模度量呢?目的无非是：

　　1.作为报价或者决策的依据。

　　2.安排具体的项目进度。

　　3.可以作为组织的生产力数据，可以有很多用途，如：各项目间横向比较，供以后项目参考等。

　　如果是为了投标报价，建议用Delphi法，功能点法、代码行法太慢了，不能适应商战社会，投标经常是没有这么多时间让你去折腾的。Delphi法的大致方法如下：

　　1.找几名资深专家，一起对项目进行WBS，把项目的工作分解为十几条最多二三十条的工作项。

　　2.全部专家各自估计每条工作项的工作量，并向其他专家阐述自己的理由。

　　3.第一次各专家估出来的结果可能差异比较大，每位专家听取别人的意见后，重新估算。

　　4.按照上述办法，各专家反复估算几次，一般次数就是2-4次，各专家估计的工作量会越来越趋近，这个时候取全部专家的平均值。

　　如果是为了目标2，安排具体的项目进度，我建议用“傻瓜估算法”，而我们亲爱的微软，就是采用这样的方法来估算规模的。这样的办法虽然原始，但有效，并且容易掌握。虽然这种办法被扣上主观成分大、项目间难以横向对比的、难以积累历史数据等多种“罪状”，但不好意思，用功能点法或者代码行法就很准吗?我们亲爱的软件工程师们认可功能点法或者代码行法吗?搞功能点法代码行法等这些“虚”办法，还不如老老实实地WBS，直接估算每个工作的工作量。

　　第一步：把公司内部最有项目经验最有估算经验的工程们召集在一起，制订组织级别的估算表框架。

　　软件开发活动，可以分类以下几类：

　　直接生产软件的活动，如：需求开发、设计、编码、测试等工程类活动。

　　项目管理类活动，如：编写项目计划、计划跟踪、发布评审等活动。

　　项目支持类活动，如：配置管理、QA检查等。

　　维护类活动，项目验收后的数据整理、修改缺陷、系统维护等活动。

　　根据公司的实际情况，列出各类项目活动，可以根据不同的项目类别而列出不同的活动，尽量把这些活动种类细化，如考虑设计时，还需要考虑设计评审的时间，考虑编写计划时，需要考虑主计划、子计划的编写等等。

　　把这些框架定好，并设计出估算表模板，供项目组使用。

　　据我的经验，很多估算没有做好的缘故，常常是忘记或者是没有估算好管理类、支持类、维护类的活动。当一个公司的估算精英聚集在一起的时候，大家要列出公司估算中常常遇到的问题，全部考虑到估算表模板中，并写上足够清晰的指导。当项目组用这些模板的时候，相当于用了估算精英们的脑袋来思考本项目的估算了。

　　第二步：项目组选用合适的估算表模板，进行由底而上的估算。

　　项目组根据自己项目的特点，选用合适的估算表模板，然后项目组成员一起在这个模板的基础上，继续细化，进行详细的WBS，列出要完成这个项目所需要的全部工作，并且把这些工作落实到具体的项目组成员身上，由负责该任务的人来估算自己完成这个任务需要多少时间，而不是由项目经理分配一个完成时间。这就是由底而上的估算办法，这是微软MSF中的估算办法，这个办法有以下好处：

　　1.最终该任务是由这个人来完成的，他估计多少时间才能做完，这个时间才是最接近实际的。

　　2.负责该任务的人进行估算的时候，肯定需要认真思考这个任务的风险，需要做哪些具体的工作，这样更容易在未开始工作之前就发现更多的潜在问题。相反如果由项目经理来分配时间，这个人就可能不会去思考这个任务了。

　　3.做这个任务的人会有被重视和尊重的感觉，他会很重视自己承诺的完成时间，并且想法设法按时间完成。这样会减少很多项目管理时间，因为每个任务负责人都会主动地跟踪好自己的工作。

　　第三步：持续完善模板，持续改进。

　　每个项目使用模板进行估算后，都可以对模板提出改进建议，把本项目的成功经验融入到模板中，让后面的项目收益。

　　“傻瓜估算法”非常直接有效，能很准确地估算出项目的工作量。学院派的人士会认为应该先估算出规模，然后再由规模估算出工作量，但我想说的是，估算规模的目的还不是为了估算工作量，如果有办法直接准确地估算工作量，干嘛还要去估算规模，干嘛还要去想功能点法好还是代码行法好?当时我们主任评估师也认可这样的做法，他也认为某些情况下工作量可以直接代表项目规模。CMMI也没有规定非要用什么功能点法代码行法来度量软件规模。

　　软件的工作量估算是很重要的一项工作，是整个项目成功的基础，用“土方法”也可以把工作量估好估准!

　　如果要满足目标3，即作为组织的生产力数据，应该如何度量呢?

　　满足目标3之前，我们应该保证我们能满足目标1和目标2，如果目标1和目标2都没满足的情况下，我们就去追求目标3，是有点“超前”，这种“超前”对公司来说可能是“拔苗助长”。当然我们希望有一种方法能同时满足这三个目标的，但到目前为止，我还没有见到过这样的成功案例。软件规模度量还是要一步一步来，不要一开始就期望吃成个“胖子”了。

　　如果在“傻瓜估算法”的基础上多做一步，我们是可以满足目标三的。在第二步进行WBS进行由底而上的估算时，这些WBS其实是可以分解成功能点或者是代码行数。我们可以利用这些WBS得到两个输出，一个是工作量，一个是功能点或者是代码行数。如果积累了一定的数据，就可以建立功能点或者代码行数与工作量的对应关系，这样不仅可以用来衡量公司的生产力，也可以利用这些经验数据来估算以后的项目。

　　项目跟踪的利器——进度度量、成本度量

　　软件开发人员加班是家常便饭的事情，最近才刚听说了一个朋友近一个月连续加班，日夜颠倒，没有周末，过着“暗无天日”的生活。我曾经问过另一个朋友他所在公司如何控制项目的进度成本的，他们公司非常“黑”，每隔一段时间公布一次加班龙虎榜，看谁加班最少，搞到他们不好意思不加班。通过不断的加班来保证进度了，通过加班不给加班费来控制成本，软件开发变成了“人间煎熬”。

　　如何才能有效地度量项目的进度与成本呢?如何少加班最好不加班，就能按期并在预算内完成项目呢?

　　我们先要回答这个问题：为什么要度量项目的进度与成本?

　　我们的目的是：掌握项目的状况，采取必要的措施使项目的进度和成本在控制范围内。要实现这个目的，我们必须先定义项目的度量比较基准，也就是需要先做好估算以及进度计划，每次的对进度和成本的度量结果，都必须与之前的估算与计划进行比较，判断项目是否在控制范围内。

　　项目规模的度量上文已经阐述，这里介绍一下如何制定进度计划，这个进度计划就是我们度量进度状况的一把尺子。

　　有个朋友曾负责过一个项目，领导要求他把这个项目周期的全部活动详细计划下来。他傻了眼了，他最多只能细化近两周的工作，越到后面，越不能细化，只能定一些关键的结点。他觉得这个要求不合理，他非常冤枉地被领导认为是无信心完成整个项目。

　　需求未细化，设计未确定，软件开发是充满挑战和具备不确定因素的智力活动，要求一下子就制定全过程的详细计划是不合理的。那是不是就不需要制定计划呢?计划赶不上变化，这是很多开发人员的口头禅，但我们必须清楚认识到，计划是控制变化的最佳办法!

　　制定进度计划合适的办法是：

　　1.近期的工作一定要细化，远期的工作需定出关键节点的完成时间，如版本发布时间、验收时间等。

　　2.进度计划必须持续细化，尽可能搞清楚不明的因素，尽快细化即将到来的工作。

　　3.进度计划的关键节点完成时间，必须保证公司的商业要求，如要满足合同的进度要求。

　　4.对于已经细化部分的进度计划要设定一些小间隔的里程碑，如保证每两周就有一个里程碑，这些里程碑就是我们的度量点。

　　其实进度度量的关键是把度量用的“尺子”做好，每次用实际情况来对照。如果按照以上原则把“尺子”做好了，进度度量办法就非常简单，就是检查这些里程碑点的完成情况了。

　　另外有不少公司采用进度报告的方式，进度报告不要只报告当前情况，进度报告必须与计划情况对照，这样的度量才有价值。很多公司没有把进度计划做好，也就是没有把度量用的“尺子”做好，没有参照物，就难以判断是否在控制范围内，是否需要采取纠正措施了。

　　如何进行成本度量呢?

　　成本分为人工成本及非人工成本，非人工成本可能包括采购、差旅等费用，这里我们先说人工成本的度量。

　　首先我们要把人工成本的“尺子”做好 。如果用项目挣值管理办法，我们是很容易度量项目的成本与进度的，但要做好项目挣值管理并不容易。这里介绍一些简单易行的“土办法”。很简单，就是先列出你的计划加班时间，不需要加班完成，还是需要加一点班完成?度量办法就是看实际加班情况与计划加班情况进行比较。

　　至于差旅成本，度量办法很简单，每个公司都需要报销的，这些数字很容易得到。问题是我们如何控制好差旅的成本?降低出差人员的住房标准?减少补贴?当然不是这样了，控制差旅成本的关键是要保证每次出差的工作质量，让每次出差都达到一定的目的，减少出差的次数。差旅成本上涨，通常是因为验收工作一拖再拖。把实施工作的计划做好并跟踪好，和客户保持良好的沟通，必要时让公司的高层与客户的高层接触来推动验收，这些才是控制差旅成本的重要办法。

　　被吹得最多的六西格玛管理

　　六西格玛被网络炒作得太厉害了，我一直没有能找到一篇能通俗说明六西格玛基本原理的文章。我们公司通过了CMMI5级了，但我还不时会遇到推销六西格玛培训的事情，这些推销者可能不知道要过CMMI4级，不精通六西格玛是不行的。

　　什么是六西格玛?

　　我第一次听说的时候，我以为六西格玛会包含六个方面，现在看来真是贻笑大方了。西格玛是统计学里面的一个概念，六西格玛，就表示六个西格玛。我们暂时不去研究这些深奥的统计学的东西，简单地说六西格玛管理就是一个稳定地输出高质量的产品(或者是服务)的管理办法，在这个过程中利用统计学的原理对数据进行分析，找出改进点，并通过再次度量数据，来验证改进的效果。

　　什么是稳定的过程?什么是不稳定的过程?

　　大家都试过野炊吧?小时候一般同学去郊外野炊，大家煮出来的饭是不是有的糊有的焦，没有几个煮得出好饭的?这个野炊煮饭的过程，我们可以认为是一个不稳定的过程，因为输出的结果都是难以预测，差异很大的。不知道大家做项目的情况是不是跟野炊的情况类似?有些项目做得好，有些项目做得差?

　　为什么用野炊的方式煮饭，结果会这样呢?如果仔细分析，我们会发现影响煮饭结果的因素很多都不受控制，如米的质量、放水的多少、火候的控制等等。这样结果自然就难以控制了。同样道理，我们做项目影响项目结果的因素也很多，如果这些因素不控制好，项目的结果也是很难估计了。

　　如果我们用电饭煲来煮饭呢?用电饭煲煮饭的时候，我们只需要保证米的质量，并且放好水，剩下的事情就是按一下开关就可以了，而且现在的饭煲都有放水的刻度，想放错水还比较难呢!我想没有谁曾经用电饭煲来煮饭出现过失手的情况吧?

　　为什么用电饭煲煮饭，能保证持续稳定地煮出高质量的饭呢?因为电饭煲已经把很多不可控制的因素，用电饭煲控制好了，我们只需要控制的东西很少，而且也很容易控制。同样道理，我们看看我们做项目的情况，如果项目没有过程，很多东西是很难控制的，如果项目不用一定的技术来改进，很多东西也是很难控制的。一个成熟度高的公司，他们的项目一定是通过一些过程及相关的技术进行控制的，这样即使是不同的人来做项目，最终出来的结果都是可接受的，偏差不大的。

　　所谓六西格玛管理来改进项目，核心思想是要找出影响项目的关键因素，想办法加以改进，当然做项目的过程比煮饭要复杂很多，要做好这个改进工作一点都不容易。

　　如果一个公司没有什么软件过程，是不能马上进行六西格玛管理的。就好像如果要过CMMI4级，如果没有做好CMMI2、3级是根本不可能的。如果你们的公司刚好是这样的情况，千万不要上六西格玛管理，你们可能会把一般六西格玛的理论家的数字游xi所蒙蔽，这个时候做的很多度量工作很可能是徒劳的，只会增加大家的负担并没有什么效果。如果想改进生产力的话，参考CMMI2、3级的要求，选择部分合适的PA来持续改进，这才是正路。

　　如果公司达到了CMMI3级水平，是不是就可以考虑进行六西格玛管理呢?

　　不尽然!六西格玛管理有一大弊病，就是要基于数字来说话，而且要有一定的经验数据为基础。软件开发行业，经常面对新的挑战，很难想象一个软件公司会几年如一日都在用类似的办法生产类似的软件。也就是说，我们辛辛苦苦分析了几个月的数据，找出了一些问题的根源，很有可能因为公司的业务变化，而让这些分析结果价值不大，也更加不要指望利用之前的历史数据分析出来的指标来管理今后的项目。

　　六西格玛管理从开始是从制造业开始应用的，而软件企业的特点是智力的竞争，知识更新非常快!如果公司不是长期稳定做某类业务的，是不适合上全套的六西格玛管理，当然六西格玛的核心思想是可以利用的。

　　这里只是对六西格玛进行了简单的介绍，我将另外写一文详细介绍六西格玛管理的基本原理。

　　量体裁衣、身体力行

　　软件度量可以是很复杂的事情，也可以是很简单的事情，大家不必被一些复杂的度量办法、高价的度量工具、还有深奥的六西格玛给吓怕了。度量工作本身并不会有任何好处，产生好处的是对度量结果的分析及相应的改进工作。

　　做度量之前，要先思考当前公司存在一些什么大问题，有什么简单的度量办法，能让你更加清楚地了解问题，并更容易分析出原因。如果你要进行一系列的改进工作，你也需要思考，有什么简单的度量办法，能让你很容易地跟踪改进的情况，并能很容易地分析出原因及采取纠正措施。

　　目标驱动度量，而不是为了度量而度量，简单就是最好的!