J’ai eu il y a quelques semaines l’occasion d’animer un petit déjeuner autour du thème du Continuous Delivery. Le terme n’est pas nouveau, mais pourtant plusieurs participants m’ont dit avoir été surpris par le contenu de la présentation, et en particulier l’articulation des trois thèmes qui étaient explicités : l’Agile, le Software Craftsmanship et le Devops. Et peut-être également par l’approche Biz-Dev-Ops, que j’essaie comme beaucoup d’autres de valoriser et de promouvoir. Ci-dessous un rapide tour d’horizon du Continuous Delivery.
Constat et motivations
Le constat à la source du Continuous Delivery n’est d’aucune originalité : les entreprises cherchant constamment à améliorer leur capacité à délivrer le plus vite possible de la valeur à leurs clients, se confrontent au vieillissement de plus en plus rapide de leur système d’information, qui implique perte d’évolutivité, augmentation exponentielle des coûts de maintenance, ralentissement des développements. Le problème n’est pas nouveau, mais peut-être que les solutions proposées, oui.
Que ce soit sur un plan théorique, méthodologique, technique ou utilitaire, de nombreuses innovations ont conduit ces dernières années à la formalisation d’un certain nombre de pratiques et d’approches. En parallèle, la révolution du Cloud, et l’apparition d’offres “as a Service” ont permit de faciliter énormément les tâches rébarbatives, coûteuses et sensibles liées au déploiement et à l’exploitation des systèmes d’information. Bien qu’il soit un peu prématuré pour considérer ces outils comme matures, il existe aujourd’hui de très nombreuses opportunités pour répondre aux défis cités précédemment : qualité/stabilité, vélocité, réactivité, évolutivité.
Contexte
L’une des erreurs communes lorsqu’il s’agit de Continuous Delivery est de considérer qu’il s’agit du buzz-word IT dans la lignée de Continuous Integration ou Continuous Deployment. Je ne rentrerai pas trop dans les explications de ces deux derniers termes, mais j’insisterai seulement sur les différents : Continuous Integration / Deployment correspondent à des patterns d’utilisation d’une Software Factory, et traduisent la capacité d’une équipe, ou d’un projet, à tester, assembler, intégrer, voire déployer des briques logicielles. Il s’agit en effet ici de concepts très IT, voire Devops. Il n’y a là aucune implication des clients ni du produit lui-même, ni de référence à la façon dont le produit final est créé. Il s’agit de termes purement techniques, propres au monde Dev/Ops
Le terme de Continuous Delivery se veut plus global, et désigne la capacité à délivrer de la valeur au client de façon continue, donc une implication du client dans la démarche.
Lorsque l’on parle de Continuous Delivery, il faut donc être particulièrement attentif au fait que les rôles concernés vont du Product Owner, ou du client, jusqu’au Developpeur, à l’Ops, en passant par des rôles davantage axés sur la gestion des tâches, la méthodologie ou l’organisation tel qu’un Scrum Master, par exemple.
“Pain points” et proposition de valeur
Lorsqu’on interroge des clients internes / externes au sujet des qualité et défauts des applications qu’ils utilisent, de la façon dont ils perçoivent les efforts fournis par ceux qui les réalisent, on obtient assez fréquemment les feedbacks suivants : les développements coûtent trop cher (et ça augmente), ils ne correspondent pas toujours / pas souvent au besoin réel, qui est visiblement mal compris. Le process de développement est considéré comme opaque et inutilement complexe, donc peu efficace et coûteux.
Du point de vue des développeurs, c’est souvent le sentiment d’être pris entre le marteau et l’enclume qui prévaut : d’un côté la pression des délais, liés à des engagement qui ont été pris par d’autres en amont (chef de projet, délais d’autres équipes ou jalons liés à des roadmaps issues de nulle part..), et de l’autre la volonté de bien faire, en respectant les best practices, les bons principes de développement. Ces équipes sont souvent épuisées et se sentent finalement peu valorisées, bien qu’elles considèrent paradoxalement être les seules à produire !
Côté Ops, ce sont d’autres contraintes qui opèrent : le fait d’avoir une relation directe avec les clients les positionne implicitement en tant que responsables…en particulier des problèmes qui surviennent ! L’incapacité à anticiper ces problèmes conduit bien souvent à une impression de travailler en mode pompier, et ils ont bien souvent la lourde tâche de devoir se porter garants de développements dont la qualité leur semble médiocre ou insuffisante.
L’un de nos objectifs sera, grâce au Continuous Delivery, d’apporter non pas des solutions, mais des moyens permettant aux personnes concernées de trouver des solutions adaptées à leur contexte spécifique.
Mise en oeuvre
Il n’existe ni recette miracle, ni de framework clé en main pour résoudre les problèmes cités précédemment. Néanmoins, nous disposons d’un vaste arsenal dans lequel chaque entreprise et chaque équipe pourra piocher afin de constituer sa propre implémentation du Continuous Delivery. J’insiste sur le fait que, contrairement à un a-priori très répandu, le Continuous Delivery n’est pas un ensemble d’outils techniques qu’il suffit d’acheter et de déployer.
Je considère que 80% des problématiques relèvent de l’humain : collaboration, communication, objectifs locaux, opacité, malveillance… Les outils ne sont qu’une implémentation de pratiques qui doivent s’ancrer dans les habitudes de ceux qui interviennent sur les projets, afin qu’elles deviennent une culture. Ce processus prend du temps, il n’est pas linéaire, il est parsemé de tentatives non couronnées de succès, il est spécifique à chaque équipe et chaque entreprise, et est bien souvent difficile à répliquer. Tour d’horizon des pratiques :
Agilité
Oui, l’Agilité constitue une part de la réponse. Certains voient dans ce terme une mode, d’autres un buzz-word vide de sens. Certains le considèrent comme un produit commercial. De mon point de vue, il s’agit surtout de factualiser des comportements qui relèvent du bon sens, et qui font leurs preuves, à savoir:
Rentrer dans un cycle d’amélioration continue : demander régulièrement du feedback à ceux qui produisent comme à ceux qui utilisent ou supportent le produit. La périodicité peut varier, mais des cycles courts (entre 1 et 4 semaines) donnent souvent de meilleurs fruits.
- Inspecter le produit, inspecter le processus et s’inspecter soi-même : tout peut s’améliorer, y compris les méthodes de travail. Je conseille fréquemment aux débutants en agilité de commencer avec un framework simple (Scrum, Kanban), mais j’attends de mes équipes agiles que, tandis qu’elles gagnent en maturité et en confiance, elles puissent adapter, personnaliser et améliorer leur propre agilité !
- Identifier les sources de valeurs, tout comme les tâches inutiles ; le Value Stream Mapping est un outil pratique et simple à utiliser, par exemple.
- La collaboration avant tout ! Il est tentant de vouloir créer des workflows de tâches entre équipes pour “gagner du temps”. Bien souvent ceux-ci peuvent même être implémentés dans des outils. Attention à rester dans le juste milieu ! L’outil doit être un support, mais pas un frein. Si les équipes administrent elles-mêmes leur workflow, pourquoi pas. Si par contre vous avez tendance à vouloir créer des équipes tierces type PMO, “process managers” ou autres, méfiance.. Traquer les relations client-fournisseur, et faire émerger des partenariats est un enjeu majeur.
- Innovation et autonomie : il est frappant de constater qu’une très grande majorité de personnes travaillant sur les projets présentent un niveau de qualification élevé ; néanmoins, la structure, la hiérarchie ou l’omniprésence de règles tuent leur créativité et leur capacité à innover ou à prendre des initiatives. Quel gâchis !! Engagez vos équipes sur des résultats tangibles, et laissez leurs la responsabilité de trouver les moyens pour y parvenir. Faites leur bénéficier de l’expérience collective, proposez leur votre aide. Des ateliers de délégation poker peuvent vous aider à situer une équipe sur une échelle d’autonomie
- Leadership : notre société est traditionnellement organisée de façon hiérarchique et les entreprises aussi. Comment les équipes considèrent-elles leur responsable : un chef ? un leader ? ne sous-estimez pas l’importance de la relation au responsable, et de sa posture envers ceux qu’il dirige. Nous sommes au 21e siècle, les mentalités ont changé ; ignorer les motivations de chacun conduit à la médiocrité et à la démotivation. Si vous pensez que votre organisation n’est pas encore prête pour le management 3.0, vous avez peut être encore raison, mais ça ne durera pas !
- Gestion du backlog : tous les acteurs doivent se parler directement, périodiquement, pour faire évoluer le contenu du backlog (business, developpers et ops). Plus les incréments seront petits, plus les livraisons pourront intervenir fréquemment, et moins coûteux seront les réajustements de cible.
Software Craftsmanship
Le fondement du Software Craftsmanship vient du fait qu’on ne développe pas du logiciel comme on construit des voitures : il s’agit davantage d’une compétence artisanale, où chacun a une approche personnelle du “comment faire”. Il est donc nécessaire de partager les méthodes et les pratiques afin d’obtenir une homogénéité entre les différents développeurs, favoriser la montée en compétence afin d’éviter la spécialisation et les risques associés, et constamment chercher à améliorer pour éviter le vieillissement prématuré. Certains concepts semblent depuis plusieurs années permettre de tirer le niveau vers le haut :
- Le Test Driven Development (TDD) : pour éviter que les tests arrivent à la fin du cycle de développement, autant les mettre au début ! En plus d’améliorer la qualité du code, cela permet également de clarifier les besoins, et de faire du design émergent.
- Le Behavior Driven Development (BDD) : next step au-delà du TDD, il s’agit ici de favoriser les interactions entre Business Analysts, Developers et Testers (les fameux “3 amigos”) ; on réduit, grâce à cette méthode, le nombre d’incompréhensions, les problèmes liés au mind mapping, et cela permet notamment de créer de la documentation exécutable vivante, favorisant ainsi la maintenabilité à moyen et long termes.
- Clean code : un code de qualité, ce n’est pas un jugement relatif, mais bien un certain nombre de principes qui doivent être respectés, et qui sont aujourd’hui assez bien normalisés. Les développeurs doivent s’entendre et s’entraider sur la mise en oeuvre de ces principes, et vérifier en continu que le code produit est en adéquation avec les objectifs.
DevOps
La collaboration entre développeurs et Ops n’est pas innée. Leurs objectifs sont parfois antagonistes : les premiers veulent du changement rapide, les seconds sont objectivés sur la stabilité. Pourtant, les deux partagent de nombreuses contraintes communes, notamment lorsqu’il s’agit d’effectuer des tâches rébarbatives liées à l’assemblage, le test ou le déploiement des livrables, ou encore lorsqu’il s’agit de récolter du feedback des environnements. Cassez le mur qui sépare les devs des ops, et engagez les à mettre en place des rituels périodiques, un outillage commun, et à réduire le temps qu’ils passent sur des tâches sans valeur ajoutée. Ces équipes regorgent autant de talents que de frustration; libérez leurs énergies, et canalisez les afin d’améliorer à la fois la qualité et la vélocité.
Évidemment, les technologies gravitant autour du Cloud et de l’Infrastructure as Code permettent de diminuer les efforts, et d’adopter des stratégies dynamiques et scalables. Implémenter toutes les nouveautés de façon aveugle serait assez dangereux, mais se refuser à les expérimenter serait une erreur.
Limites et risques
Mettre en place l’Agilité dans le monde du Dev ne présente plus trop de challenge aujourd’hui. Mais c’est encore le cas à l’échelle business-IT. Certains secteurs d’activité sont plus ouverts à la collaboration, mais la tendance actuelle semble indiquer que tous peuvent y trouver des gains. Nous ne sommes qu’au début de la révolution Agile.
Mettre en place le Continuous Delivery peut être perçu comme une opportunité, mais il faut garder à l’esprit que cela peut également être considéré comme une menace par ceux dont le travail est en opposition frontale avec ses principes. Statistiquement, je pense que 80% des personnes que je rencontre les adoptent, à rythme variable. Néanmoins, 20% s’y opposent par conservatisme, ou par posture défensive du fait de leur position hiérarchique, de leur compétence technique/métier, ou pour d’autres obscures raisons. Il ne faut jamais sous-estimer le pouvoir destructeur de ces personnes, et analyser préalablement les gains et les risques de toute transformation, en particulier lorsqu’elle repose sur des méthodes de travail, de la collaboration et de la communication.
Compte tenu du fait qu’il s’agit de transformer la culture d’équipes ou de services, il est vital de s’intéresser à la pérennité des pratiques qu’on cherche à déployer, en particulier lorsque ces équipes présentent un turn-over élevé, notamment du fait de la présence de prestataires. Les entrées/sorties de personnel doivent donner lieu à une attention particulière de la part de l’équipe. Il n’est malheureusement pas rare de constater qu’une gestion trop laxiste conduit à la disparition rapide des bonnes habitudes qui avaient été acquises au prix d’efforts durables.
Par contre, si la maturité d’une équipe est telle qu’elle est capable de s’auto-améliorer, et de gérer ses propres risques, alors les gains du Continuous Delivery récompensent les efforts fournis, et bien plus encore.
Think big, start small
La formule “Think big, start small” se prête parfaitement au Continuous Delivery.
Penser grand, c’est notamment inclure tous les acteurs dans une démarche commune, le mouvement “Biz-Dev-Ops”. C’est aussi ne pas privilégier l’approche outils, mais plutôt opter pour une approche human-centric : mettre en place une culture de l’amélioration continue, basée sur des feedbacks réguliers de ceux qui utilisent, créent ou interviennent sur le produit dans leur ensemble ; c’est également favoriser les interactions et la collaboration plutôt qu’enfermer les acteurs dans des process rigides et peu évolutifs. A la fin, les outils permettent d’implémenter, d’automatiser et de faciliter. C’est aussi prendre en compte à la fois l’Agilité, le Software Craftsmanship, et le DevOps.
Commencer petit, c’est souvent choisir les bonnes personnes, sur les bons (petits) projets, et inspecter souvent et régulièrement leurs réussites et leurs échecs, pour pouvoir ajuster la cible rapidement. De petites équipes trouveront plus facilement la voie vers le succès.
Envie d’aller plus loin sur le sujet ? Lisez cet article sur l’automatisation des tests : https://weblog.wemanity.com/why-test-automation-fails-and-how-you-will-succeed/
