（给
伯乐在线
加星标，看经典文章
）
英文：Jim Bird 编译：码农网-小峰
www.codeceo.com/article/measure-programmer-productivity.html
如果你用谷歌搜索“mearsuring software developer productivity”，那么你会发现出来的全都是一些废话，一点用处都没有的废话。——Nick Hodges，《Measuring Developer Productivity》
所以现在你知道了吧，原来我们并没有办法来衡量程序员的工作效率。
老实说，我们现在还没有明确的方法可以衡量程序员以及整个团队的生产力。我们可以确定谁可以依赖，谁比较努力，但却无法证明这些猜想，也没有量化的方法。
我们的代码写得多，所以我们的生产力更高
既然开发人员的工作就是写代码。那么，何不通过衡量代码的多少来衡量其生产力呢——看看他们写了多少行代码？
但是，不同编程语言之间的代码行数是没办法比较的，即使使用的是相同的编程语言，在不同的框架下的程序员之间的生产效率，光看代码写了多少也是无从裁定的。
更根本的问题是，通过衡量所写的代码行数来断定生产力其实没有意义的。很多软件开发中的最重要部分还包含思考和学习——不仅仅是写代码。
最优秀的程序员会将大量的时间用于了解和解决疑难杂症，或帮助他人解决难题，而不是写代码。他们会想方设法简化代码，避免重复。他们会通过实验、建立原型等方式迭代代码，替换原先旧的代码，以获得最佳的解决方案。
所以，光从代码数量上看，还真看不出程序员的生产力水平来。
我们钱赚得多，所以我们的生产力更高
我们也可以通过财务上面的盈利能力来衡量每个团队的产出，或者其他的业务措施，如有多少用户正在使用系统——如果开发人员能为企业赚更多的钱（或节省更多的钱），那么是不是他们的生产力更高呢？
利用财政措施似乎在执行层面上是一个不错的主意，但是却有太多的商业因素是不受开发团队控制的。有些开发团队很垃圾，但他们的产品就是成功了；而有些团队兢兢业业却还是只收获了失败的果实。注重节约成本的理念很有可能会导致许多管理者裁人，企图“少花钱多办事”，而不是投资于真正的生产力提高。
看来此路不通，我们需要寻找其他更有有意义的生产力指标。
我们的开发速度快，所以我们的生产力更高
衡量开发速度——敏捷速度——看起来更像是另一种从团队层面来衡量生产力的方式。毕竟，软件开发的重点是提供可工作的软件。如果你的团队能更快地拿出产品，自然是更好。
但是，速度（一个团队在一段时间内能完成的工作）与其说是衡量生产力的，还不如更精确点说，是用来衡量预见性的：用来衡量一个团队能承受多少的工作。
但是，我们又不得不考虑人员加入或离开等对速度的影响因素。而且，有一点你得清楚，速度只能只能用于衡量已知团队——由于很多因素的不同，速度并不能用于不同团队之间的比较。
保持忙碌的状态就对了
一个我认识的经理曾这样说道，与其试图衡量生产力，还不如
“保持忙碌的状态就对了。只要我们不断地挖掘问题，就一定可以找到瓶颈，解决掉这些难题。”
在这种情况下，我们会衡量——并优化——循环时间。
团队可以使用看板去监控——并限制——正在进行的工作，并确定瓶颈，使用价值流图可以了解需要优化的步骤、排序、延误和信息流。总之一切为了尽快地交货和发布。
但是我们还是不能将交货速度等同于生产力。这是因为只优化交付本身的循环时间/速度很有可能会导致更大的长期性问题，要知道这种方式实质上是在鼓励人们只顾眼前，从而偷工减料，背负技术债务。
我们的软件更好，所以我们的生产力更高
