Les propriétés du delivery agile
Les attendus d’une organisation qui opère une transformation agile peuvent se résumer en quelques points.
L’attente première est le fonctionnement en flux. C'est-à-dire de produire fréquemment des évolutions au produit réalisé.
Ces évolutions livrées doivent s’inscrire dans une logique de boucle de feedback : leur évaluation confirme-t-elle ou infirme-t-elle le bien fondé de ces évolutions ? Et cette boucle de feedback doit être courte pour favoriser les adaptations rapides.
Les incréments produits issus de ce flux doivent être “shippable”, donc déployables en production si on le souhaite sans que cela nécessite de contrôles à postériori.
Notre conviction est que la mise en œuvre d'un delivery agile doit s'appuyer sur 3 piliers essentiels. En focalisant les efforts de ses équipes de réalisation sur quelques pratiques, avec un objectif de maîtrise puis d’excellence, une organisation peut rapidement progresser dans l’agilité de son delivery.
Découper en tranches fonctionnelles fines
Qu’il s’agisse de User Stories ou d’autre chose, le découpage est la fondation du delivery agile.
Tout d’abord, il conditionne la réalité du flux. Mais cette unité de flux doit être autonome. Si elle dépend d’une autre, ce n’est plus une unité de flux, mais une tâche. L’unité de flux deviendrait alors l’assemblage des tâches nécessaires à sa réalisation.
Ensuite, ce découpage fin va raccourcir la boucle de feedback, qui est directement conditionnée par la taille de l'unité de flux.
Enfin, en réduisant la “surface fonctionnelle” de cette unité de flux, ce découpage rend plus efficace le contrôle qualité nécessaire pour que l’élément soit “shippable”.
Ce découpage doit se focaliser sur le comportement observable du produit. Mais il ne se limite pas aux utilisateurs finaux. Les « acteurs support » sont également considérés : mise en service pour les équipes devops, observabilité pour les équipes Run ou SRE, auditabilité pour la cybersécurité, etc.
Deux questions principales nous ont rendu d’inestimables services pour opérer ce découpage en tranches fonctionnelles :
- Qu’est-ce qu’on peut se permettre de ne pas faire ? Recherchez le « gras » inlassablement : ce qu’on peut enlever sans que l’unité de flux devienne vide de sens. Celui-ci pourra être réintroduit ultérieurement … ou abandonné définitivement !
- En face d’une “user story technique”, se poser la question : si on ne la fait pas, qu’est-ce qu’on ne pourrait plus faire ? Notre conviction c’est qu’une “user story technique” n’a pas de sens. Il faut revenir à la finalité, et ce « pourquoi fonctionnel » existe pratiquement toujours. Et cette question simple permet de l’identifier avec une surprenante efficacité.
Le développement guidé par les tests d’acceptation
Cette phrase relativement anodine issue du guide Scrum recèle l’un des défis les plus importants du cycle agile. Elle implique que les équipes soient en mesure, à la fin d'une tranche de temps, de prendre ce qui a été produit et de le mettre en production. Ceci doit être réalisé de manière systématique, sans traitement ni contrôle postérieur ! Dès les premiers temps de l’agilité, des pratiques ont émergées en ce sens : intégration continue ou tests unitaires, par exemple. Mais aucune n’égale le développement guidé par les tests d’acceptation pour atteindre cet objectif exigeant.
De nombreux excellents écrits ont été consacrés à ce sujet, notamment « Specification by example » de Gojko Adzic. Voici les quelques points clés à suivre pour réussir :
- Les tests d’acceptation sont le « contrat fonctionnel » de l’unité de flux. En tant que tel, ils doivent être identifiés avant d’écrire le code de production.
- Les tests d’acceptation permettent de construire une compréhension partagée de la fonctionnalité au sein de l’équipe. Plutôt qu’un fonctionnement client-fournisseur entre PO et développeurs, préférez une dynamique collaborative pour identifier les cas de test. L’atelier des 3 amis proposé dans “Specification by example” en est une mise en œuvre typique.
- Les tests d’acceptation sont une partie de la documentation fonctionnelle. Ils doivent être exprimés d’une manière compréhensible par le métier tout en étant univoques. Ils doivent aussi être maintenus et évoluer au gré de l’évolution du produit.
- Les tests d’acceptation doivent être une partie intégrante de la « définition de terminée ». Observez une « tolérance zéro » : le travail n’est pas terminé tant qu’il existe un test en échec.
- Ils sont une partie du capital du produit et pour cela doivent être automatisés de manière à prévenir les régressions dans le futur sans induire de surcoûts. Le test d’acceptation d’aujourd’hui est le test de non-régression de demain.
Les pratiques d’ingénierie
Les pratiques d'ingénierie constituent le troisième et dernier pilier du delivery agile. Le corpus de ces pratiques s’est grandement étoffé depuis plus de 25 ans. Mais il est déraisonnable de demander à la plupart de ces équipes de chercher à toutes les appréhender. Nous vous proposons un socle de 3 pratiques simples qui se complètent et se connectent parfaitement aux deux piliers que nous venons de voir. Elles constituent un bon point de départ.
Des branches à durée de vie courte
Par « durée de vie courte », nous entendons le délai entre le début et la fin de cette branche par rapport à la branche principale. Il est fréquent, hélas, d’observer l’utilisation de branches intermédiaires, qui ont rarement une durée de vie courte !
Qu’entendons-nous par « durée de vie courte » ? Ce sont des branches pouvant durer de moins d’une journée à quelques jours, jusqu’à une semaine au plus.
Notre recommandation est d’avoir des branches consacrées à la réalisation d’une seule unité de flux (d’où la nécessité de bien les découper). Quand une unité de flux ne coïncide pas avec une unité de mise en service, il peut être nécessaire de désactiver la fonctionnalité entre temps. La mise en place de « toggle features » permettant cela devient alors impérative.
Pourquoi est-il préférable d’opérer avec des branches à durée de vie courte ? Pour deux raisons principales :
- Quand on travaille « en branche », on est isolé des effets de bord des autres évolutions, c’est d’ailleurs l’objectif premier. Mais plus on travaille en isolation longtemps, plus le risque que ce qui fonctionne en isolation ne marche plus dans une branche principale qui continue d’évoluer.
- L’intégration des changements opérés dans la branche de développement en branche principale est appelée « merge ». C’est une opération qui peut être à haut risque car elle peut engendrer des collisions de modifications ou la fusion de d’évolutions incompatibles. Dans la pratique, le risque est faible sur des branches à durée de vie courte. Il peut être tout à fait prégnant sur quelques semaines. A l’extrême, nous avons croisé des situations où la réintégration de branches d’une durée d’un an ou plus ont généré des effets de bord qui ont pris plusieurs mois à être corrigés !
Voici les guidelines que nous vous proposons :
- Utilisez des branches servant d’espace de travail pour une et une seule unité de flux.
- Visez l’objectif d’intégrer vos branches sous 2 ou 3 jours, mais n'intègrez pas votre unité de flux « à mi-course » pour respecter cela. Travaillez plutôt à améliorer votre découpage.
L’intégration continue
C’est une des pratiques les plus anciennes de l’agilité. Historiquement, elle fut un véritable électrochoc pour les cycles de développement classique en réduisant les phases d’intégration à … zéro !
L’intégration continue est la seule vérité objective de l’état de réalisation de votre produit. Si elle vous donne une information différente de votre outil de ticketing, c’est à l’intégration continue que vous devez faire confiance.
Un pipeline d’intégration continu, comme on l’appelle communément, peut aller de quelque chose de très simple à une machinerie complexe opérant de très nombreuses vérifications
La conception émergente est aussi une pratique fondatrice de l’agilité, mais sans doute l’une des plus exigeantes en termes de savoir-faire de conception.
L’approche traditionnelle consiste à vouloir poser un « socle » ou des composants techniques qui serviront de support et de cadre pour les fonctionnalités qui seront ensuite réalisées. Malheureusement, cette approche présente 3 problèmes majeurs pour des avantages souvent hypothétiques :
- Le socle ne sert à rien par lui-même, seules les fonctionnalités réalisées vont nourrir le feedback produit que nous recherchons.
- Tant qu’il n’est pas utilisé par des fonctionnalités, ce socle n’a pas prouvé qu’il fonctionne comme attendu dans son contexte d’usage. C’est en réalité une forme de « dette technique ».
- Ce socle ou ces composants font des hypothèses très anticipées d’usage par les fonctionnalités qui s’appuieront dessus. Cela aboutit souvent à un socle mal adapté voir contraignant pour un produit dont la réalisation n’a même pas commencé !
Avec la conception émergente, on limite la complexité de l’architecture à la taille du problème à résoudre. On conçoit pour le moment présent et non plus pour le futur. On livre alors plus rapidement, la boucle de feedback s’accélère et on diminue la dette technique en évitant de lui donner naissance.
La conception émergente s’appuie sur une pratique clé : le remaniement du code, ou refactoring. Cette pratique exige elle-même une mise en place de tests unitaires afin d’opérer continuellement ces remaniements en toute sérénité.
Au-delà des piliers du delivery agile
Le delivery agile est un univers riche de nombreuses pratiques alimentées par des communautés comme le Craftsmanship ou le DevOps. Il est facile d’être submergé par cette abondance.
Références - Pour aller plus loin
Pour le développement guidé par les tests d’acceptation :
Pour le découpage des éléments de flux :
Pour la conception émergente :
