Release Agile

Beaucoup d’équipes agiles ou scrum se demandent encore comment gérer une release agile. Quelles sont les meilleures pratiques ? Quelles sont les pratiques existantes ?

En effet, il existe encore beaucoup de questions autour de la stratégie à avoir pour livrer le produit aux utilisateurs. Et cela est tout a fait normal car le contexte est souvent contraignant.

Release Agile

Avant de parler des contraintes amenées par le contexte, nous allons voir les différentes stratégies de release agile qui existent.

Livraison par version

Aujourd’hui la stratégie la plus classique est de livrer par lot. Bien que le terme soit très mal utilisé, il est de plus en plus fréquent de voir ce concept de livraison par lot :

• MVP (Minimum Viable Product)
• V2
• V3
• …

Si cette vision est souvent le fruit des méthodes traditionnelles, voici nos conseils autour de celle-ci :

• laisser la porte ouverte à faire évoluer les lots (selon les feedback)
• bien accepter la notion de scope variable pour annoncer les lots selon des objectifs et non selon des fonctionnalités précises

Nous donnons ces recommandations car il est fréquent de voir les lots devenir des contrats ! Hors en agile, un lot ne doit être qu’une vision de là où on aimerait aller, ouvert à tout changement et ne jamais devenir un contrat.

Déploiement continue

Ce mode de release agile est le plus agile qui existe. Dès qu’une user story est finalisée, elle part directement en production pour les utilisateurs. L’application proposée se met ainsi à jour au fur et à mesure de l’avancement des réalisations.

Ce fonctionnement implique une architecture robuste principalement sur :

• la surveillance des résultats
• les tests techniques/fonctionnels automatiques nécessaires avant d’envoyer en production
• capacité d’un retour à la version précédente automatiquement selon l’analyse des indicateurs

Certaines équipes moins matures, utilisent  le concept de livraison continue; la petite différence c’est que le product owner décide ou non de valider la livraison de la user story. Cela va un peu à l’encontre du scrum sauf si la validation de la livraison est dans un concept  stratégique et non de validation du travail de l’équipe de développement. 

Contraintes pour une release Agile ?

Le déploiement continue n’est malheureusement pas possible pour toutes les équipes scrum. En effet, les équipes ayant des développements sur des technologies très anciennes n’ont pas la possibilité de faire du déploiement continue.

Cela se complexifie quand des technologies anciennes sont dépendantes des unes des autres.

Il est facile de dire « il faut changer les technologies » mais cela implique dans les grandes organisations comme les hôpitaux des investissement de plus de 100 millions d’euros… Le contexte rend ces changements de technologies quasiment impossibles.

Cependant, les équipes doivent travailler pour avoir une capacité de livrer le plus souvent possible sans pour autant en subir des conséquences. 

MVP puis déploiement continue

Bien que l’utilisation de MVP est parfois mal utilisé, ce modèle est de plus en plus utilisé : surtout en startup !

Les équipes réalisent un MVP voire un MMP  (Minimum Marketable Product) et livre celui-ci quand il est terminé. A partir de ce moment là, les  équipes livrent en continu des  petites évolutions afin d’améliorer peu à peu la solution proposée.

Pas encore démocratisé, cette pratique est probablement l’une des plus agiles que les équipes peuvent adopter. Cela doit être en revanche combiné à l’utilisation d’un backlog réellement dynamique.

Mais on livre en continue en recette

Quand cela est possible, peu importe la stratégie de release agile choisi, l’équipe de développement doit au possible livrer continuellement sur un environnement de recette stable. L’équipe de développement sera ainsi dans de meilleures conditions pour tester son propre travail.

Mais cela n’est pas toujours simple ; certaines technologies empêchent d’avoir des environnements de recette. Les équipes de développements doivent alors trouver les meilleures solutions possibles pour réellement être en capacité de tester proprement ses travaux.

Lien utile : Make a planning release in agile