Fiche de lecture : "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations"

par Julien Kirch, le 8 octobre 2018

Ce livre par Nicole Forsgren, Jez Humble & Gene Kim est une étude s’appuyant sur les résultats des sondages State of DevOps Report de Puppet Lab qui mesurent l’état des pratiques autour du développement et des opérations.

S’appuyant sur les statistiques des différents études, l’objectif est de dégager des tendances sur les pratiques et les approches qui donnent les meilleurs résultats. Pour valider leur approche, une partie du livre couvre le détail des différents calculs.

Avec un avant-propos de Martin Fowler et des critiques louangeuses d’autres grands noms, c’est un des livres qui buzze cette année.

Rien de révolutionnaire mais des chiffres

Le livre n’offre pas d’approche ou d’idée révolutionnaire. Ce qu’il propose correspond assez bien aux bonnes pratiques actuellement prônées autour du DevOps, des pratiques agiles et de l’architecture évolutive. Les deux points forts du livre étant de proposer une synthèse pédagogique et de s’appuyer sur des chiffres.

Pour une personne qui veut s’intéresser au domaine, il s’agit d’une bonne introduction, d’autant qu’il se lit vite.

Pour moi la lecture a été rendue un peu pénible par le ton très buzzwordiens : les mots comme delight ou leverage abondent dans le texte. C’est probablement le genre qui veut ça, mais ça n’en reste pas moins désagréable.

Les idées pas vues ailleurs

Le livre contient tout de même quelques éléments intéressants que je n’ai pas souvenir d’avoir lu ailleurs, ou pas énoncé de cette manière.

La clé : le soutien de la direction

Le livre répète plusieurs fois que la différence entre les organisations où une tentative d’amélioration donne des résultats et celles où elles échouent n’est pas tant dans la cible que dans le niveau de soutien hiérarchique dont l’initiative bénéficie.

En effet changer les choses prend du temps et de l’énergie, et les résultats arrivent souvent moins vite qu’espéré, ou que prévu. Il est alors tentant d’abandonner ou de changer d’avis, surtout quand il faut demander de nouveaux budgets. La clé est alors la persévérance, qui suppose un appui hiérarchique ferme et haut placé.

L’écart se creuse

D’après les analyses du livre, l’écart se creuse entre les organisations qui ont entamé un chemin vers une meilleure qualité et des cycles plus courts et les autres.

D’après les chiffres, les gains qu’elles en retirent augmentent petit à petit avec l’amélioration progressive de leurs manières de faire, et donc également l’écart avec les organisations qui n’ont pas investi dans ces domaines.

L’agile et le DevOps ne sont donc pas des features qu’on met en place une fois, et où le fait d’attendre le plus possible permettrait de bénéficier des retours d’expérience des autres et de les rattraper en une fois, mais des chantiers à ouvrir dès que possible.

Le rythme et la qualité

Sur l’écart entre les organisations, l’étude montre qu’il est plus facile de progresser sur le rythme des livraisons que sur leur qualité.

Cela correspond à ce que j’observe autour de moi : en changeant les plannings et en s’outillant, livrer plus souvent peut être un objectif atteignable avec un effort limité, alors qu’améliorer la qualité demande un vrai changement de manière de travailler.

Cela correpond probablement aussi aux conséquences des messages passés par les éditeurs qui vendent des outils d’automatisation labellisés "DevOps".

Impact de la vélocité sur le SI

Le pilotage par la vélocité est mentionné dans les choses à ne pas faire, en ligne avec d’autres publications récentes sur le sujet.

Le livre explore un effet secondaire de la mesure de vélocité qui est son impact sur le SI.

Pour maximiser sa vélocité, le mieux est de limiter sa dépendance aux autres équipes. En effet : si les autres ne sont pas disponibles au bon moment, impossible de terminer la mise en place de la fonctionnalité, et adieu aux précieux points.

La conséquence est de pousser à faire des optimisations locales au niveau du projet plutôt que des optimisations au niveau du SI. Les conséquences possibles sont classiques : redondances, difficultés d’évolutions, et donc dette technique.