敏捷开发绩效管理之十一：如何提高人员可用率？

这是敏捷开发绩效管理的第十一篇。 也是敏捷开发一千零一问的第三十四篇。（[栏目总目录](http://blog.csdn.net/column/details/agilequestions.html)） ## 人员可用率 字面上，人员可用率指每个人的所有工作时间中，多少比例被用于真正的工作。 广义的人员可用率，还应该包括“战斗人员”的比例，如果各种行政、管理团队数量庞大，那么总可用率也会因此 降低。本文重点谈前者。 深层的人员可用率，还应该指扣除返工、浪费后的实际可用率。 关于人员可用率的数据很少，大致有两个很有参考意义。 一个是一般建议新建的敏捷开发团队，人员可用率设置大约是50%。也就是说，每个月22天，最多安排11天的工作（指完全没有干扰每天8小时都在正常工作的天数）。 第二个是IBM对项目经理的考核中，规定人员可用率应超过70%。这个值应该算是个“及格线”，也就是说，实际的可用率应该在70%以上。 ## 提升可用率的方法 有很多方法都可以提升可用率，不过有些不那么直接，有时候想不到。 越往后的方法越彻底一些，或者可以包括和实现前面的方法。 ### 内部社区 很多时候都是很多已经知道的人陪着少数未知的人（开会、讨论……），社区可以通过知识持久化来避免重复沟通。 内部社区不要被错误理解为有人在特意地“打造”社区，而要理解为把平时分散的、本来就要写的文档社区化，比如用Wiki把缩写Word内容复制粘贴一份以便于查询等等（Word顺便上传为附件），不需要做太多额外的工作。 Wiki还有很多好处，随时可以更改和重新发布，可以多人同时编辑，编辑到一半就可以看到，可以回复和互动等。 ### 减少返工 有些团队的代码总是被“扔掉”，这些代码的原作者，也可以算是不干活的人之一。所以写下代码时，一定要有信心做到日后不会被大规模扔掉。 ### 质量前移 一个典型的浪费时间的活动就是测试及之后的修正活动。这个过程包括：开发测试用例-测试-发现缺陷-记录缺陷-程序员复现缺陷-修改-测试人员重新测试…… 如果编码时开发人员能做一些类似代码审查的工作，代码缺陷会降低很多。这包括自己看自己的代码，实际上自己看自己代码这个环节能降低大约60%的缺陷（我在03年自己的度量数据，书上说能到70%，可能我当时已经算是“高手”了缺陷比较少吧，呵呵）。 ### 开放空间 开放空间可以有效减少会议数量。 之前我曾经在一家公司，他们的销售、市场、支持团队分散在公司的三个不同角落里边；公司有9个独立办公室，大小头目都分散其中。每个月各部门会分别召开一次部门会议以及各种小会，然后再一起开一次经理会。 后来把销售和支持这两个最需要沟通的团队挪到一起办公，取消了办公室，部门经理们坐在开放空间正中间办公，其他人围绕周围。结果是后来所有会议被合并为一个经理扩大会，大约历时1小时，开始说销售（最近的销售机会等），中间说市场，最后说支持（关于为销售机会做方案配置之类的）。各部门的会议则基本上都取消了。 支持部门本来想开一个短暂的每周例会，开了三周也取消了，因为发现很多事情都早就知道了，不知道的上Wiki看就可以了。 后来总经理也从办公室里边跑出来（因为他发现在经理会上我们就像万事通一样有问必答，而他什么都不知道），捡出勤的销售或支持的空位坐着办公，顺便听我们聊什么。 ### 减少团队规模 多找高手，能减少团队规模。 越小的团队约不太会需要开会或写文档等活动；而高手则不但编程快，缺陷还少。这样，可用时间就多一些。 这句话可能是史玉柱或马云说的：**“****资金不会因为高薪而浪费，更多的是因为发给了不干活的人****”**。不干活的人有很多种，有很多是隐形的。比如之前提到的返工中的人。 ### 减少代码量 “扔掉的规模有多大”？我在自己工作过的公司，见到的确切有数据的实际情况是19万行代码被改写为1.3万行。这是个纳斯达克上市公司，在国内拥有很强的实力，这个产品似乎还有相当的市场占有率，但也仍然做到这个地步。估计**多数开发团队，在刻意做过代码管理之前，几乎其代码均可压缩到1/10以下**。 这个数字可能听起来有点耸人听闻，但我分析一下原因大家可能就理解了。假设团队有10个顶尖高手，编码之神，所有代码都是不可压缩的，但是……这10个人各自为战，从来不沟通；有了前面的假设，就必须假设他们的80%代码在可复用库中（每个人自己做自己的可复用库。我们的跨3人的可复用库占67%，看起来如果自己用80%不难做到，只能勉强算是大仙级，神级还差点）。那么就可以看到，80%的代码由于没有被公共复用而重复了——当然在公共的状态下可能会有10～20的损耗，但最后可能仍然有70%的总代码是重复的。也就是说，这10个神级程序员的代码仍然可以压缩到1/3。如果再不是神级程序员，结果就…… ### 松结对编程和139团队（师徒团队） ### 这里说的是实质（松结对编程里边提到的那种）的而非名义的师徒团队。 对师徒而言，交流是潜移默化的不像开会那么花费时间，因此可以降低沟通。 对松结对编程而言，代码复用是一个基本过程（师傅不愿意让徒弟多编码，因为里边缺陷太多；实际上连师徒自己都知道，自己多编码缺陷也很多），因此代码量会减少。 由于代码数量少，而且多数类/函数都“身经百战”，因此未来返工的机会就更少。 有一些容易被问起的问题摘两个提前回答一下，借此说明实际上很多问题如果实际经历一次，就不是问题了。 **1. 新人编程少且皮毛，学不到东西怎么办？** 本人95年毕业，到01年前独立完成过两个大系统（其中一个是国庆阅兵XX指挥系统，后来演化成空军XX指挥系统），编程水平怎样？01年去新公司，被师傅发现不会用虚函数，不会模板（泛型），不会删内存（没错，C盘弄大点，坚持到飞行任务完成就重启吧，的亏是空军不是海军）！ 之后在一个师傅手下做了一年半，具体编写了多少代码不记得了（因为中间做了半年的安全加密），就记得最高峰的三个月编了1800行，推算一年半一共有5000有效行吧。年底师傅统计全年整个部门（开始5人，后来20+）编写了5万行代码而已。就凭借这段时间积累的水平，包括这家公司，我一共为三家公司写过C++编码规范，包括后来那家纳斯达克上市公司。03年遇到猎头，拿到过20000/月的Offer纯编程，因为不带团队且不在北京没去。 总之，前6年和后2年判若两人。 **2. 遇不到好师傅怎么办** 我师傅不止我一个徒弟，我自己也不止有一个徒弟，最后学成与否，几乎仅与徒弟有关。 所以不能轻易问这个问题。 除了跟师傅学习之外，那段时间还看过设计模式、Effective C++这些书。它们可能01年之前很久就出版了，但是之前却从来没去买过看过。在微型公司遇不到高手情有可原，但是总不能埋怨这些书当年没从天上掉下来吧。