自2011年我初次在敏捷之旅苏州站分享《敏捷中的度量》以来，对这个问题的求解就一直到9012年末。
最近与一些X-Developer申请者、使用者交流，针对开发者的绩效评估，需求的分解与度量依然是难点。客户认为，如果在需求上无法做到均匀，那么针对需求个数的统计就是不公平的，但是要做到需求的均匀，又是一个难以解决的问题。另一些业界观点又认为，只要拆、拆、拆，最后需求一定会“接近于均匀”的，但这个观点除非有数学上的极限证明，或者统计学上的回归分析，只能说是一种假设。
本文利用了会计准则中的商业活动、存销成本分析，提供了一套完整的敏捷模式下的研发产能度量方法。
本质是经营方式变化了
为什么从大版本到小版本，版本到迭代，迭代到持续交付，看似简单——不就是缩短发布周期嘛——企业做起来如此困难？本质是经营方式变化了。对制造企业、零售公司和服务公司，其管理和净利润计算方式都是不一样的：制造业的特殊之处是厂房和土地等资产的折旧管理，而零售公司是存货管理，服务公司是费用管理。
作为软件公司，其交付模式就代表了经营模式，交付模式变了，经营管理不变，一切都会错乱。总体而言，传统以采购厂商软件为主的IT部门，接近于制造企业；研发中心接近于零售公司，现在大家都在向服务公司的轻资产转型：比如云服务费用替代硬件折旧成本，研发成本资产化。
由于并未真正做到完全没有存货（需求积压），敏捷模式下的度量，更多是借鉴了零售的存货成本计算方式，版本制向迭代制的转变，很类似于定期盘存制向永续盘存制的转变：及时性的提升。在永续盘存制的模式下，货物的每笔收发都需要记录和结存，以随时了解企业的财产和物资，但加大了会计的工作量。对需求而言，采用迭代的模式，召开需求收集会议更加频繁，工作量加大，**但可以更加及时地了解和处理需求。**所以是不是采取迭代开发，需要企业根据自己需要的响应周期进行判断，甚至可以多种方式并存。
估算要不要做
估算（Estimate）在软件中是一个非常有争议的名词，因为管理者总是把估算当作承诺，估算又非常不准确，所以许多人都想把它“干掉”。然而Estimate还真是一个会计词汇，应收/应付往往不一定收/付真实的帐面价值，所以会计上对作出估计。在项目管理中，由于缺少对估算的实际调整，所以导致了最后的偏差，也导致了管理真实交付周期的困难。
估算真正的困难在于什么呢？在于没有依据。或者说许多企业将估算的实施弄错了。以下是关于估算的一道（经典）题目，用来测试你的理解：
项目经理让开发人员小王估算需求B的开发周期，项目经理自己评估，需要两天做完，之前小王做过一个相似规模的需求A，用了三天，小王评估需求B后，认为需要五天才能做完，需求B的估算开发周期应该是： a. 三天 b. 五天 c. 四天 d. 两天
你选择了什么？
对估算技术理解无误的话，正确答案是a，三天。因为这是事实数据，估算是基于过去发生的事实进行评估，而非主观想法，或者算平均数。
研发产出到底怎么算？
第一段提到，基于需求数量的产出计算存在两个问题：
- 需求拆分方法的难度；
- 假设需求规模的极限是平均值缺乏证明。
基本术语定义
如果你对精益系统中的名词还不太了解，这一节可以补充背景知识。主要是三个关于时间的定义：前置时间、周期时间和节拍时间。
前置时间（Lead Time） 前置时间在精益系统中衡量的是订单响应的周期，就是指从接受订单到交货成功经过的自然日。举个例子，8月30号接到订单，9月27号交货到用户手上，前置时间就是28天。在软件研发中，前置时间是指需求接受到发布上线过程中经过的所有自然日。对需求接受的定义，就是产品/研发部门与业务部门确认了这是一个有效的需求，将会被开发，而不是直接拒绝掉，所以，后面的需求澄清、分析、变更花费的时间，都会被计入前置时间之内。
前置时间是评估整个需求响应能力的重要指标，由于业务、运维都包括在内，所以它反映的是综合能力，影响因素也较多，比如，可能各个环节都很快，但手工回归测试工作量太大、太慢，整个前置时间就会非常长。缺少自动化能力的公司，不适合采用前置时间作为评估指标。
周期时间（Cycle Time） 周期时间在精益系统中衡量的是生产制造本身“有多快”，所以它统计的是从开始生产到发货经过的所有自然日。举个例子，9月12号开始执行生产计划，9月15号发出货物，周期时间就是三天。对软件研发而言，周期时间是“进入开发”到“准备发布”过程中经过的所有自然日。对需求开始设计，原则上就是“进入开发”了，因为敏捷倡导的是设计编码不划分不同阶段。准备发布是指向生产环境的发布，如果转型迭代前期，业务还做不到及时的验收，也可以把准备发布UAT（用户验收环境）作为临时的终点，然后慢慢牵引业务融入节奏。
由于周期时间去掉了需求澄清、上线部署的影响，所以它是衡量研发效率的重要指标。换句话说，这个指标不好看，改进范围就在研发内部，包括开发和测试。
X-Developer对周期时间的计算是针对某个需求，从第一次代码提交时间到最后一次代码提交时间经过的自然日，所以是非常精确的，也是非常及时的。在试用时有产品经理说，“我们的需求都是两周一迭代，不可能出现超过两周周期时间的需求。”但是数据说明了，这里就是有一些两周后针对这些需求的代码提交，不管是因为配置脚本，还是因为环境切换，还是因为客户数据导入，它们其实是没有在两周内真正完成的。
节拍时间（Takt Time） 节拍时间指的是单个产品生产花费的时间，它衡量的是单位产出的时间成本。比如说周期时间三天里，共生产出了30件待发货产品，节拍时间就是1/10天。在软件研发里，可以视为一个时期内需求的平均周期时间。
节拍时间可以度量到任务，并且可以分别度量开发和测试的任务。以2018年在某零售银行的度量为例，我们把周期时间的度量粒度放在特性上，流动效率的度量粒度放在任务上，这样一来，当特性的周期时间很短时，看任务流动性可以评估规模。
这种度量方式完美解决了需求颗粒度不均匀的问题，在此基础上我们定义出了一条公式：
研发产能 = 需求个数 * 周期时间
这条公式背后的思想是：凡是加减法搞不定的计算，用乘法搞定。
然而伟大的会计准则早就给出了更完善的解决办法，它们叫：平均成本法、先进先出法、后进先出法和个别辩认法。具体就不展开了，我们借鉴会计存货成本计算直接给出不同办法的计算方式与适用模式。
平均周期时间法 ACT - Average cycle time
平均周期时间法下的研发产能计算使用所有需求交付的平均周期时间作为第二个计算因子。“所有需求”的范围可以根据情况设定在项目内、团队内甚至跨团队。其实主要取决于你现在有多少事实数据。
研发产能 = 需求个数 * 平均周期时间
每一次需求发布上线，平均周期时间都会发生一次变化，所以如果采用的是所有的历史平均成本的话，又可以称之为移动平均法。平均法的优点是计算简单，缺点是如果团队发生较大的变化，平均周期时间会不准确，比如说，三个月前是大版本制，需求的周期时间全是三个月，现在是两周一迭代了，平均一下，还是两个月，难以及时捕捉改进。所以就有了接下来的方法。
先进先出法 FIFO - First in, first out
制定一个评估时间段，将这个时间段开始的部分的平均周期时间作为计算因子。
研发产能 = 需求个数 * 初期平均周期时间
举个例子，某公司从2019年7月开始改进，希望在三个月内看到效果。根据先进先出法：
- 在2019年7月，取2019年5月的平均周期时间作为因子计算研发成本
- 在2019年8月，取2019年6月作为因子计算研发成本，以此类推……
- 在2018年9月，因为计算因子是2019年7月，就可以评估改进的效果了。
后进先出法 LIFO - Last in, first out
与先进先出法不同的地方是，取评估周期的末期，即与当期最近的一个时间段作为计算因子。
研发产能 = 需求个数 * 末期平均周期时间
例：在2019年7月，取2019年6月的平均周期时间作为因子计算研发成本。后进先出法能够更及时地发现改进，但缺点是时间太近，可能改进真的不明显，也不太能说明问题。
个别辨认法 SI - Specific identification
个别辩认法是针对每个需求都统计出周期时间然后相加。
研发产能 = Sum(需求周期时间）
这种方法适用于在每个周期内完成的需求数量少、需求颗粒度大，并且特别不衡量的情况。比如刚开始改进时，7月，当期就可以采用个别辨认法，对每个需求的周期时间进行统计和计算。例：7月共完成3个需求，周期时间分别是12天、18天、24天，那么研发产能就是54天。
这时候可能很多读者会问了，如果需求个数 * 周期时间等于产能，那是不是需求个数等于周期时间的时候，团队的产能利用就达到最大化了？团队是不是可以轻易地作弊了？还有就是，如果我们缩短了周期时间，那在这个计算公式里，产能岂不是下降了？以下我们就来求解一下。
关于产能公式的评估
比如某团队利用FIFO方法评估，初期周期内交付n个需求，周期时间为t，现在周期时间缩短为 t-x，那么如何评估产能是上升还是下降了呢？我们先假设产能不变，即：
nt = n'(t-x) => n' = nt/(t-x)
即在缩短周期时间的情况下，如果团队保持现有产能不变，应交付 nt/(t-x) 个需求。那么就分为以下三种情况：
- n' < nt/(t-x) 说明团队产出有所下降，需求变小了，但交付容量没有增加
- n' == nt/(t-x) 说明团队产能未有改善，需求多做了一些，但每个需求更小了
- n' > nt/(t-x) 说明团队的产能提升了，需求不但做得快，而且做得更多了
举个例子，团队过去做 5 * 30 个需求量，现在做 5 * 20 个需求量，产能是下降了；但现在做 10 * 20 个需求量，产能是增加了。当团队达到 15 * 15 = 225 的“近似最大化”时，不代表就无法改进了，因为 16 * 15 = 240 就叫产能提升。
精益模式下的度量升级
简单说，敏捷看节奏，精益看流动效率——不止是速率，还要看浪费。度量公式升级如下：
研发成本 = 需求个数 * 周期时间 - 浪费
浪费的计算为每个需求在周期时间内的间隔等待时间超过1天的累计自然日。比如说某个需求在等待状态下停留了2天，浪费时间为 2-1 = 1 天。
X-Developer对浪费的计算是代码提交间隔超过1天的累计自然日，比如说9月1号提交了代码，9月2号未提交，9月3号提交了，累计浪费计为0；如果9月3号也未提交，累计浪费就开始计为1，以此类推。这种计算方式的好处是，不但捕捉到真实的研发活动数据，而且可以加快真正的持续集成节奏。因为只有代码被提交到仓库，集成部署才可能开始工作，可交付的软件这时才被构建出来——无提交，无产出。
这一产能度量的方法是场量科技首创（如有雷同，实属巧合），也在X-Developer商业版中率先实施。在社区版的应用中，我们发现许多团队都尚未实施最基本的代码提交规范（注释中包含需求编号），希望能够实施起来，因为这不但是众多大厂（微软、Google、Facebook、阿里……），也是许多开源项目（Jenkins、Spark……）的基本规范，它不但可以帮助团队缩短解决问题的时间（快速回溯需求到代码），还可以在数据驱动的时代给予科学的反馈与指导。
场量科技是一家专注于产品创新与效能优化的平台服务商，我们基于十余年的知名企业咨询经验，围绕产品创新提供工具与数据分析平台，并帮助企业优化产品研发效能。
