- Exprimez le titre de l’unité de flux en termes de finalité plutôt qu’en description d’un « quoi ». Plutôt que “écran de détail du panier d’achat”, préférez “confirmation des éléments de la commande”.
- Si le titre contient des liaisons telles que « et », « ou », « sauf » ou « excepté » par exemple, vous pouvez sans doute découper cette unité de flux en deux.
- Une unité de flux n’est pas nécessairement une unité de mise en service. Traiter d’abord du cas nominal puis des cas d’erreurs dans une autre unité de flux est possible. Mais les deux devront être mises en service ensemble !
Delivery agile : les pratiques fondamentales à maîtriser pour les équipes agiles
Le
5 minutes
En résumé
La mise en œuvre d'un delivery agile doit s'appuyer sur 3 piliers essentiels :
- le découpage en tranches fonctionnelles fines,
- le développement guidé par les tests d'acceptation,
- les pratiques d’ingénierie.
Ces pratiques, souvent négligés au profit des rituels agiles, sont pourtant les fondations indispensables pour toutes les équipes agiles.
Le découpage fonctionnel constitue le socle premier du delivery agile, plus il est fin plus la boucle de feedback est courte.
Le développement guidé par les tests d’acceptation est le meilleur moyen de livrer de manière systématique à chaque itération.
Les pratiques d'ingénierie recouvrent un ensemble (trop) riche. Il y a néanmoins 3 grandes pratiques à maîtriser avant tout pour avoir un delivery continu et performant : des branches à courte durée de vie, la conception émergente et l'intégration continue.
Les propriétés d’un delivery agile performant
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.
Enfin, 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.
Premier pilier du delivery agile : le découpage 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.
Quelques astuces pour vous aider à découper plus finement vos unités de flux
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é.
Deuxième pilier du delivery agile : le développement guidé par les tests d’acceptation
« The team should produce a potentially shippable increment at the end of the sprint »
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.
Troisième pilier : Les pratiques d’ingénierie pour un delivery continu
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.
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
Nos recommandations pour opérer un pipeline qui répondra à nos propriétés du delivery agile
- L’intégration continue (IC) doit être effectivement continue et vérifier l’état de la branche principale ! La pratique des branches à durée de vie courte va en ce sens. A l’inverse, des branches longues rendront l’intégration continue … discontinue ! Et par voie de conséquence presque inutile !
- Intégrez dans l’IC toutes les vérifications automatisables de votre « définition de terminé », en tête desquelles les tests d’acceptation.
- L’intégration continue doit être verte 1/2 : n’intégrez en branche principale que les réalisations qui auront déjà passé avec succès les mêmes contrôles sur la branche de développement. En tolérant l’intégration de développement sur lesquels subsistent des problèmes, vous aurez rapidement une IC « rouge » en permanence et deviendrez incapable de repérer les régressions.
- L’intégration continue doit être verte 2/2 : Même avec beaucoup de rigueur, vous restez exposés à des régressions ponctuelles ou des problèmes de merge. Quand ils apparaissent, les régler devient la priorité absolue afin de faire revenir l’IC au vert.
La conception émergente
Le programmeur comme le poète, manie des abstractions voisines de la pensée pure. Il construit des cathédrales dans les airs, à partir de l'air lui-même, par le pouvoir de son imagination.
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.
Les questions que nous vous suggérons quand vous réfléchissez à votre conception
- Le design auquel je pense adresse-t-il mon problème actuel, ou est-ce en prévision du futur ?
- Suis-je capable de justifier le surcroît de complexité que je m’apprête à mettre en œuvre ?
- Vais-je avoir du feedback sur le bon fonctionnement de ma conception dans l’immédiat ou devrais-je attendre une évolution ultérieure pour cela ?
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.
Nos recommandations
- Ne vous dispersez pas sur les pratiques à la mode tant que vous n’avez pas maîtrisé les piliers.
- Ne vous laissez pas paralysé par cette abondance de pratique. Comme nous l’avons évoqué, vous atteindrez un niveau de delivery agile déjà fort honorable en maîtrisant ces fondamentaux.
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 :
Vous aimerez également découvrir
Allez plus loin avec nos formations
Abonnez vous !
Qui sommes nous ?
