速度还是速率？敏捷度量的误区

 

 

“敏捷”意味着更快，所以产品负责人就可以不断的提需求，让敏捷开发团队不断的改版~不断的改版~不断的改版（重要的事重复3遍），这对吗？怎么破？

在回答这个问题前，首先看看什么是更快？更快是指用更少的时间完成预定的或更多的工作项，这对吗？

好像是对，但实际是有误区的。

在大多数的敏捷项目中，速度被定义为在单位时间内完成的工作项规模。

例如，在某个冲刺中，待办事项列表有若干事项（Items）需完成，各事项的规模（sp：Story Point，故事点是表示规模大小的单位）和冲刺结束时实际的完成进度如下：

• Item #67:  10sp,  100%
• Item #143:  5sp,  100%
• Item #81:  22sp, 100%
• Item #209: 8sp,  100%
• Item #44: 10sp, 90%
• Item #5:  4sp,  50%
• Item #99: 12sp, 0%

在这个冲刺中，速度是多少？

按照敏捷开发中速度的计算方法，计算冲刺速度时不关心“未完成”的事项，即便该事项已经完成了90%。

所以，在这个冲刺中，敏捷开发的速度等于10sp+5sp+22sp+8sp，也就是45sp/冲刺。

看到了吗，以上关于敏捷开发速度的计算，只是单位时间内完成的事项（Items）规模，并未考虑这些事项的方向是否正确。

有句老话“如果方向错了，做的越多，错的越多”。不考虑方向的后果，有时候会很严重！

 

在初中物理课本中，我们就知道，速度是速率和方向组合的结果。

因此，以上敏捷开发速度的计算，其实只是速率的计算，而非真实的速度。这是敏捷开发对速度和速率的一个误区。

你可能会感到奇怪，为什么在敏捷开发中要使用“速度”而不是“速率”的名称。对此，我也不知道。也许，只是因为“速度”听起来更加好听吧！

这也就是为什么敏捷“更快”了但还有很多人不满意的根因。他们忽略了一个基本的事实：如果敏捷开发没有在正确的方向上，那么做得更快毫无益处。

度量开发“速度”不对，那么，应该度量什么呢？

在敏捷宣言12项原则的第7项，明确说明“可用的软件是衡量进度的主要指标”。也就是说，主要应该度量的是软件所产生的价值。

那么，如何度量具有创造价值能力的可用软件呢？这很难，但可以尝试。

将物理课本中关于速度的x和y这二个坐标用成本和价值换一换，可以得到如下图示，我暂且称它为敏捷开发价值图吧。

K代表斜率，为价值与成本之比。如果事项（Item）的价值大于开发所需的成本，则该事项在高价值区，k大于1。反之，如果开发事项（Item）的价值小于开发所需的成本，则该事项在低价值区，k小于1。K等于1时，表示价值与成本相等。

通过k值，可以将事项（Item）与方向（价值/成本）关联起来，再结合上面速率的计算方式，得到的结果包含有事项所创造的价值和所需的成本信息，这才是真正的速度。

这种方法，最大的难度在于如何确定每个事项的k值。这没有更好的办法，基于“历史数据“、”经验“、”德尔菲法 (Delphi Method)“进行估算，也许是不错的选择。这样做，每增加的一个需求、每次的改版，都可以计算出所需的成本和带来的价值。用数字让那些随意提需求而不体恤开发人员的行为得到一些制约，也可能会较少一些PO和开发的“血腥*”吧。

总之，请记住，当速率与方向结合形成“含有价值/成本”信息的速度时，速度才是对成功的一个很好度量。

不管怎样，不考虑价值和成本的度量是极有误导性的，真正的度量应该关注于价值。

 

2020-1-9