如果你去谷歌和搜索 “测量软件开发人员的生产力” 你会发现一大堆的什么. 认真地 — 没有.
尼克·霍奇斯, 衡量开发人员的生产力
现在我们应该都知道 我们不知道如何衡量程序员的生产力.
没有 明确的测量方法 哪些程序员做得更好或更快, 或比较团队之间的生产力. 我们“知道”团队中的明星是谁, 我们可以依靠谁来交付, 谁在挣扎. 我们知道一个团队是在踢屁股还是在拖累他们的屁股. 但我们如何证明? 我们如何量化它?
各种愚蠢和邪恶的事情都可能发生，当你 尝试衡量程序员的生产力.
但无论如何让我们这样做.
我们正在编写更多代码, 所以我们必须更有效率
开发人员编写代码是有偿的. 那么为什么不衡量他们写了多少代码—— 多少行代码 得到交付?
因为我们有 自 1980 年代以来为人所知 这是衡量生产力的糟糕方法.
无法跨语言比较代码行 (当然), 甚至在使用相同语言、在不同框架中工作或遵循不同风格的程序员之间. 这就是为什么 功能点 被发明——试图标准化和比较不同环境中的工作规模. 听起来不错, 但功能点 没做到 进入主流, 可能永远不会——很少有人 知道功能点是如何工作的, 如何计算它们以及如何使用它们.
更根本的问题是，以生产线衡量生产率 (或功能点或其他衍生品) 输入没有任何意义. 软件开发中的许多重要工作, 最重要的工作, 涉及 思考和学习——而不是打字.
最好的程序员会花很多时间来理解和解决难题, 或帮助其他人理解和解决难题, 而不是打字. 他们找到了简化代码和消除重复的方法. 他们写的很多代码无论如何都不算数, 当他们通过实验迭代并构建原型并将所有这些都扔掉以获得最佳解决方案时.
如果我们考虑理想的结果，这些措施的缺陷是显而易见的: 尽可能少的代码行来解决问题, 和创建简化, 降低 IT 系统复杂性的通用流程和客户交互. 我们最有生产力的人是那些找到巧妙的方法来完全避免编写任何代码的人.
杰斯谦虚, 精益企业
这显然是大小无关紧要的情况之一.
我们正在制作 (或保存) 更多钱,
所以我们必须工作得更好
我们可以尝试使用每个团队交付的盈利能力或财务回报来衡量高水平的生产力, 或其他一些商业衡量标准，例如有多少客户在使用该系统——如果开发人员为企业赚了更多钱 (或者存更多的钱), 他们一定是在做正确的事.
在行政层面使用财务措施似乎是个好主意, 尤其是现在“每家公司都是软件公司”. 这些是开发人员应该分享的组织措施. 但它们不是有效或公平的开发人员生产力衡量标准. 有太多的业务因素超出了开发团队的控制范围. 有些产品或服务即使在交付它们的人做得很糟糕的情况下也会成功, 或即使团队做得很好也会失败. 特别关注成本节约导致许多经理裁员并尝试“事半功倍”，而不是投资于真正的生产力提高.
正如马丁·福勒 指出 有时间差, 尤其是在大型组织中——有时可能需要数月或数年才能看到 IT 项目的真实财务结果, 或来自生产力的提高.
我们需要到别处寻找有意义的生产力指标.
我们走得更快, 所以我们必须提高生产力
衡量发展速度—— 速度 在敏捷中——看起来像是另一种在团队层面衡量生产力的方法. 毕竟, 软件开发的重点是交付工作软件. 团队交付的速度越快, 更好.
但 速度 (多少工作, 以故事点或特征点或理想天数衡量, 团队在一段时间内交付) 真的是衡量 可预见性, 不是生产力. 速度旨在被团队用来衡量他们可以承担多少工作, 校准他们的估计并计划他们的工作.
一旦团队的速度稳定下来, 你可以 测量速度变化 在团队中作为生产力的相对衡量标准. 如果团队的速度正在减速, 它可能是团队、项目或系统中问题的指示器. 或者您可以使用速度来衡量流程改进的影响, 看看培训或新工具或新实践是否真的使团队的工作显着加快.
但你将不得不 考虑团队的变化, 当人们加入或离开时. 你必须记住，速度是一种只有在团队内部才有意义的衡量标准——那 你无法比较团队之间的速度.
虽然这并不能阻止人们尝试. 一些商店使用一个众所周知的参考故事的想法，程序中的所有团队都理解并使用它来估计他们的故事点. 只要团队在如何提出估算方面没有太多自由, 并且只要团队在相同的约束和假设下工作在同一个项目或项目群中, 您也许可以粗略比较团队之间的速度. 但 迈克科恩警告说
如果团队感觉到有丝毫迹象表明将在团队之间比较速度，则会出现渐进但一致的“点膨胀”。
ThoughtWorks 解释说 速度 <> 生产率 在他们最新的技术雷达中:
我们继续看到团队和组织将速度等同于生产力. 正确使用时, velocity 允许将“昨天的天气”合并到团队的内部迭代计划过程中. 这里的关键是速度是团队的内部衡量标准, 这只是给定团队在给定时间的容量估计. 将内部速度等同于外部生产力的组织和管理者开始设定速度目标, 忘记了真正重要的是生产中的工作软件. 将速度视为生产力会导致效率低下的团队行为，以牺牲实际工作的软件为代价来优化此指标.
保持忙碌
我认识的一位经理说，与其试图衡量生产力
“我们只是保持忙碌. 如果我们像疯子一样忙于工作, 我们可以找出问题和瓶颈并解决它们并继续前进”.
在这种情况下，您将衡量 - 并优化 - 周期, 就像在精益生产中.
周期时间——周转时间或变更提前期, 从企业提出要求到他们将其拿到手并看到它发挥作用——这是企业关心的事情, 和一些东西 每个人都可以看到和衡量. 一旦你开始仔细观察, 当您测量等待/空闲时间时，浪费和延误会出现, 增值对比. 非增值工作, 和 过程循环效率 (总增值时间 / 总循环时间).
“定义生产力并不重要, 或测量它. 识别非生产性活动并将其降至零更为重要。”
埃里克·西蒙斯, 英特尔
团队可以使用 看板 监控和限制正在进行的工作并识别延误和瓶颈. 和 价值流图 了解步骤, 尾巴, 需要优化的延迟和信息流. 有效, 您必须查看从首次发出请求到交付和运行请求的端到端流程, 并优化所有路径, 不仅仅是开发中的工作. 这可能意味着改变业务的优先顺序, 如何做出决定以及谁做出决定.
几乎在我们见过的每一个案例中, 提高一个流程块的效率对整体价值流的影响最小. 由于返工和等待时间是影响总交付时间的最大因素, 在单一功能中采用“敏捷”流程 (比如开发) 通常对整体价值流影响不大, 从而影响客户结果.
杰兹谦虚, 精益企业
将交付速度与生产力等同起来的不利方面? 优化周期时间/交付速度本身可能会导致长期问题, 因为这会激励人们短期思考, 偷工减料并承担技术债务.
我们正在编写更好的软件, 所以我们必须更有效率
“矛盾的是，当管理者关注生产力时, 很少进行长期改进. 另一方面, 当管理者关注质量时, 生产力不断提高。”
约翰·塞登, 引述于 精益企业
我们知道 以后修复错误会花费更多. 无论是 10x 或 100+x, 这并不重要. 然后 错误较少的项目交付速度更快 – 至少达到安全关键和生命关键系统的收益递减点.
而且我们知道，软件中的错误和错误给企业带来的成本可能是巨大的. 不仅仅是开发返工成本和维护和支持成本. 但对企业的直接成本. 停机时间. 安全漏洞. 丢失IP. 流失客户. 罚款. 诉讼. 生意失败.
它的 易于测量 你写的是好软件还是坏软件. 缺陷密度. 缺陷逃逸率 (特别是逃逸到生产中的缺陷——包括安全漏洞). 代码库上的静态分析指标, 使用像这样的工具 声纳管.
我们知道如何编写好的软件 – 或者我们现在应该知道. 但是软件质量是否足以定义生产力?
DevOps——衡量和改进 IT 性能
构建/维护和运营/支持系统的 Devops 团队将生产力从开发扩展到运营. 他们从我们已经研究过的两个维度衡量生产力: 交货速度, 和质量.
但 devops 并不仅限于构建和交付代码，而是着眼于端到端 IT 服务交付的性能指标:
- 交付吞吐量: 部署频率和提前期, 最大化工作流向生产
- 服务质量: 改变故障率和 平均修复时间
这不仅仅是更快或更好地交付软件的问题. 开发人员和运维人员一起工作以更好更快地提供服务, 在移动太快或一次尝试做太多之间取得平衡, 过度官僚和过度谨慎导致浪费和延误. 开发和运营需要分担结果的责任和问责制, 以及衡量和提高生产力和质量.
正如我指出的 较早的帖子 这使得 运营指标 比开发者指标更重要. 根据 最近的研究, 成功实现这些目标会提高业务成功率: 不仅仅是生产力, 但市场份额和盈利能力.
衡量结果, 不输出
在 精益企业 (你可以告诉我我刚读完), Jez Jumble 谈到了通过结果衡量生产力的重要性——衡量对组织重要的事情——而不是产出.
“如果我们没有实现我们计划以项目级目标条件的形式实现的业务成果，那么我们完成了多少故事都没有关系”.
停止尝试测量 个人开发人员生产力. 这是浪费时间.
- 每个人都知道谁是顶级表演者. 将他们指向正确的方向, 让他们开心.
- 每个人都知道那些在挣扎的人. 为他们提供成功所需的帮助.
- 每个人都知道谁不适合. 把他们搬出去.
衡量和提高团队的生产力或 (更好的) 组织层面会给你更有意义的回报.
谈到生产力:
- 措施 重要的事情 – 对团队或组织产生影响的事情. 明确的措施, 重要的, 这并不容易玩.
- 善用指标, 不为恶——推动学习和改进, 不要比较团队之间的产出或对人进行排名.
我明白为什么衡量生产力如此诱人. 如果我们能做到，我们就能比现在更容易、更客观地评估软件. 但错误的措施只会让事情变得更糟.
马丁福勒, 无法衡量生产力
关于作者
Jim Bird 是一位经验丰富的软件开发经理, 项目经理，目前是一家金融服务公司的首席技术官. 他专注于软件开发和维护中的难题, 软件质量和安全. 最后 15 多年来，他一直管理着构建和运营高性能金融系统的团队. 他特别感兴趣的是小团队如何最有效地构建真正的软件: 高质量, 在可靠性的极限下保护系统, 性能, 和适应性. 必须工作的软件, 那是正确的, 经久耐用. 本文原发于他自己的博客 构建真正的软件.
博文代表作者个人观点
而并不一定与官方NESMA政策一致.