BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Chris Sims 关注 0 他的粉丝 ,译者 侯伯薇 关注 0 他的粉丝 发布于 2010年1月13日. 估计阅读时间: 6 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

用于优先排序的传统敏捷方法是这样的,业务价值高的用户故事应该在业务价值低的故事之前实现。这个概念很简单,但是想要很好地实现它,必须首先拥有访问业务价值的机制。最近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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

赞同先评估项目的“business values”在哪里,然后再确定“user story”的方法。但是感觉各种模型或者量化的评估方法不太靠谱 by Chan Jackei

赞同先评估项目的“business values”在哪里,然后再确定“user story”的方法。但是感觉各种模型或者量化的评估方法不太靠谱,因为:
1.即使有了量化的指标或模型,不熟悉客户和行业背景的人也不可能准确的评估出结果;
2.对客户和行业背景有深刻了解的人,不需要模型或量化指标,都可以迅速的指出某个项目对客户来说是否具有价值,或者价值多大;
3.有些事情就我现在的经验来看,真的是很难量化的,依赖的是“人”的经验/阅历和一系列内在的东西,这就是这类人所存在的价值。如果有这样的人在团队中,不需要量化和建模也可以很靠谱的做完上述工作; 如果没有这样的人,没准越建模越量化反而越偏离 business values;
4.参考作者的思路问一下:采用量化或者建模的方法来评估business values,这件事情本身的“价值”在哪里?

或许我的观点反映了国内和欧美IT环境的差异吧。

Re: 赞同先评估项目的“business values”在哪里,然后再确定“user story”的方法。但是感觉各种模型或者量化的评估方法不太靠谱 by Chen Archie

一步到位是不现实的,如果多次反复推敲busness values和user story之间的关系,即使是国内的it环境也是可以评估得出来的。问题是甲方与乙方是否愿意接受这样反复沟通的成本,虽然这个成本的投资收益率很高。

Re: 赞同先评估项目的“business values”在哪里,然后再确定“user story”的方法。但是感觉各种模型或者量化的评估方法不太靠谱 by 侯 伯薇

To:Jackei
你可能更多关注的是如何来进行量化的问题,以及量化的标准应该如何来制定。
在这里我想说一个在对日软件开发中,Review和测试环节的情况,在这两个环节中,都有量化的指标,Review和测试的人员必须找出指定数量的错误和缺陷。比方说在千行代码中要找到5个bug。乍一看,这似乎有些不合理,毕竟每个人编写的代码质量都是不一样的,但是这确实有业界的标准,并且坚决的执行给软件的质量带来了很大的好处。
所以,个人认为,存在即合理,作者使用了量化和建模的方法,并将其与大家一起分享,一定是因为他已经在实践中检验过这种方法,并且起到了一定的效果。我们也可以试一下,不管其原理和“价值”,只是看这样的方法是否会对我们起到帮助。
您觉得呢?

Re: 赞同先评估项目的“business values”在哪里,然后再确定“user story”的方法。但是感觉各种模型或者量化的评估方法不太靠谱 by Chan Jackei

有道理 :)

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

4 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT