Ma rencontre avec Accelerate et son impact au sein des équipes

Cet article fait partie de la thématique Accelerate : Comment améliorer le processus de delivery ? Il s’agit d’un retour d’expérience sur la mise en oeuvre d’Accelerate chez mon client et l’impact qu’il a eu sur les équipes.

Le contexte

Depuis 1 an, j’ai intégré la Digital Factory d’un des leaders mondiaux de l’énergie au sein d’un produit dont l’objectif est de mettre à disposition une plateforme technologique qui offre des services intelligents aux collectivités locales françaises et/ou étrangères. Elle propose par exemple d'améliorer la consommation d'énergie, la congestion du trafic, la sécurité et la qualité de l'air.

Comme tout projet, nous sommes confrontés à plusieurs problèmes :

• Difficulté à s’approprier une base de code complexe, car le produit a été conçu avec une vision plus technique que fonctionnelle.
• Difficulté à faire évoluer le produit avec de nouvelles fonctionnalités, compte tenu de l’existant.
• Difficulté à déployer une nouvelle version. Chacune prend environ 100 jours à arriver en production. C’est long, fastidieux et décourageant pour les équipes.
• Difficulté de synchronisation entre les équipes qui s’entendent bien mais qui n'interagissent pas assez.

Il est constitué de 5 équipes qui collaborent. Cela représente plus d’une quarantaine de personnes dont les 3/4 proviennent de la technique (développeurs, Tech Lead, OPS, architectes, experts sécurité) et 1/4 du métier (Business Owner, Product Owner, experts).

En parallèle, une initiative est lancée chez notre client pour améliorer et harmoniser les pratiques de nos plateformes et nous sommes choisis comme pilote.

2 coachs / experts techniques sont intégrés au sein des équipes sur une durée de 6 mois.

Le but du récit

Je souhaite vous partager ci-dessous mon retour d’expérience avec la boîte à outils Accelerate, ce que j’ai vécu et vis aujourd’hui et ce que j’en retire.

Le récit est décomposé en 3 étapes principales :

-   Rendre plus lisible et modulaire la base de code et la retranscrire dans une logique métier.

-   Introduire la boîte à outils Accelerate.

-   Initier une démarche qui fait écho à Accelerate et s’est nourrie du travail réalisé par les 2 coachs sur l’approche Domain-Driven Design et Software craftsmanship

Vous verrez qu'au travers de l’article, c’est une combinaison de plusieurs facteurs qui permet d’arriver aux résultats actuels.

La première étape : Rendre plus lisible et modulaire la base de code et le retranscrire dans une logique métier

Après une phase d'observation, nos 2 coachs sont intervenus dans une approche de Domain-Driven Design en organisant des ateliers d’EventStorming avec les équipes (il s’agit d’une approche créée par Alberto Brandolini permettant de vous aider à modéliser votre domaine métier en équipe.). L’idée est de rendre le métier expressif dans le code en purgeant les abstractions technico-techniques et en s'assurant que l’intention et le vocabulaire utilisés soient explicites. Quel service est censé rendre le produit ? Quels sont ses principaux domaines pour le faire ? A qui s’adresse t-il ? Quel événement déclenche quoi ? Qui le déclenche ?

Je souhaiterais vous partager les principaux bénéfices de cette approche dans le cadre du projet :

-   Le premier a été de montrer des divergences entre les différents Product Owners sur la représentation du produit et les services qu’il devait rendre afin de converger par la suite (quels sont les principaux domaines qui constituent mon produit, quels sont les événements qui y sont déclenchés, par qui, quels sont les composants techniques qui sont sollicités).

-   Le second qui découle du premier ci-dessus, l’architecture technique mise en place était trop compliquée à assembler pour être déployée. Nous nous étions éloignés peu à peu du métier.

-   Le troisième a été  de simplifier notre CI/CD qui était trop complexe, peu automatisé, avec beaucoup d'opérations manuelles. Elle ne permettait pas de déployer facilement une release applicative.

-  Le quatrième a été de hiérarchiser et prioriser les principaux domaines auxquels le produit devait répondre. Un service (micro-service) a été choisi pour dérouler la démarche.

-   Le cinquième a été de partager que nous n’avions pas de référentiel métier commun.

-   Le sixième nous a montré que nous n'avions pas de pratiques communes au niveau des équipes de développement.

Cela reflète bien nos difficultés rencontrées au quotidien. Quand vous ne partagez pas une vision commune, que le design de votre produit devient de moins en moins lisible, que vous ne partagez pas de vocabulaire et de pratiques communes, il est de plus en plus difficile de faire évoluer le produit et le déployer devient une douleur.

Pour rendre le code plus modulaire et lisible et garder cette approche métier, le premier cas d’usage a été de réaliser un refactoring sur un micro-service qui posait question et qui a été déroulé comme fil rouge de toute l’approche Domain-Driven Design, du design jusqu’à l’implémentation et la livraison pour valider la pertinence de la démarche.

Non seulement les coachs ont apporté l’approche DDD (Domain-Driven Design) mais, comme ils ont travaillé main dans la main avec les équipes, ils ont participé à l'amélioration des pratiques de développement et, chemin faisant, ils ont commencé à murmurer à l’oreille du Tech Lead.

La seconde étape : L’homme qui murmurait à l’oreille de notre Tech Lead transverse et introduit la boîte de pandore : Accelerate

Une fois la vision commune partagée, un des coachs a commencé à introduire la boîte à outils Accelerate et ses concepts sous-jacents au Tech Lead de la plateforme transverse afin d’appréhender les différentes facettes d’Accelerate et de structurer une démarche.

Quelques éléments sur Accelerate :

• Blog OctO :  https://blog.octo.com/compte-rendu-matinale-accelerate-la-vitesse-conditionne-lexcellence-un-nouveau-paradigme-dans-le-developpement-logiciel/
• Livre Accelerate : The Science of Lean Software and DevOps: Building and Scaling High Performing Technology - Auteurs : Nicole Forgesen Phd, Jez Humble et Gene Kim : https://itrevolution.com/book/accelerate/
• Podcast Accelerate : http://bit.ly/2Z3oiOA

La troisième étape : La démarche

Précisons que la démarche choisie est propice à notre contexte et si vous le souhaitez, vous pouvez vous inspirez des éléments proposés par l’approche Domain-Driven Design et Accelerate

• Lorsque nous sommes arrivés sur le projet, nous avons identifié plusieurs problèmes : complexité à implémenter et à déployer des features, une équipe OPS pas forcément intégrée à l’ensemble du système de delivery, des périmètres fonctionnels non partagés par les équipes, des pratiques organisationnelles, techniques et fonctionnelles pas toujours partagées, des équipes qui ne communiquaient pas assez entre elles. Nous avions initié un certain nombre de sujets afin de répondre aux difficultés ci-dessus sans savoir que nous utilisions les capabilities proposées par Accelerate.
• Le produit était en cours de construction avec une forte pression du business pour déployer des fonctionnalités. Nous ne souhaitions pas déstabiliser l’ensemble des équipes et nous avons décidé de privilégier l’approche des petits pas afin d’avoir un impact sur le produit et les équipes. ll nous a fallu 6 mois pour commencer à voir les premiers effets.

Un des freins au sein du projet était qu’il nous fallait une centaine de jours pour déployer une nouvelle version. C’était long, fastidieux et générait beaucoup de frustration tant au sein des équipes que chez le client. Par ailleurs, nous n’avions pas de métriques partagées et simples à mettre en œuvre nous permettant de bâtir un référentiel et de mesurer notre progression.

Les 12 travaux

Je vous propose de me suivre au travers de ses 12 travaux herculéens qui ont été réalisés au fil de l’eau et d’autres de façon séquentielle. Ils ont été traités sous forme de Problème / Solution / Gains.

• Le premier travail : Simplifier l’application en se concentrant sur le cœur du métier, le code et l’architecture.

-   Problème : Comme vous avez pu le lire plus haut, il était devenu difficile de traduire des concepts métiers afin de les implémenter et de les déployer.

-   Solution : Une démarche de Domain-Driven Design (DDD) a été initiée pour simplifier des pans de l’application rendus complexes accidentellement par leur implémentation technique. En parallèle de l'initiative de DDD, des pratiques de craftsmanship ont été mises en place pour améliorer la qualité de nos développements et faire collaborer les équipes entre elles.

-   Gains : Une base  de code plus lisible et modulaire retranscrite dans une logique métier. Des pratiques de développement partagées par les équipes. Des équipes qui communiquent et partagent plus facilement entre elles pour faire évoluer le produit.

• Le second travail fut de définir un langage commun.

-   Problème : Nous n’avions pas de langage commun d’un point de vue métier (pour décrire les domaines fonctionnels de l’application, les événements qui les déclenchent, qui fait quoi ? Ce que cela implique techniquement ? Ce qui est prioritaire ou pas ?...) et sur les processus de delivery. Le contexte multi-équipes et les 2 ans de projets nous ont un peu éloignés les uns des autres. La compréhension est souvent présupposée mais pas souvent vérifiée.

-   Solution : La partie métier a été vue au travers de la démarche Domain-Driven Design, la partie processus de delivery a été réalisée sous forme d’ateliers avec les équipes, formalisée au travers d’un wiki interne et restituée aux équipes pour partager et améliorer le dispositif

-   Gains : Un git flow partagé et compris de tous, des pratiques communes décrites et appliquées pour faciliter notre processus de delivery qui sont revues régulièrement.

• Le troisième travail a été de construire des métriques de façon manuelle avant de les automatiser afin de partager un référentiel commun.

-   Problème : Nous savions que notre processus de déploiement était extrêmement long et peu efficace (100 jours pour déployer une release) mais nous n’avions aucune métrique simple, compréhensible et partagée par tous pour nous améliorer.

-   Solution : Nous avons décidé avec l’aide de nos coachs de mettre en place les indicateurs Accelerate :

-   La fréquence de déploiement (Deployment Frequency) => A quelle fréquence le code est-il déployé en production ?

-   Le délai de déploiement (Lead Time for Change) => Combien de temps me faut-il pour envoyer une modification de code en production

-   Le délais de réparation d’un défaut (Mean Time to Restore) => Combien de temps me faut-il pour restaurer un service inopérant

-   Taux d’échec sur changement (Change Failure Rate) => Quel est le ratio de déploiements considérés comme des échecs ?

Pour la mise en œuvre, l’ensemble des équipes ont été accompagnées avec pour objectif d’expliquer la démarche, les indicateurs, comment les interpréter et les calculer. Les indicateurs étaient visibles de tous. Par la suite, notre Teach Lead  a automatisé la production de ces indicateurs. Nous avons décidé de ne pas prendre en compte dans le cadre du lead time nos déploiements d’infrastructure qui ne posaient pas de souci et de nous concentrer sur la partie applicative pour être au plus proche de notre quotidien.

-   Gains : Nous pouvions factualiser nos problèmes, nous avions un référentiel partagé et nous pouvions suivre notre progression et mettre des actions en place si besoin pour nous améliorer.

• Le quatrième travail a été de simplifier notre CI/CD afin de redonner la main aux développeurs pour déployer leur code

-   Problème : Nous avions de multiples problèmes :

- Une CI/CD automatisée uniquement sur notre environnement de développement et de nombreuses opérations manuelles de déploiements sur nos autres environnements

- Nos tests avaient été déconnectés de notre CI.

- Toutes les équipes n'étaient pas familiarisées avec jenkins, notre git flow n’était pas partagé ou compris de tous.

- Un concepteur unique, qui n’a jamais pu bénéficier de la part de ses pairs OPS de retour sur le travail effectué dans le développement de ses pipelines.

- Beaucoup de code défensif qui rend la lecture du pipeline, son acquisition par autrui, sa maintenance et ses évolutions difficiles (Ex : check défensif sur le mail de l’utilisateur GIT au moment de lancer les tests unitaires).

Des pipelines qui font trop de choses, avec de la logique applicative pour faire de la gestion d’erreurs fines au lieu de laisser les pipelines échouer naturellement et apporter un feedback simple en cas d'échec.

Les développeurs, principaux utilisateurs de ces pipelines, ne sont pas impliqués dans la conception.

Le concepteur qui avait du mal à recevoir du feedback sur les pipelines car pendant très longtemps il s’est retrouvé seul à tout mettre en place.

Par conséquent, personne n’utilisait vraiment notre CI/CD ce qui induisait de forts ralentissements dans notre processus de delivery.

-   Solution : Le travail et le partage collaboratif des équipes OPS et de développement ont permis d’améliorer le git flow (gestion des branches, quand merger et comment le faire), de faire des rétros ensemble, des ateliers, du pair programming autour de la CI/CD entre autres

Nous avons dans notre contexte :

-   Simplifié l’utilisation de la CI/CD en limitant le nombre excessif de paramètres rendant optionnelles les étapes qui étaient en fait essentielles pour l’équipe (analyse de code avec SonarQube par  exemple).

-   Factorisé les appels à la CD. 1 seul appel à la CD par commit pour tous les composants (avant c’était 1 par composant)

-   Gains : Le refactoring de la CI/CD a permis aux développeurs de prendre la main sur le déploiement de l’environnement de recette.

• Le cinquième travail a été de converger vers un périmètre fonctionnel commun lorsque nous souhaitions déployer une release

-   Problème : Il nous était difficile de définir le périmètre d’une release commune entre les différentes équipes pour plusieurs raisons :

-   Elles n'échangeaient pas ensemble pour définir un périmètre commun.

-   Chaque équipe avait ses propres échéances.

-   Solution : Plusieurs actions ont été mises en place :

-   Les PO’s ont décidé de se réunir à intervalles réguliers afin de définir une release commune.

-   Le périmètre était partagé avec l’ensemble des équipes y compris l’équipe OPS ce qui permettait de faire des ajustements

-   Gains : Un périmètre fonctionnel partagé pour une release donnée.

• Le sixième travail a été d’intégrer la notion de « feature toggle »

-   Problème : Nous ne faisions pas de distinction entre MEP et activation pour le client. Comme nous devions nous coordonner entre les différentes équipes pour déployer la release, cela présupposait que chaque fonctionnalité devait être finalisée afin d’être déployée. Ce qui n’était pas le cas et nous devions reporter certaines fonctionnalités dans une prochaine itération qui engendrait des frustrations au sein des équipes.

-   Solution : Les équipes de développement ont mis en place pour chaque fonctionnalité des features toggle afin de décider si nous devions ou pas les activer pour le client final.

-   Gains : nous avions un périmètre fonctionnel partagé et nous ne nous posions plus de question sur le code qui devait être embarqué dans une release.

• Le septième travail a été de mettre à disposition des documents pour les équipes ayant pour objectif de faciliter le déploiement d’une release et d’organiser des revues collectives.

-   Problème : A l’origine, l’équipe OPS allait à la rencontre des différentes équipes pour déterminer les versions et les composants associés à déployer. C’était une activité chronophage pour laquelle l’équipe OPS n’avait pas de valeur ajoutée. Nous ne faisions pas de revue collective pour garantir que nous n’avions rien oublié et que tout était clair pour les équipes chargées du déploiement.

-   Solution : Nous avons décidé collectivement de rédiger plusieurs documents et d’organiser des revues croisées entre équipes. La Functional Release Note (périmètre fonctionnel de l’application à déployer), la Technical Release Note (composants techniques à déployer) prise en charge par les équipes de développement et la fiche de version des composants techniques.

-   Gains : Cela nous a permis de :

-   Partager un périmètre fonctionnel entre les PO’s  et les équipes

-   Responsabiliser les équipes de développement sur ce qu’il y avait à déployer et le partager avec l’équipe OPS.

-   Rédiger des procédures de validation par les équipes de DEV et PO’s pour que les équipes OPS après déploiement puisse valider le bon fonctionnement de la release sans attendre la disponibilité des PO’s

-   Seul le Go de Technical Release Note permettait aux équipes de préparer le merge de la branche concernée qui serait notre future release candidate.

-   Améliorer la qualité de notre delivery.

• Le huitième travail a été d’identifier des porteurs qui sont responsables de l’avancement de la release au sein de chaque équipe.

-   Problème : Personne n’était identifié pour épauler l’équipe OPS au sein des équipes de développement lorsque celle-ci rencontrait une difficulté et nous perdions un temps précieux pour analyser et corriger les problèmes.

-   Solution : Nous avons décidé d’identifier des porteurs pour chaque équipe afin de les responsabiliser et d’être réactif en cas de problème. Nous avons organisé des réunions quotidiennes de 10 minutes pour faire un point d’avancement sur la release et lever les blocages potentiels accompagnées d’un compte rendu.

-   Gains : Nous pouvions nous appuyer sur des personnes identifiées sans perturber le déroulé des équipes de développement. Le point quotidien permet à tout un chacun de connaître l‘avancement de la release.

• Le neuvième travail a été de collaborer plus étroitement entre DEV et OPS afin que chacun appréhende le quotidien de l’autre.

-   Problème : Chaque équipe restait dans sa zone de confort sans se soucier de l’autre. Une fois les développements terminés, c'était à l’équipe OPS de déployer la release et l’équipe OPS ne prenait pas le temps de s’imprégner de ce que les équipes de développement réalisaient.

-   Solution : Nous avons notamment mis en place un binômage systématique entre développeurs et OPS lors du déploiement d'une release sur les différents environnements. L’idée était que chacun se rende compte du quotidien de l’autre, des difficultés qu’il pouvait rencontrer.

-   Gains : Cela nous a permis de resserrer nos liens, de partager, de monter en compétences et d’être plus proactifs.

• Le dixième travail a été de construire un environnement dédié à l’équipe OPS

-   Problème : Nous n’avions pas d’environnement dédié pour qualifier nos déploiements d’infrastructure et l’environnement de développement était vu par les équipes OPS comme un environnement de PROD avant de valider nos procédures pour déployer sur tous les autres environnements. L’impact pour les équipes de développement et les PO’s est que nous rendions indisponible et parfois instable cet environnement. Les équipes ne pouvaient plus travailler correctement et les PO’s ne pouvaient pas valider les fonctionnalités

-   Solution : L’équipe OPS a construit un environnement dédié pour valider ses déploiements d’infrastructure afin de perturber le moins possible l’environnement de développement.

-   Gains : Un environnement de développement plus disponible pour les équipes concernées qui permet de valider le fonctionnel en amont des livraisons sur l’environnement de recette.

• Le onzième travail a été de compléter les outils de monitoring existants pour nous assurer que l’application était opérationnelle, gagner en réactivité lorsqu’un problème survenait et le partager avec les équipes de développements

-   Problème : Nous avions comme outil de monitoring splunk qui nous renseignait sur l’état de nos serveurs, charge cpu,..., Ce qui était une première information mais elle ne permettait pas de valider si notre API Manager était opérationnelle et même de vérifier que nos micro- services étaient toujours valides. L’impact était réel car à chaque fois qu’un membre de l’équipe nous informait d’un dysfonctionnement, nous mettions beaucoup de temps et d’énergie à analyser la root cause et en définitif identifier si cela relevait d’un problème d’infrastructure ou applicatif.

-   Solution : L’équipe OPS a mis en place grafana afin de monitorer l’API Manager et les micro-services rattachés. Puis nous l’avons présenté à l’ensemble des équipes pour les sensibiliser et avoir leur feedback, notamment ce qu’elles souhaitaient voir monitorer comme composant. Nous avons pour objectif de mettre un écran pour les équipes en présentiel afin de visualiser en temps réel la bonne santé de l’application.

-   Gains : L’ensemble des équipes adhère à l’outil et l’utilise pour vérifier que l’application est opérationnelle. Nous sommes plus réactifs en cas de problème et nous pouvons prévenir l’équipe concernée.

• Le douzième travail a été d’automatiser les indicateurs Accelerate et de faire des post-mortems avec les équipes à chaque fin de release en prenant pour référence les 4 indicateurs Accelerate  pour échanger et prendre des actions en vue de nous améliorer continuellement

-   Problème : Nous rencontrions 2 problèmes. Le premier : Il était parfois long de restituer nos indicateurs pour échanger avec l’ensemble des équipes. Le second : Nous étions passés de cent jours pour déployer une release à 20 jours mais nous n’arrivions pas à faire mieux depuis plusieurs releases sur la partie lead time qui était pour rappel une de nos plus grosses douleurs.

-   Solution :

Première action prise :

-   Nous avons décidé d’automatiser nos indicateurs pour fiabiliser notre collecte et faciliter sa restitution. Ce qui nous a permis de ritualiser nos post-mortems.

Seconde action prise :

-   Les développeurs ont spontanément décidé de prendre la main et de déployer sur l’environnement de recette. L’idée était qu’en cas de correctif ils leur seraient plus facile d’intervenir et de redéployer. C’est ce que nous avons mis en place. Un changement de comportement a été opéré puisqu'avant, ils laissaient l’équipe OPS déployer l'application sans se soucier de la partie infrastructure. Cette action a été faite conjointement entre les équipes de développement et les OPS afin que les développeurs deviennent autonomes.

Troisième action prise :

-   Nous avons malgré tout, vu que si les équipes de développement prenaient la main sur la partie infrastructure ce qui était une excellente chose, l’impact en lead time était très faible. Nous avons identifié 2 points complémentaires. L'environnement de développement était souvent instable (cf travail n°10) et la qualité du delivery pouvait être améliorée en demandant aux PO’s de valider les features le plus en amont possible afin de connaître le moins de problème en environnement de recette

-   Gains : Nous sommes passés d’un déploiement de 20 jours à 10. Là encore le gain a été visible par tous.

Quelles sont les capabilities que nous avons utilisées dans le cadre du projet

• Oui = Nous utilisons la capability
• Non = Nous ne travaillons pas sur ce sujet
• A améliorer = Nous avons des axes de progrès

(*) nous n'utilisons pas trunk-based mais nous sommes dans la philosophie d’accelerate d’avoir des branches à courte durée de vie

Pour quel résultat ? :

• Rappelez-vous que nous mettions environ 100 jours pour déployer une version en production, aujourd’hui il nous faut 10 jours. L’impact pour les équipes est significatif car il montre de façon factuelle que nous pouvons nous améliorer et ceci est visible à la fois par les équipes, le responsable de la plateforme mais aussi la direction avec laquelle nous partageons chaque mois les indicateurs accelerate.
• A partir du moment où les indicateurs accelerate ont été présentés ainsi que les modalités de calcul, les équipes ne discutent plus de savoir si les indicateurs sont corrects ou non mais des actions concrètes qu’il est possible de mettre rapidement en place pour s’assurer que nous sommes sur la bonne voie et pivoter si nécessaire. Notre objectif reste l’amélioration continue.
• Nous voyons que nos échanges sont plus constructifs entre les équipes : il y a une volonté permanente d’améliorer nos pratiques et in fine d’améliorer le produit
• Les équipes de développement ont décidé de déployer sur l’environnement de recette pour réduire le lead time et s’approprier l’infrastructure AWS. De facto l’équipe est sortie de sa zone de confort pour améliorer le lead time.

Nos prochaines étapes :

• Rationaliser nos environnements : Nous avons trop d’environnement par rapport au nombre de personnes au sein de l'équipe OPS. Nous avons actuellement un environnement de démonstration dédié pour les villes qui est peu utilisé, nous allons le supprimer.
• Simplifier notre infrastructure : Nous avons à la fois beaucoup de micro services qui avec le temps ne sont plus forcément d’utilités et des superviseurs qui nous permettent de collecter des données mais ne sont plus forcément maintenables.
• Automatiser nos tests : Créer un harnais de tests suffisant pour sécuriser nos développements et faciliter le quotidien de nos Product Owners.
• Continuer l’approche DDD afin de faire émerger des domaines fonctionnels. S’assurer que les domaines actuels sont toujours d’actualité.

Ce que je retiens  d’Accelerate :

Je vous propose de partager cet échange au sein d’OCTO car cela correspond bien à la vision que j’ai d’Accelerate

3 questions nous ont été posées :

• Pourquoi faire du Accelerate dans nos missions ?
• Qu’est ce que cela change ?
• Quelles sont nos convictions sur le sujet ?

Beaucoup d’entre nous y ont répondu et je vous livre le retour d’un des membres de l’équipe.

• « Parce qu’Accelerate nous offre un « modèle » scientifique et statistique (fondé sur une étude statistique à grande échelle) qui valide les pratiques et méthodes qu’on connaît chez OCTO et auxquelles on croit et un cadre qui nous permet ainsi de justifier ces pratiques et des les appliquer durant la mission”

• « D’un côté, Accelerate nous propose des métriques, stables et objectives pour mesurer notre qualité de delivery. Celles-ci permettent notamment de repérer les processus lourds, problèmes techniques ou soucis de communication qui retardent la livraison de valeur. Étant capable de mesurer, on est capable d’améliorer notre delivery en se basant entre autres sur les capabilities assez concrètes que nous propose la boîte à outils Accelerate».

• « Il n’y a pas de compromis à faire entre vitesse et qualité ». Aller en production rapidement permet d’avoir un feedback rapide et donc d’agir et de piloter le produit en conséquence. Aller en production rapidement implique une excellence technique (automatisation de tests, intégration continue, shift left on security…) et une faculté de visualisation de la chaîne de valeur de bout en bout. On croit aussi en limiter la parallélisation et livrer régulièrement des lots de petites tailles. Finalement, pour passer à l’échelle, on pense que les équipes doivent être autonomes dans leurs choix techniques et autonomes pour mettre en production -> architecture du SI découplée ! On pense aussi qu’une approche « bottom-up » (en travaillant sur les gestes du quotidien) amène potentiellement un changement culturel durable et efficace. »

Je garde aussi dans un coin de ma tête qu’ Accelerate permet :

• D’accéder à une formidable boîte à outils au service du delivery.
• D’embrasser des sujets variés (techniques, fonctionnels, organisationnels et culturels).
• D’y aller pas à pas. Vous n’êtes pas obligé de déployer les 24 capabilities d’un coup.
• De se concentrer sur quelques indicateurs, facilement compréhensibles par tous et fédérateurs.

De ne pas choisir entre vitesse et stabilité. L’idée, faites les deux, mais allez-y à votre rythme et prenez en compte votre contexte.

Pour tout savoir sur les enjeux Cloud, DevOps et Plateformes, cliquez ici.