开发人员kpi_15个KPI来跟踪开发人员的转变

最新推荐文章于 2020-12-24 10:43:42 发布

翻译最新推荐文章于 2020-12-24 10:43:42 发布 · 1.9k 阅读

4 ·

CC 4.0 BY-SA版权

原文链接：https://www.infoworld.com/article/3297041/15-kpis-to-track-devops-transformation.html

文章标签：

#大数据 #人工智能 #java #编程语言 #机器学习

本文探讨了在DevOps转型过程中15个关键绩效指标（KPI），分为业务、变更、运营和文化四个类别，以衡量速度、质量、运营卓越和团队协作对业务目标的影响。

开发人员kpi

当您踏上转型之旅时，您需要看到一个目标-某种形式的目标。目标可能并且可能会发生变化，但是如今，随着团队努力进行变化并实现新功能，其成员应使他们与可衡量的目标保持一致。然后，他们可以使用关键绩效指标（KPI）来确定团队活动是否以及以多快的速度帮助实现了这些目标。

设定可衡量的目标并传达关键绩效指标对于团队转型至关重要。 Devops推动了一套新的实践，文化变革以及IT部门在开发和运营目标上进行协作的新方法。

[ 开发最佳实践：您应采用的5种方法。 • 如何使测试自动化与敏捷性和发展性保持一致。 •InfoWorld解释了在设备开发时代的监视。 • 究竟是什么东西？ 探索如何改变软件开发。 ]

对于大型组织而言，这可能是一项重大投资，并且需要对优先级进行持续审查：您应该开发哪些应用程序来开发持续集成和交付（CI / CD）管道？您如何确定要自动化的部署作业的优先级？哪些基础架构模式值得通过基础架构即代码（IaC）自动化？实施应用程序监视和连续测试的最低标准是什么？

这些都是优先考虑的问题，但也有影响的问题：您是否真的通过devop交付速度更快？质量在提高吗？应用程序更稳定吗？您是否从问题中恢复得更快？

定义KPI的技巧是选择与目标最相关的KPI。首先，本文调查了可以在转换程序中使用的15个KPI。我将KPI分为四类：

业务KPI，直接影响业务目标
更改KPI，这些KPI证明了IT部门推动应用程序，基础架构或服务改进的能力
运营KPI，表现出卓越的运营
文化KPI，以IT组织如何协作为目标

当devop具有直接业务影响时

如果您可以确定对战略业务目标和绩效指标有直接影响的目标，则可以帮助推动变革的重要性，并有可能为其提供资金。考虑一家电子商务公司，该公司的应用程序运行缓慢或不稳定，它可以根据用户需求自动扩展云基础架构，并自动执行针对应用程序警报的恢复过程，从而改善了这些运营指标。另一个例子可能是市政府定期调查三方成员对其技术服务的满意度，并随着开发团队更快地发布更多功能而逐步改进。第三个例子可能是一所大学，它通过将一组选定的计算堆栈作为基础架构作为代码来降低成本，并证明了较低的运营成本，因为部门和教授将工作负载转移到旧环境中。

这些示例说明了一些对业务有影响的KPI：

财务KPI ，即开发对收入或成本有直接影响
使用率指标 ，用于已定义的要提高业务目标的面向客户的应用程序
用户满意度KPI ，可能会因改进发布频率和质量或其他操作指标而受到影响

选择这些KPI的关键因素是，devops所针对的实践与业务KPI之间是否存在紧密的联系。如果devops间接影响业务KPI，或者是驱动其变更的几个因素之一，则IT部门可能需要考虑其他具有更直接相关性的KPI。

[InfoWorld的要点： CI / CD入门：使用CI / CD管道自动执行应用程序交付。 • CI / CD的5个常见陷阱-以及如何避免这些陷阱。 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

当devops驱动更快，质量更高时

开发人员的主要目标之一是推动发布更频繁的应用程序，向用户发布更多的功能和技术功能，以及减少因更改而引起的缺陷和操作问题。

面对现实：许多IT组织都在努力提高其响应速度慢和易于出错的声誉。修复需要多长时间？发布新功能后，您需要制作多少个补丁程序版本才能使应用程序再次稳定？在生产中发现了多少关键缺陷？

甚至性能良好的应用程序开发团队都在努力提高发行频率，应用程序质量以及新功能和改进功能的速度。为此，他们不断提高CI / CD管道的自动化程度，使更多的测试用例自动化，并转移了更多的应用程序安全性实践。

这也不只是关于应用程序开发。 IT可以多快启动新的Hadoop ， Spark和其他数据科学平台来运行实验？补丁发布的速度有多快？防火墙规则的验证和实施速度有多快？

第二组KPI旨在捕获驾驶变化的速度和质量：

更改提前期。 这定义了从请求更改到在生产中完全实施之间的整个持续时间。示例包括更改应用程序，满足对计算环境的请求以及实施关键系统补丁。
每季度发布的功能。 企业领导者每季度进行一次思考，因此这是他们可以解释的KPI。您需要对什么是功能有一个合理的定义，而又不要太在区分什么是“小”或“大”功能。证明的主要影响是，由于自动化和缺陷少，应用程序开发团队可以完成更多工作。
部署频率。 您是按季度，每月，每周，每天还是每小时进行部署？ CI / CD管道中开发的自动化直接驱动了更频繁的部署。
测试用例自动化。 值得跟踪的三个指标是已开发的测试用例的数量，自动化的测试用例的百分比以及运行不同测试所需的时间。一些小组还找到测量测试覆盖率，已定义测试的应用程序流百分比和应用程序接口的方法。自动化速度越快，可以将更多测试作为连续测试纳入CI / CD管道。
缺陷逃逸率。 这定义了在生产中发现的缺陷数量。可以按时间段或与部署数量的比率进行检查。

评估开发人员对卓越运营的影响

发展可能影响的下一个领域是运营。 devop程序通常会影响许多IT部门指标，例如正常运行时间和应用程序性能。除了这些基准KPI以外，还可以通过以下方式来衡量开发人员的状况：

平均恢复时间（MTTR）和平均发现时间（MTTD） 。这些指标更好地代表了运营改进对业务的影响。所有IT部门都遇到运营问题，关键问题是发现和解决问题的速度如何。投资于监视，自动响应警报，应用程序日志记录和升级程序的团队可能会影响MTTR和MTTD。
业务中断时间。 这可能是一个棘手的KPI指标，但是它可以说明企业，客户或用户遭受某种形式的技术中断的持续时间，包括计划内停机，计划外停机，性能下降，数据处理延迟以及影响工作流程的持续时间。应用程序缺陷。
技术债务关闭。 技术债务记录了技术改进的待办事项。一些技术上的负担来自于快捷方式，这些快捷方式可以更快地发布或修复某些内容，但实现得并不理想。其他技术债务来自实施或设计改进，这些改进仅在用户使用该技术后才发现并需要改进。该KPI直接说明要解决多少技术债务。随着技术团队通过自动化提高生产力，应该有更多的时间来解决技术债务问题。
Devops驱动的成本降低。 通过devops自动化可以减少某些方面的成本。自动关闭或降低未使用或轻度使用的环境可以节省成本。监控应用程序以及最佳选择架构和基础架构也可以节省成本。

评估devops计划的文化影响

如果将devop设计为解决开发人员与运营管理员和工程师之间传统上存在的文化鸿沟，那么问题是，是否可以使用KPI来定义和衡量这种差距？答案是肯定的，但是它需要对定义和一些简单的测量方法进行思考。一些示例KPI：

团队幸福。 彼此费尽周折的IT团队很可能会互相指责运营问题，错过最后期限以及沟通不畅。随着devops使团队按目标调整目标，推动自动化并减少从一个团队到另一个团队的交接，这应该使每个人的工作更加轻松愉快。可以使用员工调查和其他员工敬业度指标进行衡量。
会议效率。 不一致的组织通常需要召开更多和更长的会议，以商定优先级并解决冲突。通过开发团队变得更加结盟的开发和运营团队应该需要更少，更短且更准时的会议。
学习KPI。 大多数组织都有学习和发展的目标，而devops计划是使IT参与学习新技术和实践的好方法。可以通过要求组织成员通过午餐和学习，演示，讨论和黑客马拉松之类的活动来教别人学到的东西来最好地衡量学习。学习关键绩效指标可以旨在捕获这些学习计划的频率及其影响。