陈勇的博客 - Scrum 敏捷开发培训咨询，绩效管理，团队管理，《火星人敏捷开发手册》

这是敏捷开发绩效管理的第十一篇。（栏目总目录）也是敏捷开发一千零一问的第三十四篇。（栏目总目录）人员可用率字面上，人员可用率指每个人的所有工作时间中，多少比例被用于真正的工作。广义的人员可用率，还应该包括“战斗人员”的比例，如果各种行政、管理团队数量庞大，那么总可用率也会因此 降低。本文重点谈前者。深层的人员可用率，还应该指扣除返工、浪费后的实际可用率。关于人员可用率的数据很少，大致有两个很有参考

这是敏捷开发绩效管理的第九篇。（栏目总目录）若正在为长期没有得到职务提升而感到困惑，下面的内容可能会有所帮助。因为越向上的职位越不像一个打工者，而是像一个企业的经营者。何为经营对一个开发团队而言，大致需要“经营”以下四种主要内容：产品，团队，技术，过程。当然仔细分析，可能还有更多相对次要的内容。对于一般开发人员而言，不太好理解“经营”的含义，然而经营意识的缺乏，正好是研发管理中最大的问题之一。曾经

这是敏捷开发绩效管理的第十篇。（栏目总目录）经营技术经营技术是说，不要只是把做产品/项目的过程当作完成任务或提升自己能力的过程，而是要当作为企业积累技术的过程。这听起来很容易，但做起来有难度，比如这几个问题：1. 团队是否有一个可复用的技术库？（DLL，类，函数，各种层面的）2. 团队是否有一个机制令得这些库被充分利用？（一个可度量指标就是代码行/功能点，越低越充分）……一般而言若不进行有效管理，

这是敏捷开发绩效管理的第八篇。（栏目总目录）每次敏捷开发培训课上，最备受关注的问题可以说是团队管理和绩效管理。“敏捷开发注重团队合作”“敏捷开发不考核个人”“敏捷开发放权”“敏捷开发对人的主动性要求高”……这些新话题可以说对一般程序员而言是非常陌生的，因为一般的程序员，基本上是距离客户最远的人。前面有市场、销售、售前，后面有测试、技术支持，因此最有理由远离“尘世纷扰”，只需遵循指令照章办事。一旦程

这是敏捷开发绩效管理的第七篇。（之一，之二，之三，之四，之五，之六，之七） 续前文…… 功能点估算第一级简化上次说到只用数据+操作就能准确计算规模，听起来够简单了，但其实还不够。谁能在刚拿出2页纸的需求文档时（假设昨天老板在酒桌上刚从客户那记下来的），就猜出有多少个操作？而且还不遗漏？增删改查好猜，“加入角色”就不好猜了。NESMA早就遇到过这个问题了，他们这么解决：通过统计发现每个数据差不多有7

这是敏捷开发绩效管理的第六篇。（之一，之二，之三，之四，之五，之六，之七） 直接估天数或用故事点估天数，都很“程序员”。如果在项目的甚早期，面临与客户相关的报价问题，或高层领导要统计公司绩效并想进行项目乃至行业间的比较，这两种方法都很难使用。敏捷开发内部之所以没有进化出来能做项目间比较、行业间比较、用于早期报价的估算方法，是因为敏捷的发明者和后来的实践者多数都不管这些事情。而这三样事情，比天数、故

这是敏捷开发绩效管理的第五篇。（之一，之二，之三，之四，之五，之六，之七） 度量敏捷开发的生产率一直是个难题，确切说度量任何开发方法的生产率都是一个难题，但它实际上有答案，这个答案是本文的主要内容。 度量敏捷生产率的目的真正难以回答的是度量生产率的目的是什么？很多人都认为是考核绩效，发奖金。根据上一篇文章的内容我们可以知道，这完全是行不通的：客户并不购买我们的生产率，生产率高也并不能证明产品或项目

这是敏捷开发绩效管理的第四篇。（之一，之二，之三，之四，之五，之六，之七） 最近在看德鲁克的书，发现其中很明确地写着“企业的绩效只存在于外部，而企业内部只有成本”的概念和说法，下面结合敏捷开发团队的绩效考核展开谈谈。敏捷开发有很多“外向型”思维，比如：关注客户价值，认为可交付的产品才是真正能表征工作进展的因素等等，但尚未直接与目标管理接轨。外向性思维可以防止部门间壁垒或踢皮球，而转而共同讨论对外交

这是敏捷开发绩效管理的第三篇。（之一，之二，之三，之四，之五，之六，之七） 如果有10个程序员，笔者相信至少有9个是勤奋的。但是如果有一个10人的程序员团队，其中1个人不是勤奋的，而且仍然拿到与其他人完全相同的报酬——大家猜这个团队会以90%的生产率运行，还是更低的生产率？不管大家信不信，我是相信后者的。这个是敏捷开发中对个体管理的出发点，并非我们看到有人在白拿老板的钱而要劫贫济富，而是要打造一个

这是敏捷开发绩效管理的第二篇。（之一，之二，之三，之四，之五，之六，之七）团队管理是个由来已久的话题，各式各样的管理理论和方法层出不穷。笔者因为工作原因在过去16年里与100多家企业的团队或团队领导者有较为深入的交流，看到了听到了想到了很多相关的内容，下面做一个总结。不过受个人经历所限，这不是一个客观的全面的总结，而是带有本人的角度和主张，仅供参考。 中医治病的原理中医和西医看待疾病的角度差别很大

这是敏捷开发绩效管理的第一篇。（之一，之二，之三，之四，之五，之六，之七）“敏捷开发绩效管理”本身是个伪命题，因为敏捷开发本身不想涉及绩效管理，这就像“C++绩效管理”的搭配差不多。但是人们选择敏捷开发作为管理方法是有原因的：更高的交付保障，更高的生产率，更高的质量……这和人们选择C++（而不是C）的原因还是很接近的：都是为了更高的绩效。在下面的所有文章中，“敏捷开发绩效管理”都将不再是“敏捷开发