Introduction
Comme tous les ans, l’étude state of devops 2021 est lancée. Cette étude permet d’alimenter les recherches qui ont déjà livré Accelerate, un livre qui fait maintenant référence dans le domaine de l’étude des processus de construction de logiciels.
Qu’est-ce qu’Accelerate ?
Comme déjà indiqué, Accelerate est une analyse statistique des résultats des études “state of devops” annuelles. Le gros intérêt de cette étude est de partir d’une vision brute des pratiques DevOps pour en tirer des enseignements dépassant les outils techniques utilisés.
Quatre métriques clés
L’un des premiers enseignements, et sans doute le plus médiatisé, est qu’il est possible de catégoriser le niveau de performance et de qualité d’une organisation à partir de quatre métriques facilement mesurables :
- Délai de livraison en production
- Fréquence de déploiement
- Temps moyen de restauration
- Pourcentage de livraisons en erreur
D’après Accelerate, ces métriques permettent de distinguer des organisations capables de livrer rapidement et efficacement du logiciel de qualité. C’est extrêmement intéressant, mais ça induit un biais bien connu : “quand une mesure devient un objectif, elle cesse d’être pertinente” (voir la loi de Goodhart).
D’ailleurs, Google, qui a repris les études, fournit une page (Are you an Elite DevOps performer? Find out with the Four Keys Project) détaillant l’impact de ces métriques et permettant la mise en place d’écrans les visualisant.
Autrement dit, mesurer ces métriques est intéressant pour situer une organisation en termes de capacité de livraison. Mais tenter d’optimiser ces métriques naïvement ne fonctionnera pas.
En fait, ce que montre Accelerate, c’est que ces métriques dépendent, par un jeu d’interdépendances démontrées par leurs études statistiques, de multiples facteurs.
Un réseau d’interdépendances incluant toute l’entreprise
L’un des intérêts de la méthode de sondage choisie pour les études sur l’état du monde devops, c’est de pouvoir déterminer les influences entre les différents facteurs. C’est ce qui permet aux auteurs de l’étude de produire ce schéma, qui montre tous les éléments influant sur la capacité d’une entreprise à améliorer ses résultats dans ces métriques. Et le moins qu’on puisse dire, c’est que les influences sont nombreuses et parfois peu intuitives.
L’un des exemples les plus frappants est la mise en place d’une culture organisationnelle correspondant aux critères définis par Westrum. Accelerate montre en effet que le fait d’avoir une culture d’entreprise générative, c’est-à-dire permettant la coopération, le lien entre les équipes, et abandonnant en un sens le contrôle managérial et la bureaucratie, est un élément contribuant notoirement à l’amélioration des fameuses quatre métriques.
Encore une fois, pour optimiser ces métriques, il ne faut pas chercher à les améliorer directement, mais plutôt optimiser les critères leur permettant de s’améliorer. C’est aussi intéressant que contre-intuitif. Et c’est l’une des leçons de cette lecture.
Et si l’approche présentée dans Accelerate est intéressante, elle n’est pas sans limites.
Les limites d’Accelerate
La vision produit est absente
La première chose à noter est que cette approche travaille effectivement l’accélération de la livraison et tout ce qui peut l’impacter, mais n’étudie absolument pas la vision de ce qu’est un produit logiciel : comment définir un produit logiciel, comment le faire vivre ? Ces questions, qui sont en fait des prérequis à la livraison de ce produit, et donc à la mise en place de DevOps ou d’Accelerate, ne sont pas traitées.
Le système socio-technique de l’organisation n’est pas étudié
Si Accelerate parle du management et de l’importance du mode d’organisation choisi, le livre ne développe pas les aspects liés aux liens entre l’équipe et le logiciel qu’elle produit.
On peut parler de l’application de la loi de Conway pour définir une organisation adaptée au logiciel produit, aux limites de ce qui est exprimable en rétrospective, ou d’architecture socio-technique… Dans tous les cas, une organisation est avant tout un artefact socio-culturel qu’il faut faire vivre au-delà de sa capacité à produire des artefacts techniques. Et ces aspects très intéressants, qui ont été présentés par les modèles d’organisation de Spotify, d’Amazon et d’autres entreprises, ne sont pas étudiés, alors qu’ils conditionnent clairement de nombreux aspects présentés par Accelerate.
Aucun chemin d’amélioration n’est proposé
Si Accelerate réfléchit aux moyens d’accélérer la livraison de code, et si l’équipe fournit également un outil d’assessment, il n’y a en revanche pas de définition d’un chemin de migration vers des livraisons plus rapides. Et en un sens, c’est normal. En effet, comme l’explique plusieurs fois le livre, chaque équipe est spécifique, elle a des forces et faiblesses particulières. Par conséquent, les défis à accomplir pour atteindre un haut niveau de performance dépendent très précisément de l’équipe et ne peuvent donc pas être normalisés. En un sens, c’est l’une des limites du type d’étude : en choisissant une vue “en coupe” de l’industrie informatique, on peut facilement voir les différentes méthodes et leur impact sur la capacité à livrer, mais il est difficile d’étudier les chemins qui transformeront une entreprise qui peine à livrer efficacement en un leader DevOps.
Accelerate n’est peut-être qu’une vision des modes
Accelerate est bâti sur quatre années d’étude des processus de développement. Or l’industrie informatique subit le balancier de la mode sur une période plus longue. Et les phénomènes qui étaient à la mode il y a quatre ans font encore partie des tendances lourdes. En revanche, si on regarde plus loin dans le passé, on verra que certaines pratiques, certaines méthodes, ont complètement disparu (par exemple la livraison de logiciels clients ne se fait plus actuellement, sauf dans le monde des smartphones). Et si ces pratiques ont disparu, leur intérêt ne peut être évalué comparativement aux méthodes actuellement employées. Et c’est normal, dans une étude fondée sur une démarche inductive, cherchant donc à valider des hypothèses à travers les cas présentés en réponse à l’étude statistique.
On peut donc voir dans cette étude certaines pratiques considérées comme mauvaises (par exemple les CAB, qui n’apportent d’après cette étude aucun avantage aux entreprises les pratiquant), mais aucune qui soit fatale à un projet. Parce que le plus grand biais est sans doute de n’interroger que les entreprises actuelles, et donc de subir le biais du survivant : les entreprises qui ont mis en place des méthodes qui leur ont été fatales ne sont plus là pour répondre au sondage.
Le métier n’est pas étudié
Enfin, et c’est sans doute le biais le plus important, il ne semble pas exister de métier au sein d’Accelerate. C’en est même troublant : on réfléchit à la boucle de feedback avec les utilisateurs à travers des ateliers, de l’A/B testing et d’autres pratiques, mais on ne réfléchit pas vraiment au métier, ni à la valeur que l’organisation livrant du logiciel doit apporter. Pourtant, c’est sans doute l’un des aspects les plus importants du développement : essayer d’apporter à l’utilisateur le bénéfice métier souhaité. Et ce sujet est sans doute aussi délicat que celui de la livraison logicielle pour définir les bons et les mauvais acteurs. Google est sans doute l’exemple le plus parlant : la réussite de l’entreprise n’est pas tant liée à sa capacité à livrer du logiciel qu’à la valeur métier produite par son application phare, le moteur de recherche.
Mais quel intérêt ?
Malgré ces limites, Accelerate est quand même une lecture extrêmement intéressante dans une entreprise comme la nôtre pour de multiples raisons.
D’abord, en tant qu’entreprise de conseil, Accelerate fournit à Zenika une façon parfaitement adaptée d’expliquer la raison pour laquelle nous fournissons des prestations couvrant l’accompagnement agile, l’artisanat logiciel, le devops, et autres domaines. Et si ce lien est particulièrement adapté au métier de notre entreprise, il permet aussi de lier les enjeux techniques des organisations aux impacts qu’ils auront sur ces organisations (par exemple, le fait que l’accélération de la livraison passe par une plus grande autonomie des équipes de développement quant à ces livraisons).
Au sujet des enjeux, la grande force est également de pouvoir partager ces objectifs entre tous les acteurs de l’équipe : qu’on soit coach agile, développeur, ops, manager, directeur, les objectifs présentés par Accelerate parlent à tous les membres de l’équipe, et permettent un alignement des travaux réalisés par les différents membres de l’équipe. Ces objectifs vont également permettre d’aligner les membres de l’équipe, mais aussi les différentes équipes de l’organisation, ce qui est particulièrement intéressant dans les entreprises de grande taille dans lesquelles les pratiques tendent à diverger. Et si cette divergence est source d’enrichissement, il ne faut pas qu’elle entraîne l’incompatibilité des pratiques. Or Accelerate permet précisément, au-delà des techniques utilisées, d’assurer une vision commune des bonnes pratiques. Parce que dans ces équipes qui ont des pratiques assez différentes, l’organisation du livre donne en quelque sorte les différents chemins permettant de s’améliorer, et de s’harmoniser au sein de l’entreprise, sans pour autant avoir une valeur prescriptive forte : si les axes sont les mêmes, les chemins d’amélioration dépendent de l’équipe, et permettent donc à chaque équipe d’avancer de la manière la plus adaptée à ses besoins et ses capacités du moment.
Enfin, et c’est peut-être l’un des aspects clés, Accelerate est fondamentalement une approche bottom-up : en partant d’une question simple “comment livrer plus rapidement du code de meilleure qualité”, les sujets abordés dépassent largement le simple cadre des outils techniques pour venir travailler au niveau organisationnel. Et grâce à des métriques facilement compréhensibles, les membres des équipes de développement peuvent facilement mettre en place des actions ayant un potentiel mesurable d’amélioration. Et le plus intéressant pour nous chez Zenika, c’est que cet objectif est atteint en travaillant également le sujet du bien-être au travail, ce qui en fait une étude améliorant à la fois la capacité technique des équipes, mais aussi la capacité à permettre l’épanouissement des personnes, en fournissant un objectif, un alignement, et une vision qui correspondent à des critères de qualité faisant de l’informatique un outil réellement utile et efficace.
Pour aller plus loin
Les travaux sur Accelerate continuent au sein du laboratoire DORA de Google. Ce laboratoire a mis en place un outil d’assessment rapide (https://www.devops-research.com/quickcheck.html). Il vous permettra facilement de mesurer votre niveau de maturité dans ce cadre. Par ailleurs, les capacités Accelerate ont été mises à jour, comme à chaque fois que l’étude State of Devops annuelle paraît.
D’un autre côté, Nicole Forsgren travaille maintenant chez GitHub où elle a produit le rapport SPACE.
Accelerate sert également de base aux livres édités par IT Revolution (https://itrevolution.com/devops-books/).
En France, certaines entreprises commencent à adopter les métriques définies dans Accelerate pour pouvoir étudier leur capacité à livrer et améliorer cette capacité.
Enfin, comme déjà écrit plus haut, nous utilisons de plus en plus Accelerate en interne comme cadre nous permettant de mieux qualifier nos interventions et nos pratiques.
Découvrez notre formation Accelerate
