软件度量是一个体系化工程，需要反馈和反应目标的达成率。而且对于精益软件来说，价值度量最为重要，直接反映研发的有效性和库存。

封面

1 价值

“一个点子的价值只能存在它的使用当中。”  ------托马斯·爱迪生(1847—1931)

指标体系

如何提高交付的价值：

•识别和拆分高价值特性，小批量交付；

•减少和消除低价值特性。

1.1 识别和拆分高价值特性

提升软件交付的市场价值首先在于优先交付高价值的产品和特性。精益软件开发提倡使用拉动（Pull）的方式，尽可能以小批量的方式，交付市场己经发出强烈、确定需求信号的特性。

较大的需求粒度和交付批量会带来的一系列潜在的问题。

•首先是“绑架”高价值特性。

•然后还会导致高价值特性很难“夹塞”。

识别和拆分高价值特性

1.2 反馈提升价值

对于即将或是正在开发的软件而言，减少无用特性的关键是快速收集反馈。

在传统的开发模式下，即使是在强调反馈的螺旋模型里，反馈是以版本为单位大批量的方式进行的，也就是说用户预期的项目目标和范围早早就己经基本定好了。很少会重新审视特性的价值，调整目标和范围。

瀑布模式下的用户反馈模型

精益开发强调的是快速、小单元的反馈，根据反馈的结果，及时对计划进行调整，一旦发现价值不佳的特性就尽快从发布计划中剔除，并用价值更高的特性替换，这就是可适应计划（Adaptive Planning）。

迭代开发模式下的用户反馈模型

反馈的有效性则通常取决于反馈提供者是否是真正的产品使用者或决策者，还有反馈收集者的水平。

1.3 减少没发挥价值的特性

软件开发中，最大的浪费，也可能是最常见的浪费，其实是开发没用或是很少被使用的产品和特性。

Standish Group的特性和功能利用率统计

没被使用的特性不仅本身是浪费，还会增加系统的复杂度。

没有被用到的特性是如何发生的呢？

1、业务分析人员或是客户代表，他们负责跟开发团队合作，识别和梳理用户的需求。在很多情况下，他们自己并不是最终用户。由于各种因素，没有挖掘到真正的客户需求。

2、另一个重要的因素是客户试图取得安全感的心态。客户经常会觉得如果当下不把需求说全了，以后可能就没机会了，所以把只要想象得出来的东西都先放到桌面上来，塞进项目范围。

3、另一个主要的原因是大多数组织的预算和规划制度。很多组织使用年度预算的方式；预算和调整预算申请的繁琐过程和结果的不确定；很多公司把固定预算、固定目标的方式作为项目规划和招投标的政策，基本排除了在项目过程中根据最新掌握的知识和信息调整优先级的可能性。

1.4 交付价值的度量

价值度量的反馈

1.4.1 发布前——评估待开发特性的价值

价值的量化手段是通过估算在产品各个阶段的投入以及产出，以贴现现金流DCF（Discounted Cash Flow）的方式来计算产品生命周期或是路线图中产生的净现值NPV（Net Present Value）。 本书不讨论。

虽然增量投入方法（IFM）提出了一个明确的框架，但是实际操作起来还是面临很多的挑战，如下所述。

（1）并不是所有的软件产品都会产生资金上的收入，验证性和预研性项目。

（2）即使产品会产生收入，这些产品或特性的价值并不是开发组织自己说了算，而是由市场决定，市场的反馈一般非常滞后。

（3）市场对产品定价，或是说产品或特性在市场上能创造的价值取决于多方面不确定的因素。

那么我们是否应该放弃用价值度量呢？当然不是。回到度量的目的，准确地度量价值的绝对值并不是我们度量的目的，我们是为了引导开发组织更快、更早地交付价值而度量。

价值交付速率包含两个因素：交付速率和单位产量所产生的价值。交付速率取决于开发组织的生产效率；而单位产量所产生的价值，取决于从交付管道里先流出来的是否是高价值的特性。

这是一个定价模型：

（1）这个评估过程也应该包含非特性类的工作，比如像提升软件可靠性、可用性的改造活动。

（2）如果不同部门有不同的优先级，可以考虑先定一个固定数量的价值总额度，以及几个部门分配的额度，各方把自己拥有的价值额度分配给待开发的特性。

（3）当为每个特性分配价值之后，通过统计交付的特性的价值，就可以计算出团队或部门的交付价值。这里可能跟踪的指标包括：版本交付价值、迭代交付价值。

1.4.2 发布后——验证价值

Eric Ries在他的《Lean Startup》一书中提到[注释]，一个公司在使用看板来管理用户故事的时候，使用了4个状态：Backlog，In Progress，Built，Validated。

由于数字渠道在各个行业的广泛运用，企业IT组织的服务开始直面最终用户的挑战。企业应用也愈来愈像互联网产品和服务那样，追求实时、小粒度（特性）的验证、反馈和演进。

1)可以通过自己部署收费或开源的系统，在企业内网上收集软件和软件特性的使用情况.

2) 在log日志里标识出用户的行为，然后用脚本加以分析，也能分析评估用户或关联系统，对特性的使用、调用行为。

1.4.3 尝试的价值

当我们尝试提高价值转换率的时候，另一个需要考虑的因素是尝试所产生的价值。一味地确保每个开发的特性都要被用上，都要产生价值，可能带来的一个副作用是打击了尝试和创新的积极性。

AB 测试，通过把对同一特性的不同实现暴露给两组类似的客户，观察这两组客户的使用习惯的差异，从中选择更佳的实现，也可以利用观察中发现的模式，进一步改进特性的实现，以期望获得更大的价值。

反馈点分成4个阶段：

•手绘的低保真原型

•反映真实产品关键界面的高保真原型

•可以运行的MVP（最小可行产品）

•实现覆盖目标用户群的关键特性，经济上可持续的产品

产品开发的反馈漏斗

在高度动态的创新市场上，创新也变成了一个用户拉动的过程，只有客户表示愿意买单，想法才会得到投资，被拉向下一个反馈点。对于这个创新漏斗，漏斗本身的吞吐量和在每个反馈点的验证有效性是其效率的指标。

小结

软件的度量是一个体系化的实践，通过一些数据可以反馈一下软件的现状和问题，有助于改进。价值度量是整个度量体系最终要，也是最难衡量的，直接反馈研发的有效性。