Je rencontre encore des équipes qui pensent que la fin du sprint représente une release. Ce n’est évidemment pas le cas et nous allons profiter de cet article pour en parler et pour voir les différents types de release qui existent en Scrum.
Pourquoi faire des release qu’en fin de Sprint ?
Certaines équipes sont en stresse en fin de Sprint car elles pensent qu’elles doivent tout livrer en production pour la sprint review. Non, les itérations n’ont jamais imposée de livrer quelque chose en production à la fin. Il faut faire attention car cette façon de faire peut-être même contre-productif.
Le découpage de user-stories doit avoir pour but de pouvoir tester l’application morceau par morceau (des incréments) ; cependant pouvoir tester ne veut pas forcément dire pouvoir livrer en production.
Il existe en fait différentes façons de faire que nous allons voir à la suite mais vous pouvez livrer en production de différentes façons.
Quelles sont les types de mise en production ?
Il existe différents types de mise en production pour des équipes qui font du scrum et qui diffèrent aussi par rapport à la maturité du produit voire de l’entreprise et de son contexte.
Livraison continue / déploiement continue
Ce type de mise en production est de plus en plus fréquent mais impose une bonne maturité de l’équipe à l’excellence technique si on ne veut pas que ces mises en production deviennent réalités.
Pour expliquer le concept, dès que le développeur « pushera » son travail, il sera directement mis en recette (pour la livraison continue) ou en production (pour le déploiement continue). Le concept de livraison continue imposera qu’un responsable fonctionnel valide la recette avant la mise en production alors que le déploiement continue enverra la mise à jour en production sans aucune validation humaine.
Article : Le Continuous Delivery et Continuous Deployment
Cela implique en effet d’avoir des outils de livraison de qualités et récents comme un outil de versioning comme Git, des outils de tests automatisés…
Attention, la stratégie de l’entreprise peut amener à interdire le déploiement continue pour différentes raisons possibles :
- associer des livraisons de fonctionnalités complètes à un acte marketing
- respecter des raisons légales
- valider la mise en production avec une instance de l’entreprise
Livraison par version
Dans des produits agiles, rien n’empêche de livrer par version. On va déterminer x user-stories qui partiront en production en même temps. Etant agile, on s’autorisera que le scope puisse bouger avec le temps sur la release.
En général, on travail cela très facilement avec un Story Mapping enchainé d’un release board :
Article : Bien comprendre la création d’un story-mapping
Article : Faire une planning release en agile
Par contre, il reste indispensable de livrer au fur et à mesure sur un environnement de recette stable afin de tester régulièrement le produit et de récupérer un maximum de feedback des utilisateurs clés.
Livraison à une date T
Suivant le concept rappelé par le triangle agile que vous pouvez visualiser ci-dessous, le concept est de définir une date T et de livrer tout ce qui sera terminé à cette date.
Article : Qu’est-ce que l’agile iron triangle ?
Dans ce type de livraisons, il est possible également d’imaginer ce qui sera livré (avec un release board par exemple) mais en gardant toujours en tête que le scope soit variable.
Cependant, cette façon de faire plait que rarement dans les grands groupes car il manque un côté « contrôle » à cette méthode. Oui les grands groupes ont généralement encore un peu de mal avec la notion de scope variable.
Livraison par feature
Plus rare, il est possible de faire des livraisons par feature ce qui s’approche concrètement de la livraison par lot. Pour rappel, la feature est un ensemble de user-stories ; voici un exemple de découpage de backlog possible :
Cette méthode permet de livrer fréquemment mais n’est pas possible dans les équipes qui ne veulent pas livrer toutes les user-stories d’un seul coup : exemple lorsqu’on définit un MVP (Minimum Viable Product) très détaillé.
Livraison par Sprint
La livraison par Sprint est équivalente à la livraison à une date T mais sur une période très courte. Cette méthode existe mais n’est pas obligatoire en Scrum. Cela est souvent fait lorsque les équipes veulent livrer rapidement mais doivent faire un contrôle général de l’application parce qu’il manque de l’intégration continue et que les différents environnements sont trop différents les uns des autres.
Conclusion sur les release
Vous connaissez à présent de nombreuses façons de faire pour vos release. Il ne faut pas s’imposer une méthode mais choisir celle qui sera la plus adaptée à votre contexte. A vous de jouer.
Bonjour Judicaël,
Tu peux y ajouter la livraison « on demand » (que l’on retrouve fortement chez SAFe) qui peut rejoindre la livraison par feature sur demande de l’utilisateur.