为什么软件工程中的可预测性胜过速度

在科技领域，速度通常是衡量开发团队生产力的首选标准。速度是敏捷软件开发中使用的一种评估，用于衡量团队在给定时间段内可以完成的工作量，通常由每次迭代中完成的故事点或用户故事来表示。换句话说，这取决于团队编写代码和推出功能的速度。但是，虽然速度很酷，但如果平衡不当，可能会导致糟糕的结果和一堆幕后混乱。

尽管还有许多其他测量方法相互配合，构成了一个跟踪进度的出色系统，但速度仍然是最受欢迎的测量方法之一，因此也是最常被误用的测量方法之一。

速度的诱惑……及其危险

速度常常成为焦点。团队为自己能够如此迅速地推出新功能或适应最新的市场变化而感到自豪。这种对速度的追求体现了与竞争对手保持同步、保持用户参与度以及不断创新的愿望。思考过程很简单：行动越快，取得的成就就越多，为利益相关者提供的价值也就越多。

现在我们来分解一下。全速前进有时可能意味着错过一些更重要的东西——在工作中减少甚至没有倦怠的能力，从而保持一致性。想象一下以超快的速度建造一座超高层建筑，但基础不稳定。随着时间的推移，这可能会造成大量的技术混乱——这就是那些快速修复解决方案的隐性成本，这些成本稍后会受到影响。当然，闪电般的快速交付有其吸引力，但值得考虑的是它之后可能带来的麻烦。

可预测性：强大的工具

可预测性作为一种衡量标准，是指团队或系统在给定时间段内交付结果的一致性和可靠性。团队不应该专注于速度，而应该将注意力转向增强可预测性。

有几个原因：

• 与利益相关者设定明确的期望。

  一个团队取得不同的成果——一个月获得 100 分，然后接下来的两个月仅获得 10 分——对于利益相关者来说可能会像坐过山车一样。不稳定的产出让利益相关者陷入两难境地，不确定接下来会发生什么。相反，一支连续一个月拿下 40 分的球队将成为 MVP——他们成为比赛中可靠的球员。这正是商业领域真正渴望的——可预测性。

• 错误越少，游戏时间就越长。

  虽然不可预测性可能偶尔会带来辉煌的爆发，但从长远来看，真正获胜的是可预测性的稳定性。有一点是：可预测性的路线图并不通用。当然，每个团队都有自己的旅程。然而，表现最好的人有一个模式。

  
  

  成熟的敏捷实践是高绩效可预测团队的共同点。无论他们是沉浸在 Scrum、看板还是混合方法中，这些团队都已经确定了与其核心相符的节奏，为结构化工作和创作自由提供了空间。另一方面，有一种持久的增强动力，使每一个冲刺或迭代都超越前一个。

  
  

  让我们考虑一个具体的例子。 Atlassian 的 Jira 最初是一个简单的错误和问题跟踪器，但现已发展成为世界上最受欢迎的项目管理工具之一，为广泛的行业提供服务。当然，公司的崛起有很多不同的因素，但可预测性无疑是最重要的因素之一。凭借一致迭代的历史（推出一致且定期的更新）、反馈循环、可扩展的生态系统和透明的路线图，Jira 已在全球许多组织中确立了自己的地位。

平衡：速度与可预测性

尽管我在本文中的首要目的是展示为什么可预测性胜过速度，但我的职责是提到最佳实践始终是两者之间的良好平衡。毫无疑问，在选择最公平的衡量标准时，可预测性是最有前途的游戏。但是，如果您有能力构建多方面的评估系统，那么找到校准两个（甚至更多）测量的方法是最好的方法。

找到黄金中间立场需要采取混合方法。这并不意味着仅仅分割差异，而是将这两个元素集成到开发生命周期中。例如，迭代开发可以在特定冲刺期间提供速度爆发，然后是可预测性和细化优先的时期。认识到速度和一致性的价值，团队将能够针对特定项目和阶段定制方法，利用各自的优势来生产既及时又可靠的产品。

总而言之，记住软件领域不应该是一种无尽的负担，这一点很难但确实很重要。当本来就很复杂的工程任务因有问题且有时很肤浅的指标而变得更加复杂时，工作的真正本质就会变得模糊，往往会加剧不必要的紧张。如果您是技术团队的掌舵者，那么反思如何衡量成功并指导您的团队至关重要。最好的办法是询问并不断检查您想要评估的其他开发人员。