下载掌阅APP，畅读海量书库
立即打开
企业是如何衡量开发者效率的？最常见的方法是通过工作量来衡量。曾经有一些企业使用诸如代码行数或代码测试覆盖率之类的度量标准，但这些显然是不好的选择，不知道现在还有哪些企业在这么做。如果可以通过1行代码或100行代码解决一个问题，那么1行显然更可取，因为每一行代码都有维护成本，代码测试覆盖率也是如此。覆盖率本身并没有说明测试的质量，而且糟糕的测试还会带来额外的维护成本。
本书尽量保持用词与开发模式无关。作者见过采用DevOps实践的企业，包括敏捷模型、Scrum模型、 规模化敏捷框架（SAFe） 、看板和瀑布法等。但每个系统都有自己的术语，作者尽量保持中立。例如，本书使用“需求”，而不是“用户故事”或“产品待办事项”，但本书使用的大多数示例都是基于Scrum的。
衡量开发者效率的最常用方法是估计需求。将需求分解成小的项目（例如用户故事），然后由产品经理评估业务价值。接下来开发团队评估故事，并对其工作量估测出一个值。不管使用的是故事点、小时、天还是其他数字，基本上都是交付需求所需工作量的表示。
如果读者将这些数字报告给管理层，那么用估计的工作量和业务价值来衡量效率可能会产生副作用。这会存在某种观察者效应：人们试图提高数值。在以工作量和业务价值为衡量标准的情况下，人们很容易为“故事”分配更大的数字。这是通常会产生的情况，特别是在比较不同团队的数值时：开发者将为“故事”分配更大的数值，产品经理将同时分配更大的业务价值。
虽然这不是衡量开发者效率的最佳方法，但如果在开发团队和产品经理之间的日常交流中进行评估，也没有太大的危害。但是，如果评估过程是在正常的开发过程之外进行的，这甚至可能是有害的，并会产生非常大的副作用。
对于实现更大的功能或计划，“成本是多少？”这个问题的答案通常会在正常开发过程之外进行评估，并在决定实施之前进行完善。但是如何评估一个复杂的功能和计划呢？
在软件开发中所做的一切都是全新的。如果软件已经开发完成，可以直接使用该软件而不是重新编写它，那么即使是完全重写现有模块仍然是全新的工作，因为使用了新的架构或新的框架。从未做过的事情只能以有限的确定性来估计。这是一种猜测，而且复杂度越大，不确定性也越大（见图1-2）。
图1-2 不确定性
不确定性锥形图经常用于项目管理，使用前提是在项目开始时，成本估计具有一定程度的不确定性，但随着计划的不断进展而降低，直到项目结束时为零。 x 轴通常是所花费的时间，它也可以与问题的复杂性和抽象性有关，需求越抽象越复杂，估计中的不确定性就越大。
为了更好地估计复杂的功能或计划，可以将其分解为更便于估计的部分，并且需要提出一个解决方案架构，作为工作分解的一部分。由于这是在正常的开发过程之外完成的，而且时间上也超出了预期，因此它有一些不必要的副作用，例如：
●一般情况下，开发团队不可能全员在场。这会导致沟通多样性降低，从而在解决问题时创造力会下降。
●重点是发现问题。事先能够发现的问题越多，估算可能就越准确。特别是以后如果把估算作为衡量绩效的标准，人们很快就会发现只要提出更多的问题，就可以获得更多的时间用来拖延，甚至也可以为需求虚增更高的估算。
●如果有疑问，负责估算任务的工程师就会采用更复杂的解决方案。例如，如果不确定是否可以用现有的框架解决问题，他们可能会考虑编写自己的解决方案，以防万一。
如果管理层仅使用这些数字来决定是否去实现某个功能，则不会造成太大的损害。但是一般情况下，需求（包括评估和解决方案体系结构）不会被丢弃，或者稍晚才会进行功能实现。在这种情况下，还有一个创造性稍低的解决方案，它是针对问题而不是解决方案进行优化的，这不可避免地会导致在实现功能时缺乏创造性和创造性思维。
评估并不是一件坏事，如果应用在正确的场合，它会很有价值。如果开发团队和产品经理讨论下一个用户故事，评估可以有助于推动交流。例如，如果团队使用“扑克规划”评估用户故事但是评估结果不一致，表明人们对如何实现它有不同的想法。这可能引发有价值的讨论，并可能更有成效，因为可以跳过一些具有共识的讨论。对于业务价值来说也是如此。如果团队不理解为什么产品经理分配了一个非常高或者非常低的估计数字，这也可能引起重要的讨论。也许团队已经知道如何取得成功的结果，或者在不同角色的感知上存在差异。
但是很多团队在完全不评估需求的情况下会感觉更合适。特别是在高度实践化的环境中，评估通常被认为是浪费时间的行为。远程和分布式团队通常也不喜欢进行评估，他们经常会进行面对面的会议或发起关于问题和Pull Request的讨论。这有助于记录交流过程，并帮助团队以更异步的方式工作，这也有利于跨越不同时区的开发者进行协作。
不讨论开发者开发效率的情况下，开发团队应该被允许自行决定是否需要进行评估。这也可能随着时间的推移而改变。一些团队从中获得价值，而另一些则没有，让团队决定什么对他们有效，什么无效。
评估更复杂的功能或计划的最佳方法是什么，以便产品负责人可以决定这些是否值得实现？可以召集整个团队成员，询问以下问题：这能在几天、几周或几个月内完成吗？另一个选择是使用类比估计，并将计划与已经交付的产品进行比较。接下来的问题是：这个计划是比之前交付的产品更容易，还是更复杂？
最重要的是所有工程师的直觉，而不是分解需求或预先制定解决方案架构。然后，让每个人为单元分配一个最小和最大的数值。对于类比估计，使用相对于原始计划的百分比，并使用历史数据计算结果。
最简单的报告方法如下所示：
目前的团队，
如果我们优先考虑“项目名称”的项目，
该团队有信心在“最小值”和“最大值”之间交付功能。
取最小值和最大值是最安全的方法，但如果悲观值和乐观值的估计相差太远，也可能导致数字失真。在这种情况下，取平均值可能是更好的选择，如下所示：
目前的团队，
如果我们优先考虑“项目名称”的项目，
该团队有信心在“平均最小”和“平均最大”之间交付功能。
但是取平均值（算术平均值，在Excel中使用=AVERAGE（））意味着存在更高或更低的偏差，这取决于单个估计的分布。偏差越高，越不能相信可在此期间交付该功能。要了解估计值是如何分布的，可以计算标准偏差（在Excel中使用STDEV.P（）），查看最小值和最大值的偏差，也可以查看每个成员的估计。偏差越小，说明数值越接近平均值。由于标准差是绝对值，因此不能与其他估计进行比较。要得到一个相对的数字，可以使用 变异系数（CV） ：用标准偏差除以平均值，通常以百分比表示（在Excel中使用STDEV.P（）/AVERAGE（））。数值越高，说明数值越偏离平均值；数值越低，说明团队成员对他们的估计或整个团队对最小值和最大值的估计越有信心。示例如表1-1所示。
表1-1 计算评估的例子
为了表示估计值偏差的不确定性，可以添加一个置信度指标。使用文本（例如低、中或高）或百分比级别，如下所示：
目前的团队，
如果我们优先考虑“项目名称”的项目，
该团队有“信心程度”的信心在“算术平均值”内交付功能。
在这里没有使用固定的公式，因为这需要根据团队实际情况确定。从例子中的数据（见表1-1）我们发现最小值平均2.7和最大值平均6.3相差不大。如果观察单个团队成员，会发现有更悲观和更乐观的成员。如果以前的估计证实了这一点，那么即使最小值和最大值的CV值非常高，也可以非常自信地认为平均值是真实的。那么估计可能是这样的：
目前的团队，
如果我们优先考虑新奇计划项目，
该团队有85%的信心在4.5个月内交付功能。
这种估计不是什么高深的科学。它与复杂的估计和预测系统没有关系，例如三点估计技术（https://en.wikipedia.org/wiki/Three-point_estimation）、PERT分布（https://en.wikipedia.org/wiki/PERT_distribution）或蒙特卡罗模拟方法（https://en.wikipedia.org/wiki/Monte_Carlo_method），它们都依赖于需求的详细分解和对任务（工作）级别的估计。这个想法是为了避免提前计划和分解需求，更多地依赖于工程团队的直觉。这里的技术只是用于了解自己在整个团队中收集的数据点。这还只是猜测。
在跨职能团队中，工作量并不是衡量开发者效率的一个很好的指标，尤其是如果基于估计，而且速度不仅仅取决于开发者。那么，如何从开发者效率转变为工程效率呢？