如何评估业务价值的高低?

  • Chris Sims
  • 侯伯薇

2010 年 1 月 12 日

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

用于优先排序的传统敏捷方法是这样的,业务价值高的用户故事应该在业务价值低的故事之前实现。这个概念很简单,但是想要很好地实现它,必须首先拥有访问业务价值的机制。最近Pascal Van Cauwenberghe描述了一个用来定义业务价值的方法,叫做“业务价值建模”,这可能会对我们有帮助。

在 Pascal 的《你如何评估用户故事的业务价值?你不会!》一文中,他断言,假设我们首先得到的是用户故事,然后才估计它们的业务价值,那么就会存在重要的缺陷。Pascal 建议,好的做法是首先回答这个问题:“我们如何才能找到传递了业务价值的用户故事?”接下来他建议了这样的方法:

  • 在开始一个项目或者产品之前,我们首先要决定想要达到什么样的价值(或者利益)
  • 然后我们要找到并改善传递价值的业务过程。
  • 然后我们要找到并改善使得传递价值的过程有效的辅助业务过程
  • 当团队需要用户故事的时候,我们会采用价值最高的过程,然后针对团队的需要以正确的粒度将其分解为用户故事。由于团队会不断提取故事,所以我们只需要生成最基本的一组用户故事。

接下来的文章中,Pascal 探究了术语“业务价值”的意义。他对于单独的度量像“股东价值”并不满意,因为他注意到通常多个股东会有不同的目标和需求。Pascal 使用的是叫做“业务价值建模”的过程:

  • 识别恰当的股东。
  • 识别他们的需求和目标。
  • 在他们如何度量 / 测试需求和目标的达成方面达成一致 。
  • 选择最重要的(几个)度量和测试,也就是“价值驱动因素”。
  • 定义价值驱动因素之间的关系
  • 使用价值驱动因素来对我们的工作保持专注并按优先级排序,这个工作要从开始一直做到结束。

Brandon Carlson在文章《在眨眼间完成故事的优先排序》中也描述了一种用来分配业务价值的方法,与上述的方法在某种程度上是类似的。他的方法首先会识别有助于业务价值的特性的属性,然后用来创建业务价值。他的团队列举了这样的属性,包括很多方面,如:合同义务、市场窗口(Market Windows)、客户影响、系统健康以及企业策略。然后每个领域的业务专家都会对特定领域产生影响的特性进行评分。基于这些输入,每个提出的特性的业务价值的分数都会被计算出来。

一旦所有的股东都对他们自己的属性进行了评分,那么评分会被记录,对于产品带有最大正向影响的特性会移动到列表的最顶端。无需争论(好吧,就算有一些,但之前似乎不会),只要看数字……由于做了这个改变,我们已经见证了优先排序会议为生产力带来的显著提升。最基本的优先顺序是在会议的最先几分钟内设定的,但这会使得整个会议的时间显著减少,可能从一个半小时减少到半个小时。

Mike Cohn的各种对于“为你的产品备用品按照优先级排序”的具体展示中,他已经告诉了我们多种访问相对业务价值的技术。这些技术包括“模式审查”、“模式评分”、“相对重量”以及“卡诺分析”等等。在其中一种具体的展示中(在 Scrum Alliance 站点上提供了该展示),Mick 甚至还分享了一个财务模型,它为模式(作为相关用户故事的集合的模式)赋予了价值,体现在净表现值内部回报率两个方面。

生产力度量上,James Shore发现,拥有度量业务价值的方法是创建令人满意的对生产力的度量的前提。

有一种方法可以被用来定义编程团队的有效输出。那就是看团队的软件在业务上的影响如何。你可以度量收入,投资的回报或者其它反应业务价值的数字。

James 在《价值速率:更好的生产力度量》一文中回顾这个主题的时候,他承认对于业务价值来说,很难创建一个好的度量标准。

尽管我仍然很喜欢这个方法,但它还是有缺陷的。度量价值真的很困难。某些类型的很有价值的工作不会直接导致销售额的提升。同时,某些提升价值的原因与团队的工作是无关的……某些类型的故事会以传统的方式提供价值。修改很烂的具有破坏性的缺陷的价值是什么呢?是软件的整体价值吗?还是没有任何价值?适应并完成的价值又是什么呢?

James 最终建议,要创建业务价值评估,方式与敏捷团队创建工作评估的方法类似。Kelly Waters还在《在敏捷软件开发中度量业务价值》一文中推荐了这种方法。随着故事规模的增大,Kelly 使用斐波那契数列来将相关的业务价值分配给每个故事。

和开发团队以点数来评估的方式一样,产品所有者会为每个项目确定业务价值,它们彼此都是相关的。此处的关键在于评估业务价值是相对的,例如,业务价值为 2 的特性的比业务价值为 1 的特性重要两倍;而一个价值为 5 的特性拥有价值为 1 的特性五倍的价值,以此类推……为后备列表中的每个项目都赋予业务价值的点数,这会让你能够计算“业务速率”,例如,在每个 Sprint 中实现了多少业务价值(以点数计算)。你可以把它画在“燃尽图”上,显示随着时间的推移所累计实现的业务价值。

你的组织是如何度量业务价值的呢?这是如何影响开发者所做的工作的优先排序呢?请留言,分享你的经验和意见。

查看英文原文:Estimating Business Value

敏捷架构文化 & 方法