诺顿装好后要升级好几次
重要要点
- 速度预测通常约为50%。 你在押硬币
- 蒙特卡洛模拟是一种更好的预测方法
- 避免设置测量目标
- 关注趋势,而不是单个数据点
- 测量系统的多个方面。
速度不适用于预测或诊断,Doctor Norton在Experience Agile 2019上指出。这是一个复杂系统的滞后指标,该系统太不稳定了,无法知道我们的未来表现。 它不够稳定,无法可靠使用。
诺顿(Norton)将速度定义为随着时间推移实现价值传递的工作单位。 他说,这是明智的衡量标准。 但是,即使将速度与实际部署或交付联系起来,它仍然不会告诉您有关该过程的任何信息。 他说,仅凭这一措施,我们就无法判断团队是否表现良好。
为了获得更高的概率预测,您需要了解速度历史记录,积压量,开始日期和分割率,这是积压量增长的指标。 诺顿(Norton)展示了如何使用蒙特卡洛(Monte Carlo)模拟来预测团队何时能够交付。 根据我们希望拥有的置信度,团队将需要更多时间才能交付。
对于诊断,诺顿展示了如何使用累积流程图。 它们可以帮助我们跟踪一段时间内已完成和未完成的工作量,查看范围的变化并找出瓶颈所在。
敏捷和领导力教练Doc Norton在Experience Agile 2019上谈到了使用速度和其他指标。 InfoQ对他进行了采访。
InfoQ:您如何定义速度?
诺顿医生 :最简单的说,速度是指随着时间的推移实现价值的工作单位。 在大多数地方,它只是时间上的工作单位,但这不是速度,因为它没有明确的方向。 那只是速度。 速度是一个向量,它需要一个方向。 这就是为什么我们添加“朝价值”的原因。 它提醒我们,我们正在朝着特定的方向前进。 如我所见,价值就是学习,降低风险或提高效用。
对我来说,直到意识到价值,我们才算速度。 如果团队了解到诸如新处理是否增加交互作用之类的信息,我们肯定会降低风险,例如当依赖的不稳定系统出现故障时证明新的缓存技术可以工作,或者我们提供了诸如以下功能的实用程序:用户实际参与其中,然后我们考虑完成的故事并将其计入速度。 在很多地方,完成开发时都会计算速度。 如果这个故事永远不会上演,他们仍然会把它算作速度。 我认为他们缺少关键点。
在更深层次上,速度也是复杂系统的滞后指标。 正如所有滞后指标一样,它们对于预测未来不是很有用,但对于确认趋势和模式很有用。 想一想大部分零售领域的季度销售额-第四季度并不是第一季度销售额的指标,但可以为我们确认总体趋势,即每年年底销售额都会增长。
InfoQ:您在谈话中表示速度几乎没有用。 你能详细说明吗?
诺顿 :我现在已经在敏捷会议上调查了1000多人。 大约90%的被调查者对速度没有把握,在速度和展开之间没有联系,或者仅靠速度无法可靠地投影大量工作。
在接受调查的敏捷采用者中,只有10%的人发现速度对于完成工作和投入生产时的实际测量和预测很有用。 计划和预测是速度的目的。
基于这些数据,我认为可以说速度几乎没有用。
InfoQ:有时候人们会说速度是团队可以控制的。 您对此有何看法?
诺顿 :这是一个危险的观点,尤其是如果您正在管理。 指责演员的领导者没有把握大局,也没有看到他们在创造成果中所扮演的角色。
每个系统都是完美的; 它会产生设计要产生的确切结果。 如果适当的系统产生了错误的结果,那么系统内参与者的错误就更少,而系统本身的错误就更多。 我们可以告诫人们不要成为更好的演员。 我们可以坚持认为,他们应该基于某些关于人类的信念或规则-某些道德或伦理上的期望-表现不同。 但是,所有人类行为中的一个关键因素是他们在其中运行的系统或环境。 一个想要完成工作的完全理性的人会夸大估计值或在促进和奖励速度超过促进和奖励安全的环境中提高质量标准。 这并非普遍如此。 一些员工会坚持安全而不是速度。 但这确实足以对大多数组织中的大多数团队产生影响。
因此,当管理层将重点放在速度上,或更糟糕的是,设定速度目标时,参与者的行为自然是必然的结果。 游戏不是系统的团队,而是系统设计师。
InfoQ:如果团队想利用速度来看看他们是否在进步,那有可能吗?
诺顿 :也许吧,但不是很好。
首先,由于速度通常是每次迭代的故事点,并且故事点是团队抽象和估计的,因此速度极易发生漂移。
漂移是细微的变化,随着时间的流逝而累积。 您通常不会在很小的范围内注意到它们,而是在更宽的时间范围内进行比较,这非常明显。 以一支知道他们应该随着时间增加速度的团队为例。 果然,他们做到了。 我们可能会看到它们正在传递更多的价值。 但是还有多少呢? 我们如何确定?
在许多情况下,如果您回顾了几年前的一组故事,并要求该团队重新评估它们,那么它们的整体数字将比原始估计要高。 我的前提是,这是因为我们的估算值通常会随时间推移而逐渐升高。 每次迭代之间,较大估计值的偏差并不明显,但在四分之一或数年中却很明显。 您可以使用参考故事来帮助减少这种漂移,但是我不知道是否可以消除它。
第二,即使您可以证明估计值根本不会漂移,您仍然仅在测量一个维度-交付率。 要知道您是否正在改进,您可能还需要了解代码质量,客户采用率,客户保留率和系统性能,仅举几例。
速度不会告诉您有关系统运行状况,团队运行状况或公司运行状况的任何信息。 它甚至都没有真正告诉您分娩的健康状况。 很难用很少的信息来确定您是否正在改进。
InfoQ:对于使用速度来预测何时完成某事,您有什么建议?
诺顿(Norton) :预测仅与用于创建预测的数据和技术一样好。 对于大多数团队而言,以速度进行估算意味着您有大约50:50的机会在预测日期或之前完成。 考虑一下-您使用的是均值和推断-当然,您的预测将处于各种可能性的中间。 这也意味着您几乎不知道可能会错过多少分数。 可能的交货日期范围是几天,几周还是几个月? 根据您使用的技术,您可能不知道这一点。
我曾经对均值应用标准差以获得范围。 然后,我意识到许多速度分布不是高斯分布,而是偏移的。 因此,标准差在数学上并不正确。 而且很难用概率来解释范围。
我现在所知道的最可靠的技术是运行蒙特卡洛模拟。 Focused Objective上的人们有一个电子表格可以为您完成此任务; 它称为吞吐量预测器,您可以从免费工具和资源中下载它。 基于历史速度数据和大量工作积压,他们运行了500个模拟项目,以确定在一组日期或之前完成工作的可能性。 这是对发生的情况的简单说明,但足以基本理解。
该技术提供了具有概率的范围; 让您进行更好的对话。 使用此技术,许多客户发现他们所使用的速度技术产生的概率小于50%。 看到救济浮出水面真是太好了,因为他们意识到,并不是他们不能很好地管理团队,而是他们的预测不够充分。
InfoQ:我们如何使用逃逸的缺陷来衡量质量?
诺顿 :逃逸的缺陷是生产中发现的缺陷。 对于我执教的球队,没有其他缺陷,因此“逃脱”是多余的。 但是在某些组织中,存在质量保证缺陷和逃逸缺陷的概念。 逃避的缺陷是我们在这里所关心的。
测量迭代或吞吐量样本中引入的逃逸缺陷的数量可能会有所帮助,但可能会产生误导。 我们可能会发现每次迭代所逃避的缺陷数量正在增加。 我们知道这不是“好”新闻,但是我们知道新闻有多“坏”吗?
为了帮助我们确定,我们可以查看相对于吞吐量的逃逸缺陷数。 这给了您可以用来查看趋势的比率。 困难的部分是您需要齐心协力来确定在哪个迭代或吞吐量采样周期中引入了缺陷。 根据团队和系统的使用方式,这并不总是容易做到的。
假设您的速度历史记录为8、9、12、14、19和21,逃逸的缺陷数分别为2、2、3、3、4和4。 如果逃逸的缺陷是质量的衡量标准,那么质量是提高,降低还是维持?
如果仅看逃逸的缺陷,我们可以得出结论,它们显然正在上升。 由此可以得出结论,每个周期发布的软件质量都在下降。
但是,如果我们将其视为吞吐量与逃逸缺陷的比率,则得出.25,.12,.25,.21,.21和.19。 由此可见,通过生产量逃逸的缺陷总体呈下降趋势。 这意味着尽管缺陷率增加了,但实际上相对于价值率而言却在下降。
InfoQ:团队如何才能更好地使用指标?
诺顿 :我认为团队是否需要以更有益的方式利用指标需要考虑以下几件事。 避免设置测量目标。 关注趋势,而不是单个数据点。 测量系统的多个方面。 使用该信息来通知系统调整。
避免设置测量目标。 当一项措施成为目标时,它不再是一个好的措施。 这是古德哈特定律的解释。 指标是有关系统运行方式的信息。 它们是系统的副产品。 当您采取措施并通过设置目标将其转换为控件时,便将该措施注入到系统中-实际上就是在更改系统。 测量不再意味着它曾经做过的事情,因此,您认为刚刚设定的目标不再是您认为的目标。
关注趋势,而不是单个数据点。 减少对当今价值的关注,而对趋势更加关注。 指标趋势如何? 它会根据您的策略朝您期望的方向发展吗? 如果趋势不符合预期,请考虑系统中可能是根本原因的原因,并设法解决。 知道在某些时候,合理的策略会导致指标趋向于与正常预期方向相反的趋势。 例如,当您从整体式服务过渡到微服务时,代码往往会变得更加复杂。 一旦删除了旧的整体式代码,复杂性就会再次下降。
测量系统的多个方面。 每个系统都有紧张关系。 如果仅测量一个维度,则不太可能了解系统的真实运行状况。 例如,如果我们只专注于交付速度,则可能无法注意到对质量,客户采用功能或员工满意度的影响。 所有这些最终都会影响我们维持系统的能力。
使用该信息来通知系统调整。 我们只是在努力告知,而不是在设定目标。 我们正在研究趋势,并将其与基于我们的策略的期望进行对比。 而且,我们正在研究多个维度,以帮助确保我们不会对特定维度进行过度优化。 当我们在上述任何一个方面的趋势都偏离时,我们要考虑需要进行哪些调整,以使系统更接近健康的平衡。
关于被访者
诺顿装好后要升级好几次