这是敏捷开发绩效管理的第十一篇。 也是敏捷开发一千零一问的第三十四篇。（[栏目总目录](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年之前很久就出版了，但是之前却从来没去买过看过。在微型公司遇不到高手情有可原，但是总不能埋怨这些书当年没从天上掉下来吧。

这是敏捷开发绩效管理的第十篇。 ### 经营技术 经营技术是说，**不要只是把做产品/项目的过程当作完成任务或提升自己能力的过程，而是要当作为企业积累技术的过程。** 这听起来很容易，但做起来有难度，比如这几个问题： 1. 团队是否有一个可复用的技术库？（DLL，类，函数，各种层面的） 2. 团队是否有一个机制令得这些库被充分利用？（一个可度量指标就是代码行/功能点，越低越充分） …… 一般而言若不进行有效管理，20人团队的代码冗余率可能在95%左右，也就是95%左右的代码是多余的。在2004年的一次技术改造中，一个19万行，13人×9年的产品，被改造为1.3万行，1人×1.5年的相同产品（更关键的是缺陷少了，这次改造的直接动因就是原来产品的缺陷众多而且隐藏很深）。 这并不是个例：这家公司是纳斯达克上市的上千人的电信软件公司，其开发和管理强于一般的中小公司，后者的技术水平可能更差。但由于普遍而言人们使用别人代码的比例很低（我们常常感觉到用过别人的东西，但若自己数数，又会发现不过就几百行代码而已），所以人数越多可压缩的比例越高；再加上由于多数人连自己的复用做的也不好，所以在未完善管理的情况下，对代码进行大规模压缩的潜力一般都接近在2×人数倍以上。 注意这个例子中，较少的代码不但有更高的生产率，质量也随之提高，甚至更加明显。 类似这种规模和周期的软件及团队，都应该刻意地在开始就不要只以完成当前任务为唯一目标，而开始架构和积累整个技术架构。 “若刚开始的时候老板不给充分的时间怎么办？”一则我从来没有见过老板指着我们的可复用库说：“不要编写这个，直接给我垒代码”；二则及时被给予足够的时间，多数团队也没有形成这样的可复用库；三则可复用库的生效速度是很快的，若前三个月投入复用的时间还没有赚回来，那么多半做错了……考虑到这些，多数时候缺少对技术的经营，其实是我们软件人员自己的问题。 ### 经营过程 过程就是人们做事的方法，说大一些，就是“企业文化”。 文化是很容易被谈论又很容易被忽视的东西。很多底层的程序员能看到远在天边的企业文化，但却看不清楚自己面前的编码文化。 在2001年的一个团队里边（就是我第一次感受松结对编程与139团队的那个团队），刚开始只有5个人，人们不需要专业的测试人员而仰赖高手帮助新手查看代码和自己自主测试来保障质量；一年以后，当团队扩张到25个人的时候，这个传统仍然存在——此时我们的专业测试人员只有2个，而且只负责整体测试。 这是因为在团队成立的开始，团队尝试建立起一种以高质量为荣的团队文化，所有制造大量的缺陷程序员（包括刚开始时的我本人），都会同时受到鄙视和帮助，人们可以选择接受两者，或者只接受前者。结果是接受帮助的人逐渐摆脱了被鄙视的局面，他们继承了这种传统，进而帮助后来的新人。 可以被经营的过程有很多，有很多完全无需领导授权即可进行，另一些需要在进行一定程度后说服领导进行下一步的支持。这些过程包括： 1. 代码审查 2. 开放的办公室空间 3. 白板和经常的讨论会 4. 基于白板的简单设计（比如预想陈述） 5. 看板 6. 松结对编程 7. 1-3-9团队 …… ## 谁来经营 “如果老板能让我放手管理，我也可以经营好我们的团队。可是……”这是常常听到的一句话。 实际上，老板一般都是“放手”管理的。多数团队的领导者（尤其项目经理）与自己团队相处的时间，超过再上一级的100倍。若这些时间——其实应该说是精力——被充分用来经营团队，而不是简单地执行传声筒和工头的角色，本文所说的经营完全可以实现。 **本人正在参加CSDN博客之星评选，如果您经常来本博客阅读或曾经下载《火星人敏捷开发手册》，欢迎投票（需要登录）：** [http://vote.blog.csdn.net/item/blogstar/cheny_com](http://vote.blog.csdn.net/item/blogstar/cheny_com) **每人可以为10个博主投票，所以如果看到其他常去拜访的博主，也请投上一票！**

这是敏捷开发绩效管理的第九篇。 **若正在为长期没有得到职务提升而感到困惑，下面的内容可能会有所帮助。因为越向上的职位越不像一个打工者，而是像一个企业的经营者。** ## 何为经营 **对一个开发团队而言，大致需要“经营”以下四种主要内容：产品，团队，技术，过程**。当然仔细分析，可能还有更多相对次要的内容。 对于一般开发人员而言，不太好理解“经营”的含义，然而经营意识的缺乏，正好是研发管理中最大的问题之一。 曾经有一个与员工一起培训的部门经理，在第一天培训（讲用户故事，需求管理，用户建模，版本规划等）最后拍案而起说：“研发团队不关心市场经营，这个就是我们现在最缺少的！”。 具体缺少什么呢？我们来看看一个开发团队的两种职责描述，就能发现问题。 这是一种很正常的描述： 1. 产品：收集、描述和分析产品需求。 2. 团队：计划并分配人员完成任务。 3. 技术：保证产品的技术先进性与质量。 4. 过程：建立和维护项目管理制度。 …… 这些都是中规中矩的管理概念，甚至可以说，如果能按上述条目完成管理，已经属于比较好的了。但在阿米巴式经营，或者说百度提到的“狼性”文化中，这些还不够。 因此整体上可以看出，做这四件事情的人，显然是“被雇来”按照“既定制度”管理产品、团队、技术和过程的。 当然这里边有一个先有鸡还是先有蛋的过程：“如果我们本来就被雇来奉命行事的，又怎么可能不奉命行事呢？”这正是阿米巴经营要解决的问题。 **其实很多时候领导都希望放权，但当看到所有人对“做什么”都不关心，而只是盯着“怎么做”，领导就退缩了。** ## 经营什么 ### 经营产品 **经营产品就是要真正把产品当作自己要做的东西，而不是别人雇自己来做的东西。** 要经营的内容，大致包括： 1. 基于产品的商业计划（时间上的，偏重营收分析） 2. 客户群定义（空间上的） 3. 产品版本规划（基于时间及客户群的综合分析） …… 实际开发中比较容易忽略的是1和2，典型的情况包括： 1. 开发人员只盯着发版计划，却不关心发版的产品的销售情况和客户反馈 2. 开发人员不断开发功能，却不知道产品可能卖给谁，甚至连用户是谁都有点模糊（在我培训课程中有一个沙盘演练环节，此情况屡屡出现！） …… 如果陷入了这两种情况，就要思考是否忘记了主动经营产品。 还有一些比较复杂的以后或许有机会会讲到（确切说，现在还没有足够的能力写出来），比如：产品线规划，即不同产品的搭配，以在原客户群中产生附加值或占领更大的市场。 ### 经营团队 精英团队就是要把自己的部门、小组当作自己的小公司一样经营。包括： 1. 思考合理的人数和知识体系 2. 思考下属员工的职业生涯规划 3. 理解和优化团队的投入产出比 …… “**投入产出比**”是一个很重要的属性，就是要理解自己团队在公司中的位置，并利用营收数据来指导团队的发展。 举个例子：曾经有一次我们的团队营业额达到了上一年的3倍多一点，而大家的收入也平均增长了30%左右（这个是估计的），但大家仍然觉得心里不平衡：因为3倍和30%还是有很大差别的。但随后的营收分析揭示了一点：其实即使我们在营业额暴增之后，每年仍然净亏损150万元左右。有了这个数据，团队就冷静多了，也有了新的目标。这不是说要用这种方法“防止给下属加薪”，而是说**无源之水是不长久的，要令团队知道、思考和改善自己所处的经营状态。** 对开发团队而言，可能没有直接可以考量的营收指标，但是另外一些指标一般也是一笔糊涂账： 团队的生产率？质量？成长性？…… 别说具体的数值，可能连合理的定义方法团队都较少去思考。这些都是缺少经营感的表现。 当然要做到精英团队很难！但这正是需要做的原因之一，因为一旦做成，别人很难复制。 （待续……） ### **本人正在参加CSDN博客之星评选，如果您经常来本博客阅读或曾经下载《火星人敏捷开发手册》，欢迎投票（需要登录）：** [http://vote.blog.csdn.net/item/blogstar/cheny_com](http://vote.blog.csdn.net/item/blogstar/cheny_com) **每人可以为10个博主投票，所以如果看到其他常去拜访的博主，也请投上一票！**

这是敏捷开发绩效管理的第八篇。 每次敏捷开发培训课上，最备受关注的问题可以说是团队管理和绩效管理。 “敏捷开发注重团队合作”“敏捷开发不考核个人”“敏捷开发放权”“敏捷开发对人的主动性要求高”……这些新话题可以说对一般程序员而言是非常陌生的，因为一般的程序员，基本上是距离客户最远的人。前面有市场、销售、售前，后面有测试、技术支持，因此最有理由远离“尘世纷扰”，只需遵循指令照章办事。一旦程序员们被“放权”“主动”考虑“客户价值”并与队友们“团队合作”而且“不被考核”，反而不知所措。 阿米巴经营就是解决这个问题的。 本文会通过对阿米巴经营与软件开发管理及敏捷开发之间的关系，配合本人在一家公司管理市场/销售/实施团队时做的绩效管理改革（当年的营业额同比增长200%），分析软件行业实施阿米巴经营的一些潜在措施。 ## 序言：何为阿米巴经营 阿米巴经营简单说就是把企业分解成众多独立工作的小组，而每个组员都具备经营意识和行为。 对常年做开发的程序员而言，阿米巴经营整体还是不太好理解的。下面结合软件开发业的特点，及敏捷开发中相关的术语，做一些介绍。 阿米巴经营有5个大目标，他们是： ### 1. 全员参与经营 这是一种典型的唤醒沉睡员工的思路。 什么是沉睡员工？百度最近的狼性与小资的消息可以说做了一个完美解释： 李彦宏将狼性文化定义为敏锐的嗅觉、不屈不挠奋不顾身的进攻精神，群体奋斗。他同时表示将淘汰小资，他将小资定义为有良好背景，流利英语，稳定的收入，信奉工作只是人生的一部分，不思进取，追求个人生活的舒适才是全部的人。“要让所有员工更明确如果想找一个稳定工作不求有功但求无过的混日子，请现在就离开，否则我们这一艘大船就要被拖垮。” 软件公司整体上有两大类人与“经营”距离甚远，一种是行政人员（HR、财务、文秘……），另外一种是技术人员（开发，测试，美术，技术支持……）；而经营感最强的则是业务人员（市场，销售，售前，产品经理……），当然还有公司老板。如果管理不当，很容易造成经营感若的人员变成“小资”。 ### 2. 以核算进行目标管理 有些岗位是非常难以核算的，比如行政人员。 技术人员也不是太容易进行核算，别看管理指标一大堆（进度，质量，成本……），但是要具体拿出一个来做绩效考核，还真的很难。那么应该怎么做呢？答案是：**用外部目标对内部人员进行核算**。 比如如果用内部目标度量开发人员，开发人员会告诉你说：“我们的生产率就是生产代码（或更高级一点，功能点），所以要想提高生产率，就多招聘一些人吧”。而对外部目标而言，生产率是赚钱的速度，也就是**人均产值**，面对这个目标，开发人员要重新思考：“客户买我们产品的目的是什么，哪些功能值钱，哪些不值钱；能不能用更少的代码完成这些功能以提高生产率？”注意如果用内部目标，代码少生产率反而低。 ### 3. 透明管理 一想到透明管理，做软件的第一感觉就是软件度量，其实还不然。 **企业，无论是哪种类型的企业，第一个需要透明化的东西，就是营收数据：到底赚了多少钱，哪些部门哪些产品哪些人赚的；到底花了多少钱，哪些部门哪些产品哪些人花的。** 如果这些都不透明，简单度量一些代码行、缺陷率，无益于企业整体的发展。当然有人会说：“我们就是一个普通的开发人员，能度量清楚自己的代码、缺陷就已经不错了，哪有闲心和能力去管理部门和产品？”如果刚才真的有这种想法，恭喜，你已经成为一个没有狼性的小资了。 敏捷开发中的透明化管理多数都是一线数据的透明化，当然原因不是“目光短浅”，而是敏捷开发本来要解决的就是这类问题。但产品经理及产品总监应该具备透明管理的意识，即要意识到自己所管理的产品是一个一方面有收益，另外一方面有投入的循环过程。原来那种不管人力研发成本、甚至不管产品销售状况而只管产品需求的产品管理方法，将很快过时。 ### 4. 公司的上下整合 有没有遇到过这些情况： 销售部门需要一个重要的功能才能打动一大类新的客户，所需的时间也不是非常多，但去找开发人员的时候，开发人员都很忙；过了N年M月，新版本一次一次发布，都没有那个重要的功能，而新的客户也因此没有被打动；而新版本发布之后，并没有更多的客户被其中新增的功能所打动；问他们为什么不开发那个销售部门急需的功能时，大家说都很忙…… 这是典型的整合问题，简单说是销售和开发两个部门的横向整合问题，但从根源上，是老板-销售 与 老板-开发 这两条上下整合线出了问题。换言之，公司的大老板必须知道自己公司到底最近在做什么，并让所有部门协同来完成这个工作。 敏捷开发中的产品版本规划与此相关；而产品线规划（敏捷开发中没有提到），与此的关系更大。 ### 5. 培养领导人 很多时候，公司的多数人都在避免自己成为一个可以被替代的人，相反，所有人都希望自己变成独当一面的人，因此自己的位置也就安全了。这是典型的小资思维。但另外一些人则在做相反的事情：他们在培养自己的接班人，并希望把自己的工作分出去，以便自己可以在更高的位置接手更重要的事情。这个就是典型的狼性思维。 很多人会问：“你培养好了接班人，不但没有更高的位置也没有接手更重要的事情，反而因为不需要了而被开掉了，怎么办？”这样想的人，多半没有做过这件事情，或者误以为自己做了这件事情（日后会有文章详述）。 敏捷开发中的团队协作，尤其是松结对编程及139团队，其主旨就是希望能培养人的可替代性。尤其对团队领导或高手而言，应该意识到有人能替代自己的工作——开始是技术上的，之后是管理上的——是一件能扩大自己下属团队的最佳方法，也是另下属团队能独立思考自主运营的最佳方法。 阿米巴经营在国内尚处于探讨阶段，IT公司更是如此。 不过如果大家听说过“内部创业”，或对当前游戏团队的运营模式有所了解，不难想象其操作原理。 不过要说到可分享的经验，尚为时过早。之后的文章，将通过这5点进行更深入的探讨，找到一些思路。 **** **本人正在参加CSDN博客之星评选，如果读完并喜欢这篇文章，欢迎投票：**[http://vote.blog.csdn.net/item/blogstar/cheny_com](http://vote.blog.csdn.net/item/blogstar/cheny_com)

这是敏捷开发绩效管理的第七篇。 续前文…… ## 功能点估算 ### 第一级简化 上次说到只用数据+操作就能准确计算规模，听起来够简单了，但其实还不够。 谁能在刚拿出2页纸的需求文档时（假设昨天老板在酒桌上刚从客户那记下来的），就猜出有多少个操作？而且还不遗漏？增删改查好猜，“加入角色”就不好猜了。 NESMA早就遇到过这个问题了，他们这么解决：通过统计发现每个数据差不多有7个操作，所以刚才咱们找出了3个数据，那么： 3个 × （数据7 + 操作4×7个操作） = 3 × 35 = 105，嘿，把角色和权限的操作问题也给解决了，不用猜了。 如果有几个数据要管理也不知道怎么办？那也太粗糙了吧，再去细化一下吧（别细化报表上有几个按钮，按了按钮后的逻辑是什么……那个和规模无关；只确认是不是数据）。 这样准吗？来自课后的10个数据表明，基于这种功能点作出的工作量估算与实际项目数据相比，最大误差在正负50%左右（本人手里没有详细数据所以没分析，应该取P50就是中值的误差比较好，可能在30%左右）。虽然听起来误差大得乍舌，但是在手里只有2张纸的时候，已经很准确了。某政府部门的要求是到400%以内都可以接受，因为他们在一个项目的招标中，4个供应商报价最大差别是12倍。 总结一下这一级别的简化方法就是：**每个内部数据35点**。另外如果是外部接口数据（比如要取LDAP），那么每个**外部接口数据15点**。 第一级简化适合**项目合同期/项目初始计划**的早期估算。 ### 第二级简化 如果项目已经完成了，不用猜了，就可以数到底有几个操作，就不用猜每个数据有7个了。 不过，到软件界面上面数显的很不专业，**如果我们的史诗故事是基于数据写的，用户故事是基于操作写的，数史诗故事+用户故事不就得了**？比如图中这个：  图中就是刚才提到的用户/角色/权限的局部，一共3个数据（小课本是史诗故事），外加19个操作（蓝色的是用户故事，其中两个“新建+查看”分别代表两个，要×2），加起来是 3 × 7 + 19 * 4 = 21 + 76 = 97，已经很接近105个了……如果考虑到这个软件还没有编完，我们第一级简化还是蛮准的嘛（归功于NESMA的长期努力）。 完成这些功能需要 105 × 9 = 945 小时 = 118人天。如果我们有一个迭代，正好要完成这些功能并将其部署上线，那么就按118天计算吧（如果只编写出来不测试，大约是70%的工作量）。当然这不是说任何一个人都花相同的时间，而是基于现在业界收集上来的数据，团队人均花费这么多。个体的生产率差异可达5倍，但团队却都差不了太多。 另外单个故事的精度也很差，比如如果某人正好编过某功能，可能一小会就完成了。但是如果很多人编写很多故事，大数定理会起作用。 总结一下这级别的简化方法就是：**每个内部文件按7点（每个外部接口按5点），每个操作按4点，加起来就是功能点**。 这个级别的简化**适合每个迭代确定工作量；还可以在项目完成后，总体计算开发效率作为绩效管理的依据（算是回到绩效管理了）**。   ## 遗留问题 正如前言，很多敏捷世界的新鲜事，在别的世界早就不是新鲜事了（当然别的世界也有他们的新鲜事），提出和解决下面这些问题的很多前辈都已经去世了。 本文只是指出有这么一种方法，并非这种方法的操作手册，这种方法还是需要培训的（有现成的）。 1. 就这么简单？ 不是，简化的功能点大约需要一整天的培训，后续估算（推导工作量/工期/成本）还需要一整天。里边有很多细节。 复杂的功能点大约需要2～3天培训，另外一般5天左右的指导，如果要CFPS证书还有一个3天左右的考前指导。 2. “每个用户操作 = 一个用户故事？那修Bug怎么办？做小的改动怎么办？提升性能怎么办？” 可以记录成不同类型的故事，但是就别计算功能点了。图中三个绿色箭头，就是三个对原有故事的“增强”，其特点就是无法描述为完整的用户操作。 他们不计数，但是在统计时已经被平摊到计数的故事里边了。 我自己实践的时候发现，有些故事为了开发方便，极有可能包含两个操作（如上面的“角色首页”包含新建和查询两个操作），建议可以当作一个故事，怎么舒服怎么来不要太生硬，但是加个记号知道是2个操作，防止数错。 3. 每个数据都是/才能是史诗故事吗？ 不一定，我有一个史诗故事叫做“性能优化”，它就不是，也不计算它。 4. 每个动词都是操作？ 不一定。简单而言就是只有”主语是用户“的动词才是操作。”。 暂时还没有遇到有些Backlog Item不是用户操作但是很想当成用户故事的情况，如果有，可以在史诗故事/用户故事上设置一个字段，如果是才计数。 5. 非功能性需求怎么办？ 最早提出来也最早被解决的问题，标准功能点的非功能性调整因子是1970左右（天啊……）提出的有点老了多数都不适用了；个人最喜欢的是韩国标准中的调整因子，大致可以理解为普通的乘1，科学计算之类的乘1.3左右，运营计费乘1.5左右，生死攸关的乘2左右。 非功能性调整因子一般包括规模因子、领域因子（韩国标准包括8大类约50小类）、质量因子（韩国标准包括4个质量因子，每个三个等级）、开发语言因子这几个。有时候不会觉得他们考虑不周，反而是多虑了…… 6. 准吗？ 不准。因为这种方法虽然很准，但是那个”9小时/功能点”是业界数据，最好用自己的数据重新回归一下。 本人正在回归自己的，可惜只有一个项目在做，所以不得不每个迭代都当作项目来看待。一般稍微大点的企业有一年时间积累20个（子）项目数据就可以了。 7. 有前途吗？ 有。芬兰，澳大利亚，韩国，日本……的政府采购均采用这种方法计算价格。中国的国标预计在明年出台，即政府采购项目均将使用这种方法报价（或指导报价）。 8. 有的项目好坏可不是光看开发的功能多少，还要看创意和…… 是的，**用这种方法度量绩效的目的，是为了提升开发绩效，加快开发速度，而不是计算工资奖金或评价项目好坏**。在[之四](http://blog.csdn.net/cheny_com/article/details/6713089)里边已经提到，必须在赚来钱的时候才能发奖金，它是由外部目标驱动的。 在产品开发中，往往收入与功能多少的关系不很直接甚至完全没有关系，但在一些直接由功能点报价的政府项目、外包项目里边，这个可以直接作为外部目标考核。   **本人正在参加CSDN博客之星评选，如果读完并喜欢这篇文章，欢迎投票：**[http://vote.blog.csdn.net/item/blogstar/cheny_com](http://vote.blog.csdn.net/item/blogstar/cheny_com) **** 点击下载免费的敏捷开发教材：《[火星人敏捷开发手册](http://blog.csdn.net/cheny_com/article/details/6616794)》  

这是敏捷开发绩效管理的第六篇。 直接估天数或用故事点估天数，都很“程序员”。如果在项目的甚早期，面临与客户相关的报价问题，或高层领导要统计公司绩效并想进行项目乃至行业间的比较，这两种方法都很难使用。 敏捷开发内部之所以没有进化出来能做**项目间比较、行业间比较、用于早期报价**的估算方法，是因为敏捷的发明者和后来的实践者多数都不管这些事情。而这三样事情，比天数、故事点，在老板眼中更接近生产率绩效。 这时候就需要功能点估算。 ## 功能点估算 ### 由来 功能点估算是另外一个世界的事情。每100个懂敏捷的人中，可能才有1个懂CMMI；而懂CMMI的人中，可能才有100个懂功能点，而100个懂功能点的人中，也只有1个人懂敏捷……这就是三个世界，但每个世界都和敏捷世界一样热闹，一样有可操作的方法，只是互相不通信而已——结果是，**每个世界都不知道别人已经早就解决了自己冥思苦想的问题**。 **用功能点度量软件的目的，是在早期获知软件开发的工作量，进而推算开发成本**。 由于这个目的，使得它实际上是与开发工作量的相关性也最强（远远超过Delphi/代码行/故事点/用例点……多个国家的政府使用此估算采购软件，中国大约2年就后采用），而且居然和用户故事还有很好的对应关系。 功能点本身很复杂，大家可以在网上查到一些资料，这里不多说了。标准功能点分析尤其复杂，有一次有一个欧美发包商来到中国，问“我们现在已经有100多页文档，谁看过之后知道这个项目要多少钱才能开发出来，以及为什么，我们就把这个项目给他。”笔者介入了此事，也知道标准功能点能解决这个问题，但是却不能在给定的时间内完成（只有2天的时间解决此问题，而用功能点至少需要10～15天）——国外ISBSG也转发度量Guru Capers Jones的邮件称“只有极少数的项目采用了功能点估算，因为成本太高”。这件事情促使笔者尝试找简单的功能点估计方法，直到后来在另外一个世界发现有人早就解决了大约10年了……那就是NESMA的简化功能点，如果不嫌麻烦请参阅[http://www.nesma.nl/section/fpa/](http://www.nesma.nl/section/fpa/)（点击左边 Advanced 下面的 Early&Fast FPA）。 不过建议直接看下面。下面的概念作了**很大的调整以便于用有限的文字理解**，如果有懂FPA的读者看出破绽不要奇怪（本人是正规做FPA培训和研究的）。 ### 什么是简化的功能点估算 在我们的开发工作中一共有两类东西要开发，一种是数据，一种是操作。 所谓数据，就是比如要编写一个CRM，其中有“用户、角色、权限”这三种东西，就是要管理的数据，这里权且记下用户有“3个数据”要管理。 所谓操作，就是对用户，应该有增、删、改、查、加入角色……这些称之为操作，这里权且记下对用户，用户会做“5个操作”。 倘若角色和权限没有操作（虽然这是不可能的），那么在NESMA简化方法中由于每个数据是7点，而每个操作是4点左右，那么就可以算出来一共有： 3 × 7 + 5 × 4 = 21 + 20 = 41点。 ISBSG/IFPUG包括中国的CSBSG等都有**不同行业/不同类型软件的生产率统计**，如果你在中国，用C#或Java开发一个类似OA/CRM这样的业务流转软件，那么生产率大约是9小时/功能点（来自于10多个学员的课后数据），也就是上面那个小软件，要用9×41 = 369小时大约是46人天。 “什么？这点内容我不到一星期就能做完。”是，也不是。这一时间的包含了需求分析/设计/编码/测试/集成/上线部署期间的所有时间，还包括开会讨论的时间，和别的功能联调的时间，培训的时间，修改万恶的Bug的时间，提升性能的时间，改善易用性的时间，上网找图标的时间，上班看博客的时间——总之一个真实项目中可能发生的时间全都平摊在这里。 听起来够简单了，但其实还不够。 谁能拿出2页纸的需求文档（假设昨天老板在酒桌上刚从客户那记下来的），就猜出有多少个操作？而且还不遗漏？增删改查好猜，“加入角色”就不好猜了。 怎么办？请看下文。 点击下载免费的敏捷开发教材：《[火星人敏捷开发手册](http://blog.csdn.net/cheny_com/article/details/6616794)》   **** **本人正在参加CSDN博客之星评选，如果读完并喜欢这篇文章，欢迎投票：**[http://vote.blog.csdn.net/item/blogstar/cheny_com](http://vote.blog.csdn.net/item/blogstar/cheny_com)

这是敏捷开发绩效管理的第五篇。 度量敏捷开发的生产率一直是个难题，确切说度量任何开发方法的生产率都是一个难题，但它实际上有答案，这个答案是本文的主要内容。   ## 度量敏捷生产率的目的 真正难以回答的是度量生产率的目的是什么？ 很多人都认为是考核绩效，发奖金。根据上一篇文章的内容我们可以知道，这完全是行不通的：客户并不购买我们的生产率，生产率高也并不能证明产品或项目盈利，应该为团队设立外部目标，否则很可能得到一个生产率很高，但是实际上很烂产品——质量上或易用性上很差，抑或其他想象不到但一定遇到的原因。这是我们说为什么用外部目标而非内部目标考核团队的原因。 或许又有人说：“开发得快不快是团队的事情，产品好不好则是产品负责人的事情。”这样也不对，相当于我们在自组织之后，当我们享有勇气，尊重，沟通……这些敏捷的特质之后，我们居然得到了一个只关心自己的开发速度，而置客户价值和企业利益于不顾的团队。“受激励的个体”只被自己小团队的绩效所激励，并不爱也不关心自己的产品，这绝对不是敏捷开发的初衷。 **度量生产率的目的不是绩效考核，而是是希望提升生产率绩效。将度量结果进行横向和纵向比较，可以分析造成生产率差异的原因，并进而提升生产率绩效。** ****  # 微观度量方法-故事点 ### 故事点估算方法 “每月完成的人天数”这个方法不说了，用尺子量尺子，肯定不行的。不过通过统计每月的实际投入天数，可以优化人员利用率，并间接提升生产率。  “每月完成的故事点”这个是比较好的方法。 所谓故事点法，就是提前选择一些大家都熟知的、以往做过的、典型的故事，比如： 1. 对单个表进行增删改查 2. 对父子表的增删改查 3. 为一个已经存在的数据表增加一个复杂报表 4. 修改一个中等难度的BUG …… （实际上这些故事应该是具体的，而不是像上面例子中一样看起来更像是“分类”） 然后人拿出当年的历史记录，将当时所投入的人天数称为“故事点数”（也有别的做法但这个最简单）。比如“对单个表进行增删改查”当年用了4天，那么标准故事点就是4。 当下次估算时，人们又发现有一个故事也是“对单个表的增删改查”，于是就先选定基数为4，再讨论这次与上次比，到底复杂多少。如果一致认为可能复杂20%，那么故事点就是5。 如果大家的生产率不变，那么这个故事应该5天完成，但是如果结果却是4天就完成了，则表明大家的生产率提高了。当然不是一个一个故事度量，而是把整个迭代内的故事点加起来度量。 通过**纵向比较故事点，可以知道大家是否比以前的生产率提高了**。 横向比较故事点比较有难度，因为每个团队乃至项目都会选定自己特有的标准故事，而且极难说明这个团队和那个团队的标准故事的转换关系。 ### 故事点的局限性 在推广故事点这件事情上笔者有所保留，建议尝试但需注意风险，必要时知难而退。在笔者遇到的这么多做敏捷的企业和人里边，还没有见到有人提到他们的故事点应用是成功的。 原因在于找到大家都熟知的、以往做过的、典型的故事很难，而让所有人记住它们当年的详细情况以便日后对比修订就更难。 04年笔者去做咨询的一家企业有他们的故事点模板（他们并不做敏捷开发，但却使用完全类似的方法），一共有17种标准故事，已经记录了25个项目的故事点数据和实际工作量数据，每个项目从4个故事到上百的故事不等，他们希望笔者能帮他们计算一下“17个标准故事分别对应多少人天”。终于遇到了又有标准故事又有历史数据的情况，这比所有一穷二白想使用故事点的企业可乐观多了。 这是一个所谓“线性规划”的问题，涉及“最小二乘法”“超越方程”这些玄乎的名词，但却在Excel表里有这个功能，不过是10分钟的事情并不费力，真正费力的是解释其结果：求解的答案是——某些标准故事是负数，也就是说如果把这几种故事当作负数对待，那么以往发生的25个项目的预测结果与实际结果最符合。 再换一种直白的解释：**用这17种故事预测工作量不准。** 或许有人会说他们的17种故事选得不好，或他们的水平很差。怎么说呢，他们是一家1000多人的电信企业，专职做过程管理的人就有5人，还认真地记录了这么多数据，恐怕当年选定故事的过程也是经过思考的。倘若他们都难以建立其故事点，一般的10人团队想自己做一套恐怕更难。 回过头来观察他们公司的**失败原因，是在为新的故事找到对应的标准故事后，没有根据其差异进行调整**，而是机械地选择了标准故事的故事点，导致误差很大。在采用故事点的时候应该注意。但他们考虑到某些故事的回归结果居然是负数，即使“进行调整”结果也会是血淋淋的，甚至可以说基本扔到了标准故事从头估算，最终放弃了故事点，采用了另外一种方法，就是下篇文章提到的“功能点估算”。 笔者之前的一篇文章有故事点估算方法的更详尽的介绍，但角度不同：[敏捷估算：故事点与直接估算天数的差异](# "敏捷估算：故事点与直接估算天数的差异") 故事点为我们提供了一种比较客观度量敏捷生产率的方法，但其局限性限制了其应用。下一篇文章将介绍另外一种广泛应使用的方法：功能点估算法。    点击下载免费的敏捷开发教材：《[火星人敏捷开发手册](http://blog.csdn.net/cheny_com/article/details/6616794)》   **本人正在参加CSDN博客之星评选，如果读完并喜欢这篇文章，欢迎投票：[http://vote.blog.csdn.net/item/blogstar/cheny_com](http://vote.blog.csdn.net/item/blogstar/cheny_com)**

  这是敏捷开发绩效管理的第四篇。   最近在看德鲁克的书，发现其中很明确地写着“企业的绩效只存在于外部，而企业内部只有成本”的概念和说法，下面结合敏捷开发团队的绩效考核展开谈谈。 敏捷开发有很多“外向型”思维，比如：关注客户价值，认为可交付的产品才是真正能表征工作进展的因素等等，但尚未直接与目标管理接轨。外向性思维可以防止部门间壁垒或踢皮球，而转而共同讨论对外交付价值，从下面的对比可以看出这点。 ## “内向型”绩效及其导向 进度：“各阶段按时完成率”会导致分析和设计人员草草结束工作，而将大量不确定工作推给开发人员；开发人员则如法炮制，把延期踢给测试人员。 质量：“千行代码缺陷率”会导致开发人员在很多“是否是缺陷”问题上与测试人员争执不下，另外一些次要的如使用不便、不直观等问题则被长期搁置。 成本：“与计划相比的人员超支率”会导致项目经理很不愿意接受变更，即使是那些显然能给客户带来巨大价值的。 功能：“需求规格中需求的完成比例”会导致开发组思维局限于当年编写需求规格时期的认识，而不能在整个漫长的开发过程中不断精化需求。 此外还有一些更可怕的数据，比如“每月生产的代码行数”“每月生产的功能点或故事点数”（这个很有迷惑性）“每月修改的缺陷数”等，都是不恰当的绩效。德鲁克“企业内部只有成本”的理念指出，无论是文档，代码，可运行软件乃至最终产品，若尚未被销售，都只是成本的一部分。 多数采用内向型绩效的公司和团队，其绩效结果都不好。究其原因，单个部门/工种/个人各自追求自己的绩效，并不会导致整个项目外部绩效的提升（这称为“合成谬误”）。 某些内向型绩效甚至是互斥的，处于零和状态。比如测试团队人均发现的缺陷数（测试团队的绩效）与开发人员人均缺陷数（是开发团队的负绩效）并存，则**两个团队无论如何都无法同时提升绩效**，导致他们永远无法像一个团队一样互相帮助。若你的公司有这样的绩效，则研发人员与测试人员打架就不用奇怪了。 其他多数内向性绩效，都存在潜在的互斥关系。比如前面提到的个阶段按时完成率即内部存在互斥，而“需求规格中需求的完成比例”必与“客户需求响应率”互斥。 ## 外向型绩效 下面是一些潜在的**“外向型”绩效**，由于之前提过不同企业乃至产品的外向型绩效差别很大，请灵活运用。 **产品研发型** **进度：** “与竞争对手相比同档产品的上市日期比较”适合消费电子类产品。 “响应分销商需求的时间”适合渠道比较强势的情况。 这些外向型绩效应该作用在整个团队上，换言之不管哪个环节导致了进度差，都一起得到底的绩效。从而促使整个团队一起思考如何提升绩效。 需求和设计人员为了能让开发人员提前开工，可以采取分段写需求和设计的方法，把最影响架构又最不会发生变化的部分先写出来，让开发人员提前开工干活；而开发人员也可能会采取同样的策略，阶段式地发布产品，让测试人员可以提前测试，防止最后缺陷太多导致产品延期；而需求和设计人员又回过头来用开发的进度和测试的缺陷率，来判断产品应该消减功能换取上市时间，还是增加更多功能以换取竞争力。 可见**一个为外部目标奋斗的团队，会很容易地团结起来，共同思考提升绩效的最佳策略。**   **质量：** “每月待处理质量问题数”咨询过的一家ERP公司的实际数据（但他们尚未用这个数据考核），此数据一般符合瑞利分布，因此可预测未来的质量问题数量。 “每月终端用户投诉数”适合消费电子、网络游戏等与客户比较紧密的行业。 “每月分销商投诉数”适合渠道比较强势的情况。 “每月论坛缺陷提出数”适合……我在的一家企业使用BBS免费处理缺陷。 用最终用户提出的抱怨作为外部质量目标的策略，不是说大家不用测试了，把缺陷留给用户。而是：**用我们测试了但仍漏给客户让其发现的缺陷，来修订我们对缺陷的认识，修订发现缺陷的方法。** 有很多产品，收到的客户关于易用性的抱怨，远远多于对功能和常规缺陷的抱怨，就应该将“易用性差”作为核心的质量问题，进而作为质量重点。我在下载一款总体评价4星半的Android短信软件时，发现近期的评价很多都是“越来越难用了”“没用的功能越来越多”甚至“更新太频繁了（给了1星）”等等，最近的一些评分平均估计会下降到4星以下。这些抱怨应该当作质量管理的最终考核标准，因为下载者无疑会根据这些评价来决定是否安装软件，而不是看那些“千行缺陷率”“测试人员发现缺陷数”。 **成本：** “产品实际投入产出”适合很长的战线。 试想如果是手机研发，应该在开发阶段就做好测试、维护、重刷系统等接口，另外应该优化性能以选择低端硬件，否则整个产品极难保障盈利。 而且还会发生若软件做得好（但软件的研发成本要上升），则可以节省一些硬件资源或减免某些专用硬件的情况。这时候若要分别考核软件部门和硬件部门，就很难实现了。 **需求：** “每月待处理需求数”咨询过的一家ERP公司的实际数据，如果产品试销售过程中此数据很大而且消退很慢（符合瑞利分布），则表明产品与客户的需求不符。估计也能呈现一些易用性方面的因素。 “客户尖叫度（Customer Screaming Rate）”苹果成功的标志性绩效指标，不谈需求，因为他要超越需求。要学习这个很难，但要理解并体现其精神。 “软件与硬件需求匹配度”适合消费电子，比如若硬件与软件研发平行，则最终交付产品中交付的软件和硬件应该匹配，而不能“18个功能中，硬件完成了12个，软件完成了13个，但其中6个不重合（就是说这些功能交付不了）”，这样软硬件部门才会共同配合。 某手机厂商很擅长上一条，他们一年的200个项目中，只有3个延期，就是很好地利用了功能排序-软硬件对齐的方法，牺牲次要功能保证上市时间。 **项目开发型** 产品做的多，项目做的少，不敢多说，请各位补充吧！ **为团队设立外部绩效目标的目的，是对齐团队的不同角色、工序、人员的目标，从而互相帮助提升共同的绩效。** 外部目标多数可以被客户、用户或市场明确感知，其提升几乎意味着带来收入的增加。如果想在测试人员发现Bug的时候发奖金但却发现账上没有钱，那就改到客户很少抱怨的时候发吧，那时候账上肯定有钱。    注：这是一篇旧文，因符合本系列的内容，在进行了很大改动后重新编辑发布在这里。    **本人正在参加CSDN博客之星评选，如果读完并喜欢这篇文章，欢迎投票：**[http://vote.blog.csdn.net/item/blogstar/cheny_com](http://vote.blog.csdn.net/item/blogstar/cheny_com)   点击下载免费的敏捷开发教材：《[火星人敏捷开发手册](http://blog.csdn.net/cheny_com/article/details/6616794)》  

这是敏捷开发绩效管理的第三篇。   如果有10个程序员，笔者相信至少有9个是勤奋的。但是如果有一个10人的程序员团队，其中1个人不是勤奋的，而且仍然拿到与其他人完全相同的报酬——大家猜这个团队会以90%的生产率运行，还是更低的生产率？不管大家信不信，我是相信后者的。 这个是敏捷开发中对个体管理的出发点，并非我们看到有人在白拿老板的钱而要劫贫济富，而是要**打造一个共进退的团队**。 本文的部分内容在之前的若干博文中提到过，因符合本系列的内容，在此处从另外一个角度加以说明。   ## 领导压力 领导压力指那种直接由领导监督产生的压力，在“每个毛孔都流着血和肮脏的东西”的时代或企业非常普遍。特征表现为：领导深度过问过程而不只是结果，领导现场监督（在计算机时代，则有人发明了一种软件可让领导直接监控员工屏幕）等等。 领导压力的问题在于：领导很难无处不在无时不在；领导很可能是外行；领导就算不是外行，对单个任务而言，了解程度也一般低于任务承担者。 领导压力一般是面向个体的，因为团队不会帮助领导管理个体，相反其整体上处于帮助个体而疏远领导的状态。 如果你所在的企业越来越关注大家的考勤，已经在办公室安装了摄像头，正在调研一款屏幕监控软件……那么，代打卡现象一定很普遍，坐在电脑前什么也不做的人一定很多，定期切换屏幕的习惯正在大家中间养成…… 办公室是一个团队合力解决问题的场所，而不是内部博弈的场所，因此领导压力是一个不明智的选择。 ## 同行压力 同行压力是一种由员工管理员工的方法，因而解决了时间、空间、知识差异的问题。 不过这种管理不是通过授权某人管理另外某人，而是通过为团队指明一个共同利益，从而使其在获取共同利益的时候互相管理。 典型的同行管理行为发生在敏捷开发中的“（每月）计划会议”和“（每日）站立会议”。在计划会议中，团队在确认谁负责哪个任务之前，先共同估算每个任务的预计工时，之后才自由领取或指派负责人；而在站立会议中，任务的负责人则报告进展情况，如果和计划有大的偏差，需要说明遇到的困难，以便大家进行帮助。 其中所使用的**共同估计**和**共同跟踪**是实施成功的关键活动。   ## 同行压力的外在条件 不过有时一些应用敏捷开发很久的开发团队并没有真实感觉到“同行压力”的作用，原因是同行压力的实现需要一些先决条件来支持。 1. **跨职能团队** 如果分工过于细化，技术壁垒太高，很难展开共同估计。有些团队本身是跨职能团队（如10个都是开发人员），但却往往因为过度进行模块分工而导致工作无法胡同。跨职能团队底线是：任何任务至少有两个人可以完成。 使用小组而非个人作为接收任务的最小单元是建立跨职能团队的一种方法。 采用师徒制度，采用[松结对编程方法](http://blog.csdn.net/cheny_com/article/details/6581517)，是明确小组责权的一种好的方法。 2. **先估计后分配** 原因显而易见：若任务已经分配，多数“无关人员”的兴趣和注意力将大大降低。 3. **匿名估计** 即使是一个跨职能团队，如果第一个人首先说出估计结果时，其他人可能因为各种心理问题而导致无法客观地表达自己的意见，尤其当第一个人是最强或最弱一员的时候。 宽带Delphi和[估算扑克](http://blog.csdn.net/cheny_com/article/details/6587277)是两种常见的匿名估算方法，其中后者因为简单快捷在敏捷开发中广为使用。 4. **挑战和优化估计** 为了防止计划会变成一个无聊的监督行为，在匿名估计中数值相差较大的组员要进行“挑战（Challege）”，寻求最优化的估计。之所以称之为挑战，是因为团队不能简单地进行求均值、投票，而是大家分别说出理由（一般估计最低的先说），尝试确认是否有可重用的组件、额外的测试要求等诸多可能影响估计结果的因素，重新投票直至结果接近。优化估计的过程借助团队的知识和智慧澄清了很多个体似是而非的猜测，结果不但为大家所接受，也更客观。 5. **共同跟踪** 共同估计是共同跟踪的前提。只有这样，在跟踪时（比如每日立会上）大家才会关心别人任务的实际情况，在遇到困难时（往往是发生了超出当年计划意料之外的事情），人们会更理解任务为何发生延期，且更容易激发热情去帮助任务负责人。 在一个采用师徒制度和松结对编程的团队，共同跟踪活动不限于每日立会，而是会渗透到[日常开发活动](http://blog.csdn.net/cheny_com/article/details/6590360)中。 6. **团队绩效** 即认为若某个工作没有完成，责任属于整个团队而不是具体负责人。这样既可以防止有任务没人接，也可以防止有些人把着任务不放。 在较大的团队里边由于有从众心理，往往很难让一个人在心理上承认自己应为另外9个人中的一个没有完成任务而负有责任。但当把他们切分成小组时，情况会有所改观。尤其是师徒制度下师傅的团队责任感会很强。 **7. 可完成的任务** 若任务总是无始无终（比如“开发可重用库”）或很难有标准判断是否完成（比如“需求分析”），则很难估算和跟踪，也无法形成同行压力。 **8. 开放空间** 既包括**物理上**的开放空间即人们可以观察到每个人在做什么，也包括**逻辑上**的开放空间即人们可以观察到别人任务的进度。 匿名性被心理学分析为引发违规的重要诱因，比如群体事件中的蒙面者更加胆大妄为。跨职能团队、共同估算、开放空间等均起到**破除个体匿名性**的作用。 在开放空间和个人空间之间有由来已久的纷争，仁者见仁智者见智。不过笔者放弃了所有拥有独立办公室的机会，坚持坐在团队的中间乃至正中央。因为工作并非永远令人兴奋、感觉顺畅，我非常担心自己会放弃自律而有所松懈。那时候产生的所有负面效果的**第一个受害者是我**，而不是公司或其他人。   上述内容在很大程度上已经替代个体考核管理了团队中的个体，帮助他们提升绩效，但如何最终考核他们的绩效（正如前言，工资和奖金毕竟是发放到个人账户上的），日后会有博文再议。     若团队的个体绩效已经与团队的整体绩效对齐，那么他们一起去做什么呢？那就是我们的下一个话题：为团队设定外部目标。   **本人正在参加CSDN博客之星评选，如果读完并喜欢这篇文章，欢迎投票：**[http://vote.blog.csdn.net/item/blogstar/cheny_com](http://vote.blog.csdn.net/item/blogstar/cheny_com) 点击下载免费的敏捷开发教材：《[火星人敏捷开发手册](http://blog.csdn.net/cheny_com/article/details/6616794)》    

这是敏捷开发绩效管理的第二篇。 团队管理是个由来已久的话题，各式各样的管理理论和方法层出不穷。笔者因为工作原因在过去16年里与100多家企业的团队或团队领导者有较为深入的交流，看到了听到了想到了很多相关的内容，下面做一个总结。不过受个人经历所限，这不是一个客观的全面的总结，而是带有本人的角度和主张，仅供参考。   ## 中医治病的原理 中医和西医看待疾病的角度差别很大。 中医受到当年条件所限，并不知道致病的原因是细菌、病毒还是其他什么。由于没有显而易见的敌人，**中医采取的策略是扶正去邪，就是让让人体自身加强，从而自然地消灭”邪气“**。 比如中耳炎，西医的解释是：“多由感冒引发……急性中耳炎是中耳黏膜的急性化脓性炎症，……致病菌乘虚侵入中耳……常见的致病菌主要是肺炎球菌、流感嗜血杆菌等。”因此若能将这些病菌铲除，则可治愈。 而中医则认为：中耳炎是因肝胆湿热（火）邪气盛行引起，就是”情绪激动“导致中耳炎。因此应先”淡定“，然后配合治疗方可。 中医的解释读者看起来可能感觉不可思议，但我很久以前得中耳炎导致内耳积水的时候去西医看了几天没好（当时也没有感冒），给一位中医朋友打电话求助，他一语道破：你最近“激动”了，令我大吃一惊，也立刻相信他肯定能治好。实际治疗过程只有一上午，只使用了两根细针在离耳朵一米远的肢体末端扎了2小时，没有任何其他药物——换言之从表面上看“没有任何东西被任何药物杀死”，但10分钟后鼻腔和耳朵就有明显干燥感，半个月后自愈了。 后来一问，原来他自己也得过此病，去过很多医院（医生各有所长，也有去医院的时候呵呵）花了几千块无法治愈，差点变成“聋子中医”，最后求人不如求自己，自创医术把自己给治好了，还治好了20多个病人。（他最近开始在梁冬开设的[正安药房](http://www.baidu.com/s?wd=%C1%BA%B6%AC+%D5%FD%B0%B2%D2%A9%B7%BF&rsv_bp=0&inputT=4031)上班） 扎一米远的地方为何能治好耳朵？原因是那个地方有个穴位，可以**调整和激发自身的自愈能力，由人体自己把疾病治好**。   ## 对团队管理的启示 团队也无时不处于众多“病菌”的围困之中，其中一个病菌似乎是“个体懒惰”，而对症下的药自然就是“考核个体”。 很可惜，这个病菌不是致命菌，看下面几个问题就知道了： “个体差异主要来自于哪里？”懒惰是一个方面，能力是另外一个方面。能力相同的人中，最懒的和最勤奋的程序员的工作产出相差多少？估计能相差30%就算不错了。那么同是懒惰或勤奋的人，能力最差的和最强的程序员工作产出相差多少？10倍！所以，这里有一个大得多的病菌。 “最近M公司和N公司业绩下滑了50%，原因何在？”因为大家变懒一倍？或者能力下降50%？显然不是，他们的产品管理出了问题。这个病菌大得致命。 那为什么多数软件公司都简单地通过考核个人来提升绩效呢？**因为那样虽然无效，但是却简单**。 其实以往的很多处理策略，都有这个倾向，比如：需求变更频繁，客户说不清楚需求，工期紧，人员流动……对每件事情单个而言，似乎都有几种“青霉素”一针见效：需求变更频繁？就走需求变更流程，统计变更数量，向客户递交变更工作量；客户说不清楚需求嘛？我们写需求让他们签字，需求不签字不开工，签了字就不准变更了；工期紧？加人加班！人员流动？多写文档，不怕流动……等等不一而足。然而到用的时候就会知道：几乎所有这些青霉素都导致过敏！ 敏捷开发的“不考核个体”的思路，其实和中医理论很相近：**尝试打造一个能自组织自更新的团队，来消除各种问题**，而不是就问题论问题地处理。   ## 自组织团队 何为自组织团队？“领导放权了，让我们管自己，自己估算，自己领取任务，所以我们现在是自组织团队。”这个认识太浅。 不是简单地去掉领导和流程后就能剩下一个“自组织团队”，这样得到的多半是一个无组织团队——否则这也太简单了，我们的先人和领导们简直是傻子。 事实是：**自组织团队，是一个依靠团队的自组织能力，自我管理自我更新，消除各种有害因素，来达到提升绩效的团队**。 仔细分析一下，导致团队或公司绩效差的有害因素有很多： **团队级别**的也就是本系列希望讨论的包括（大致由小至大）： 个体懒惰 个体能力差 个体懒惰导致团队懒惰 个体能力差导致整个产品的质量差/进度慢 …… 如果领导放权了，我们自己估算，自己领取任务，但这些有害因素仍然在，那么我们就不是一个自组织团队。我们只是一个生病了不打针不吃药的病人而已。   ****本文提到了敏捷开发对于提升绩效的主要机制：不是依靠一个有强大控制能力的领导，或一个固定的流程，而是**一种能自我适应和改进的机制，进而让团队进入自组织状态，以自己的方法解决问题。** ****下一章节将会提到用于取代“个体考核”来激励个体的敏捷因素：同行压力。     附： 导致团队或公司绩效差的有害因素  **产品级别**的包括（大致由小至大）： 功能定义错误 产品版本定义错误 产品概念/用户群定位错误 产品线组合错误 …… 这些将在敏捷开发产品管理的系列中涉及，敬请关注（尚未开发，作者2011-08-21注）。   **本人正在参加CSDN博客之星评选，如果读完并喜欢这篇文章，欢迎投票：**[http://vote.blog.csdn.net/item/blogstar/cheny_com](http://vote.blog.csdn.net/item/blogstar/cheny_com) 点击下载免费的敏捷开发教材：《[火星人敏捷开发手册](http://blog.csdn.net/cheny_com/article/details/6616794)》    

这是敏捷开发绩效管理的第一篇。 “敏捷开发绩效管理”本身是个伪命题，因为敏捷开发本身不想涉及绩效管理，这就像“C++绩效管理”的搭配差不多。但是人们选择敏捷开发作为管理方法是有原因的：更高的交付保障，更高的生产率，更高的质量……这和人们选择C++（而不是C）的原因还是很接近的：都是**为了更高的绩效**。在下面的所有文章中，“敏捷开发绩效管理”都将不再是“敏捷开发中如何做绩效管理”，而是“**如何利用敏捷开发提高绩效**”。   ## 何为绩效管理 绩效管理常常被片面理解为绩效考核，即如何确定个人的绩效，如何提工资和发奖金的问题。实际上绩效管理还包含**制定绩效目标**，**制定绩效计划**，**制定配套的制度推动绩效**等等，当然也包括最后的**绩效考核**，以最终达到**绩效持续提升的目的**。 上述内容在本系列中都有考虑，并根据笔者以往的经验和经历给出一些实际的案例供研讨使用。   ## 从一个经典问题看绩效管理的出发点 绩效管理不是敏捷开发的要求——如果能理解敏捷开发也不是瀑布模型的要求，敏捷开发爱好者们或许就会释然了——绩效管理是**企业管理的要求**，是企业为了持续提升自己的绩效而采取的措施。 从这个角度我们来看一个由来已久的问题：“**敏捷开发是否考核个人？**”很多人会脱口而出：“敏捷开发不考核个人。”但是如果再问“企业管理要求必须考核个人怎么办？毕竟工资和奖金不是发到团队总账户上的”估计再下去的回答，就只能说是闪烁其辞了。 其实这也是一个伪命题，所以才导致很难回答。下面一点点分析。 企业绩效管理的目的不是为了考核个人，而是为了提升企业绩效，所以尝试考核个人的企业实际上在“**利用考核个人提升企业绩效**”（尽管提升个人绩效会提升企业绩效，但勿入此牛角，因为前面有个尖）。因此这个问题从原始出发点来看，应该是：“**企业是否应该通过考核个人来提升绩效**？”，那么答案就是：“**敏捷开发有比考核个人更能提升绩效的方法**”。不是因为用了敏捷开发就不能考核个人，而是**选择了敏捷开发，就意味着已经选择了比考核个人更有效的提升绩效的方法**，因此没有必要让企业管理和敏捷开发较劲，它们打不起来的。 不过这个或者这些更有效的方法是什么呢？这就是本系列博文的主要内容。 本系列博文将较多涉及**团队级别的绩效管理**，内容包括团队管理的策略，个体管理，团队的外部目标设定，如何分解到个人，不同团队绩效管理的差异，非物质激励等。 另外一个高级话题则是**产品级别的绩效管理**，包括产品发布计划，产品版本计划，产品线管理，产品负责人及产品负责人团队，不同产品类型的搭配等等。但这个话题以另外一个主线组织会更顺畅：**敏捷开发产品管理**，因此会形成另外一个系列，但其核心内容仍是“**如何通过敏捷开发管理产品提高绩效**”，如果您觉得本系列所涉及的范围太窄，敬请关注 [http://blog.csdn.net/column/details/productmanagement.html](http://blog.csdn.net/column/details/productmanagement.html)。   （有读者反映每篇文章太长了，本系列会以较多的短篇文章形式发布，以便于选择关心的内容分别阅读。）   **本人正在参加CSDN博客之星评选，如果读完并喜欢这篇文章，欢迎投票：**[http://vote.blog.csdn.net/item/blogstar/cheny_com](http://vote.blog.csdn.net/item/blogstar/cheny_com) 点击下载免费的敏捷开发教材：《[火星人敏捷开发手册](http://blog.csdn.net/cheny_com/article/details/6616794)》    

> 原文出处：[敏捷开发绩效管理系列](http://blog.csdn.net/column/details/agiledeptchen.html) 作者：[陈勇](http://blog.csdn.net/cheny_com) **本系列文章经作者授权在看云整理发布，未经作者允许，请勿转载！** # 敏捷开发绩效管理系列 > “敏捷开发绩效管理”本身是个伪命题，因为敏捷开发本身不想涉及绩效管理，这就像“C++绩效管理”的搭配差不多。但是人们选择敏捷开发作为管理方法是有原因的：更高的交付保障，更高的生产率，更高的质量……这和人们选择C++（而不是C）的原因还是很接近的：都是为了更高的绩效。