Thierry De Pauw - From bi-annual to fortnightly release for 15 teams and a single monolith (EN)

[00:00:08] OK, bonjour. Euh, je suis Thierry et bah mince alors, il parle français le con et il fait sa présentation en anglais. Désolé.
[00:00:22] Bon, voilà. Euh, eh bien, je vais commencer par faire ce que je fais de mieux. C'est euh, être vulnérable. Tout le reste, c'est juste être un imposteur.
[00:00:37] Euh, donc je suis sacrément timide et introverti. Tous les bons ingrédients pour parler, n'est-ce pas ? C'est ça, ouais. Euh, en fait, je n'aime pas parler en public. Oui, pourquoi le faites-vous alors ? Eh bien, j'aime en fait avoir parlé et c'est euh, c'est un outil de réseautage fantastique pour les introvertis. Et je dois dire ça, sinon je ne me sens pas à l'aise. Donc, c'est fait, maintenant nous pouvons commencer. Euh, donc je vais partager le parcours de 15 équipes au sein d'une agence fédérale belge qui voulaient passer de euh, des livraisons bi-annuelles à des livraisons bi-hebdomadaires en moins de quatre mois.
[00:01:41] Euh, les 15 équipes travaillaient sur un seul monolithe. Euh, les 15 équipes étaient composées d'ingénieurs logiciels, d'ingénieurs de test et d'analystes. En parallèle, il y avait quelques euh, équipes de support transversales impliquées comme euh, les architectes, les administrateurs de bases de données, les euh, ingénieurs de build et de release et les ingénieurs d'infrastructure et d'opérations.
[00:02:15] Maintenant, le monolithe était écrit en Java utilisant la technologie EJB. Euh, il était très ancien, comme 15 ans, très grand, énorme, euh, déployé sur un unique serveur d'applications JBoss, euh, et utilisant cette unique et grosse base de données Oracle centrale. Classique, n'est-ce pas ? Maintenant, ce monolithe était assez important pour l'agence car c'est le seul logiciel qui faisait tourner toute l'activité de l'agence et qui servait également les 11 millions de citoyens belges. Donc, une chose assez importante.
[00:03:06] Ainsi, l'agence avait trois à quatre releases majeures prévues par an. Enfin, ils avaient l'habitude d'en avoir. Et ces releases majeures étaient un très gros problème. Chaque fois qu'une approche, le stress augmentait. Et puis il y avait un gel du code pendant des semaines, pendant lesquelles il y avait des salles remplies d'utilisateurs en sessions de test, euh, faisant des tests de régression et puis des tests d'acceptation, s'assurant que la nouvelle fonctionnalité fonctionnait comme prévu, s'assurant qu'aucune nouvelle régression n'était introduite, et pourtant, après chaque et unique release majeure, une série de correctifs urgents devait être appliquée en production. Hmm. Maintenant, tout le monde n'était pas amusé par ces releases majeures au sein de l'agence, en particulier les euh, les experts métier. Euh, les personnes situées entre le métier et l'IT. Elles voulaient voir les fonctionnalités livrées plus souvent parce qu'elles voulaient un retour plus rapide, elles voulaient voir comment ces fonctionnalités étaient utilisées en production et ensuite prendre de nouvelles décisions à ce sujet. Et donc, début 2017, quelques personnes se sont réunies, euh, pour discuter de la question, comment pouvons-nous nous débarrasser de ces releases majeures ? Euh, et ils ont vite réalisé, eh bien, que ce ne serait pas si facile et qu'ils avaient besoin du soutien de la direction.
[00:04:35] Euh, heureusement, la direction était assez favorable à l'idée, mais ils voulaient un business case avant d'approuver de travailler sur ce problème. Et donc,
[00:04:45] les gens ont alors commencé à estimer l'effort d'une release majeure et le résultat a été assez surprenant.
[00:04:53] Donc, chaque release majeure avait un délai de déploiement de 28 jours. C'est le temps entre la création d'un binaire et le déploiement de ce binaire en production. Et pendant ces 28 jours, 334 jours-personnes ont été consommés. Wow. Donc, avec cela, le dossier a été monté et la direction a approuvé le projet d'amélioration du processus de release.
[00:05:24] Donc, en septembre 2018, l'agence m'a contacté avec la question, oui, pouvez-vous nous aider à passer des releases bi-annuelles aux releases bi-hebdomadaires ?
[00:05:36] Et d'ailleurs, nous aimerions que ce soit fait d'ici la fin décembre.
[00:05:41] D'accord.
[00:05:43] Alors, vous pouvez imaginer ma surprise. Donc, dans ma modeste carrière, je n'ai jamais vu une organisation euh, aussi grande aller aussi vite vers euh, la livraison continue. Mais le bon côté, c'est qu'ils sont venus me voir et maintenant j'ai une histoire à partager.
[00:06:06] Maintenant, ça allait être ma toute première expérience avec 15 équipes. Assez, assez impressionnant. Euh, avant cela, j'avais eu une expérience avec sept équipes réparties entre la Belgique et l'Inde. Euh, je n'avais pas vraiment de plan pour gérer ça. Je n'étais pas vraiment satisfait du résultat, bien que l'organisation semblait l'être car ils sont revenus vers moi pour un autre département. Et avant cela, j'ai principalement travaillé avec des équipes uniques. Alors, cette fois, je voulais avoir, eh bien, quelque chose comme un plan ou plus précisément, eh bien, je voulais une structure qui m'aiderait à m'attaquer à ça. Et je ne voulais pas utiliser de modèles de maturité comme je l'ai souvent vu utilisé dans les transformations numériques parce qu'ils sont fondamentalement imparfaits. Donc, ils supposent que euh, l'apprentissage et l'amélioration sont linéaires, sans contexte et répétables entre les équipes et les organisations. Euh, ils se concentrent sur l'atteinte d'un niveau statique de changements technologiques et organisationnels et euh, ils euh, ils veulent juste atteindre un niveau statique, enfin, un niveau statique et un état statique, euh, appelé état mature, et puis ils disent que c'est fait. Et donc, eh bien, inévitablement, vous vous retrouvez avec le projet de transformation numérique classique, qui a une date de début et une date de fin définie à l'avance. Alors que nous savons tous que la transformation numérique n'est jamais réellement terminée. C'est une chose qui se produit continuellement et donc nous devrions nous concentrer sur euh, l'atteinte de capacités et de résultats et adopter un paradigme d'amélioration continue. Et donc, je voulais essayer le kata d'amélioration. Maintenant, au même moment, mon ami Steve Smith, que vous connaissez tous maintenant, euh, terminait son livre, Mesurer la livraison continue. Et curieusement, Steve utilisait également le kata d'amélioration, mais il l'a étendu avec la théorie des contraintes appliquée au processus de livraison IT afin de trouver les goulots d'étranglement et ainsi de trouver les expériences les plus susceptibles de réussir. Maintenant, habituellement, quand je suggère cette façon de travailler à des prospects, donc en utilisant le kata d'amélioration, en faisant de la cartographie de chaîne de valeur, euh, et puis en appliquant la théorie des contraintes, eh bien, la plupart du temps, j'ai le silence de l'autre côté de la ligne et je n'ai jamais de nouvelles d'eux. Et un jour, j'ai eu la réaction : mais ça va impacter tout notre processus de livraison IT. Et puis il y a eu le silence de mon côté, comme, que dois-je dire ? D'accord. Euh, mais cette fois j'ai eu de la chance. Mon contact à l'agence était le coach agile interne avec une solide expérience Lean et Kanban, qui euh, a pas mal aimé l'idée de mener des expériences et de prendre des décisions basées sur les données. Maintenant, plus tard, j'ai appris que la direction informatique n'était pas très amusée par l'approche, eh bien, parce qu'ils veulent une feuille de route, mais je ne peux pas donner de feuille de route parce que, eh bien, ce n'est pas parce que nous avons fait quelque chose dans une organisation que nous pouvons simplement rejouer, répéter cela dans la même, dans cette organisation.
[00:09:39] Chaque organisation est unique et a ses contraintes uniques.
[00:09:45] Donc, la première chose que nous avons faite a été euh, de mettre en place une équipe centrale qui dirigerait l'adoption de la livraison continue. Euh, et la raison en était que euh, je n'allais pas arriver là avec une armée de coachs. Donc, je ne suis pas McKenzie ou Accenture. C'était juste moi qui allais les aider. Euh, et donc avec ma disponibilité limitée et mon temps limité, il était impossible que je sois en contact avec les 15 équipes.
[00:10:17] Donc, par conséquent, j'allais être en contact avec l'équipe principale et l'équipe principale serait ensuite en contact avec les 15 équipes. Maintenant, la création de cette équipe centrale était assez simple. Ainsi, le coach agile a simplement envoyé un e-mail à toute l'organisation informatique invitant tout le monde avec suffisamment d'informations de base, d'intérêt et de motivation à participer. Et nous nous sommes donc retrouvés avec euh, 20 personnes représentant euh, les différents rôles des 15 équipes. Nous avions donc des ingénieurs logiciels, des ingénieurs de test, des euh, analystes, et nous avions également un architecte, un ingénieur de build, un ingénieur de release. Malheureusement, nous n'avons jamais vu les administrateurs de bases de données et nous n'avons jamais vu les euh, ingénieurs d'infrastructure et d'opérations, bien qu'il y ait eu pas mal de problèmes dans ce domaine également. Mais bon, peu importe.
[00:11:13] Maintenant, investir dans les pratiques qui rendent la livraison continue, la livraison continue est très précieuse. Et cela a été confirmé par la recherche académique menée par le Dr Nicole Forsgren et par le livre Accelerate également du Dr Nicole Forsgren et de ses amis. Où elle a découvert que, eh bien, en adoptant la livraison continue, les performances de livraison IT s'amélioreront, et avec l'adoption du lean product management et d'une culture organisationnelle générative, eh bien, il y aura une amélioration des performances organisationnelles. Comme nous parlons en termes d'argent, plus de chiffre d'affaires, générant plus d'argent. Mais vous devez comprendre que la livraison continue est en fait une approche holistique pour atteindre la bonne stabilité et la bonne vitesse pour vos services IT afin de satisfaire la demande métier. Et il ne s'agit pas seulement de vitesse comme beaucoup ont tendance à le penser. Eh bien, il s'agit avant tout de qualité et de stabilité. Nous avons donc besoin de la qualité et de la stabilité pour améliorer la vitesse, car cela évitera les reprises de travail. Mais nous avons aussi besoin de la vitesse pour améliorer la stabilité et la qualité, car, eh bien, la vitesse nous donnera un retour rapide qui nous permettra d'améliorer la qualité et la stabilité.
[00:12:38] Euh, et maintenant je suis un peu perdu.
[00:12:45] Maintenant, afin d'améliorer la vitesse et la stabilité, nous devons appliquer une grande quantité de changements technologiques et organisationnels à notre organisation. Et nous devons appliquer cela aux contraintes uniques et aux circonstances uniques de l'organisation, et c'est ce qui rend l'adoption de la livraison continue si difficile. Donc, cela commence par une liste de changements technologiques à adopter.
[00:13:18] Euh, chacune d'entre elles est très précieuse. Chacune d'entre elles est chronophage et assez difficile à adopter, mais chacune d'entre elles est un catalyseur de la livraison continue. Maintenant, avec ces changements technologiques, vient tout un tas de changements organisationnels qui sont beaucoup plus chronophages, beaucoup plus difficiles à adopter, mais beaucoup plus précieux que les changements technologiques. Alors, choisissons-en un. Alignement de la loi de Conway. Hier, il y a eu une discussion sur la loi de Conway.
[00:13:50] Donc, les administrateurs de bases de données et les ingénieurs de build et de release étaient dans des départements différents des 15 équipes, avec des chefs de service différents. En conséquence, eh bien, cela crée le surcoût de communication nécessaire. De plus, seuls les administrateurs de bases de données étaient autorisés à effectuer des modifications de base de données. Les 15 équipes n'étaient pas autorisées à toucher la base de données et les administrateurs de bases de données n'agissaient pas comme des coachs. Donc, de temps en temps, il arrivait que lors d'une release majeure, un changement de base de données ne soit pas appliqué. Oups.
[00:14:34] Eh bien, souvenez-vous de la série de correctifs urgents.
[00:14:38] Euh, maintenant, ce problème n'a jamais vraiment été résolu pendant ces quatre mois. Euh, nous avons dû attendre une autre crise quelque part en mars 2019 pour trouver une meilleure solution, pas encore comme elle devrait l'être, mais déjà meilleure.
[00:14:57] Euh, où commençons-nous ? Commençons-nous par améliorer la stabilité ou commençons-nous par améliorer la vitesse ?
[00:15:07] Maintenant, pour être honnête, ce ne devrait pas être une question car, eh bien, si vous êtes un jour confronté à euh, devrions-nous améliorer la vitesse ou la stabilité ? Eh bien, vous devriez vous concentrer sur la stabilité. La vitesse suivra. Toujours.
[00:15:21] Maintenant, mais devrions-nous commencer par appliquer des changements technologiques ou devrions-nous commencer par appliquer des changements organisationnels ? Quel changement devrions-nous faire en premier ? Lequel devrions-nous faire ensuite ? Lequel fonctionnera ? Lequel ne fonctionnera pas dans notre contexte ? Maintenant, pour avancer dans ces conditions incertaines, eh bien, nous avons besoin de quelque chose qui nous y aidera. Et c'est là qu'intervient le kata d'amélioration. Donc, le kata d'amélioration est un cadre d'amélioration continue pour euh, la mise en œuvre et la mesure du changement organisationnel. C'est donc un cadre pour atteindre des objectifs dans des conditions incertaines. Il a été décrit par Mike Rotter dans son livre, Toyota Katas, et il se compose de quatre étapes qui sont répétées en cycle. Nous commençons donc par définir une direction, une vision, un objectif, quelque chose que nous voulons atteindre dans un futur lointain.
[00:16:17] Il se peut que nous n'y parvenions jamais, mais le but est d'aligner tout le monde sur la direction afin qu'il soit clair où nous nous dirigeons.
[00:16:28] Et nous itérerons vers cette direction en utilisant des conditions cibles, donc des itérations d'amélioration avec un horizon allant d'une semaine à trois mois. Donc, une fois la direction fixée, nous commençons par analyser la condition actuelle. À quoi ressemble le processus actuel ? Quelles données avons-nous ? Euh, et ensuite nous définissons notre première condition cible, donc la première amélioration que nous voulons atteindre. Il a une date fixée et un objectif mesurable comme un critère d'acceptation. Maintenant, pendant cette phase de planification, l'équipe ne sait pas comment avancer dans la direction de la condition cible. Ce n'est que pendant la phase d'exécution que l'équipe commence à réaliser de très nombreuses expériences avec des changements technologiques et organisationnels, en utilisant le cycle PDCA. Donc, nous planifions une expérience et un résultat attendu. Nous exécutons l'expérience et collectons les données. Nous analysons le résultat et le comparons avec le résultat attendu. Si c'est un succès, nous intégrons le changement dans la base de référence. Si ce n'est pas le cas, nous le rejetons et nous recommençons. Maintenant, pour l'agence, le kata ressemblait à ceci. Donc, afin de satisfaire la demande métier des experts métier, eh bien, l'organisation a compris qu'elle devait adopter des releases bi-hebdomadaires. Donc, la direction était assez claire. Une dernière release majeure aurait lieu fin décembre et à partir de là, toutes les releases auraient lieu toutes les deux semaines.
[00:18:08] Pour analyser euh, la condition actuelle, nous allions organiser euh, un atelier de cartographie de chaîne de valeur pour cartographier les valeurs, la technologie, la euh, la chaîne de valeur technologique. C'est-à-dire toutes les étapes qui se déroulent depuis la validation du code dans le contrôle de version jusqu'à la mise de ce code entre les mains des utilisateurs en production. Maintenant, pour la cartographie de la chaîne de valeur, nous allions utiliser des post-it et nous allions faire cela en groupe avec toutes les personnes impliquées dans l'ensemble du processus de livraison IT de bout en bout présentes dans la salle. Maintenant, l'avantage des post-it est qu'ils sont plus fluides. Il est plus facile de les réorganiser et donc il est plus rapide d'itérer sur la cartographie de la chaîne de valeur qu'en utilisant des dessins. Et quand on fait ça en groupe, eh bien, que se passe-t-il ? Eh bien, ça commence en désordre et puis ça devient plus désordonné et puis ça devient vraiment, vraiment désordonné. Mais au fur et à mesure que les gens itèrent et affinent la carte de la chaîne de valeur, ils construisent sur la connaissance des uns et des autres. Il faut donc comprendre qu'une organisation est un système adaptatif complexe où, lorsque chacun ne dispose que d'une quantité limitée d'informations, personne n'a une vue d'ensemble complète de l'ensemble du processus de release IT de bout en bout. Donc, au final, nous nous retrouvons avec une carte de la chaîne de valeur qui intègre toutes les connaissances que toutes les personnes présentes dans la salle ont sur le processus de release.
[00:19:36] Et donc, nous nous sommes retrouvés avec cette carte de chaîne de valeur pour le processus de release majeure qui prend six mois. Donc, pendant cinq mois, il y a une accumulation de fonctionnalités.
[00:19:48] Ensuite, nous avons un gel du code de trois semaines. C'est à ce moment-là que nous avons des salles remplies d'utilisateurs en sessions de test. C'est là que les 334 jours-personnes commencent à être consommés. C'est aussi là que la prise de conscience commence à émerger que la qualité est en fait une chose. Et puis nous avons un déploiement d'une semaine.
[00:20:16] Et quand c'est fait, eh bien, nous avons du champagne. Chouette.
[00:20:21] Évidemment, nous venons de passer six mois à mettre quelque chose en production. Alors, eh bien, nous pourrions aussi bien le célébrer.
[00:19:44] monces, il y a une accumulation de fonctionnalités. Ensuite, nous avons un gel de code de trois semaines. C'est le moment où nous avons des salles remplies d'utilisateurs lors des sessions de test. C'est là que les 334 jours-personnes commencent à être consommés. C'est aussi là que la prise de conscience commence à émerger, que la qualité est en fait une chose importante. Et puis nous avons un déploiement d'une semaine.
[00:20:14] Et quand c'est fait, waouh, nous avons du champagne. Youpi !
[00:20:21] Évidemment, nous venons de passer six mois à mettre quelque chose en production. Alors, nous pourrions aussi bien célébrer cela.
[00:20:30] Mais cela a également révélé un deuxième flux de valeur, un processus de publication de correctifs beaucoup plus rapide, conçu pour les correctifs de production, qui se produisait toutes les deux semaines. Et où, occasionnellement, mais de plus en plus, des fonctionnalités étaient également déployées. Regardez ça. Comme c'est pratique.
[00:20:54] Alors, souvent, lorsque le coût de transaction pour la publication de fonctionnalités est trop élevé, souvent, un flux de valeur plus rapide, tronqué, émergera pour les correctifs de production, ce qui entraînera des flux de valeur doubles. Nous avons donc un flux de valeur de fonctionnalités avec des délais de plusieurs mois, et un flux de valeur de corrections avec des délais de plusieurs semaines. Ainsi, bien que ce soit un anti-patron, cela a été assez crucial pour le succès de ce parcours, car ce processus de publication de correctifs a révélé le potentiel de l'organisation à adopter la livraison continue. Donc à partir de ce moment-là, nous nous sommes uniquement concentrés sur ce processus de publication de correctifs et avons simplement abandonné le processus de publication majeur. Nous ne l'avons plus jamais regardé. Maintenant, certaines personnes étaient confuses par cette décision et ont essayé de ramener mon attention sur le processus de publication majeur en demandant, oui, mais pourquoi n'essayons-nous pas de réduire le délai du processus de publication majeur ? Ce à quoi j'ai répondu : eh bien, regardez, vous faites déjà cela. Vous publiez déjà toutes les deux semaines. Mais vous le faites sous le radar, de manière cachée. Maintenant, nous allons rendre cela visible et très transparent. Et nous pourrions très bien rendre ce processus de publication de correctifs plus stable afin de pouvoir remplacer le processus de publication majeur.
[00:22:18] Maintenant, afin d'identifier les expériences et afin d'identifier la prochaine ou la première condition cible ou la première amélioration que nous voulions atteindre, nous allions appliquer la théorie des contraintes au processus de publication des correctifs pour identifier le goulot d'étranglement. Donc, la théorie des contraintes est un paradigme de gestion introduit par Eli Goldrat dans son livre séminal de 1984, 'Le But'. Donc, si vous ne l'avez pas lu, je vous conseille vraiment de le lire. Si vous n'aimez pas lire des livres, il existe aussi une version bande dessinée, qui est en fait très bonne. Maintenant, la prémisse centrale de la théorie des contraintes est que chaque système a un seul goulot d'étranglement directeur.
[00:23:08] Et passer du temps à améliorer autre chose que le goulot d'étranglement n'est qu'une illusion. Donc, si nous avons un système linéaire composé des étapes A, B et C, et que B est le goulot d'étranglement, perdre une heure sur B, c'est une heure perdue pour l'ensemble du système. Gagner une heure sur A et C n'est qu'un mirage. Car si nous augmentons le débit sur A, cela ne fera qu'augmenter l'inventaire devant B, et si nous augmentons le débit sur C, cela entraînera une sous-alimentation en travail pour C. Maintenant, nous pouvons appliquer la théorie des contraintes sur notre chaîne de valeur technologique, car la chaîne de valeur technologique devrait être un processus homogène où chaque étape est déterministe, un peu comme dans la fabrication.
[00:23:55] Et maintenant, en appliquant la théorie des contraintes à notre processus de livraison informatique, eh bien, nous serons en mesure d'identifier le goulot d'étranglement et ainsi nous serons également en mesure d'identifier les expériences les plus susceptibles de réussir. Et donc, afin d'identifier le goulot d'étranglement, j'ai demandé à tout le monde dans la salle de prendre une note adhésive verte et d'essayer d'estimer la durée de chaque étape. Et puis prenez une note adhésive rouge et essayez d'estimer le taux d'échec de chaque étape. Maintenant, cela n'a pas besoin d'être très précis. La plupart du temps, les organisations n'ont pas cette information. Nous voulons donc juste avoir une idée, un ordre de grandeur.
[00:24:36] Maintenant, curieusement, le goulot d'étranglement n'était pas les tests de régression manuels, ni les tests manuels en pré-production, comme la plupart des gens s'y attendraient, moi y compris. Maintenant, le goulot d'étranglement était en fait les tests automatisés, l'exécution des tests automatisés. Oui, mais attendez. L'exécution des tests automatisés ne prend qu'une à quatre heures, alors que les tests manuels prenaient une demi-journée à une journée. Comment cela peut-il être un goulot d'étranglement ? Eh bien,
[00:25:12] Le test automatisé avait un taux d'échec assez élevé, et nous y reviendrons. ce qui a entraîné beaucoup de retravail et de réexécution des tests automatisés, ce qui s'ajoute au délai total. Et en outre, chaque voie que vous voyez là représente une branche de contrôle de version. Donc, à chaque fusion d'une branche, eh bien, le test automatisé devait être réexécuté, ce qui s'ajoutait au délai total.
[00:25:40] Maintenant, jusqu'alors,
[00:25:44] chacune de ces 15 équipes gérait ses tests automatisés de manière autonome. Chacune avait donc ses propres ensembles de tests automatisés. Et ils ont décidé au cas par cas s'il fallait exécuter les tests ou non, et quels tests exécuter ou non. Eh bien, principalement basé sur, oui, quels changements ont été appliqués au système, alors je suppose que nous pouvons exécuter ces tests et ces tests et ces tests. Euh, oui.
[00:26:15] Donc, en conséquence, personne n'avait vraiment une vue d'ensemble du nombre de tests existants et de leur stabilité. Donc, afin d'accroître la visibilité et la transparence sur ces tests, j'ai suggéré comme première expérience, eh bien, implémentons le pipeline de déploiement.
[00:26:34] Maintenant, ce n'était pas vraiment un pipeline de déploiement. Eh bien, il ne déployait pas dans les différents environnements. Il n'exécutait que des tests automatisés. Car le déploiement s'est fait avec un autre outil. Peu importe. Euh, maintenant, le pipeline de déploiement est un modèle de conception clé de la livraison continue. C'est donc la manifestation automatisée de la sortie du code du contrôle de version
[00:27:01] entre les mains des utilisateurs en production. Et le but est d'accroître la visibilité et la transparence sur l'ensemble du processus de publication de bout en bout, ce qui augmentera le feedback et qui augmentera également l'autonomisation des équipes. Dès lors, à chaque changement, tous les tests automatisés seraient exécutés. Maintenant, j'ai aussi suggéré qu'ils devraient collecter certaines métriques sur le pipeline de déploiement, le temps de cycle, et le taux d'échec. Le temps de cycle était donc de huit heures,
[00:27:33] et le taux d'échec était de 70%. Oups.
[00:27:37] Oui. Assez élevé. Maintenant, la raison du taux d'échec très élevé était assez diverse. Euh, premièrement, les tests automatisés se trouvaient dans un dépôt de contrôle de version différent de celui de la production, ce qui entraînait un décalage des tests automatisés avec le code de production. L'idée, ou plutôt le concept, qu'un test défaillant fasse échouer un candidat à la publication était totalement inconnu de l'organisation. Jusqu'alors, ils appliquaient quelque chose appelé l'analyse des échecs de test. Donc, chaque fois qu'un test échouait, ils en analysaient la cause. Si le test échouait à cause d'un changement récent de fonctionnalité couverte par le test, alors l'échec du test était accepté et le candidat à la publication était rejeté. Mais si aucun changement n'était survenu sur la fonctionnalité couverte par le test et que le test échouait toujours, ils se disaient, bon, ça ira, je suppose.
[00:28:40] Et ils ont donc accepté le candidat à la publication. Oui, qu'est-ce qui pourrait mal tourner, n'est-ce pas ?
[00:28:49] Euh, d'autres raisons étaient que, euh, les données de test n'étaient pas nettoyées avant d'exécuter les tests automatisés. Euh, beaucoup de tests dépendaient de services tiers, qui étaient parfois en ligne, parfois hors ligne, ce qui entraînait des tests en échec.
[00:29:08] Cela nous a donc conduits à cette condition actuelle. Nous avons donc deux flux de valeur : un flux de valeur de fonctionnalités, le processus de publication majeure, et un flux de valeur de corrections, le processus de publication de correctifs. Le délai du processus de publication de correctifs est de huit heures, et le taux d'échec est de 70 %.
[00:29:30] Maintenant,
[00:29:33] Pour la première condition cible, la première amélioration, l'équipe a décidé que ce serait la stabilité, ce qui est un choix juste. un choix juste étant donné que si vous améliorez la stabilité, la vitesse suivra.
[00:29:48] Et ils voulaient réduire le taux d'échec de 70% à 30% en un mois.
[00:29:57] Et puis ils ont commencé à identifier les expériences à exécuter. Le premier a donc été la mise en place d'un pipeline de déploiement, c'est fait, cochez. Euh, ils voulaient commencer à évaluer ou analyser les tests en échec quotidiennement et commencer à réellement faire quelque chose à ce sujet. Euh, ils voulaient recréer la base de données avant d'exécuter les tests automatisés afin que les données de test soient nettoyées avant d'exécuter les tests automatisés. Ils voulaient avoir un environnement séparé pour leurs tests automatisés par rapport aux tests manuels afin que, eh bien, il y ait moins de conflits entre les tests manuels et automatisés. Ils voulaient arrêter les services tiers et puis je leur ai suggéré, eh bien, ce serait aussi intéressant si nous pouvions collecter automatiquement des métriques sur le temps de cycle et le taux d'échec afin de pouvoir commencer à créer des tableaux de bord et à observer les tendances. Est-ce que nous nous améliorons ou est-ce que nous régressons ?
[00:31:05] Maintenant, c'était pour le plan. Maintenant, l'exécution s'est déroulée légèrement différemment, euh, et cela m'a pris six mois de plus après qu'ils aient atteint la livraison continue,
[00:31:19] pour réaliser que c'était en fait un exemple de, euh, conversations de peur. Eh bien, et en fait, ce sont Jeffrey Fredericks et Douglas Squirrel qui, euh, m'ont attiré l'attention sur cela.
[00:31:37] Euh, donc les conversations sur la peur nous ont aidés à atténuer la peur et à avoir les conversations difficiles que nous devions avoir pour avancer. Donc, les conversations sur la peur font partie des cinq types de conversations qu'une organisation devrait avoir pour devenir une organisation performante. C'est décrit par Jeffrey Frederick et Douglas Squirrel dans leur livre.
[00:32:00] Conversations Agiles. C'est, euh, enfin, je peux conseiller le livre. C'est vraiment bien. Maintenant, dans ce qui suit, je vais partager trois peurs, mais il y en avait d'autres. Euh, Et si vous voulez avoir la liste complète des peurs, eh bien, c'est dans le livre, Conversations Agiles.
[00:32:19] Donc la première peur était celle de la complexité. Donc quand je suis arrivé en septembre, le prochain cycle de publication majeure avait commencé quelque part en juin.
[00:32:31] Donc donner à l'organisation deux mois pour accumuler des fonctionnalités. Maintenant, je n'étais pas vraiment à l'aise avec l'idée d'avoir un grand basculement fin décembre entre la dernière version majeure et ensuite passer à des versions bi-hebdomadaires. J'ai pensé que ce serait trop risqué.
[00:32:51] Et donc j'espérais qu'il y avait un moyen de déplacer progressivement les fonctionnalités prévues pour la version majeure vers le processus de publication des correctifs, et de le faire de manière incrémentale, et finalement de se débarrasser de cette dernière version majeure pour que cela ne se reproduise plus. Maintenant, il m'a fallu pas mal de temps pour comprendre et encore plus pour accepter que cela ne serait pas possible. Et je me souviens que nous avons dessiné et dessiné sur le tableau blanc, essayant de m'expliquer pourquoi cela ne peut pas fonctionner.
[00:33:29] Et c'est ce que nous avons finalement mis au tableau. La raison pour laquelle cela ne fonctionnait pas était une stratégie de ramification complexe qui était en place. Ils utilisaient donc quelque chose qui ressemblait à un flux Git. Ils avaient donc une branche de développement à long terme et une branche principale ou semi-principale à long terme. Oui, maintenant ça devient intéressant, n'est-ce pas ? Euh,
[00:33:53] certaines équipes commettaient directement dans le développement. Certaines équipes commettaient dans des branches de fonctionnalités. D'autres équipes utilisaient des branches d'équipe et d'autres encore utilisaient une combinaison de branches d'équipe et de fonctionnalités.
[00:34:06] Auto-organisation. Autonomie, quelque chose comme ça. Euh. Maintenant, la plupart des branches vivaient pendant des semaines ou des mois.
[00:34:20] Maintenant, lors de chaque publication bi-hebdomadaire, ou plutôt, lors de chaque publication de correctifs, ce qui s'est passé, c'est que, euh, les correctifs et les fonctionnalités prévues pour la publication de correctifs étaient sélectionnés et déplacés de la branche de développement vers la branche principale. Ce qui a entraîné un éloignement de plus en plus marqué de la branche de développement par rapport à la branche principale et a rendu presque impossible la fusion de la branche de développement dans la branche principale. Alors, que s'est-il passé lors d'une publication majeure ? Eh bien, le déploiement s'est fait à partir de 'develop', ce qui était possible parce que 'develop' incluait tous les correctifs et fonctionnalités déjà déployés avec les processus de publication de correctifs. Plus les fonctionnalités prévues pour le processus de publication majeure. Et ils ont simplement supprimé la branche principale et en ont recréé une nouvelle, et ils recommencent. Alors, avec un grand soupir, surtout de ma part, nous avons accepté que pour atténuer cette peur de la complexité, il fallait simplement accepter qu'une dernière version majeure aurait lieu fin décembre. Avec le recul, je dois admettre que c'était moins risqué que je ne le pensais. Parce que, eh bien, dans la période précédant le basculement entre le processus de publication majeure et le processus de publication de correctifs, nous avons amélioré progressivement le processus de publication de correctifs et l'avons rendu de plus en plus stable. Et chaque fois que nous ajoutions de nouvelles améliorations, eh bien, elles étaient implémentées immédiatement et exécutées toutes les deux semaines. Donc, c'était suffisamment testé au moment où nous allions faire le basculement. Maintenant, l'équipe voulait aussi implémenter Git, enfin, un vrai Git Flow en janvier après la dernière version majeure.
[00:36:07] Maintenant, les gens qui me connaissent savent que je ne suis pas un grand fan du branching. Mais étant donné le contexte, il était juste d'opter pour cette implémentation. Maintenant, ils m'avaient aussi promis qu'ils travailleraient à réduire la durée de vie de leurs branches. Cela a moins bien fonctionné.
[00:36:30] Donc six mois plus tard, ils luttaient toujours pour avoir un pipeline de déploiement stable. Entre-temps, le délai est passé de huit heures à quatre heures, ce qui constitue une nette amélioration du cycle de rétroaction. Parce que tout d'un coup, ils pouvaient exécuter leur pipeline de déploiement deux fois par jour au lieu d'une fois par jour. Le nombre de tests automatisés a augmenté, non pas parce que les équipes écrivaient frénétiquement de nouveaux tests. Non, juste parce que les équipes découvraient, oh, nous avons un tas de tests ici, que nous avions oubliés. Devons-nous les ajouter au pipeline de déploiement ? Oui, faites-le, s'il vous plaît.
[00:37:07] Euh, mais la stabilité ne s'est pas améliorée du tout. Nous avons dû attendre fin novembre avant d'avoir le premier pipeline de déploiement d'écran où tous les tests étaient au vert, puis il est redevenu rouge pendant deux semaines supplémentaires. Oui, à ce moment-là, je n'étais pas vraiment rassuré que cela fonctionnerait.
[00:37:29] La deuxième peur était celle des échéances. Faisant partie du gouvernement, l'agence avait des échéances légalement imposées et, eh bien, ne pas respecter ces échéances n'était tout simplement pas une option. Mais la question est arrivée, eh bien, mais comment allons-nous atteindre ces objectifs difficiles sachant qu'un seul pipeline de déploiement défaillant peut bloquer une publication ? Et étant donné la stabilité du pipeline de déploiement, c'était une crainte légitime.
[00:38:00] Maintenant, pour atténuer cela, l'équipe principale a proposé une dérogation manuelle du pipeline de déploiement. Ainsi, malgré l'échec du pipeline, proche d'un objectif difficile, l'équipe pouvait décider de passer outre le pipeline de déploiement et d'accepter quand même le candidat à la publication. Et atténuer le risque en introduisant suffisamment de tests manuels. Maintenant, je n'étais pas très amusé par ce choix car je craignais que cela ne supprime la pression d'agir concrètement pour améliorer les tests automatisés. Et ma crainte a été confirmée, mais comme je l'ai déjà dit, six mois plus tard, ils avaient encore du mal à avoir un pipeline de déploiement stable.
[00:38:45] Et la dernière peur était celle des bugs, et c'était la plus grande préoccupation de la gestion informatique. Un seul problème grave ferait la une de tous les journaux belges pour l'agence et nuirait à sa réputation. Et encore une fois, étant donné la stabilité des tests automatisés, c'était une crainte bien fondée. Ainsi, de nombreux tests étaient instables, non déterministes, réexécuter un test défaillant en isolation le faisait souvent passer au vert. Maintenant, pour atténuer cela, l'expert QA a suggéré,
[00:39:23] eh bien, ne pourrions-nous pas diviser les tests automatisés en deux ensembles de tests ? Nous avons un ensemble de tests stables, qui sont la plupart du temps au vert, et ils sont exécutés par le pipeline de déploiement tout le temps. Et nous avons un ensemble de tests, euh, mis en quarantaine, instables, et ils ne sont exécutés que la nuit. Et chaque fois qu'un test en quarantaine échoue, il ne fera jamais échouer un candidat à la publication. Alors que si un test stable échoue, il fait échouer le candidat à la publication et le candidat à la publication est rejeté. Maintenant, curieusement, le temps de cycle a été réduit de quatre heures à deux heures. Donc, tout d'un coup, ils pouvaient exécuter le pipeline de déploiement quatre fois par jour. Imaginez l'accélération du feedback.
[00:40:18] Maintenant, la dernière version majeure a eu lieu comme prévu, fin décembre, sans problèmes majeurs, ce qui a rassuré la direction informatique pour avancer avec le plan d'adoption des versions bi-hebdomadaires. La première publication bi-hebdomadaire était prévue pour la troisième semaine de janvier. Tout le monde retenait son souffle, s'attendant à une tempête de problèmes. Et en fait, ça s'est très bien passé, sans grand problème. On avait l'impression d'une publication de correctifs normale, bien que le processus sous-jacent ait changé radicalement. Donc, en rendant les peurs discutables et en atténuant ces peurs, eh bien, cela a introduit suffisamment de protection pour que l'agence puisse avancer avec des publications bi-hebdomadaires. Et à partir de là, chaque publication sortait toutes les deux semaines, comme une horloge, et cela ne s'est jamais arrêté. Et je me souviens qu'à mon retour, après la première publication bi-hebdomadaire, eh bien, j'ai vu des sourires partout. Tout le monde était super excité. Ils ne pouvaient pas imaginer qu'un tel changement soit possible au sein d'une telle organisation, et pourtant ils l'ont fait.
[00:41:37] Les publications bi-hebdomadaires sont-elles considérées comme une livraison continue ?
[00:41:43] Eh bien, la livraison continue a un seuil de succès dynamique. Nous disons qu'une organisation est en état de livraison continue lorsqu'elle a atteint la bonne stabilité et la bonne vitesse pour ses services informatiques afin de satisfaire la demande métier. Et donc, avec les publications bi-hebdomadaires, la demande des experts du domaine était satisfaite. Alors oui, ils ont atteint la livraison continue.
[00:42:13] Cependant, j'ai aussi réalisé, et ce fut une sacrée surprise, qu'il est possible d'atteindre la livraison continue sans jamais atteindre l'intégration continue. Waouh, bien qu'il soit dit dans la communauté que l'intégration continue est un prérequis à la livraison continue. Ainsi, l'intégration continue a un seuil de succès statique. Nous disons qu'une organisation est en état d'intégration continue lorsque chaque membre de l'équipe ou de l'organisation s'engage au moins une fois par jour dans la ligne principale, chaque engagement déclenche une construction automatisée et l'exécution de tests automatisés, et, euh, chaque fois que la construction échoue, elle est réparée dans les 10 minutes. Maintenant, avec les données que nous avions sur l'agence, eh bien, il était clair qu'ils n'avaient jamais atteint l'intégration continue.
[00:43:06] Pff. Maintenant, est-ce une bonne chose ? Eh bien, non. Ce n'est pas une bonne chose. Nous ne serons pas en mesure de maintenir la livraison continue à long terme. Nous courrons un niveau de risque plus élevé de déploiements retardés et de pannes de production que les gens ne peuvent supporter. Et cela entraînera beaucoup de stress, beaucoup de fatigue et un épuisement professionnel. Et cela aura un impact sur la performance de votre organisation.
[00:43:43] Maintenant, souvent, quand j'étais là, je me demandais, eh bien, qu'est-ce que je fais réellement ici ? Ça n'avance pas. Ça ne mène nulle part. Euh, le changement était très lent. Les expériences n'étaient pas implémentées. La stabilité ne s'est pas améliorée. Je me sentais très peu de chose, très insignifiant et par moments vraiment, vraiment épuisé. Et pourtant, c'est arrivé.
[00:44:12] De la manière la plus inattendue. Et c'est arrivé, eh bien, parce que cette équipe principale était une équipe très performante, très motivée. Ils voulaient absolument atteindre cet objectif. Le coach Agile interne a passé beaucoup de temps à créer un environnement sûr. Euh, l'équipe principale a beaucoup communiqué au sein de l'organisation sur ce qui allait se passer, ce qui allait changer, quelles seraient les conséquences. Et, euh, aussi le le cadre temporel très court, moins de quatre mois, a créé un sentiment d'urgence. Et puis, surtout, l'équipe principale a simplement utilisé l'inertie de l'organisation à son avantage. Ils ont simplement décidé et agi plus vite que l'opposition n'a pu réagir.
[00:45:08] Maintenant, le principal, eh bien, le plus grand avantage de tout ce changement est qu'il a créé de la transparence et de la visibilité. Cela a mis en lumière tous les problèmes dont tout le monde était conscient, mais maintenant c'était visible. Euh,
[00:45:27] et une fois que les tableaux de bord étaient en place et montraient l'évolution du temps de cycle et de la stabilité, euh, la direction informatique s'est de plus en plus intéressée à cela et cela a débloqué plus de budget pour le coaching technique. Donc de mon côté, je n'ai passé que 12 jours de mon temps sur ce parcours.
[00:45:51] Euh, donc deux jours de lancement où nous avons défini le kata d'amélioration, fait l'atelier de cartographie des flux de valeur, appliqué la théorie des contraintes, puis défini la première amélioration cible et ensuite défini toutes les expériences. Et cela a ensuite été suivi par un suivi d'une journée, donc un jour par semaine de suivi par moi-même. Et donc mon rôle était davantage un rôle d'orientation et d'explication des principes et des pratiques. Tout le dur labeur, tout le travail d'amélioration a été en fait mis en œuvre par l'agence, pas par moi. Alors merci. C'était tout.

Transcription (Traduit)