1.引言
软件开发方法，尤其是敏捷开发方法，正在越来越多地借鉴精益生产中的管理理念，其中主要的核心就是持续改进。要想持续改进，除了对改进方向的经验性认识以外，可以量化的改进目标也是一个无法回避的环节。在大规模实施精益管理的过程中，如何找到合理的度量，并合理利用这些度量，始终是一个难题。
度量是在一个特定组织上下文中形成的一系列共识。在一个软件开发组织里，度量统一的不仅仅是度量单位、度量对象、度量手段，更重要的是统一对目标的认识。
度量是将经验模型向量化模型进行匹配的尝试。量化模型有个非常重要的优势——方便进行比较：1)跟自己比较：持续改进，持续超越自己，就需要比较自己发生的变化；2)横向比较：是激励大家提升效率的手段，也可以知道公司在行业中的位置。但是软件开发中的很多信息都难以用量化模型来描述，当前流行的各种成熟度模式（如CMMI模型）都是将经验模型向量化模型匹配，这种量化模型本身具有局限性，度量的结果来源于对大量上下文信息的汇总、过滤和抽象，这种简化容易让人们在度量中失去了度量发生的场景细分，以至于为了度量而度量。
度量是包含人、流程、组织和工具的一个动态系统。如果把软件开发组织看作一个动态的系统，度量实际是作为反馈机制来对这个系统产生作用。
度量不是软件开发固有的活动，作为一个组织来说，应该积极地评估当前的度量活动的成本，分析是否真正为达成业务目标发挥着价值，从而确保运行度量体系的投入产出是在一个合理的水平。软件开发中并不所有的目的都要有度量来达成，度量也不是帮助达成所有目标的灵丹妙药。
2.度量对象
为了更加系统地对度量的对象做出分析，需要对交付对象的粒度有个合理的定义。合适的粒度首先需要寻找一个合适的方式来拆分度量的对象软件。怎么去评估一个功能是否完成，需要对完成做出清晰的定义，使开发和管理人员对完成有统一的认识。建议使用一个重要的概念——DoD（Definition of Done）。DoD是软件生产所需活动的一个检查列表，这些活动包括：需求澄清、功能设计、编码、单元测试、功能测试、联调、集成测试，还有一些暂时没有考虑的活动，如：前期的需求发现、体验设计，后期的部署、线上反馈等。DoD的计划分成3个层面：1）特性/用户故障DoD；2）迭代DoD；3）发布DoD。对于一个软件开发组织而言，定义不同层面的DoD分别包括什么活动取决于多项因素，例如产品本身的复杂度、业界适用的开发和测试手段，以及团队和组织本身的复杂度。团队对DoD定义达成共识，并将其明确地记录下来，严格执行。随着团队交付能力的提升，DoD应该逐渐演进。
3.指标体系
3.1价值
可以从两个角度来提高交付的价值：1）识别和拆分高价值特性，小批量交付；2）减少和消除低价值特性。
提升软件交付的价值首先在于优先交付高价值的产品和特性。精益软件开发提倡使用拉动（pull）的方式，尽可能以小批量的方式，交付市场已经发出强烈、确认需求信号的特性。较大的需求粒度和批量交付会带来的一系列潜在的问题，“绑架”高价值特性，导致高价值特性很难“加塞”。从交付价值上看，排队加塞并一定是坏事。环境会发生变化，团队也会由于获得了更多的信息和知识而改变先前的判断，这些不可避免的因素都可能导致在交付过程中发现更高价值的特性，插队行为在大粒度、大批量的交付模式下，就会导致项目延误，甚至导致许多半成品。
增量投入方法试图将系统分解程基于客户价值的单元——最小可销售特性（MMF），一个能快速交换给客户并提供一定市场价值的相对独立的特性。依据价值排序，小批量、高频率地交付是提高一个组织价值交付速度的有效途径。
交付价值的度量可以把产生价值的速度作为指标，分为发布前和发布后。1）发布前评估待开发的特性。价值的量化手段时通过估算在产品各个阶段的投入以及产出，以贴现现金流的方式来计算产品生命周期或是路线图中产生的净现值NPV。准确地度量价值的绝对值很难实施，也不是度量的目的，是为了引导开发组织更快、更早地交付价值而度量。这是一个定价模型。在每个阶段、开发部门、支持部门和产品管理部门或是市场销售部门一起协商，对下个阶段要开发的产品、版本、特性和子特性进行定价。评估过程应该要包含非特性类工作，如软件可靠性、可用性的改造性工作。2）发布后进行价值验证，度量特性在生产环境中产生的价值。价值可以是收入、用户增加、用户粘性等方式体现，也可以是品牌声誉、技术竞争力等无形资产的提升。通过分析产品和特性的价值，我们能够识别出潜在的问题，发现潜在的高附加值产品和特性，产生有根据的行动。
3.2响应速度
交付周期的定义是一个流程或项目启动到其结果显现所需的时间。关注交付周期的缩短是精益理念的一个重要组成部分。
提升市场响应速度应该关注版本、特性、用户故事和缺陷这四个层面交付单元的周期数据。1）版本发布：从项目立项到发布的时间，是端到端的发布周期，其结果通常是交付速率和响应速度的一个权衡。2）特性发布：在特性层面上，从需求定义到集成测试、验收测试、回归测试完成的周期，基本上代表了一个开发组织响应市场需求的最快速度。3）用户故事平均周期：从用户故事被纳入迭代计划，经过分析、开发、测试等环节，到被验收的时间，这是一个最小的端到端工作单元在一个团队中流转的时间。4）缺陷生命周期：缺陷的平均生命周期代表团队对测试、运维的响应速度。缺陷定位和修复周期通常也意味着代码的可维护性，还有自动化测试保护网的完善性。
对于版本发布层面，通常使用价值流图（VSM-Value Steam Mapping，如下图）来分析一个流程端到端的效率。1）识别目标产品或是共享流程的产品系列。2）定义流程的范围，使用标准的符号描述当前实际运行的价值流图：加工环节、等待队列、信息流等3）评估分析当前价值流图，尽可能到现场去观察并获取信息，识别出是哪些浪费在阻止系统形成理想的流动（Flow）状态，分辨潜在的改进点。4）绘制未来理想情况的价值流图。5）引入各方干系人，通过结构化的方法讨论并寻求接近理想价值流的解决方案，从而制定行动计划。6）定期召开干系人会议，通过评估初始的价值流图、最新的价值流，以及期望的价值流，讨论行动进展。
对于特性、故事、缺陷层面，关注的是开发执行过程中的状态，通过观察在软件开发生命周期中某个时间点的指标数据，分析影响交付响应速度的因素，累积流图（Cumulative Flow Diagram，如下图）是一个颇为有效的手段。累积流图早期出现在排队理论里，用来呈现在一段时间范围内，处于不同工作环节或阶段的工作队列的大小。通常把软件开发的工作队列称为backlog，队列中每个工作单元的生命周期一般会包含分析、开发、验证等不同的阶段和状态。开发团队通过记录工作单元状态变化的各个时间点，并基于这些信息绘制累计流量图。没有完成的工作是半成品 WIP（Work In Progress）， WIP的数量直接影响到交付周期和交付时间点的确定性。交付周期和交付时间点对于当前版本来说是个结果数据，处于半成品状态的工作量就成了预警交付周期和交付时间点的有效信号。在迭代交付模型中，半成品的增多意味着交付时间点的不确定性增强。
以上的价值流图（VSM）和累计流量图（CFD）两种手段很容易就能帮助我们发现开发过程中的瓶颈、等待、返工、库存，以及一些对最终产品没有价值的活动对响应周期的影响。
3.3 交付速度
交付速率是单位规模组织在单位时间内所能交付的软件规模，度量包含两个方面：1)迭代速率：团队在一个迭代中完成的用户故事点数。实践中通常用连续2~3个迭代的平均值来指示一个团队的速率。为了确保速率计算结果能比较真实地反映未来的风险，只要没有通过DoD质量保障手段检验的特性，其工作量都不应当被计算在当前迭代完成的速率里。2）节奏指标：代码合入频率核构建频率。只有成功通过自动构建里的各项验证活动的代码，才能被计入速率的统计。节奏代表了代码速率的稳定性和可靠程度，稳定的节奏通常也意味者进度的稳定和质量的稳定。节奏还代表了反馈的周期，快速合入代码并验证意味着更早地发现存在的问题，减少由于把问题留到后面所带来的更加高昂的定位和解决成本。
如果把软件开发组织的活动看作是一个动态的系统，提高交付速度就是要提高系统能力，方法主要有3个方面：1）提高个体的交付能力；2）优化系统的结构；3）减少交付活动中的浪费。
3.4质量
精益专注在缺陷发生的源头将其发现并解决，通过减少缺陷在价值链上流向下一个环节的可能性，从而减少缺陷带来的成本。为了达成目标，每个工作环节都应该有最低的质量要求。质量属性分为功能质量和结构质量：1）功能质量衡量的是软件符合客户、用户的需要和期望，也就是对其使用场景、使用目的的符合程度，此外，还包括软件在特定硬件、操作系统、浏览器等环境上运行相关的性质；2）结构质量属于软件的静态性质，衡量的是在代码、设计层面上，软件是否符合非功能的需求，比如可靠性，可维护性、可移植性等。这些属性又分为外部质量和内部质量两个大类。
提升内部质量的动力来源于：对于生命周期较长的产品，降低其持续开发的成本；对于当前版本来说，提供开发进度的可靠性，降低后端测试周期长度和工作量的不确定性。影响到内部质量的原因之一是技术债。技术债指的是软件开发组织或个人，在开发和设计的时候选择了权宜之计以取得短期的方便快捷，却给日后带来额外的代价。用债务这样一个财务术语来隐喻不良的软件架构和代码所带来的后果，目的是为了引入“利息”的概念。技术债指的是增加或维护新特性带来的成本问题，这些成本通常随时间而增加。可以用一个公式对技术债带来的成本进行一个大致的计算，作为一个趋势性的度量指标，为相关人员决定是否要采取干预性措施提供有效的信号。综合技术债=(10%轻微问题数+25%普通问题数+50%严重问题数)*平均修复时间(小时)*成本/小时。另外，一些节奏性指标也能对产品的质量趋势提示指示性的信息：构建成功率，构建成功率高意味项目后期的风险降低，分解到构建的各个环节，包含了编译通过率、代码规范通过率、测试通过率、集成频率等。开发速率趋势，大幅波动的开发速率通常意味着开发过程中的瓶颈，或是技术/过程中的障碍，我们可以通过观察迭代速率来了解这方面的情况。
外部质量涉及到产品质量的度量和开发过程质量的提升。产品质量的度量包括：满意度是产品交付到用户手中，用户直接使用之后的感觉和反应，通常有直接和间接两种方式来度量。直接方式是试图直接度量用户正面和负面的反应。间接方式可以以用户感知的产品可靠性和故障成本来衡量。开发过程的质量是产生可预见的产品质量的基础，提升的方法有：缺陷防范、更早地发现缺陷、减少回归缺陷。1）缺陷的防范是一个反馈的过程，应该定期从测试或用户报出的缺陷中抽样选取一些典型或严重缺陷，运用5why等技术，分析是否可以通过某些方式来防范，而要度量在多大程度上防范了缺陷，实际就是度量反馈机制的有效性。2）缺陷的排除也是一个反馈的过程，大多数组织当中发现缺陷的时间通常都比较滞后，通过评审、走读等方式能评审发生变化的一部分代码，但很难判断出系统其他部分可能受到的影响，最后的结果就是仍然把测试作为最主要的缺陷发现方法。更早地发现和排除缺陷，意味着必须加快反馈速度。迭代开发模式地一个重要意图就是缩短从问题产生到发现到排除的时间，从而降低成本和项目风险。3)想以稳定的节奏达成快速反馈、快速发布的交付目标，前提条件就是能够以低成本快速地进行全面有效地验证，自动化测试的价值日渐突出。
3.5能力
如果把软件开发活动看作一个动态系统，提高系统能力的一个方面就是提高团队中个体的交付能力。
个人能力主要关注三个方面：1）技术能力：解决问题，并完成任务的能力，也就是我们常说的把事情搞定的能力。2）首创能力：产生想法，并将其实现的能力，这项能力跟主动、创新相关。3）社交能力：与其他人协作过程中运用并发挥其技术能力的能力，比如协作、沟通、主动、辅导、领导力。
当产品复杂到一定程度，需要大规模团队协作的时候，组建有端到端交付能力的全功能团队，培养覆盖多项能力-学习型组织项领域能力的多面手，是减少开发瓶颈、提升交付效率和质量的关键。
4.结语
《代码大全》作者史蒂夫·麦康奈尔说过：“不要指望任何单个维度的生产力指标能够给你一个关于生产效率的完善图景。”简单的度量数据并不能将我们直接引向结论，更多时候是帮助组织和团队观察开发过程中实际发生的活动，将观察结果和预期相对照，提出有价值的问题，以做出判断，产生有效的行动。通过这样的一个正向反馈，持续学习，持续改进我们的开发方法。成功的度量体系建设一定是演进式的。
本文内容摘至《精益软件度量-实践者的观察与思考》。
