Fabien Arcellier, ont organisé une matinale sur le thème d'Accelerate avec comme titre "La vitesse conditionne l'excellence : un nouveau paradigme dans le développement logiciel".
Une matinale pour éclairer et rendre activable l'étude Accelerate qui démontre, chiffres à l'appui, que la performance logicielle est déterminée par la faculté à livrer le plus souvent possible. Faire mieux, plus vite et à l'échelle, c'est une réalité accessible : pour y arriver, 24 capabilités concrètes à mettre en oeuvre dans votre organisation, des tests automatisés à la réduction de la taille des projets et des tâches en passant par la transparence de l'information et le découplage de l'architecture. Ca va parler DevOps, produit, méthodologie, culture, architecture...
==> les Slides de présentation
Accelerate un livre framework révolutionnaire ?
Christian Fauré, directeur scientifique d’OCTO Technology présente Accelerate (le livre) comme un coup éditorial qui, sans révolutionner les concepts bien connus du DevOps, a le mérite de les valoriser en répondant à la question cruciale qui s’impose de plus en plus dans les secteurs où l’IT est prédominante **"**Quelles sont les caractéristiques d’une organisation technologique performante ?"
Cette question fait écho à celle posée par Nicholas G. Carr dans son livre polémique Does IT matter? publié en 2004 où il présentait l'IT exclusivement comme un centre de coût.
A ce titre, nous percevons Accelerate comme un livre d’économie (du logiciel) qui établit scientifiquement la corrélation entre la performance du delivery logiciel et la performance économique d’une organisation.
L’ouvrage est la compilation et l’analyse des résultats d’une démarche scientifique démarrée en 2014 par les auteurs (Nicole Forsgren, Jez Humble et Gene Kim) qui a pour objectif de déterminer la recette magique des entreprises les plus performantes dans le delivery logiciel.
L’étude (DevOps Research & Assessment (DORA)), porte sur plus de 30 000 organisations de toutes tailles, de tous secteurs d’activités et de toutes les régions du monde. L’étude est un sondage déclaratif d’une série de questions sur le delivery de logiciel (les phases de conception et de design sont exclues de l’étude).
Cette étude, appuyée par un protocole scientifique robuste, permet de connaître l’état de l’art des pratiques en delivery logiciel pour faire émerger et partager les pratiques des meilleurs “performers” afin de rendre son organisation plus performante.
Un modèle de capabilités plutôt qu’un modèle de maturité
C’est là le coeur de l’ouvrage : une proposition de valeur fondée sur 24 capabilités concrètes adoptées par les organisations les plus performantes. La force du modèle de capabilités d’Accelerate tient essentiellement à deux choses :
par rapport à un modèle de maturité qui adopte une approche systémique (on considère l’état de l’ensemble du système), le modèle d’Accelerate offre une vision pragmatique et fournit des leviers d’amélioration activables
par rapport à un modèle de maturité qui pose une échelle de valeur subjective, le modèle d’Accelerate est intrinsèquement objectif puisqu’il se fonde sur la capacité d’une entreprise à réaliser telle ou telle opération de telle ou telle façon
En pratique, Accelerate présente 24 capabilités regroupées en 5 familles (en anglais dans le texte) :
Ces capabilités sont interconnectées et, avant de vous présenter comment les appréhender, nous commencerons par la fin en vous livrant les résultats de l’étude et les indicateurs de mesure que prônent le modèle et la conclusion de l’étude. Nous aborderons les influences du modèle Accelerate (DevOps, Lean, Flow et Agilité) puis les points forts de celui-ci pour conclure avec des recommandations sur la façon de mettre en place ce modèle dans votre organisation.
Enfin Jérôme Didat, d’Essilor Instrument nous partagera son retour d’expérience sur l’application du modèle Accelerate dans son équipe.
La performance de delivery comme facteur de prédiction de la performance globale de l’organisation (business et non business)
#Spoileralert : La conclusion de l’étude fait ressortir que les organisations les plus performantes dans leur delivery logiciel atteignent en moyenne deux fois plus souvent leurs objectifs que les organisations les moins performantes.
Les auteurs avaient d’ailleurs eux-mêmes du mal à le croire ! Mais même en ajoutant d’autres variables liées à la performance d’une organisation, le résultat des études des années suivantes (2015/2016/2017) reste sans appel : c’est toujours la performance dans le delivery qui est le facteur principal permettant de prédire la performance globale d’une entreprise.
Mesurer la performance du delivery : une tâche complexe
La performance du delivery s’entend comme la faculté à fournir de façon continue un logiciel à valeur ajoutée à ses utilisateurs.
Pour éviter les biais et obtenir des indicateurs comparables et durables, les auteurs ont fait le choix d’un parti-pris fort en considérant que la performance du delivery se mesure à partir du moment où le code est terminé et mis à disposition (donc hors phases de design, conception et développement), ceci afin d’éliminer la variabilité parfois extrêmes inhérentes aux activités de design.
Historiquement trois principaux indicateurs de mesure de la performance ont été utilisés et/ou le sont toujours :
Dans tous les cas, cet indicateur favorise l’optimum local au sein d’une équipe et pas l’optimum global à l’échelle d’un écosystème. Et l’on sait très bien qu’un SI est un ensemble de systèmes interconnectés entre eux et où de multiples équipes doivent travailler ensemble. Pour reprendre la citation de J-P Sartre “L’enfer c’est les autres”, il ne faut surtout pas oublier que “l’utilisateur voit le SI comme un produit qui rend un service mais pas comme un ensemble de logiciels”.
Mais alors, quelles sont les caractéristiques d’un bon indicateur de performance de delivery ?
3 critères principaux émergent :
La performance dépend autant de la cadence à laquelle les choses sont produites que de la stabilité et qualité des éléments produits.
Il est bon de se rappeler que souvent, quand on va vite, on fait des erreurs, et c’est pourquoi les 4 Indicateurs clés comprennent 2 indicateurs de vitesse et 2 indicateurs de stabilité.
Indicateurs de vitesse :
Indicateurs de stabilité :
L’ouvrage regroupe les organisations en 3 niveaux de performers :
L’état de l’art en 2017
Les enseignements à en tirer :
C’est l’une des grandes conclusions de l’étude :
Les organisations les plus rapides sont aussi les plus stables : entre vitesse et stabilité, il n’y a pas de choix à faire
Le modèle repose sur les meilleures pratiques issues des principaux courants de philosophie du développement logiciel
L’objectif est de briser le mur de la confusion entre développeurs et production.
Un des principes centraux de la culture DevOps est tout le monde est responsable :
Lean
Nous retenons de la philosophie lean qu’il faut limiter la parallélisation (des tâches) pour aller plus vite
Rappel de la LOI DE LITTLE (1961) ⇒ TEMPS DE RÉALISATION = TÂCHES EN COURS / DÉBIT)
Pour aller plus vite, on peut donc soit réduire l’encours, soit augmenter le débit. La solution la plus simple et la plus économique, c’est de limiter l’encours.
L’objectif du flow est de mettre en place une cadence rythmée : l’IT est caractérisée par une forte incertitude et il faut en tirer partie pour amener le produit / service au plus vite vers les utilisateurs pour savoir ce qu’ils veulent / aiment.
Pour cela, le Flow recommande de réduire la taille des lots car plus le lot est gros, plus il est risqué et plus il s’auto-alimente. Parmi les principaux problèmes liés aux lots de travail de grandes tailles, on peut citer : l'augmentation de l'incertitude et du risque, l'augmentation du besoin et des coûts de pilotage, la réduction de la vitesse de la boucle de feedback et la démotivation des équipes**.**
Donc pour aller vite et réduire les risques, la meilleure option est de réduire la taille de vos lots.
Economiquement, cette approche peut aussi s’avérer extrêmement avantageuse lorsqu’elle est couplée aux capacités techniques adéquates. C’est ce que démontrent les deux graphiques ci-dessous qui mettent en évidence le lien entre le coût du stock par rapport au coût de transaction pour un ensemble de fonctionnalités.
On constate que le principal levier d’action est le coût de transaction qu’il faut optimiser pour pouvoir livrer fréquemment à moindre coût. Cela passe par un ensemble de des pratiques et des techniques à mettre en place : DevOps, automatisation, QA intégré dans l’équipe…
En conclusion, les méthodes sont importantes mais il faut implémenter les techniques associées pour pouvoir en tirer parti, faute de quoi les méthodes seules risquent de n'avoir aucun sens d'un point de vue économique.
Et l’agile dans tout ca ?
Chez OCTO, nous sommes de fervents partisans de l’agile dont nous portons les convictions auprès de nos clients dans toutes nos missions.
Nous savons également que le manifeste agile décrit un état d’esprit général, des valeurs, une culture, une façon de faire et qu’il ne recommande pas une méthode ou un ensemble de pratiques à acquérir. Il donne une vision globale du processus mais pas du développement logiciel en lui-même. En conséquence, il se prête bien à un modèle de maturité mais mal à un modèle de capacité.
Le prérequis fondamental du manifeste agile est d’aller vite en production pour chercher rapidement de la valeur. Ce principe s’exprime ainsi dans le manifeste : “Notre plus grande priorité est de satisfaire le client en livrant au plus vite et de façon continue un logiciel de valeur”
En revanche, s’il expose la livraison rapide et continue de valeur comme un prérequis, il ne donne aucun indice concret sur la façon d’y parvenir.
(La réciproque est tout aussi valable : si vous ne livrez pas vite et bien, en continu au client alors vous n’êtes pas agiles)
Un autre principe est primordial :
“Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts”
Là encore, le manifeste ne donne pas un mode opératoire et c’est là que le modèle d’Accelerate entre en jeu et nous permet de trouver des réponses, notamment si notre objectif est d’acquérir la capacité et l’ambition de livrer au moment où on le souhaite (plus de détails dans la section suivante)
En conclusion
Ce qu’on cherche à faire dans le développement logiciel, c’est de se positionner au milieu de ce diagramme de Venn
Et comment y arriver ?
Dans ce triangle d’or, la façon habituelle de réaliser les choses est héritée des usages de l’industrie manufacturière :
Dans le développement logiciel, à cause de la nature incertaine de cette activité, nous avons la conviction qu’il faut faire l’inverse :
Entrons maintenant dans le détail du modèle. Comme le mettre en place ? Quelle implémentation est préconisée ? Comment prioriser ? Par quelles capabilités commencer ?
La bonne nouvelle, c’est que vous avez probablement déjà mis en oeuvre certaines pratiques donc personne ne part véritablement de zéro !
Le modèle en détail
Il comprend 24 capabilités, c’est-à-dire 24 pratiques concrètes et mesurables, regroupées en 5 familles :
Avertissement : Le niveau de “zoom” des capabilités est hétérogène, tantôt haut niveau comme la gestion des versions dans le continuous delivery tantôt très spécifique et opérationnel comme le trunk based development.
Les capabilités haut niveau méritent d’être creusées en profondeur pour les rendre parfaitement activables sur le terrain (ex. “tests automatisés” est très générique).
Nous n’allons pas rentrer dans le détail de chacunes des capabilités mais plutôt vous présenter l’esprit d’Accelerate sur les grandes familles du modèle.
Objectif: obtenir une vision pipeline de l’ensemble de mon application jusqu’à la production.
En pratique : sécurisation du pipeline, gestion automatique et maîtrisée de l’arrêt de la chaîne de delivery si des défauts sont repérés, versionning...
Objectif: se donner les moyens de garantir l’adéquation du produit au besoin
En pratique : rendre le travail des équipes visible, recueillir rapidement les retours utilisateurs par des tests UX, travailler en petits lots…
Objectif: accompagner les équipes dans la maîtrise de leur périmètre en autonomie.
En pratique : L’architecte s’assure de la déployabilité et la testabilité du logiciel, il aide les équipes à devenir autonome en définissant des territoires d’autonomie.
// Infos importantes // L’étude met en avant le fait que cela fonctionne qu’importe l’architecture initiale en place (monolithe, micro-services…)
Objectif : Agir sur les gestes du quotidien pour faire changer durablement la culture
En pratique : Pas de recette miracle, ce sont la mise en place des autres capabilités qui vont booster et changer votre culture.
On pense toujours que “la culture c’est les autres” (pour reprendre encore une fois la maxime de J-P Sartre). Ce qu’Accelerate propose en s’inspirant du béhaviorisme, c’est de renverser la perspective en s’attaquant à la culture par ses manifestations et non par ses fondements : pour changer la culture, il faut donc changer les gestes du quotidien plutôt que de tenter de modifier les systèmes de valeur ou leurs symboles les plus enracinés.
La philosophie de la démarche peut se résumer en une boucle continue entre mesurer l’impact et agir sur les capacités pour apprendre et s’améliorer.
Comment et par où commencer ?
Recommandation 1 : Adopter une approche progressive et durable
L’implémentation du modèle implique des changements profonds qui impactent toute l'organisation. Pour autant, nous préconisons une approche incrémentale pour que le changement essaime et que les premiers résultats appuient la démarche.
Actions suggérées :
Recommandation 2 : Commencer local avant de viser global
Nous conseillons de débuter par les familles de capabilités internes à l’équipe (Continuous Delivery et Product & Process) pour poser des bases solides qui permettront le passage à l’échelle de l’organisation avec les familles de capabilités transversales (Culture, Lean management & monitoring et Architecture).
Par ailleurs, notre conviction fondamentale, c’est que la technique et la méthode se nourrissent mutuellement. Le fait de commencer par les deux familles Continuous Delivery et Product & Process créé une boucle de feedback qui se renforce et permet à l’équipe d’être encore plus efficace sur ces deux familles de capabilités.
Recommandation 3 : Mesurer le passage à l’échelle
Le passage à l’échelle, c’est le moment de tous les dangers. Bonne nouvelle, ça se mesure, notamment au regard de l’indicateur “nombre de de déploiements par jours rapporté au nombre de développeurs”
Les principaux constats :
En d’autres termes, si vous augmentez la taille de votre organisation mais que votre fréquence de déploiement rapportée au nombre de développeurs stagne ou diminue, c’est que vous avez encore des capabilités à creuser avant de continuer à grossir.
Pour aller plus loin : en 2015, Amazon (pas AWS) déclare 50M de déploiement par an (voir cette vidéo : https://youtu.be/esEFaY0FDKc?t=1125)
Recommandation 4 : Privilégier l’internalisation
L’étude révèle que le recours massif de prestataires externes (outsourcing) est un facteur d’influence négatif sur les performances du delivery logiciel des organisations. Il est primordial que les compétences et les apprentissages liés à la mise en oeuvre soient maîtrisés et maintenus à long terme par les membres de votre organisation.
Dans la mesure du possible, il faut internaliser les connaissances et le savoir-faire et n’avoir recours à des prestataires externes que pour des besoins ponctuels d’expertises ou de conseils.
#Instantpub Un cas d’usage pertinent pour faire appel à un prestataire externe serait de mesurer l’avancement de votre organisation sur chaque capacité du modèle Accelerate. Nous avons développé une offre de conseil outillée OCTOBench (disponible en français et anglais) pour répondre à ce besoin croissant.
La démarche s’inscrit dans la continuité de l’étude DORA, avec une démarche d’auto-évaluation de vos équipe à l’aide un support de questions déclaratives, détaillées et une restitution précise sous forme de radar.
Nos experts vous accompagnent dans l’organisation de l’étude : choix des équipes à évaluer, préparation à l’envoi des questionnaires, recueil et analyse des résultats et restitution et recommandations sur mesure par rapport aux résultats. Intéressés ? Intrigués ? Contactez-nous.
Exemples de rendu :
Questionnaire :
Restitution :
Et si je veux commencer tout de suite, je choisis quelles capabilités ?
Nous avons observé 5 manques qui reviennent le plus souvent chez nos clients et nous y avons associés les 2 capabilités les plus essentielles pour s’engager dans un processus d’amélioration sur le modèle Accelerate (à l’exception du soutien aux équipes qui s’exprime par une seule capabilité).
A vous de définir de leur implémentation en fonction de votre contexte, de vos douleurs et de vos objectifs. Gardez toujours à l’esprit que l’approche la plus efficace consiste à aborder les problèmes avec un double angle d’attaque, à la fois technique et méthodologique.
==> Retrouvez en vidéo, le retour d’expérience de Jérôme Didat d’Essilor Instrument la mise en oeuvre du modèle Accelerate dans son équipe.