En 2022, le rapport Accelerate State of DevOps contenait quelques surprises. L’un était un changement des clusters de performance traditionnels. Le rapport a également introduit une nouvelle façon de regrouper les organisations à l’aide d’une dimension supplémentaire.
Cet article vous présente les clusters de performances d’origine, explique les modifications et décrit comment vous pouvez utiliser les nouveaux groupes.
Modifications précédentes
Ce n’est pas la première fois que quelque chose change. Il y a eu des changements au cours des huit dernières années alors que les chercheurs découvrent de nouvelles connexions ou une nouvelle direction à explorer. De plus, certaines modifications passées ont eu un impact direct sur la nouvelle technique de clustering.
Dans les précédents rapports DevOps, les chercheurs de DORA (DevOps Research and Assessment) ont utilisé quatre indicateurs clés pour diviser les organisations en ensembles basés sur les performances :
Débit
- Fréquence de déploiement
- Délai de modification
Stabilité
- Modifier le taux d’échec
- Temps moyen de récupération
En 2018, DORA a ajouté une nouvelle métrique pour disponibilité pour mesurer la performance opérationnelle d’une organisation. Plus tard, ils ont changé cela en fiabilité.
Vous pouvez mesurer les performances de livraison de logiciels avec les quatre métriques d’origine (souvent appelées les quatre clés). Ensuite, en utilisant les cinq étapes, vous mesurez la livraison de logiciels et opérationnel performances, souvent abrégées en Performances SDO.
Une bonne performance par rapport aux cinq mesures stimule la performance organisationnelle. Votre organisation est plus susceptible d’atteindre ses objectifs lorsque les équipes excellent dans ces mesures. Vos performances opérationnelles permettent la relation entre les performances de livraison de logiciels et les résultats organisationnels.
Groupes
Un cluster est un groupe de données dont les membres sont plus similaires les uns aux autres qu’aux éléments d’un autre groupe. Ceci est utile dans le rapport State of DevOps car il permet à de nombreuses organisations d’être organisées méthodiquement à des fins de comparaison.
L’équipe de recherche utilise le clustering hiérarchique pour découvrir les groupes de performances dans le rapport State of DevOps. Cette technique ne définit pas les clusters à l’avance mais les laisse émerger des données.
Les chercheurs testent des hypothèses à l’aide de clusters. Par exemple, en regroupant les organisations en fonction de leur fréquence de déploiement, ils peuvent voir que les organisations qui se déploient plus souvent sont plus susceptibles d’atteindre leurs objectifs. Ensuite, chaque fois que les chercheurs répètent l’analyse sur un échantillon différent, ils peuvent tester la validité de l’hypothèse. Cette approche scientifique est la façon dont les chercheurs augmentent leur confiance dans les pratiques qui stimulent la performance.
Clusters de performance de livraison de logiciels
Si vous avez suivi le rapport sur l’état de DevOps pendant un certain temps, vous serez familiarisé avec les clusters de performances de livraison de logiciels. Chaque groupe représente un niveau de performance différent par rapport aux métriques de débit et de stabilité. Cela se traduit généralement par quatre clusters.
Les organisations peuvent comparer leurs performances de livraison de logiciels aux clusters en fonction des métriques de débit et de stabilité et identifier les domaines d’amélioration potentiels.
Comment les clusters de livraison de logiciels ont changé en 2022
Le changement le plus apparent apporté aux clusters de livraison de logiciels en 2022 était qu’il n’y avait que trois groupes au lieu de quatre. La suppression du groupe de performance d’élite est décrite plus en détail plus loin, mais considérons d’abord les changements apportés aux autres groupes, car ils sont tout aussi surprenants.
Le groupe à faible performance
Vous constaterez que les performances du cluster le plus bas se sont améliorées sur trois mesures, avec un délai et une fréquence de déploiement correspondant au groupe de performances moyennes en 2021. Le temps moyen de résolution a également été multiplié par plus de 6. Cependant, le taux d’échec du changement a augmenté.
Le groupe de performance moyenne
Le groupe à performance moyenne s’est amélioré par rapport au délai et à la fréquence de déploiement, correspondant au groupe à haute performance de 2021 pour ces mesures. Ils ont également réduit leur temps moyen de résolution et conservé les mêmes taux d’échec des changements.
Le Groupe Haute Performance
Le groupe haute performance fusionne les performances des clusters haut et élite de 2021.
Le groupe de performance d’élite
Seuls trois clusters ont émergé en 2022, il n’y a donc pas de groupe de performance d’élite en 2022. Il y a deux explications à cela :
- Les répondants d’élite en 2022 ont été absorbés dans le groupe de haute performance amélioré.
- Le profil démographique est différent en 2022 par rapport aux années précédentes.
Au cours des années précédentes, de nombreux répondants travaillaient dans la livraison de logiciels depuis plus de dix ans. Cependant, en 2022, la proportion de répondants ayant plus d’une décennie d’expérience a diminué de moitié. Le changement semble moins surprenant puisque la plupart des répondants ont moins d’expérience que ceux qui ont répondu aux sondages des années précédentes.
Bien que vous puissiez voir le changement clair dans la démographie, on ne sait pas si cela rend l’échantillon plus ou moins représentatif de l’industrie du développement de logiciels. Lors de l’examen du niveau de performance de votre équipe, vous pouvez comparer l’expérience de votre équipe avec les répondants au sondage pour voir si vous avez accès à des développeurs très expérimentés qui peuvent avoir un impact important.
Le changement démographique et la disparition subséquente du groupe d’élite suggèrent que l’expérience est le moteur de la performance. Cependant, le lien entre les capacités spécifiques et les résultats reste constant chaque année.
La suppression de la catégorie des performances d’élite ne signifie pas que ces organisations ont abandonné le développement de logiciels. Au contraire, différentes personnes répondent à l’enquête chaque année, et il y a eu cette fois un changement inhabituel dans le type de répondants. De plus, les répondants de cette année avaient globalement moins d’expérience, il n’est donc pas surprenant qu’ils aient moins bien performé par rapport aux mesures de débit et de stabilité.
Au lieu de perturber l’étude annuelle de DevOps, l’évolution démographique des répondants a fourni une occasion unique de découvrir de nouvelles pistes d’exploration.
Récapitulatif des performances de livraison de logiciels
Dans le tableau ci-dessous, vous trouverez une comparaison de 2021 et 2022. La position verticale de chaque cluster indique le niveau de performance, et les cercles indiquent la taille de chaque groupe.
Les changements de performances et de distribution signifient que vous pouvez les considérer comme trois nouveaux clusters de performances plutôt que comme une évolution des précédents. Des recherches supplémentaires sont nécessaires pour comprendre ces changements, mais elles sont probablement liées à l’évolution démographique des répondants.
Les clusters de performances SDO
En plus des changements apportés aux groupes de livraison de logiciels, DORA a ajouté une nouvelle répartition prenant en compte les performances opérationnelles. Les nouveaux clusters pour les performances SDO utilisent les cinq mesures de débit, de stabilité et de performances opérationnelles :
Débit
- Fréquence de déploiement
- Délai de modification
Stabilité
- Modifier le taux d’échec
- Temps moyen de récupération
La performance opérationnelle
- Fiabilité
La métrique de fiabilité capture la fréquence à laquelle l’équipe atteint ses objectifs de fiabilité.
Les étiquettes attribuées aux groupes suggèrent un scénario dans lequel vous pouvez vous attendre aux performances associées par rapport aux métriques. Par exemple, le cluster « starting » présente ce que vous pouvez attendre d’une équipe dans les premières étapes du développement d’un produit ou d’une fonctionnalité. Ce groupe a des performances modestes par rapport à chaque dimension. Au début, l’équipe peut se concentrer davantage sur l’innovation que sur la fiabilité.
Voici les clusters de performances SDO, avec des performances faibles mises en évidence :
Ces groupes sont plus descriptifs que les clusters de performances de livraison de logiciels. Plutôt que de rechercher des performances élevées pour tous les produits et toutes les équipes, une organisation peut adopter une approche plus équilibrée. Par exemple, vous pouvez planifier différents niveaux de performances entre une équipe travaillant sur votre produit principal et une autre travaillant sur un nouveau produit.
Cette approche n’est pas sans danger. De nombreuses équipes restent en permanence dans le groupe de départ, ne résolvant jamais les problèmes de fiabilité qui débloqueraient l’impact positif que les performances de livraison de logiciels peuvent avoir sur les réalisations à l’échelle de l’organisation. Vous avez peut-être travaillé dans des équipes qui ressemblaient au cluster qui prenait sa retraite malgré le développement actif d’un produit logiciel. Les caractéristiques de performance du cluster qui prend sa retraite seraient présentes dans une organisation bureaucratique où l’équipe des opérations agit comme des gardiens, empêchant les changements de se déplacer dans le système pour maintenir la stabilité.
Vous pouvez afficher les noms de cluster comme des explications les mieux adaptées pour des choix de performances délibérés. Par exemple, vous pouvez choisir de renoncer à une certaine fiabilité pour encourager la prise de risque et l’innovation lors du développement d’une nouvelle idée. Si vous ne faites pas de choix intentionnels, vous risquez d’inventer un récit pour expliquer les mauvaises performances. Des recherches futures pourraient tester l’exactitude de ces noms de grappes.
L’application la plus pratique des nouveaux clusters consiste à les utiliser pour concentrer vos efforts sur vos systèmes logiciels de base. Les systèmes que vous vendez et les applications métier qui vous donnent un avantage concurrentiel sont ceux qu’il faut d’abord mettre en place. Ne classez jamais ces systèmes comme ralentissementet ne désignez un système que comme sortant lorsque vous avez un plan actif pour son retrait ou son remplacement.
- Les équipes à l’état fluide utilisent plus couramment les capacités du modèle d’équation structurelle DevOps, telles que :
- Automatisation du déploiement
- Architectures faiblement couplées
- Livraison continue
- Contrôle de version
- Modalités de travail flexibles
Conclusion
Les clusters de performances de livraison de logiciels d’origine restent essentiels dans votre évaluation des performances de votre organisation. La performance opérationnelle libère les avantages de la haute performance, étendant leur impact au niveau organisationnel. Les nouveaux clusters de performances SDO tentent de démontrer l’importance de la fiabilité pour la livraison de logiciels, mais peuvent être trompeurs en raison de la tentative d’attribution d’étiquettes sans jugement.
La disparition du groupe de performance d’élite est probablement liée aux changements démographiques. De plus, cela nous a peut-être amenés à découvrir qu’une équipe a besoin de développeurs expérimentés pour atteindre les niveaux de performance les plus élevés.
Vous devez consolider ces informations à l’échelle de l’industrie avec une stratégie de mesure locale pour vous assurer que vos efforts d’amélioration continue sont dirigés par leur impact réel sur votre organisation….