PDFDevOps 指标
您最大的错误可能是收集了错误的数据。
Nicole Forsgren 博士，Mik Kersten 博士
“软件正在吞噬世界。” ——马克·安德森
“你无法管理你没有衡量的东西。” ——彼得·德鲁克
来自各行各业的组织都在拥抱软件，将其作为向客户交付价值的一种方式，我们看到软件正在推动传统科技行业以外的创新和竞争力。
例如，银行不再以在保险箱中隐藏金条而闻名：相反，金融行业的公司正在竞相利用软件来争夺市场份额。通过使用创新的应用程序，银行使其客户只需滑动几下即可完成大部分日常银行业务，从存入支票到在银行账户之间安全地转移资金。此外，银行本身可以通过多种方式改进其服务，例如使用预测分析来检测欺诈交易。其他行业也看到了类似的变化：汽车现在是轮子上的计算机，甚至美国邮政总局也正处于大规模的 DevOps 转型之中。软件无处不在。
领导者必须拥抱这个新世界，否则就靠边站。Gartner Inc. 预测，到 2020 年，一半尚未转变其团队能力的首席信息官将被排除在其组织领导团队之外。正如每位优秀的领导者都知道的那样，你无法改进你没有衡量的东西，因此衡量软件开发过程和 DevOps 转型比以往任何时候都更加重要。
通过软件向业务交付价值需要跨越复杂系统的多个团队的流程和协调，并且涉及开发和交付兼具质量和弹性的软件。作为从业者和专业人士，我们知道软件开发和交付是一门日益困难的艺术和实践，并且管理和改进任何流程或系统都需要对该系统有深入的了解。因此，衡量对于创建有效的软件价值流至关重要。然而，准确的衡量并非易事。
衡量 DevOps
收集可以提供跨软件交付管道洞察力的衡量指标是困难的。数据必须完整、全面和正确，以便团队可以关联数据以推动业务决策。对于许多组织来说，采用最新的最佳敏捷和 DevOps 工具使这项任务变得更加困难，因为组织内记录保存的多个系统激增。
跨组织软件交付数据的主要来源之一是年度 DevOps 状态报告（可在 https://devops-research.com/research.html 找到）。2 这项行业范围的调查提供了证据，表明软件交付在高绩效技术驱动型组织中发挥着重要作用。该报告概述了技术、流程和文化领域的关键能力，这些能力有助于软件交付的绩效，以及这反过来如何促进员工福祉、产品质量和组织绩效等关键成果。
在基于调查的研究的支持下，组织开始使用调查数据来衡量他们自己的 DevOps “准备度”或“成熟度”。虽然这种类型的数据可以提供关于 DevOps 可以在团队和组织中发挥的潜在作用的有用观点，但危险在于组织可能会盲目地应用调查结果，而不了解这种方法的局限性。
另一方面，一些组织完全批评基于调查的数据，而是尝试仅使用系统数据来衡量或评估他们的 DevOps 准备度或成熟度。这些组织正在基于存储在其存储库中的系统数据创建指标，他们也可能不了解该方法的局限性。
通过了解这些局限性，从业者和领导者可以更好地利用每种方法的优势。本文总结了衡量软件价值流的两种独立但互补的方法，并分享了混淆这两种方法的一些陷阱。这两种方法定义如下
• 调查数据。使用调查措施和技术，提供价值流的整体和定期视图。
• 系统数据。使用基于工具的数据，提供价值流的持续视图，并限于自动收集和关联的内容。
互补的方法
仅靠系统数据或仅靠调查数据都无法衡量现代软件交付管道的有效性。两者都是需要的。互补的衡量方法可以为组织提供更完整的开发和运营环境图景，解决每种方法的关键差距，并为组织提供他们开发和交付具有竞争力的软件所需的信息。
作为一个类比，考虑制造商如何跟踪复杂装配线的效率。每个步骤的仪器仪表提供关于每个阶段和端到端系统中的流速和缺陷率的数据。用装配线员工的调查数据来增强它可能被证明是无价的——例如，发现新部署的协作机器人给员工带来的身体压力比机器人供应商承诺的要大。
在更高的缺陷率、更低的员工调查分数，甚至诉讼出现之前捕获这些信息可能被证明是无价的。在这个例子中，调查数据为系统数据提供了领先指标，或者提供了系统数据可能根本不会透露的见解。虽然装配线制造在指标和数据收集方面非常成熟，但在如何衡量软件交付方面，行业共识严重缺乏。这意味着这种实践仍处于起步阶段。（请注意，这可能与领域本身的相对成熟度有关：制造学科已经存在很长时间了，因此那些研究和衡量它的人已经有几十年的时间来完善他们的技艺；相比之下，软件工程是一个相对年轻的领域，使其衡量研究成熟度要低得多。）因此，对于组织来说，了解他们可以通过哪种方法衡量什么以及不能衡量什么，以及他们需要采取哪些步骤来了解其软件交付价值流至关重要。
通过作者在收集调查和系统数据方面的数十年集体研究和经验——并通过与数百家全球组织的数十名专家的深入讨论得到证实，这些专家将软件价值流衡量作为其数字化转型的关键部分——本文概述了理解您开发和交付软件能力所必需的措施。
立即开始构建基线
有几个原因表明，系统数据和调查数据都应该用于衡量定义您的软件交付流程的价值流。其中最重要的原因是，大多数组织似乎几乎看不到或没有对其软件交付实践的可靠衡量。
组织越早开始衡量，基线就建立得越早，并且可以用于衡量相对改进。对于小型组织来说，将系统指标作为初始基线可能很容易。例如，一个 20 人的创业公司可以使用诸如 Jira 之类的问题跟踪器来衡量 MTTR（平均修复时间）。然而，大型组织将需要包括服务台和潜在的其他计划系统，以便确定该基线，并且可能尚未实施提供跨系统可见性的工具。我们建议立即开始基线收集，对于许多组织来说，这将意味着在努力捕获和关联系统数据的同时收集调查数据。
在缺乏完整的系统衡量的情况下，全面的调查可以相对快速地（即在几周内）提供系统的整体视图。将此与系统指标提供的系统完全可见性进行对比。获得端到端系统数据可能是一个漫长的过程，因为您首先需要在系统之间部署衡量解决方案，然后确保跨系统集成到位，以便可以正确关联数据。现代价值流指标正在使这变得更容易，但对于许多组织来说，这是一个多年的项目。
虽然尽早开始以获得系统数据的好处非常重要，但部署调查数据几乎可以立即提供价值和基线信息来源。这对于基准化当前和未来的调查数据，以及在系统数据到位后将调查数据与系统数据进行比较都很有价值。因此，最好现在使用调查措施捕获系统基线，同时继续构建基于系统的指标。
一旦您完全配备了基于系统的指标会发生什么？您可以继续使用基于调查的指标来增强和捕获独特适合调查方法的其他数据。
仍然有一些对软件交付很重要的衡量指标，例如文化衡量指标，基于调查的衡量指标会捕捉到，而基于系统的指标可能会遗漏。此外，同时拥有两种类型的指标为三角测量提供了机会：如果您的调查指标提供的数据与来自您系统的数据截然不同，这可以突出系统中的差距。
有些人可能会说这样的差距只是“人们撒谎”的领域，但如果所有与系统密切合作的人都在撒谎，您可能需要将他们的经验视为真实的数据点。如果您的工程师始终报告构建时间过长，而系统数据报告构建时间过短，这可能是 API 中的配置错误吗？或者可能是基于系统的衡量指标仅捕获了部分数据？如果不持续收集来自与您的系统合作的专业人士的见解，您将错过看到全貌的机会。本文的其余部分概述了每种衡量类型的优缺点。
基于系统的指标
基于系统的指标通常指的是来自构成端到端软件交付价值流的各种记录系统的数据。此数据的重要方面包括
• 完整性。从特定记录系统（例如敏捷工具）捕获的数据是否足够完整，以提供作为计划目标的可见性、指标和报告类型？例如，如果展示更快的上市时间是目标，是否捕获了足够的历史数据来推导出新产品和功能交付速度的趋势线？
• 全面性。是否跨所有记录系统捕获了足够的数据？例如，为了衡量客户请求的上市时间，您可能需要来自客户/支持跟踪系统、路线图/需求系统、敏捷工具和部署工具链的数据。
• 正确性。数据是否充分关联以确保正确性？例如，如果支持工单和缺陷实际上是同一个项目，但存在于两个不同的系统中，是否应该以某种方式集成这两个系统以表明它们是同一个项目，或者您是否冒着在这种情况下重复计算缺陷的风险？
系统数据优势
• 精确性。只有系统生成的数据才能准确显示分钟、秒和毫秒级的响应时间。
• 持续可见性。系统生成的数据特别适合持续/流式数据和实时报告。您只需将其指向数据存储并收集所有内容以供以后进行有针对性的分析。
• 粒度。来自系统的数据可以提供非常精细的数据，允许您报告子系统和组件。这对于识别趋势和瓶颈很有用，但需要额外的努力来创建完整系统的更高级别图景。数据越精细，绘制完整图景所需的工作就越多。
• 可扩展性。一旦实施了集成和可见性基础设施，就可以将其指向所有系统。这意味着该解决方案可以从获得单个项目的可见性扩展到获得数十个或数百个项目以及大量数据的可见性。
用一个类比来说明：在建造房屋时，承包商可能会使用混凝土作为地基；木材/钉子/螺丝/石膏板用于墙壁；布线和管道；砖用于外墙；油漆/地毯用于装饰；加上厨房和浴室的任何材料。为了跟踪和监控进度，您在房屋建造过程中构建监控以跟踪构造的每个部分并安装它。一旦安装完成，这个基础设施（特定数据）的每一部分都可以持续提供亚秒级间隔（精确度）的报告和指标（连续数据）。然后，您可以组合和关联（数量和规模）这些内容，以创建房屋中正在发生的事情的完整图景。
系统数据挑战
• 捕获系统之外的行为。这可能是基于系统的数据中最重要但最容易被忽视的限制。一个例子是版本控制：您的系统只能告诉您其中的内容。正在完成的工作中有多少没有被签入版本控制系统？常见的罪魁祸首包括系统配置和数据库配置脚本。
• 获得整体视图。最终，系统级数据可以提供系统的相对完整视图，但这需要完整的仪器仪表，加上跨度量的关联以及报告和可视化技术的成熟度，以便团队可以了解系统状态。这是一项不小的任务，尤其是在没有正确的工具和基础设施到位的情况下进行。此外，整体视图应包括流程的人工方面，例如部署和软件冲刺的难度，这对于理解工作的可持续性非常重要。
• 捕获系统中的漂移。如果您系统堆栈的任何部分发生更改并且您的数据收集器未更新，则您对系统的视图将不准确。请注意，这不是一流数据报告解决方案的特征，但它发生在某些商业系统和许多自制解决方案中，因此值得一提作为需要注意的条件。
• 文化或感知度量。如果您想衡量文化的各个方面，这些是感知性的，应该通过调查来衡量。此外，任何来自系统数据库（例如人力资源系统）的度量通常都不能很好地代表您试图收集的数据，并且将是滞后指标。也就是说，他们只能在某件事发生后才能衡量它（例如有人离开团队或组织）。相比之下，调查措施可以让您及时衡量对文化的看法，以便根据信息采取行动。
基于系统的指标很有用，但它们无法完整描绘出您的软件交付工作正在发生的事情。因此，强烈建议您使用互补的调查措施来增强您的指标。
基于调查的指标
基于调查的指标通常指的是关于系统和人员（例如文化）的数据，这些数据来自调查。理想情况下，这些调查会发送给那些在系统本身上工作并且非常熟悉软件开发和交付系统的人员——即执行者。团队最好避免调查管理层和高管，因为正如 Forrester 最近的一项研究表明，高管往往会高估其组织的成熟度。3
此数据的重要方面包括
• 内聚性。基于调查的数据特别擅长提供系统的完整和整体视图。这是因为它可以捕获关于系统、流程和文化的信息。定期且以有规律的间隔（每四到六个月）衡量您的系统。
• 正确性。调查设计和衡量是一个公认的学科，可以利用它来提供关于系统和文化的良好数据和见解。通过使用精心设计的调查，其中包含经过严格开发和测试的、在统计上有效且可靠的调查问题，组织可以对其调查数据充满信心。
调查数据优势
• 准确性。当正确收集时，调查数据可以提供关于系统、流程和文化的准确见解。例如，您可以通过询问团队关键任务以自动化或手动方式完成的频率来衡量系统能力。当设计正确时，这提供了一种快速而准确的衡量方法，可用于基准化和指导改进工作。
• 系统的整体视图。调查特别擅长捕获系统的整体图景，因为受访者提供的答案综合了与自动化、流程和文化相关的数据。
• 与系统数据进行三角测量。调查数据提供了系统的另一种视图，允许您在存在两种对比视图时识别问题或错误。当这种情况发生时，不要自动否定您的调查措施：通常情况下，配置或系统行为的更改会改变系统数据的收集方式，而调查措施保持不变——只有这两种措施的差异才会引起对底层系统中更改的注意。
• 捕获系统之外的行为。在系统数据的讨论中，版本控制被用作一个例子，说明如果仅从您的系统收集数据，数据将是不完整的。您可以通过使用调查来更全面地了解系统内部和周围正在发生的事情。例如，是否存在绕过版本控制的情况？
• 与系统相关的文化或感知度量。调查数据提供了对做这项工作的感觉的见解：组织文化、工作满意度和倦怠是工作节奏可持续性和招聘/保留的重要领先指标。研究表明，良好的组织文化可以推动软件交付和组织绩效2，而工作满意度可以提高收入1。主动（通过调查数据）而不仅仅是被动（通过人力资源数据库中的离职率指标）监控这些应该是所有技术经理和高管的优先事项。
让我们回到房屋类比。当使用系统数据时，您可以从报告的系统的每个部分获得详细信息。当通过调查问题询问人们时，这种详细程度是不可能（或不现实）的——但是您可以非常快速且轻松地全面了解您的系统或其组件正在做什么。例如，您可以可靠地确定房屋是否处于良好状态：任何人都可以报告房屋是否着火、房间是否脏乱或烟雾弥漫，或者事件是否造成损坏。收集这些数据所需的时间比仪器仪表化然后关联和综合数百或数千个数据点所需的时间要快得多。如果您的调查和系统措施不一致，您就有充分的理由开始调试系统。
调查数据挑战
• 精确性。虽然您可以向从业者询问大致情况，但不应依赖他们提供详细或具体的信息。当您询问部署频率时，您的调查选项以对数刻度增加：人们通常可以告诉您他们是否按需、每周、每月、每季度或每年部署软件。这些频率很容易通过基于系统的指标来确认（当可用时——尽管这是一个从系统中获取的非平凡指标，因为它需要从部署管道中的多个系统获取数据）。
• 数据的连续性。要求人们频繁地填写调查会让人感到疲惫，而调查疲劳是一个真正的问题。最好限制通过调查收集大数据的频率——例如，每六个月左右一次。
• 数量。您收集的数据量与您收集数据的频率有关。经验告诉我们，调查应保持在 20-25 分钟（或更短）以内，以最大限度地提高参与度和完成率。也有一些值得注意的例外：亚马逊著名的开发者调查每年推出一次，大约需要一个小时才能完成，但工程师们对结果非常感兴趣和投入，因此他们花时间完成了调查。
• 紧张环境中的衡量。如果管理层非常明确地表示，诚实是不安全的，或者结果将用于惩罚团队，那么任何调查答复都将是可疑的。引用已故的 W. Edwards Deming 的话：“哪里有恐惧，哪里就会有错误的数据。” 但是，公平地说，基于系统的指标在不安全和充满恐惧的环境中同样可疑，甚至可能更可疑。为什么？因为只需要一个拥有根访问权限的人在系统中插入一个恶意指标，以及一个疲惫的人在同行评审或 CAB（变更审批委员会）中错过它（正如我们这些看过邪典经典电影《上班一条虫》的人可以证明的那样）。相比之下，需要几个或几十个或数百个人来大规模歪曲调查结果。
结论
软件正在推动全球各行各业的组织的价值。为了帮助更快地交付价值、质量和可持续性，公司正在进行 DevOps 转型。为了帮助指导这些困难的转型，领导者需要了解技术流程。
这个过程可以通过良好的衡量计划来阐明，该计划允许团队成员、领导者和高管了解技术和流程工作、计划计划并跟踪进度，以便组织可以向主要利益相关者展示投资的价值。基于系统的指标和基于调查的指标各自都有固有的局限性，但是通过在互补的衡量计划中同时利用这两种类型的指标，组织可以更好地了解其软件交付价值链和 DevOps 转型工作。
参考文献
1. Azzarello, D., Debruyne, F., Mottura, L. 2012. 热情的化学反应. 贝恩公司； http://www.bain.com/publications/articles/the-chemistry-of-enthusiasm.aspx。
2. DevOps 研究与评估。 2014 年、2015 年、2016 年和 2017 年 DevOps 状态报告； https://devops-research.com/research.html。
3. Stroud, R., Klavens, E., Oehrlich, E., Kinch, A., Lynch, D. 2017. 危险的脱节：高管高估了 DevOps 成熟度。 Forrester。
相关文章
在质量保证中采用 DevOps 实践
融合软件开发的艺术与科学
James Roche
https://queue.org.cn/detail.cfm?id=2540984
工程师统计学
将统计技术应用于运营数据
Heinrich Hartmann
https://queue.org.cn/detail.cfm?id=2903468
响应型企业：拥抱黑客之道
很快每家公司都将成为软件公司。
Erik Meijer 和 Vikram Kapoor
https://queue.org.cn/detail.cfm?id=2685692
Nicole Forsgren 是 DevOps 研究与评估 (DORA) 的联合创始人、首席执行官兼首席科学家。她以衡量技术流程的工作以及迄今为止最大规模 DevOps 研究的首席调查员而闻名。她曾担任教授、系统管理员和性能工程师，她的作品已在多家同行评审期刊上发表。Nicole 获得了亚利桑那大学管理信息系统博士学位，并且她是克莱姆森大学和佛罗里达国际大学的学术合作伙伴。
Mik Kersten 是 Tasktop 的创始人兼首席执行官，并推动公司的战略方向和以客户为中心的创新文化。在 Tasktop 之前，Kersten 启动了一系列开源项目，这些项目改变了软件开发人员的协作方式。作为施乐帕克研究中心的科研人员，他创建了第一个面向方面的开发环境。他获得了不列颠哥伦比亚大学计算机科学博士学位，他的研究兴趣集中在价值流架构上。
版权所有 © 2017，所有者/作者持有。出版权已许可给 。
最初发表于 Queue 第 15 卷，第 6 期—
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑评估非密码哈希函数的标准
尽管密码和非密码哈希函数无处不在，但在它们的设计方式上似乎存在差距。出于各种安全要求，存在许多针对密码哈希的标准，但在非密码方面，存在一定数量的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布非常有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
随着领导者在财政紧缩和人工智能等变革性技术的背景下寻求优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者凭直觉接受，良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改善 DevEx 的拟议计划和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极端低代码技术进行的实验室实验结果来研究生产力差异，从而为该主题提供新的见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技术来为商业和社会服务，但它也很健忘。在其快速前进的运动中，它容易受到时尚潮流的影响，并且可能会忘记或忽略针对其面临的一些永恒问题的行之有效的解决方案。用例于 1986 年首次引入，后来普及，是这些行之有效的解决方案之一。
© 保留所有权利。