品读经典，敏捷文化。大家好，我是吴舜贤。
今天我们继续关于度量指标的话题。第9章给大家讲了很多关于度量和度量指标的内容，但可惜的是，作者并没有在正文中特别指出常用的度量指标。
在《敏捷文化》的附录部分，作者将度量指标分了三个层级，并列举了一些常见的度量指标。我们就来看一看具体都有哪些度量指标。
度量指标的三个层级
好的度量指标有利于把精力集中在实际效果上，可以推动有效的改进，而不当的指标会使团队停止改进工作，把重点放在无益于增加交付价值的活动上。
在组织、项目和团队中，可以在许多方面使用度量指标，确保指标提供有用的信息，促进有效的行动，同时又不会产生障碍。选择的实际指标要根据实际情况而定。
常用的度量指标主要包括如下三个层级：
1. 内部度量指标
2. 企业度量指标
3. 外部度量指标
1. 内部度量指标
内部度量指标主要在团队和项目内部用来度量和改进工作，主要在软件开发交付周期内进行收集。因此，交付团队要尽可能地实时处理这些信息。
内部度量指标的度量周期越短越好。
内部度量指标的使用中，要考虑收集和分析指标数据的实际成本。比如，为了加强早期的缺陷分析，一些团队在问题跟踪系统中记录开发人员用单元测试所发现的缺陷，这会对团队的工作效率产生巨大的影响，但这么做基本不会产生有用的实际价值。
内部度量指标主要在部门、项目或团队内部使用，它有利于团队层面采取实际行动。
有效的内部度量指标包括：技术债务、测试覆盖率(路径或分支代码)和正交缺陷分类等。
而不当使用内部度量指标的情形有：
1. 将迭代速度作为一个团队的绩效指标，而不是仅评估项目的进度。
2. 连续使用因果关系分析方法，使团队付出高昂的代价。
3. 单元测试缺陷跟踪容易导致无用工和官僚作风。
2. 企业度量指标
企业度量指标是指用于评估企业经营或战略有效性的度量指标。不同于内部指标，企业度量指标是跨团队的，不能用于团队层面，以免产生误导。
企业度量指标的周期时间通常比内部指标更长。
作者举了一个例子。某公司需要评估他们的软件开发团队的效率，希望了解技术和流程投资的有效性。
他们把度量的重点放在每个程序员每月所写代码的行数和每行代码的成本上。他们最初的设想是找出代码和客户价值之间的正比关系。由于这些指标颇具争议，使用不当会造成不良行为，所以在收集和使用这些数据时要格外小心。他们的做法是，直接从开发库收集数据，横跨整个业务领域，按目标平台进行平均。
收集的原始数据包括以下几种：
1. 库里不重复的代码行数。用这个指标评估开发团队创建代码的速度。平台软件和产品软件的代码分开统计。这个指标较好体现了工具开发、培训和流程改进的投资有效性。
2. 多次重用的代码行数。用来评估代码重用对商业价值的贡献。结果清楚表明，这个指标是迄今为止最有效的方法，用于衡量团队是否在不断为客户提供价值。
3. 支持库中的代码行数。这解释了售后支持的发展趋势和现有客户的产品升级策略。由于在不同的软件层次上支持客户的需求，这个数据的增长最快。
4. 整体开发人员、运维支持人员和其他费用。这表明企业各类活动的整体生产力和效果。
该公司利用这些数据揭示了多个项目多年的趋势，以此验证和指导了在开发过程和基础设施上的投资。此外还发现，每个开发人员开发的不重复代码行数基本趋于平稳，但评估的商业价值趋向于大幅提升，这说明每个开发人员的生产力趋于稳定，但产出的价值不断提高。
因此，作者的结论是，谨慎使用指标而不做表面文章，即使是有争议的度量指标，也可以产生良好的效果。
合理的企业度量指标包括：
1. 汇总的所有管理人员的净推荐值，评估他们对其开发团队的支持程度。
2. 平均周期时间，评估企业交付产品的平均周期。
3. 产生盈利的可能性。
不合理企业度量的情形
1. 在团队层面统计每个开发人员所写的代码行数。
3. 外部度量指标
外部度量指标是指企业外部对产品或企业能力的度量，用以了解市场对产品或企业能力的反应。
比如，常见的度量指标是已售出的解决方案或产品的净推荐值、企业信任指数员工调查等。
其中的企业信任指数员工调查，由Great Place to Work每年组织，调查许多公司并评估公司员工感受到的信任程度。他们分析和整理这些数据，发布在年度报告中。
该调查具有很高的诚信度，揭示了企业的信任指数与其经营业绩之间的紧密关系。
合理的外部度量有产品的净推荐值。
外部度量不合理的例子有：
1. 在销售人员在场时完成客户满意度调查，无法得到真实满意度。
2. 横跨几个产品的净推荐值，所得数据对单个产品没有任何行动和指导意义。
常见的度量指标
作者打心眼儿里不愿意指点别人应该使用什么指标。我猜测原因可能有如下几个方面：
1. 避免产生误导。因为一旦你明确指出了某个度量指标，本身就表明你推荐使用这个度量指标。但如何有效使用具体指标，要具体情况具体看。
2. 度量指标有适用周期，一旦取得效果，就要考虑重新评估和调整。我们常犯的错误是，不能经常评估和调整所使用的度量指标。
3. 度量指标不宜太多。如果作者指出各个方面的度量指标，则数量会比较多，人们会觉得无所适从。
但不管怎么样，我们还是需要一些指标，以便于合理选择、有效使用这些指标来为项目、组织和团队提供指导。
所以，作者在附录部分列举了一些度量指标。我不打算一个一个给大家讲解，因为有些指标的含义显而易见，所以大家可以认真读一下这个指标列表。
企业对产品交付的支持程度的度量指标：
1. 企业净推荐值
2. 管理净推荐值
3. 会议净推荐值
预测项目进展的度量指标：
1. 看得见的价值，即完成了多少功能
2. 故事点燃尽，即完成了多少故事点
3. 功能点交付，即交付了多少功能点
交付质量及技术债务方面：
1. 每次迭代结束时记录的缺陷，特别是严重程度为1和2的缺陷
2. 未修复的严重程度为3和4的缺陷
3. 单元测试或回归测试的代码覆盖率
4. 运行成功的测试用例
5. 正交缺陷分类
对无意义开发的度量
1. 软件构建过程的中断次数
2. 模块等待集成的时间
开发过程有效性和改进的度量
1. 按时完成迭代的情况
2. 完成反思行动的情况
3. 用户故事顺延到下一个迭代的情况
4. 需求完成的周期时间
5. 价值流量图
实践的可信度度量
1. 实践措施的净推荐值
客户对产品的态度
2. 产品净推荐值
商业效率的度量
1. 整个周期时间
2. 达到收支平衡的时间
3. 获利时间
4. 利润和损失
5. 投资回报率(ROI)
5. 净现值(NPV)
6. 利益干系人的净推荐值
7. 等等。。。。。。
企业文化的度量指标
1. 从失败中学习
2. 承担风险
3. 创新
4. 跨职能团队的可用性
5. 在成功项目中全体成员的参与情况
6. 信任度
对管理的度量
1. 员工人数与企业人力资源的百分比
2. 员工人数与交付的产品
以下是要尽量避免的指标使用情况：
1. 把速度作为团队效率的指标
2. 把技术债务作为团队能力的指标
3. 鼓励英雄行为
4. 以故事点为工作时间，或者以工作时间为故事点
小 结
我们以附录E部分所列的度量指标为主，分析了三个层级的度量指标，即内部度量指标、企业度量指标和外部度量指标。
然后列举了常见的一些度量指标。这些指标在不同的场景下合理使用会产生不错的效果，但不合理的使用也会导致严重的后果。所以，需要认真分析每一个度量指标的具体含义、使用场景和限制措施。
问题来了
最后，和大家一起来思考几个问题：在你的组织里，
1. 经常使用哪些内部度量指标、企业度量指标和外部度量指标？
2. 这些度量指标的使用，为你们带来了哪些实际的效果和益处？
3. 除了已经列举的度量指标，还有哪些度量指标？为什么要选择这些度量指标？
用户评论