每日分享最新，最流行的软件开发知识与最新行业趋势，希望大家能够一键三连，多多支持，跪求关注，点赞，留言。
软件工程不仅仅是编码技能。
几十年来，组织一直在尝试衡量软件开发的生产力。很多时候，注意力都集中在易于量化的指标上，例如工时、提交的代码行数、功能点或每个 sprint 添加的功能。遗憾的是，这些都不足以预测团队的生产力。这是一个如此复杂的问题，以至于有些人宣称无法解决。
尽管有这些失败的尝试，DORA 还是着手建立发展生产力的衡量标准。
什么是DORA？
DORA（DevOps Research and Assessment）是一个由 Nicole Forsgren、Jez Humble 和 Gene Kim 于 2015 年创立的研究团队。该小组的目标是寻找改进软件开发的方法。在七年的时间里，他们调查了各行各业数百个组织的数千名软件专业人士。
该团队的研究结果首次发表在Accelerate: The Science of Lean Software and DevOps (2018)上。这本书介绍了与高绩效组织相关的四个基准：DORA 指标。
在上述书籍出版的同一年，谷歌收购了该集团并建立了DORA 研究计划，负责发布年度DevOps 状态 告。
DORA 指标是什么？
DORA 的研究获得的突破性见解是，在足够长的期限内，速度和质量之间没有折衷。换句话说，从长远来看，降低质量不会产生更快的开发周期。
速度和稳定性都至关重要。专注于以牺牲质量为代价添加功能会导致代码不合标准、版本不稳定和技术债务，最终扼杀进展。
DORA 确定了软件开发的两个关键方面：
吞吐量：衡量新代码达到生产所需的时间。
稳定性：衡量部署失败的频率和平均修复时间。
DORA用两个指标衡量稳定性：
服务恢复时间(MTTR)：组织（平均）从生产故障中恢复所需的时间。
更改失败率(CFR)：导致生产失败的发布或部署的百分比。
在吞吐量方面，DORA 增加了两个指标：
部署频率(DF)：组织成功向用户发布产品或将其部署到生产环境的频率。
DORA 衡量软件开发的两个方面：稳定性和吞吐量DORA 指标使用以下 4 个级别来衡量：精英、高、中和低。公制低的中等的高的精英部署频率每 6 个月少于 1 次每月 1 次至每 6 个月 1 次每周 1 次到每月 1 次按需（每天多次部署）变更准备时间超过 6 个月1个月至6个月1天到1周不到1小时是时候恢复服务了超过 6 个月1天到1周不到一天不到1小时更改失败率16% 到 30%16% 到 30%16% 到 30%0 至 15%
根据2021 年 DevOps 状态 告 (PDF)，不同级别的性能是惊人的。
精英团队的生产力是其他团队的数千倍。 2021 年，DORA 团队引入了第五个指标：可靠性，它通过评估组织如何达到或超过其可靠性目标来衡量运营绩效。
使用 DORA Metrics 达到精英级别
让我用一些警告作为本节的开头：
-
DORA 指标仅在跟踪团队在 DevOps 旅程中的进度时有效。它们不能用于比较团队或个人。
-
不应混淆目标和指标。由于所有指标都可以被玩弄，将指标等同于目标会导致不正当的激励措施。例如，如果管理层决定不计成本地优化部署频率，那么部署他们能想到的任何微小更改都将符合团队的最佳利益，无论它是否为用户增加了价值。
-
组织文化对团队绩效有着巨大的影响。我们将在后面的帖子中回到这个问题。
好的，既然这已经不碍事了，让我们继续吧。
在过去的几年里，精英团队的数量一直在增长。2018 年，只有 7% 的团队或组织被认为是精英。到 2021 年，这一数字增长到 26%。所以我们知道增长是可以实现的。
提高吞吐量
生产周期慢的组织部署频率低，变更准备时间长。通常，我们可以通过优化持续集成和持续交付(CI/CD)、识别组织问题、加速测试套件和减少部署摩擦来提高吞吐量。
问问自己，“是什么阻止我现在发布？” 答案将揭示组织中的瓶颈。例如，您可能在代码审查上浪费了太多时间，等待 QA 批准更改，或者在其他团队完成他们的功能之前等待发布。
您可以通过多种方式提高吞吐量：
减少发布的大小。经常运送小而安全的变化。如果某个功能尚未准备好迎接黄金时段，请将其隐藏在功能标志后面或暗启动。
确保整个部署过程是自动化的，只需按一下按钮即可完成。这意味着在部署过程中没有清单和人工干预。
采用基于主干的开发。它将减少合并冲突的机会并鼓励协作。
通过管理缓慢的测试和删除不稳定的测试来优化持续集成的速度。
跟踪您在软件交付过程中的每个步骤上花费的时间。检查周期时间并找出可以节省时间的地方。
提高项目的稳定性
没有稳定性的速度最终会导致技术债务的累积，并且花费更多的时间来修复错误而不是发布功能。当稳定性指标看起来不好时，用户体验就会很差，开发人员将大部分时间都花在灭火而不是编码上。
您可以遵循以下一些想法来提高稳定性：
在CI 管道中实施代码质量检查。拒绝发布不符合标准的代码。
加强代码同行评审过程或尝试结对编程。
当灾难来袭时，专注于恢复而不是所有其他任务。
确保您的系统中有足够的监控和可观察性，以便快速确定故障原因。
每次发生严重中断时都要召开“经验教训”会议。
在部署管道中使用冒烟测试，以避免在错误环境中进行部署。
对您的部署实施自动回滚。尝试金丝雀或蓝绿部署。
生成文化
或许不出所料，2021 年 DevOps 状态 告发现精英团队与组织内的生成文化之间存在高度相关性。“生成文化”一词是由 Ron Westrum 创造的，用来描述一种包容、高度合作的文化，它提供了承担风险所需的心理安全，而不必担心后果。
组织的文化超越了单个团队。它必须由管理层支持，由工程团队共享，并在整个公司范围内维护。生成文化消除了孤岛，鼓励了工程团队之外的协作。
病态 （权力导向）官僚 （以规则为导向）生成 式（以性能为导向）合作度低适度合作高度合作使者“开枪”被忽视的使者训练有素的信使推卸责任狭窄的职责风险共担不鼓励桥接允许桥接鼓励桥接失败导致替罪羊失败导致正义失败导致查询新奇粉碎新奇导致问题实施新颖性
结论
认为改进 DORA 指标会自动产生更好的团队是错误的。反之亦然：包容的、生成性的文化自然会产生更高的基准。换句话说，没有机会在低合作、规避风险的环境中维持一支精英团队。将指标设定为目标不仅是短视的，而且通常表明组织已误入病态或官僚文化。
您想知道您的 DORA 分数是多少吗？参加DevOps 快速检查并找出答案！
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！