Nick Hodges，《Measuring Developer Productivity》
所以现在你知道了吧，原来我们并没有办法来衡量程序员的工作效率。老实说，我们现在还没有明确的方法可以衡量程序员以及整个团队的生产力。我们可以确定谁可以依赖，谁比较努力，但却无法证明这些猜想，也没有量化的方法。
我们的代码写得多，所以我们的生产力更高既然开发人员的工作就是写代码。那么，何不通过衡量代码的多少来衡量其生产力呢——看看他们写了多少行代码?
但是，不同编程语言之间的代码行数是没办法比较的，即使使用的是相同的编程语言，在不同的框架下的程序员之间的生产效率，光看代码写了多少也是无从裁定的。
更根本的问题是，通过衡量所写的代码行数来断定生产力其实没有意义的。很多软件开发中的最重要部分还包含思考和学习——不仅仅是写代码。
最优秀的程序员会将大量的时间用于了解和解决疑难杂症，或帮助他人解决难题，而不是写代码。他们会想方设法简化代码，避免重复。他们会通过实验、建立原型等方式迭代代码，替换原先旧的代码，以获得最佳的解决方案。
所以，光从代码数量上看，还真看不出程序员的生产力水平来。
我们钱赚得多，所以我们的生产力更高我们也可以通过财务上面的盈利能力来衡量每个团队的产出，或者其他的业务措施，如有多少用户正在使用系统——如果开发人员能为企业赚更多的钱(或节省更多的钱)，那么是不是他们的生产力更高呢?
利用财政措施似乎在执行层面上是一个不错的主意，但是却有太多的商业因素是不受开发团队控制的。有些开发团队很垃圾，但他们的产品就是成功了;而有些团队兢兢业业却还是只收获了失败的果实。注重节约成本的理念很有可能会导致许多管理者裁人，企图“少花钱多办事”，而不是投资于真正的生产力提高。
看来此路不通，我们需要寻找其他更有有意义的生产力指标。
我们的开发速度快，所以我们的生产力更高衡量开发速度——敏捷速度——看起来更像是另一种从团队层面来衡量生产力的方式。毕竟，软件开发的重点是提供可工作的软件。如果你的团队能更快地拿出产品，自然是更好。
但是，速度(一个团队在一段时间内能完成的工作)与其说是衡量生产力的，还不如更精确点说，是用来衡量预见性的：用来衡量一个团队能承受多少的工作。
但是，我们又不得不考虑人员加入或离开等对速度的影响因素。而且，有一点你得清楚，速度只能只能用于衡量已知团队——由于很多因素的不同，速度并不能用于不同团队之间的比较。
保持忙碌的状态就对了一个我认识的经理曾这样说道，与其试图衡量生产力，还不如“保持忙碌的状态就对了。只要我们不断地挖掘问题，就一定可以找到瓶颈，解决掉这些难题。”
在这种情况下，我们会衡量——并优化——循环时间。
团队可以使用看板去监控——并限制——正在进行的工作，并确定瓶颈，使用价值流图可以了解需要优化的步骤、排序、延误和信息流。总之一切为了尽快地交货和发布。
但是我们还是不能将交货速度等同于生产力。这是因为只优化交付本身的循环时间/速度很有可能会导致更大的长期性问题，要知道这种方式实质上是在鼓励人们只顾眼前，从而偷工减料，背负技术债务。
我们的软件更好，所以我们的生产力更高众所周知，软件中出现bug和错误会导致成本显著提高：不仅开发返工成本高了，维护和支持的成本也高了。而最最重要的是，差的软件可能会造成客户的流失，甚至是生意的失败。
要想衡量你正在写的软件是好是坏也很容易：缺陷密度、缺陷逃逸率，以及利用SonarQube之类的工具对代码库进行静态分析。
我们知道如何编写好的软件。但是软件质量是否真的足以定义生产力?
开发人员——衡量和改进IT性能开发团队试着综合上述一些因素来衡量生产力：交付速度和质量。
但开发人员并不限于创建和提供代码——相反还需要着眼于为端到端提供IT服务的性能指标：交付吞吐量和服务质量。
所以这不只是软件更快、更好的问题，而是需要提供更好更快的服务，在速度和功能之间选择平衡，衡量并提高生产效率和质量。
还有一点，最近有研究表明，企业要想成功：不仅生产力要提高，更重要的是要提高市场份额和盈利能力。
衡量成效，而不是产量不要再试图去衡量单个开发人员的生产力了。
这纯粹是在浪费时间。
每个人心中都有一杆秤。 对于表现优秀的——鼓励他们继续朝着正确的方向前进，再接再厉。对于那些努力上进的——给予他们帮助。对于那些不适合的——可以请出去了。
衡量和提高团队或组织级别的生产力将会让你收获更加有意义的回报。
所以当涉及到生产力时：
1.衡量关键因素——能对团队和组织起重要作用的因素。
2.设置的指标应该是起积极作用的——可以推动学习和改进，而不是造成团队或个人之间关于产量的恶性竞争。
