生活制约的理论
生命周期变量

速度签名分析

速度分析 大多数敏捷项目跟踪他们的速度。在过去的10年左右,我一直在研究我的项目的速度配置文件和我可以获得数据的任何其他项目。速度配置文件讲述一个关于项目的故事,以及签名是唯一的。

跟踪故事或更正常的每个迭代的正常点,给出了经典的速度图,例如下面所示的速度图。

迭代速度样本

在这里,我们可以看到虚线蓝线所示的投影速度和深蓝色所示的实际速度。

从观察到15-20个项目,我已经注意到以下重新灼录模式。我是唯一一个,还是这些常见?
 

速度签名元素

过度承诺 - 当第一次要求速度投影时,团队产生过于乐观的预测。然后,新环境的必然并发症和延误(缺乏牵引)意味着少于预计所提供的交付。

幸运的是,大多数项目都要不注意这些早期迭代预测,因为它们是惊人的变化。我倾向于基于其他更传统的估计措施来完成更多的估计,以便逐步结合速度反馈,因为它变得更加可靠。

估算方法滑块   

斜坡到涅ana. - 鉴于有前途的初步进展趋势,当团队凝胶和更可重复使用的框架开发出来时,我们将继续越来越好,更好地变得更好?不幸的是,现实有一种干扰的方式,通常随着代码基础的发展,所以支持工作(假设常规的比赛),重构负载和复杂性;所有这些都可以减少不断变得更快的影响,因此不会发生斜坡(在我的项目上)。

平衡力平面衬里 - 与斜坡与未发生的斜坡有关,是平衬的特点。我们在技术上继续改进,实施过程改进,但速度保持不变。我猜测,通过提高应用程序复杂性,重构负载和支持努力,正在取消增量团队的改进。 (或者团队刚刚满足于他们当前的水平!)网络结果是速度以统一的速度持续。

过山车 - 这里均衡的力平面衬里正在发挥,没有重大上下或下降趋势正在发生,但迭代到迭代,我们有一些振荡。这是在我当前的项目上发生的,是我了解的两件事的一个功能,也许更多。首先,偶尔将批量未完成的故事转发到下一次迭代并在那里完成。由于我们没有声称信贷,直到我们的商家代表批准故事,一些迭代在以前的迭代中开始工作,以便完成。第二个因素是审查队列;我们的业务代表在测试申请时致力于测试的应用程序比其他人需要更长的时间。偶尔的“为中小企业审查准备”的队伍队伍建立了抢劫了衡量的真正迭代并在审查追赶所发生的迭代中存入更大的信贷。

速度过山车

谁在乎?
我们都应该和我们都不应该。一些变异是自然的,只是预期。爱德华兹德明告诉我们 常见的原因变异 只是历史范围内的变化,是正常的,在个体的高或低值中缺乏重要意义。相反,它只是“噪音“在系统内。

然而 特殊原因变化 是系统内的趋势或新的意外,紧急或以前被忽视的现象。它是历史经验基础之外的任何变化或系统中一些固有变化的证据。它是 ”信号“在一个系统中。

经典经理错误

德明警告我们 两个经典错误经理制作:
1) 干扰常见的原因变化 - 有些东西只是各种各样的含量,所以让它走。
2) 没有特别原因变异 - 如果发生了一些大移位,我们应该采取行动。

他还建议使用 控制图表 跟踪变化并尝试识别需要干预的特殊原因变化。
ControlChart.  

在这里,我们看到了具有上下控制限制(UCL和LCL)的测量特性。这些公差内的任何东西都被认为是常见的原因变化,而超出这些限制特殊原因变化。

我们可以在具有速度公差的敏捷项目中轻松完成此操作。

 速度容差

还有什么呢?
这些是我观察到的一些速度签名,但我将有兴趣知道是否有其他人经历过这些或只是我?此外,还有什么杂乱,我们如何最好地解释它?


 

注释

安德鲁布洛克

如果你 've有一个体面的数据集,可以'如果您使用它以更好地预测预测的速度'始终在承诺?

迈克格里菲斯

嗨安德鲁,

是的,我们使用先前的迭代速度作为未来的指南。这被称为“昨天的天气”。当我们有很少的先前数据依赖时,在项目中早早发生承诺。对不起,如果我没有明确,请谢谢你的问题。

最好的祝福
麦克风

此项对应的评论被关闭。