速度反模式

速度是与敏捷软件开发相关的最广泛使用的和滥用度量。让我们快速看看一些最受欢迎的虐待。

但首先…

一个对话

很高兴再次见到你。您的软件开发组织的情况如何？

我们正在做敏捷！

那太棒了。恭喜。你用的是什么类型的过程？

你的意思是？我们正在做敏捷！

我的意思是，你是使用scrum，还是极端编程，或者是什么？或者你制作了自己的过程吗？

嗯......嗯......用冲刺是什么？

那是scrum。

哦好的。那就是我们使用的那样。

我懂了。你是如何规划和跟踪你的工作？您使用的是什么类型的指标？

当然，我们正在使用敏捷度量。我们正在做敏捷！

当然。但哪些？

好吧，这只要一个，我猜。你知道。速度。

正确的。您的速度是否足够稳定，您可以将其用于预测？

嗯......好...不知道你在问什么。

好的。好吧，没关系。你的冲刺有多长？

两周......

<点头/>这非常典型。

…通常。

嗯什么？

通常，两周通常，除非我们有问题，否则我们完成了所有的承诺。

唔。那很有意思。如果Sprint长度变化，您如何预测您可以完成的工作量的工作量？

不知道你说的“预测”是什么意思。我们只是估算每个用户故事的时间，并将其转换为故事点。

你从一个时间估计开始并将其隐瞒到故事点？

是的。一世告诉你在做敏捷，不是吗？

你做到了，是的。

这很简单。四个小时等于一个故事点。你知道，这只是基本的敏捷。

当然。我一定忘记了这一点。

估计并不完美。如果需要超过两周，那就是它的方式。所以我们延长冲刺，直到我们完成它。必须逼真，对吗？

是的。必须逼真。嗯，至少你在每个Sprint中都提供了生产就绪解决方案增量。

正确的！这是重要的事情。

是的。因此，每隔几周，您正在将代码移动到生产中，除非需要更长时间。

正确的。出色地…

好吧......什么？

我们每隔几周完成我们的部分解决方案，通常。

你的是什么？

编码。

所以你提供代码，而不是别的，每两周一次......到生产？

不，不是直接投入生产。那太疯狂了!没有人会这么做。这将是不可能的！！

那么代码在哪里？

给基础架构团队。

他们决定何时把它投入生产？

不，你不是在听吗？我们正在做敏捷！它们将其转化为功能测试团队的测试环境。

你是说有三个不同的小组在扯平之前接触了密码吗测试首次？

好吧，是的。当然。你正在听起来像一个坏的事物。

真的。有些东西告诉我，我应该为以后保存“坏”这个词。

这是一个好主意，是的。

那么，您是如何使用速度来预测的呢?也就是说，了解在Sprint的过程中您可以同意完成多少工作?

同意？哈！产品所有者告诉我们必须提供什么。这是他们的工作。你之前没有听说过敏捷吗？我们估计所有用户故事，以便我们可以将故事点符合到下一个Sprint。

适合他们。

是的。

如果不合适怎么办?

我们与产品所有者讨论。

出色地，那听起来很有希望！

是的。我们合作弄清楚如何使我们的估计更小，因此故事点将适合冲刺。

但有时你会发现它们根本不适合你。然后你延长了Sprint。

现在你正在赶上！这是敏捷的！

所以…原谅我问…如果你有变长短跑,你只完成一部分工作之前将它交给另一个团队,你调整你的用户故事的大小,这样的工作量决定将“适合”成一个冲刺,和一个故事点为基于时间的估计只是另一个名字,那么你真的做用你的速度数字？

当然，我们在烧烤图上绘制他们！在Sprint内刻录，并为释放燃烧。你知道，基本敏捷！我们的刻录图表看起来非常好。

毫无疑问。但是什么样的决定人们是否基于该信息？

嗯......好...不知道你在问什么。

速度定义(大概)

转向那种奇妙和美丽的信息商店维基百科，我发现了一个速度的定义，这些速度更像是一个速度的速度，并将这些经历拿走了速度的“定义”。维基百科条目可以改变，所以我们可以希望改进。目前，让我们搬到那个并继续寻找定义。

Scrum联盟在网上有题为题为Catia Oliveira的文章，“速度”。她的定义如下：“速度是一支球队在迭代中完成的故事点数。”她增加了她标题的手绘速度图表，“令人敬畏的手工速度图”。

这对她的部分不是虚假的。这真的很简单。

真的。

我不确定为什么人们会发现这个定义令人困惑。实际上，它可能是故事点，它可能是用户故事的数量，它可能是估计时间的数量完成，它可能是生产门票的数量关闭......这可能是完成工作量的任何合理度量。在任何情况下，它只是一个简单的数量。一二三。然而，速度似乎让很多人混淆了。

也许这种混淆部分源于“completed”这个词。在这种背景下,完全的并不意味着代码已准备好用于基础架构团队移动到测试环境，因此功能测试团队可以使用它。它的意思是完全的到它的指出可以被释放为了制作，如果关键利益相关者制作亚博vip9通道商业决策释放它。没有技术步骤剩下来准备发布的代码。

许多开发团队在只开始应用敏捷方法的组织中运营，或者认为敏捷方法必须调整敏捷方法严重“按比例”。他们的组织结构和关于通过角色专业化或根据萨尔班 - 奥克斯利分离职责的效率的效率的假设排除了他们能够提供的能力任何事物在生产现状状态。

但根据敏捷规则，他们认为他们需要跟踪速度。

所以他们弥补了东西。

事实是，如果一个团队没有每次迭代至少一次提供生产就绪解决方案增量，则它们没有速度。让我清楚：我并不意味着他们的速度数字是不正确的。我的意思是他们没有任何速度数字。他们可能是报告某物在标题下，“速度”，但它不是速度。不能。他们真的没有完全的任何事物。

速度定义（希望更好）

奥利维拉的定义是速度的实际工作定义，使团队能够预测他们可能在不久的将来可以在不久的将来完成的工作量，这是基于最近在过去的运输表现的实证观察。我对她的定义唯一的扩张是注意到故事点不一定是衡量单位。

所以，速度并不复杂。但是，它确实有一个关键依赖性。我观察到，当团队使用时间盒式迭代过程模型时，速度只是有意义。否则，速度根本没有意义。

一个时间盒式迭代过程模型有两个定义特征：

• 迭代是相同的长度
• 在每次迭代中，某些功能必须完成指向它的指出可以被释放到生产（或包含在产品中），没有额外的技术步骤来准备它

如果其中任何一个都不正确，那么团队就没有速度。

反形

在我的关于软件开发度量标准的预订据说，我建议在交付团队级别跟踪指标有两个原因：转向正在进行的工作，并量化过程改进努力的影响。在组织中有更高级别的度量标准的其他用途，但在团队级别，这些是主要用途。

速度可用于转向正在进行的工作，只要它按预期使用。了解团队通常在一个单位中提供多少，给我们一个基础，以便在可能完成给定的范围时预测，或者计划目标交货日期可以完成多少范围。但是当球队没有使用时间盒式迭代过程模型时正确，那么无论他们报告为“速度”都没有用;它实际上可能是误导性的。

提供的速度可用于量化过程改进努力的效果，所以提供了如预期用途。提供了一支球队对数字不好，以避免惩罚，然后我们可以随着时间的推移观察速度的改善。如果三分故事在3月份八天八天，10月份四天，那么它肯定会看起来好像他们有所改善某物假设他们不是游戏数字。

在这本书中，我的方法是解释指标如何与进步或过程改进的转向工作，收集和解释数据的机制以及共同的反模式;也就是说，公制的滥用。

事实证明，速度特别容易发生滥用。似乎“每个人”想要成为敏捷，人们通常会知道敏捷需要跟踪速度。因此，它们开始从第一天跟踪速度，即使它们可能不是（又一）可以在单次迭代的空间中提供生产就绪解决方案增量。在达到这一点之前，可能有多年的组织变革。

但是，尽管他们没有任何东西，但它们乐观地开始跟踪速度。这导致各种各样的问题。本书中列出的关键反模式是：

设置速度目标。速度是对团队的实际交付性能的实证观察;它不是目标。如果您设置目标，您的团队将简单地调整故事大小，以便它们似乎达到目标。什么都没有改变。

替代百分比完成百分比。在线性过程中，跟踪到目前为止范围完成的百分比是明智的。当组织首次应用敏捷方法时，他们经常将这个度量重新命名为“速度”，以“听起来更敏捷”。因为他们(还)没有正确地使用定时迭代，所以这只是一个名称游戏。

瞬时最大速度。在我们可以在预测中使用的有意义观察之前，团队必须在几个迭代中定居。常识是假设团队可以从一开始就可以实现任意的“最大”速度。使这个错误的组织倾向于为他们的第一个释放或两者计划提供太多工作。当它没有发生时，他们开始怀疑敏捷是在第一个地方这么好主意。

基于一厢情愿的预期业绩。有时，利益相关者试图说服团队调整他们的估计，以便他们可以获得更多。这种方法实际上并不导致更多完成，敏捷。在许多情况下，团队努力实现（或被要求实现）所谓的“延伸目标”。实际上，我们忽略了团队证明的交付绩效的现实，并替代了一厢情愿的思考。一支球队可以寻找改善其过程或其技术实践的方法，但他们不能简单地“伸展”他们的真正交付能力，而不是我们可以伸展12盎司的玻璃瓶，所以它将持有24盎司。

比较团队的速度。组织领导人需要能够将团队层面的指标汇到行政仪表板，可能沿途遍历组织的中间层。他们常见的是假设它们可以与速度相同。但速度高度依赖于每个团队如何运作，以及他们表现的工作的性质。速度观测不能在团队中有意义地比较。有一件事组织要尝试并使其成为所有团队的故事点。这样做的实际效果是使所有速度测量完全毫无意义。基于此类测量的任何预测可能是错误的。也可以翻转硬币。

那我们该怎么办?

如果您可以实现一个时间盒式迭代过程模型，无论您选择的特定方法如何（Scrum，XP等），那么速度观察将可用于转向工作和量化过程改进的目的。一世f this is not feasible in your organization, either by management intent or due to the challenges of restructuring the organization toward an Agile model, then consider alternative metrics that serve a similar purpose but that don’t have the dependency on a time-boxed iterative process.

精益学派的度量标准不依赖于任何特定的过程模型或方法。他们只是测量发生了什么。这意味着，如果你的团队中有些人用敏捷方法做得很好，而另一些人却在苦苦挣扎，这并不重要;如果您的一些团队正在销毁计划特性的积压，而其他人正在处理未计划的工作，如生产支持票据或基础设施请求;如果一些团队能够在整个交付过程中独立地移动他们的产品，而另一些团队则需要专业团队的支持。这也意味着将有可能将团队级别的度量汇总到执行仪表板上，而不丢失保真度或意义。

看看以下基本精简指标，看看它们是否似乎满足您的需求：

• 交货时间
• 循环时间，包括平均CT和CT变化
• 循环效率，A.K.A.过程循环效率
• 队列深度

结论

速度可能是与敏捷开发相关的单一滥用度量。牢记追踪速度，以“敏捷”是不强制的。如果您的团队满足速度有意义的依赖关系，它可能对您有用。否则，查找在上下文中有意义的指标。实用。