BVSSH的两个重要指标：周期与质量
正面模式7.1慢下来是为了快起来
“更快”衡量的是可持续的交付速度。一个易于衡量的指标是发布节奏，即软件发布的频率。发布节奏是最简单的指标，因此它的意义最小。例如，你看到6个“项目”同时推进，每个项目都有6个月的前置时间，且项目之间间隔一个月。这给人的印象是团队每月都在进行迭代。事实上，由于大量的情境切换，流动效率始终很低，6个月的前置时间难以实现技术卓越，流动障碍仍未解决。
考虑到概念兑现的更大范围的端到端前置时间，以及反面模式4.1中描述的“紧迫性悖论”，我们将在正面模式7.2中看到企业架构历史、决策和设计如何对“更快”产生重大影响，而不仅仅是影响单个产品开发团队的改进。
还有一个指标（对速度同样有一定的影响）是“更高质量”。质量应该是连续的，质量是生产出来的，而不是检验出来的。衡量“更高质量”的一个滞后指标是“生产中的事故”。这是一个主要的衡量指标，因为空谈不如实践。非生产环境下的缺陷不是质量的衡量指标，它们只是未完成的工作。
此外还有一些重要的质量衡量指标，如静态代码分析度指标。SonarQube等工具可以帮助我们对代码层级的设计质量的某些方面进行高质量的数据可视化。它们还可以发现安全漏洞和潜在错误、测试代码覆盖率、剪切和粘贴重复代码，发现违反代码编写规范的地方，判断代码复杂性等［将这样的工具插入开发人员的集成开发环境（IDE）中，从而将这些质量检查移到最左边（例如，SonarLint，SonarQube的集成开发环境插件，或FXCop、Checkstyle、ESLint等语言专用工具）］。
代码的可维护性是优化结果的关键。所谓可维护性，即代码容易理解（无论是单行代码，还是方法代码或功能代码，抑或设计的嵌套模块）。静态代码分析可以帮助我们找出那些本不需要如此复杂的代码。
分阶段实施这些方法已经取得了显著成效。你可以首先将代码质量可视化并呈现给团队，然后让团队遵守质量标准。例如，SonarQube区分了库存（旧）代码和流动（新）代码，并允许团队在代码流上设置质量标准，从而支持持续改进。
