跳转到主要内容

这是我今天的星座图:

金牛座,随着时间的推移,事情会有所改善。你不应该依赖那些可能不会按你想要的方式实现的东西。

正如您所看到的,它是无用的,就像您的团队的速度指标和消耗图表一样。

速度指标和占星术一样令人讨厌,因为它们都没有提供任何关于为什么某些事情出错或如何修复的洞察。此外,只要你眯起眼睛足够用力,燃烧图表和星座图都会显示你想要看到的东西。

停下来想想。除了告诉你“速度很低”之外,倦怠表还揭示了团队的瓶颈、问题和低效率?没有什么

低速,就像水星逆行一样,可以解释你想要的一切。因为速度让人们完全无法洞察团队的问题,所以管理者可以想出任何理由来证明他们已经想到的任何非生产性决策,比如为效率低下的系统增加资源,或者告诉人们“更加努力工作”,培养更大的“紧迫感”-这些词就像今天的星座一样模糊。

总而言之,速度是一个糟糕的指标,因为它没有提供预测能力,也无法帮助您做出决策。

在这篇文章中,我将阐述您应该使用的度量和可视化方法,以帮助您改进流程,并使您的团队更加高效和可预测。

我将首先将工程团队建模为排队系统。然后,我将解释影响排队系统性能的四个核心指标以及它们之间的相互关系。

然后,我将把这些指标转换成图表,以演示如何监控系统的性能,并一眼就发现有问题的模式。

本文的第三部分介绍了其他一些粒度度量和可视化,它们提供了预测能力,帮助管理者发现效率低下。

在这篇文章的结尾,还有一个简短的警告,帮助人们避免误用这些指标和可视化,以及一个简明的摘要,供您与团队分享。

系统及其度量

理解哪些指标最能代表工程团队的绩效的最佳方法是将其建模为排队系统。在这个系统中,任务在一端,软件在另一端。团队本身是在中间的处理机制。

In an engineering system, tasks come in on one end and valuable software comes out on the other

为了监控该系统的性能,我们必须将指标附加到其部分。这样,我们将了解每个部分的性能以及它们如何相互影响。

让我们从将指标附加到右侧和左侧开始。

在左侧,在任务进入的地方,我们有到达率,它代表随着时间的推移到达。在右边,在任务出来的地方,我们有离开率-也称为吞吐量-表示随着时间的推移离开。

The arrival rate determines how quickly tasks arrive on the left side, and the throughput determines how quickly tasks depart on the right side

每当到达率超过系统的离开率时,系统中的项目数量(在制品)就会增加。因此,队列形成。当队列形成时,每个项任务所需的时间越来越长。

The larger a system's queue, the longer teams will take to get to the queue's end

到达率和离开率之间的差异越大,在制品的增长就越显著。因此,循环时间增加的速率也将更大。

另一种可视化这种现象的方法是通过累积流程图。此图显示随时间进入和离开系统的任务的累积数量。

累积流程图是一个有用的图表,因为它一目了然地显示了关于团队绩效的大量信息。

在该图表中,底部斜率表示随时间推移交付的任务的平均数量(吞吐量),而顶部斜率表示随着时间推移进入系统的任务平均数量(到达率)。

随着平均到达率的增加,顶部和底部坡度之间的差异随着时间的推移而急剧增加。因此,系统中正在进行的工作量(由频带之间的垂直距离表示)增长更快。反过来,由带之间的水平距离表示的平均循环时间也会更快地增加。

下图显示了当平均到达率超过平均完成率时,这些指标如何随时间变化。

When arrival rates are greater than departure rates, WIP increases over time, increasing the average cycle-times

希望使团队的周期时间更加统一的经理可以尝试将任务进入系统的速率与任务离开系统的速率相匹配。

当平均到达率等于平均离开率时,在制品保持不变,循环时间也保持不变

这样,WIP保持不变,循环时间也保持不变。

通过了解这四个指标之间的关系,管理者知道当变量发生变化时,他们的团队将如何表现。这样,他们知道要影响哪些变量才能获得正常的周期时间,从而使他们的团队具有可预测性和生产力。

描述这种行为的另一种方法是使用利特尔定律,它在这些变量之间建立了明确的关系。

 

Avg. Cycle Time=Avg. Throughput/Avg. Work In Progress​

这个简单的公式总结了您刚才在累积流程图中看到的行为。

将系统分解为多个子系统

对于工程师来说,交付一项任务,他们不只是简单地输入一堆代码,然后直接发送到生产中。相反,他们编写一些代码,让人对其进行审查,将代码部署到登台环境,验证,然后才将其发送到生产环境。

同样,我们可以将该过程建模为排队系统。不同之处在于,我们现在处理的是一个由多个队列组成的排队系统,这些队列相互馈送。

An engineering system modeled as a system composed of multiple queues feeding one another

将我们的工程系统建模为多队列系统的优势在于,我们仍然可以使用相同的度量来分析其行为。此外,我们仍然可以使用累积流程图来监控其性能。

让我们继续绘制多队列系统的累积流程图。这一次,我们将把“正在进行”区域分解为多个其他区域,代表不同的队列,它们是流程的不同部分。

A cumulative flow diagram for a multi-queue engineering system

尽管分解了累积流程图的频带,但同样的原则适用。然而,这一次,我们有了更多关于系统不同部分如何行为的粒度信息。

如果我们想知道需要评审的项目数量,我们可以查看“开发”和“评审”带之间的垂直距离。类似地,我们可以查看这些波段之间的水平距离,以确定项目从“开发”到“审查”所需的大致平均时间

The cumulative flow diagram's properties remain the same in spite of us having broken it down into multiple bands

除了指标的视觉表示保持不变之外,它们之间的动态性也保持不变。

例如,假设任务进入审查阶段的速率大于它们部署到阶段环境的速率。在这种情况下,图表的红色带将膨胀,显示正在进行的工作增加,因此平均循环时间增加。

When tasks become ready for review more quickly than they are reviewed, WIP increases, and, consequently, cycle-times elongate

度量之间的这种动态再次揭示了匹配到达率和离开率的重要性。这种做法适用于整个系统及其不同部分。

这种比率匹配正是看板在日本制造商的“经济奇迹”期间表现如此出色的原因

与流行的观点相反,看板卡并不指看板上的卡(或张贴)。相反,他们指的是制造过程中某一部分的人发送给前一部分的卡片,以表明他们准备接受更多的工作。

例如,一个使用看板的汽车制造商只会在喷漆阶段的人发回一条信息说“我们有能力喷漆更多的零件”时才将零件送到“喷漆”阶段

通过将这些信号从排队系统的末端发送到其开始,制造商可以对其流程的不同部分进行评级匹配,从而提高其可预测性并减少在制品,当工厂地板上有数百件时,这一点尤其有害。

这就是戈德拉特约束理论背后的理论。管理模式侧重于识别和迭代修复这些瓶颈,以便不断调整各路段的出发或到达率,使其相互匹配。

在软件行业中,有时我们会遇到类似的固定瓶颈。当公司依赖手动测试而不是自动测试时,可能会出现这种情况。在这种情况下,我们可以识别瓶颈并修复它,以提高我们的测试段偏离率。

其他时候,我们的瓶颈是暂时的,因为我们没有重复复制相同的工作。相反,我们正在创建新工件的配方,这意味着可变性。因此,除了知道如何编码之外,工程师还需要了解如何测试和操作他们的软件。这样,我们可以动态分配资源,以填补不同流程阶段的瓶颈。

有些团队可能没有意识到这些动态,但作为人类,我们善于自然地找到改进流程的方法。这就是为什么我们提出了自动化测试文化和开发“DevOps”文化的原则。

在任何情况下,当管理者意识到这些指标背后的原则时,他们可以更容易地看到瓶颈所在,并提出创造性的解决方案来改进流程,而不是简单地采用自动化测试或灌输“DevOps文化”,这可能不适用于所有情况。

累积流程图上的其他问题模式

正如您在上一节中所看到的,膨胀带表示流程不同部分之间缺乏速率匹配。缺乏速率匹配会导致正在进行的工作增加,从而导致周期时间延长。

除了隆起带之外,其他模式还提供了有关过程中有问题部分的有用信息。

在本节中,我将提供一些有问题的模式的例子,解释每一种模式可能表明什么,并建议可能的干预措施。

扁平线

平线表示流程特定部分的非活动期。

例如,假设您的部署脚本已损坏。在这种情况下,从“部署”阶段到“完成”阶段的偏差将为零,导致累积流程图中出现一条平线。

Flat lines indicate long periods of inactivity in a particular part of the process

这样的扁平线有助于管理者更快地识别流程中的故障部分,并找出问题所在。

除了帮助管理者发现中断的流程外,平线还可能表明流程中的某一部分过于痛苦或耗时,从而导致其发生频率较低。在这种情况下,工程师一次转移大量任务,以节省自己多次执行痛苦任务的工作量。

例如,假设您的部署过程是手动和耗时的。在这种情况下,将项目从“部署”阶段移动到“完成”阶段的交易成本很高。

这样的大批量转移将在累积流程图中显示为“阶梯”。

 

Stair steps may indicate that a particular part of the process is slow or painful. Consequently, it happens less often and there are larger batch transferrals

这些大批量转移是Martin Fowler和许多其他作者提倡持续交付的原因。当部署频繁发生时,除了减少更改增量和错误空间,还可以更容易地对工程系统的不同部分进行评级匹配。

消失的乐队

每当一个频带消失时,它就发出信号,表明该过程的特定部分正在饥饿。换句话说,消失的频带表明上游段比下游段具有更快的处理速率。

例如,假设您的团队有各种自动化工具来帮助进行评审。在这种情况下,评审比开发更快,导致评审过程匮乏。

Disappearing bands indicates a particular part of the process is starving

在这种情况下,饥饿本身并不成问题。尽管如此,您无法将项目纳入审查的事实表明,通过增加重用或重构软件的复杂部分,加快开发阶段可能是有利的。通过这样做,您将试图匹配“开发”和审查阶段的离开率。

这种模式还可能表明上游部分(开发阶段)高度可变,导致您的团队更加不可预测。因此,“评论”乐队的规模不断激增和消失。

当有固定数量的资源等待接收工作时,饥饿会成为更大的问题,如在制造业。当资源被交叉训练以在流程的不同部分工作时,我们可以动态地将工作转向瓶颈。这就是为什么避免筒仓非常重要。

还必须注意到,经理的目标不一定是不惜一切代价避免饥饿。优先考虑效率(每个人都在忙)的经理会增加排队的形成。因此,正如我在另一篇博文中解释的那样,它们最终会增加在制品和周期时间。

其他有助于发现问题的可视化

有时,仅仅因为累积流程图看起来完美无瑕,并不意味着团队的绩效是最佳的。

例如,假设您的团队持续发布大量关键错误。在这种情况下,每当有人发现其中一个bug时,bug修复就会成为首要任务,并很快完成。

当这种情况发生时,您的累积流程图可能会显示到达率与离开率匹配,但除了错误修复之外,什么也没有做。因此,您的团队将不会发布任何功能,任何其他任务都将被丢弃。

例如,下图可以说明这种情况。

A cumulative flow diagram doesn't specify which items get done, it specifies the quantities of items entering and leaving the system

在这种情况下,我们说你在积累“流动债务”。这意味着你人为地老化一个问题,以加速另一个问题。

另一种思考“流动债务”的方法是想象你从一个任务到另一个任务借用周期时间。

流动债务扼杀了可预测性,因为优先级的变化会导致其他问题人为老化。在这种情况下,很难预测您何时完成某项工作,因为您不知道某项工作是否会将注意力从正在进行的项目上移开。这就是为什么必须完成你开始的工作。

要可视化流动负债,可以使用散点图,在Y轴上显示项目的年龄,在X轴上显示流程阶段。这样,您可以在流程的不同阶段可视化每个项目的年龄差异。

A scatterplot which illustrates the age of the different work items throughout your progress

或者,可以使用循环时间直方图。当您有流量负债时,这样的图表将显示循环时间的双峰分布,这意味着您可能会看到左侧的峰值,其中循环时间较短,右侧的另一峰值,其中周期时间较大。右侧的大周期时间表示产生流动负债的项目,而左侧的短周期时间表示加速项目。

A cycle time histogram showing a bimodal distribution indicating some items may be expedited while others artifically age

最后,确定流动负债的另一种方法是查看您的“流动效率”。团队的流效率衡量项目在阻塞状态下花费的时间百分比。

例如,如果一个团队的平均流量效率为50%,则问题平均在50%的时间内被阻塞,导致问题人为老化。团队的流动效率越低,尾部循环时间越长。

把它们放在一起。

工程团队可以建模为排队系统。在这样的系统中,任务在一端,软件在另一端。

您可以使用四个指标来衡量这种排队系统的性能:

  • 到达率-任务到达系统的速率
  • 正在进行的工作-任何给定时间正在进行的项目数
  • 离开率或吞吐量-任务离开系统的速率
  • 循环时间-任务离开系统所需的时间

当系统到达率超过系统离开率时,正在进行的工作量将增加。WIP的增加表示任务队列的增长。当队列形成时,周期时间会延长,因为到达队列末端的时间越来越长。

可视化系统随时间变化的性能的一个很好的方法是使用累积流程图,它绘制了随着时间的推移正在进行和完成的任务数量。

在累积流程图中,顶部斜率表示到达率,底部斜率表示离开率(或吞吐量)。带之间的垂直距离表示正在进行的工作量,带之间的水平距离表示近似的平均循环时间。

要更详细地分析系统性能,可以将排队系统分解为多个连接的排队子系统。这些子系统中的每一个子系统都相互馈送。您也可以在累积流程图中执行这样的分解,方法是将“正在进行”区域分解为表示流程不同阶段的多个其他区域。

当一个子系统的吞吐量超过下一个子系统时,下游系统的到达和离开之间会出现不匹配。因此,在下游系统中将形成队列,循环时间将延长。这就是为什么必须对您的流程进行评级匹配。

为了更容易地对流程进行评分和匹配,您可以对工程师进行交叉培训,以处理流程的不同部分。这样,您可以动态地将工作导向瓶颈,瓶颈在软件开发等随机过程中往往是可移动的。

子系统之间到达和离开率的这种不匹配将通过特定频带的膨胀在累积流程图中表现出来。膨胀带代表了无法跟上上游子系统到达率的过程。

除了膨胀带,累积流程图还可以帮助您发现另外两个问题:

  • 大批量转移或中断流程-当生产线变平时
  • 消失频带-当子系统饥饿时

仅仅因为累积流程图看起来不错,并不意味着你的团队表现良好。

累积流程图显示了流程不同部分中的项目数量,但并不确切显示这些项目是什么。因此,您的到达率可能与您的离开率相匹配,这可能只是因为一些项目正在加速,而其他项目则被留下腐烂,永远无法完成。这种现象被称为“流动债务”。

您可以使用循环时间散点图来检测_flow debt_并查找异常值。或者,您可以使用循环时间直方图并寻找双峰分布。

关于良好指标的注释和几句警告

好的度量有三个特征:

  • 它不是一个目标,而是一个最终状态,它有助于确定你是否朝着正确的方向前进。
  • 它是可操作的-它帮助管理者做出决策,并干预系统以产生改进。
  • 它与具有特征1和特征2的其他指标有明确的关系-您知道当您使用不同的杠杆时,其他指标将如何变化。

我认为我在这篇文章中倡导的度量标准是好的度量标准,因为它们具有所有三个特征。另一方面,速度却没有这些。

尽管认为这些指标“良好”,但我必须敦促管理者不要:

  • 将指标转化为目标-正如古德哈特定律所述,当你将指标转化成目标时,它们不再是一个好指标。这是因为人们会不惜一切代价与系统博弈,使指标变得更好,而不是真正实现组织的目标。
  • 将指标武器化——正如戴明所说,“只要有恐惧,你就会得到错误的数据”。
  • 使用指标作为替代,与您的团队交谈并进行定性分析。-指标必须起到“警钟”的作用。当出现问题时,它们会敲响警钟,但你的工作是确定如何干预。

管理者还必须意识到,完全按指标管理(按结果管理)就像W.E.Deming所说的“驾驶汽车从后视镜看”。

过去不一定与未来相似。然而,发现过去行为的模式可以帮助你适应未来,避免犯同样的错误。

进一步阅读

  • 产品开发流程的原则:第二代精益产品开发-Donald G.Reinertsen
  • 可操作的可预测性敏捷度量-Daniel Vacanti
  • 什么时候完成精益敏捷预测,回答客户最重要的问题-Daniel Vacanti
  • 高容量利用率对团队绩效的影响-卢卡斯·达科斯塔
  • 为什么长期计划不起作用,以及如何修复它们-卢卡斯·达科斯塔

如果您希望使用我在这篇文章中提到的任何可视化或度量,它们都可以在可操作敏捷上使用,正如Daniel Vacanti在其精彩的著作《可操作敏捷可预测性度量》中提到的那样

 

本文: