大多数敏捷团队心中都有一个隐含的假设:“价值”与团队的“速度”直接成正比。这种看法在某些情况下也许是正确的,但是在大多数时候,团队的速度并不能反映他们真正交付的价值。
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 认为:
关键之处在于:不要让你的业务专家在交付之后度量业务价值(这样很难!),先让他们估算。每个故事(或者功能)在列入开发日程之前先进行估算。在每个迭代结束时,将所完成的每个故事的业务价值估算汇总起来。这就是你的“价值速度”。它类似于传统的速度,但是是基于客户对于业务价值的估算,而不是程序员对投入成本的估算。
这样看来,速度并不能总是反应团队的真实生产力。关键在于度量交付的价值,并作出努力,争取在每个迭代中都能交付更多的价值,而不是更快的速度。
评论