价值、速度和价值速度之对比

  • Vikas Hazrati
  • 郑柯

2009 年 8 月 4 日

话题:敏捷架构文化 & 方法

大多数敏捷团队心中都有一个隐含的假设:“价值”与团队的“速度”直接成正比。这种看法在某些情况下也许是正确的,但是在大多数时候,团队的速度并不能反映他们真正交付的价值。

Ryan Shriver 认为:价值是对已交付益处的度量,要由利益干系人决定。而另一方面,速度是团队在一个迭代中完成的故事点数的累加。这些故事点数是否全部都有价值,还是个问题。在 Ryan 看来,开发团队应该提出下面的问题:

回答这个问题:对于给你的项目、产品、服务提供经费的人来说,他们觉得什么最重要?是他们从解决方案中得到的好处吗?比如增加收入、市场份额,或是提升运营效率(我们将这些称为业务价值)?

还是开发团队的估算准确率、或者速度?

与之类似,Mike Cottmeyer 提出价值和速度之间没有明确的关联关系。也许团队能够以很快的速度开发一个又一个的功能,并因此得到很大的速度值。然而,如果销售团队无法售出产品,或者业务部门无法使用,那么开发团队基本上就没有提升什么价值。他还指出:复杂产品的价值将会取决于整个链条中所有团队增加的价值。Mike 认为:

假如目前有四个团队共同开发一个要推向市场的产品套件。团队 A、B、C 的速度都令人高兴,但是团队 D 的人都还没到齐。Team D ultimately delays the release... and the overall product is late to market. 最终团队 D 导致了产品发布延迟,整个产品也错过了最好的上市时间。与此同时,竞争对手刚刚发布了他们产品的最新版本,而你们的产品就不怎么样了。

这样看来,如何衡量团队 A、B、C 对于你的产品的整体价值起到多少帮助作用呢?再次强调:速度很高,不等于价值很高。

那么,如果速度有缺陷,衡量生产力的最佳度量方式是什么?

Kai Gilb建议设立产品价值负责人角色。他阐述了如何在 Scrum 中将项目干系人产品价值结合起来,以衡量价值。这里,产品负责人在项目干系人和产品价值的层面上作出规划,设定优先级,并跟踪结果。

Ryan Shriver列举了其他衡量价值的技巧

James Shore推荐使用一种有趣的方式来衡量生产力。这被称为价值速度。 James 认为:

关键之处在于:不要让你的业务专家在交付之后度量业务价值(这样很难!),先让他们估算。每个故事(或者功能)在列入开发日程之前先进行估算。在每个迭代结束时,将所完成的每个故事的业务价值估算汇总起来。这就是你的“价值速度”。它类似于传统的速度,但是是基于客户对于业务价值的估算,而不是程序员对投入成本的估算。

这样看来,速度并不能总是反应团队的真实生产力。关键在于度量交付的价值,并作出努力,争取在每个迭代中都能交付更多的价值,而不是更快的速度。

查看英文原文:Comparing Value, Velocity and Value Velocity

敏捷架构文化 & 方法