译者 | 李睿
审校 | 重楼
在持续交付的软件世界中，产品的频繁发布已经成为现状，大多数开发商都在争相将他们的产品进行更新。在云计算和其他先进技术的支持下，持续集成（CI）/持续交付（CD）管道正在蓬勃发展(安全和质量问题也是如此)。但是，随着开发速度成为焦点，快速已经成为工程团队成功的主要衡量标准，这损害了人员、流程和产品的价值。
当工程团队的开发速度是唯一的指标，将会错过什么?在这个狭窄的视野之外会发生什么?这些短视的指标可能会遗漏什么?
在黑暗中进行软件开发
随着Scrum的兴起，故事点的速度已经成为敏捷软件开发生命周期（SDLC）的主要驱动力。
例如，开发团队在这周完成了多少个故事点?怎样才能让他们在满足验收标准的情况下交付更多的故事点?
速度被视为工程团队成功的代名词，快速被誉为任何成功的工程团队的首要关注点。交付更多的故事点，显著是正在“做这件事”。
这种冲动并非没有道理。从企业高管的角度来看，一款完美的产品如果错过了上市的时机，就没有多大价值。当然，它可能充满了开发人员的智慧，但如果它没有产生商业价值，很快就会被抛弃，而不是“行业游戏规则改变者”。因此，致力在行业领先是值得的。事实上，一项研究发现，仅将产品上市时间缩短5%，投资回报率就可以提高将近13%。
然而，对速度过于痴迷可能忽略了优化任何一个软件解决方案的实际影响的几个关键因素。
当人们如此狭隘地关注速度时，考虑一下需要问的一些问题：
- 是否形成良好的产品规格，并与团队交付产品的方式保持一致?
- 是否针对目标业务问题构建了正确的解决方案?
- 代码是否能够高质量地编写，以避免日后的重写?
- 更好的是，代码是否可以在一开始就进行测试驱动，从而使重构变得微不足道，并记录需求？
- 在下一次迭代中会产生多少技术摩擦？
- 系统是否安全、稳定、可扩展?是否容易扩展?
显然，人们都在追求速度和质量，但目前工程团队对速度指标的迷恋只会助长各方的坏习惯。
在通常情况下，工程团队并没有让开发周期的每个阶段都对相同的基于指标的交付评估负责。产品团队通常不会根据其速度进行评估，产品管道的不同部分也不会对工程的延误相互负责。
产品的指标遗漏了什么?
公平地说，很难衡量产品开发的速度。有一种理解是，产品开发是一个流程，甚至是一门艺术，需要实验和迭代，软件工程也是如此。
将产品团队的衡量标准降低到向工程团队输出票证的速度显然是荒谬的。
然而，在他们的迭代过程中，产品团队在某个时候开始创建票证——没有任何真正的指标衡量这些票证是否形成良好，是否可以由工程团队正确地使用。也没有任何评估这些任务是否可以在可用的时间内实际完成。而且不要求这些任务包括备份计划，以适应意外的黑天鹅、困难和延迟。
工程师处理这些票证并创建和部署代码。衡量生产力的标准是他们交付这些部署的速度。
在这个周期中，工程团队可能会从产品团队那里继承一些忽视潜在冲突或忽视重要需求的票证。但到那时，软件开发工程师们正在根据推出日期或预计时间表完成工作，并根据他们的速度进行评估。由于速度是关键绩效指标（KPI），花费在票证故障排除上的时间最终会影响团队的整体表现。
例如，假设软件开发工程师收到一张票证，其要求都源于产品方面的误解，只有他们才可能看到，但花费20分钟来梳理这个事实。这是一段非常宝贵的时间，工程师本可以将这些时间用于编写功能的测试或开发其他可以推动进行的应用程序。有时，直到已经花费大量的时间编写代码之后，才意识到票证是错误的。
现在，也许20分钟或几个小时对时间线来说并不是一场灾难。但是，当在多次迭代中重复出现问题时，突然之间，工程师很难弥补失去的时间，从而产生越来越多的“产品债务”。
截止日期导致错误的决定
不完美的票证与基于速度的KPI相结合，会助长工程方面的不良习惯。当截止日期是唯一重要的标志时，工程师别无选择，只能在继续开发之前整理这些票证，将会影响开发进程。
软件开发工程师的编码将变得草率，出现大量缺陷，并面临技术债务威胁。最后，匆忙开发的产品只会让未来添加新功能变得更加困难，从而为下一轮循环激活恶性循环。
但是，截止日期将会准时到来。
在这样的环境中，软件开发工程师总是感到时间紧迫，无法将工作做到最好，而且要完成一个没有完全在他们控制范围内的指标，这也是导致他们工作倦怠和快速离职的原因。为了开发团队和软件行业的发展，不能继续失去最优秀的人才，无论是现在还是将来。
根据美国劳工统计局的数据，从2021年到2031年，企业对软件开发人员的需求将增长25%。因此，现在不是测试最有价值开发人员是否决定离职的时候，也不是试图让他们竭尽全力的时候，尤其是当最终产品也因此受到影响的时候。
鸡和猪的寓言
在任何敏捷软件开发生命周期（SDLC）中，解决问题都是流程中关键的嵌入部分。众所周知，开发出的产品永远不会是完美的（需要后续进行测试）。但是，如果没有任何与票证质量相关的KPI，产品团队几乎没有动力重新思考他们的流程，因此这将继续产生不必要的浪费，这可能会让工程团队争分夺秒进行开发。
鸡和猪的寓言最好地说明了角色的差异。在制作早餐的过程中，鸡贡献的只是鸡蛋，而猪却贡献一条猪腿，他们的贡献截然不同。产品团队贡献需求：好的、坏的，或者通常介于两者之间。缺陷是不可避免的，必须进行迭代。但是，当时间线偏离计划时，往往是工程团队最终陷入困境，即使最终的结果是一个更有价值的解决方案。
为什么速度经常被认为是软件开发的一个重要指标，而它却经常阻碍协作和质量保证?产品团队和工程团队不是机械地生产、接收和执行订单，而是需要跨越通道，团结合作，以制定真正有效的解决方案，包括当流程不按照票证计划进行时的充足应急措施。
保持完美，并继续前进
那么，是否建议对有问题的票证进行更严厉的惩罚？不能这么做。产品团队在制定更有价值的解决方案时应该得到宽容和具有灵活性。
软件开发是一个流程，甚至是一门艺术，由人类执行，并为人类服务。如果开发人员像机器一样工作会阻碍创造性思维和迭代，可能无法创造出最好的解决方案。产品开发的进展通常不会遵循线性、可预测的路径。如果一种方法行不通，必须尝试不同的想法。有时候会找到一个更好的方法来创造更多的价值，即使花费更多的时间。
也许更重要的是，产品团队和工程团队需要在开发过程中紧密合作，以支持积极的结果和持续的改进。从长远来看，更多的前期沟通可以节省大量时间，因为这两个团队都有机会完成从功能需求到编码现实的过渡。
不要忘记“无可指责”的检验的核心原则。如果没有共同的责任，企业将无法对任何给定的Sprint中出现的问题有着细致的理解。在一个无可指责的文化中，无论是谁的错，产品团队和工程团队都将共同努力，了解事情为什么会出错，以便掌握所发生事情的复杂性，并了解如何在未来纠正它。如果工程团队需要找到更有效地工作的方法，那很好，但是产品团队可能也需要迭代以持续改进他们的票证。
产品团队和工程团队团结合作
对于开发团队来说，像速度这样的指标并不是衡量成功的唯一标准。事实上，他们从根本上错误地描述了应该如何构建产品：在产品和软件开发功能之间进行平衡和协作。速度并不是最重要的指标。衡量成功的真正标准是业务价值(由产品所有者与工程团队合作定义)和工程团队对该价值交付的结合。
众所周知，如果没有敢于质疑假设和测试可能性极限的产品团队，以及勇于接受这种挑战的工程团队，那将一事无成。因此需要让这两个团队都处于最佳状态，承担风险，测试他们的能力极限。只有在一起团结合作，产品团队和工程团队才能开发出高质量的、突破性的软件，从而应对风险，超越期望，并加速超越竞争对手。
原文标题：Measuring engineering velocity misses all the value，作者：Jeremy Duvall
