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

发布时间:2017-1-17 19:03:44 编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"敏捷开发绩效管理之十一:如何提高人员可用率?",主要涉及到敏捷开发绩效管理之十一:如何提高人员可用率?方面的内容,对于敏捷开发绩效管理之十一:如何提高人员可用率?感兴趣的同学可以参考一下。

这是敏捷开发绩效管理的第十一篇。(栏目总目录)也是敏捷开发一千零一问的第三十四篇。(栏目总目录)人员可用率字面上,人员可用率指每个人的所有工作时间中,多少比例被用于真正的工作。广义的人员可用率,还应该包括“战斗人员”的比例,如果各种行政、管理团队数量庞大,那么总可用率也会因此 降低。本文重点谈前者。深层的人员可用率,还应该指扣除返工、浪费后的实际可用率。关于人员可用率的数据很少,大致有两个很有参考意义。一个是一般建议新建的敏捷开发团队,人员可用率设置大约是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年之前很久就出版了,但是之前却从来没去买过看过。在微型公司遇不到高手情有可原,但是总不能埋怨这些书当年没从天上掉下来吧。

上一篇:面试问题集锦二
下一篇:java Android SDK安装与…

相关文章

相关评论