Chaque année, l’étude Accelerate est mise à jour grâce au rapport annuel State Of DevOps Report (ou SODR).

Cette étude met en évidence un catalogue de pratiques ou capacités qui prédisent des impacts sur la performance de votre équipe et de votre organisation.

Vous trouverez une présentation de cette étude ici: https://blogzenika.wpcomstaging.com/2021/08/18/accelerate-vu-par-zenika/

Vous pouvez découvrir rapidement le contenu du livre grâce à cette vidéo: https://www.youtube.com/watch?v=QCwI0LibKiw

*******

L’objectif du rapport est comme chaque année de présenter les différentes façons de travailler (ou capacités Accelerate) qui seraient utilisées par les organisations les plus performantes.

Pour cela, les personnes, qui mènent le programme DORA, formulent d’abord des hypothèses en se basant sur les tendances (AI, etc..) puis enquêtent à travers le monde via un formulaire, récoltent et analysent les données.
Suite à une analyse de ces données, le programme DORA peut confirmer ou non des liens de prédictions.

En se basant sur le modèle de prédiction ci-dessous , Le programme DORA (DevOps Research & Assessment) s’est focalisé, cette année, sur les attentes suivantes:
– Performance de l’organisation (Rentabilité, Productivité et réduction des TTMs)
– Performance des équipes (capacité à créer de la valeur, à innover et à collaborer)
– Le bien-être au travail

Selon le rapport (p5), il y a un intérêt certain d’appliquer les “enseignements”(traduction pure et dure) mentionnés dans le rapport tout en gardant les recommandations suivantes à l’esprit:

• Accelerate est une boussole, un guide et non pas une recette toute faite.
• Les métriques doivent servir uniquement à voir les progrès des équipes.
• La mesure n’est pas l’objectif (vous me voyez venir avec la loi de goodhart ?! (voir p10 du rapport))
• Les équipes doivent adopter le mindset de l’amélioration continue

Ce qui marque en premier lieu, ce sont les similitudes avec le rapport 2022:

• L’importance de la fiabilité et de la performance opérationnelle. Les pratiques SRE sont une manière de répondre à ce besoin.
• La culture est essentielle pour la mise en œuvre des capacités.

Dans cet article, je mettrais en avant les nouveautés ou des éléments qui se démarquent.

Voici les principales nouvelles conclusions issues du rapport (classées par ordre d’apparition):

• L’approche user-centric est utilisée par les organisations les plus performantes.
• L’utilisation de l’IA n’améliore pas (N.d.T: pas encore ?!) la productivité d’une organisation.
• Une documentation claire et pertinente a une influence sur la mise en oeuvre des pratiques techniques DevOps comme les tests automatisés par exemple
• Il est stratégique d’avoir des infrastructures flexibles (scalabilité, service à la demande, etc..). Le cloud est un moyen d’avoir des infrastructures dites flexibles.
• Les revues de code doivent être rapides.
• Pourquoi “qui vous êtes” est important !

Nous détaillerons chaque section au fur et à mesure.

*******

L’approche user-centric.

Est ce vraiment une révélation ? Pas tant que cela.
Si on parle de comprendre les besoins des utilisateurs et d’y répondre au plus près grâce à des interactions et des itérations, cela est un sujet déjà très bien connu dans l’agilité.
Par contre, ce que montre cette section, ce sont les bénéfices de cette approche pour votre équipe et votre organisation.

En effet, en 2023, l’approche user-centric serait la pratique qui prédit le plus fortement un impact sur votre performance organisationnelle (productivité, rentabilité et réduction des TTMs (Time To Market))

Autre point intéressant, ce sont les 3 questions à se poser dans votre équipe sur cette pratique:

• Est ce que votre équipe comprend bien les besoins des utilisateurs ?(souvent on a une distance avec les utilisateurs qui nous empêche de poser les bonnes questions)
• Est ce que l’ensemble de l’équipe est aligné sur l’envie et sur la manière de répondre aux besoins de l’utilisateur ?
• Est ce que les feedbacks utilisateurs sont récoltés et priorisés par la suite ?

Je trouve ces 3 questions importantes car elles mettent en évidence des perspectives et créent des prises de conscience sur:

• La distance entre l’équipe et l’utilisateur (de producteur à consommateur, quelle distance/relation avez-vous besoin ?)
• L’engagement de chacun/chacune à répondre aux besoins de l’utilisateur
• La manière dont vous récoltez du feedback, des évidences sur ce qui est produit et livré.

Au final, on cherche à ce que l’équipe construise le bon produit et qu’elle le produise bien dans le but d’améliorer l’expérience utilisateur.

Et vous, comment répondez-vous aux 3 questions précédentes ?

Un sujet classique mais souvent sous-estimé en entreprise !

*******

L’utilisation d’une IA n’aurait pas d’impact sur votre performance en livraison continue (c.a.d pas d’impact sur les 4 métriques DORA)

Durant l’investigation, DORA a orienté ces hypothèses sur l’accompagnement des IA dans le but de produire plus vite.
Le constat est le suivant en 2023:

• L’IA augmenterait légèrement la performance d’une équipe de développement
• Mais l’utilisation d’une IA ferait baisser la performance de votre organisation !

L’adoption de l’IA comme accompagnant pour produire du code permet d’améliorer un peu la performance de l’équipe.
Cependant, il semblerait que le code produit avec l’assistance d’une IA pose problème par la suite.

Suite à ce constat, je me pose les questions suivantes:

Est-ce lié à un manque de confiance sur le livrable créé avec assistance IA ? Le code produit prendrait-il plus de temps lors des codes reviews ?

Le rapport est peu exhaustif à la suite de ce constat.

A mon avis, cela n’est qu’une question de temps et d’adoption dans les organisations.

Mais je serais intéressé de votre avis si vous ou votre équipe utilisez une IA pour produire du code.

*******

Une documentation claire et pertinente

Ma préférée !

On est loin de la valeur agile: “Des logiciels opérationnels plus qu’une documentation exhaustive” !

Ici, la documentation a un rôle fondamental selon l’étude.

“Une documentation claire, pertinente et accessible pour créer des logiciels opérationnels !”

Selon le rapport, une documentation de qualité aurait un impact sur l’influence de la mise en œuvre des pratiques techniques DevOps (CI, CD, Tests automatisés, etc…).
Pour rappel, les capacités techniques ont un impact très fort sur votre delivery et la qualité dans votre organisation !

Notez cependant que l’on ne demande pas une documentation exhaustive mais une documentation qui soit:

• pertinente
• accessible (facile à trouver)
• claire

Je suis actuellement en train d’expérimenter cette capacité dans une organisation (je rédige une documentation qui respecte les 3 critères précédents. Je partagerai mes observations dans quelques mois)

Pour en savoir plus: https://dora.dev/devops-capabilities/process/documentation-quality/

*******

Avoir des infrastructures flexibles

N’oublions pas que DevOps est né d’une réflexion agile par son créateur Patrick Debois.
En 2008, il pose la question suivante: comment gérer notre infrastructure de façon agile ?
1 an après naît le mot DevOps.

Le cloud est l’outil majeur pour avoir des infrastructures flexibles. Il est fortement utile.

Quelle différence avec 2022 ?

On parle de flexibilité et de 5 critères (source la NIST)
En se rapprochant de ces 5 critères, on peut prédire des impacts sur la performance de notre organisation.

Déjà présenté par Nicole Forsgren en 2019, ces critères sont les suivants :

– Service à la demande

– Élasticité rapide (scale up/scale down)

– Accès aux services depuis n’importe quel endroit du monde

– Partage des ressources et allocation de ressources

– Mesure des services (FinOps, etc…)

Il y a eu pas mal de critiques sur la promotion du cloud faite par une entité qui est provider

D’un autre côté, y a-t-il vraiment d’autres alternatives au cloud pour obtenir une souplesse sur la création/mise à disposition de nos infrastructures ?
Et au final, a-t-on vraiment besoin d’infrastructure flexible ? A méditer…

*******

Les revues de code doivent être rapides. (Rédaction Anthony MARQUET)

En effet les revues de code doivent être “rapide” , selon le rapport, afin de continuer à incrémenter le produit fréquemment et récolter du feedback rapidement.

Cependant il ne faut pas confondre vitesse et précipitation !

Trop rapide

Cela va générer :

• de la frustration de la part de l’équipe qui aura le sentiment d’avoir bâclé son travail
• de la dette technique
• une implémentation non évolutive synonyme de rework
• un risque de bug qui sera soulevé plus tard par l’équipe QA. (retour à la case départ)
• un désengagement d’une partie de l’équipe : “il faut voir avec ce développeur car c’est son code” .

Trop lente

Cela risque de mettre des tensions dans l’équipe car :

• La vélocité de l’équipe dans son ensemble est réduite.
• Les développeurs commencent à protester contre le processus de révision de code.
• La qualité du code peut être affectée à cause de la pression qui sera accrue.
• Le délai de livraison de l’incrément sera impacté

Finalement cette tâche importante dans le processus de développement d’un produit doit être “comme un accord” par l’ensemble de l’équipe produit.

Il faut mettre le bon effort en fonction de la complexité de la tâche. La mise en place de règles peut aider l’équipe à mieux timekeeper cette étape afin d’ avoir le sentiment de livrer un travail de qualité.

*******

Pourquoi “qui vous êtes” est important !

Un sujet qui me tient à cœur.

Voici des constats issus du rapport (Chapitre 8) qui me glacent le sang. Pour des raisons de respect du contenu, je me suis permis de traduire les phrases tel quel:

• Les personnes interrogées qui se sont identifiées comme étant sous-représentées d’une manière ou d’une autre ont déclaré des niveaux d’épuisement plus élevés de 24%.
• Les femmes ou les personnes se définissant comme telles ont déclaré un niveau d’épuisement professionnel supérieur de 6 %.
• Les personnes interrogées qui s’identifient comme sous-représentées déclarent effectuer 24 % de travail répétitif en plus.
• Les femmes ou les personnes se décrivant elles-mêmes comme étant de sexe féminin ont déclaré faire 40 % de travail répétitif en plus.

Si les données s’avèrent pertinentes, qu’attendons-nous pour réagir en conséquence ?
Nous aurions tous et toutes à y gagner à agir.

Et même les entreprises.

Dans le cas où le seul levier d’action serait l’argent, l’autrice d’Accelerate Nicole Forsgren a publié les éléments suivants:

Les recherches montrent que les équipes plus diversifiées en termes de genre sont plus intelligentes, réalisent de meilleures performances d’équipe et obtiennent de meilleurs résultats commerciaux. (ref: Accelerate the science behind devops and lean, chap 10 , p110 — Diversity in tech (Women in DevOps))

Il reste à espérer que les démarches autour du RSE puissent fortement faire évoluer les choses !

En parlant d’inclusion, je vous recommande l’excellente conférence de Véronique Sermage

*******

Pour finir:

Globalement, je préconise la lecture du rapport et de vous faire votre propre avis.
Je vous invite également à porter votre attention sur le sujet de la documentation et sur le sujet de l’inclusion.

Un bémol.
On parle encore d’adoption de mindset, ce qui en soit ne veut rien dire…

Shook a observé qu’il était possible de changer les comportements mais pas la manière de penser des personnes.
Cela passe par la création d’environnement qui prête à changer les manières d’interagir selon lui.

Enfin en tant que business leader, je vous préconise de lire cette page car en général tout découle de vous !
https://dora.dev/devops-capabilities/cultural/how-to-empower-software-delivery-teams/

*******

Petit mot personnel de l’auteur:

Cela fait 1 an que nous participons à la communauté DORA avec William BARTLETT et que nous insistons sur l’importance de la loi Goodhart ( Strasthern, Marilyn (1997))

Aujourd’hui, nous avons le plaisir de retrouver cette loi dans le rapport 2023 en page 10. Un grand merci !

Et vous chèr.e. lecteur/lectrice, merci d’être aller jusque ici !
A très vite !

Geoffrey GRAVEAUD

Rédaction/Traduction:

Geoffrey GRAVEAUD

Anthony MARQUET: “Les revues de code doivent être rapides”