Il existe régulièrement une question qui se pose pour les équipes agiles peu importe la méthode utilisée : doit-on faire de la validation continue ou de la validation par lot. La réponse n’est pas si simple que ça.
Qu’est-ce la validation continue ?
La validation continue est le concept simple de dire que les demandes (comme des user-stories par exemple) seront validées au fur et à mesure. Cependant, cela implique d’être dans un environnement favorable pour utiliser cette méthode de validation.
En effet cette méthode qui parait souvent être la plus idéale, ne le sera pas forcément dans certains contextes. Elle peut même parfois s’apparenter à de la double-validation.
Contexte favorable
Quand on a une stack technique de qualité et récente avec de la livraison continue voire du déploiement continue, cette technique peut-être redoutable. Avec un Product Owner à 100% sur le projet, cela permet d’avoir des validations au fil de l’eau et d’avoir des retours rapides sur les demandes terminées.
Dans ce contexte favorable, on peut même voir les développeurs valider les demandes directement avec le Product Owner dès le développement terminé ; cela leurs permet de prendre une nouvelle demande qu’après validation totale de la précédente demande. C’est nettement plus efficace pour les développeurs de ne pas avoir le besoin de revenir sur une ancienne demande parce que le Product Owner ne remonte que très tardivement les bugs constatés.
Contexte défavorable
il existe malheureusement beaucoup plus de contextes défavorables pour effectuer de la validation continue que de contexte favorables.
Si le Product Owner n’est pas à 100% sur le projet comme dans de nombreux grands groupes, il devient vite difficile pour ne pas dire impossible de faire de la validation continue.
Quand la mise en recette implique 1 à 2 heures d’effort par l’un des membres de l’équipe cela peut devenir une perte de temps de faire de la validation continue. J’ai d’ailleurs rencontré une équipe encore dernièrement dans cette situation.
Certes, l’idéal serait que l’équipe ait une mise en recette (ou production) totalement automatisée mais ce n’est pas forcément le cas… Sur des anciennes technologies, ce n’est d’ailleurs pas toujours possible. Du coup, faut-il vraiment faire de la validation continue dans ce cas ?
Qu’est-ce que la validation par lot ?
La validation par lot est tout simplement l’inverse de la validation continue. Il existe différents types de validations par lot.
Des moments dédiés à la validation
Le Product Owner se réservera du temps dans la semaine pour valider un ensemble de demandes terminées par l’équipe de développement. Cependant cela peut-être déroutant car les développeurs vont devoir à la suite réserver du temps pour réaliser les éventuelles corrections d’anomalies remontées par le Product Owner.
Les équipes qui fonctionnent en méthodes agiles, vont parfois devoir redoubler d’énergie pour tout corriger surtout si les retours arrivent en fin de sprint. Ce n’est probablement pas une situation idéale car une certaine pression pourra se faire ressentir et les développeurs peuvent remettre du temps pour retourner dans cette partie du code.
Un freeze time
Cette méthode qui est de moins en moins présente peut cependant aider certaines équipes qui sont encore dans un contexte défavorable à la validation continue (mise en recette trop longue, Product Owner peu présent….)
Pour faire simple, l’équipe va déterminer que le dernier jour de sprint sera totalement dédié à du test et à de la correction ; les demandes non terminées ne seront plus traitées dès que l’équipe arrivera dans la période du freeze time.
Certaines équipes font quand même de la validation au fur et à mesure du sprint en utilisant cette méthode.
Article : Scrum : ajoutez un freeze time pour mieux tester
La limite WIP (work-in-progress) déclenche la validation
Peu présent mais certaines équipes décident de déclencher une période de validation quand il y a X demandes à tester. Le nombre est déterminé par l’équipe. C’est une méthode prise directement des notions proposées par le Kanban tout en pensant Lean (limiter la perte de temps dans la chaîne de production).
Cela permet de limiter les mises en recette quand elles sont très longues tout en faisant de la validation « presque » continue.
Conclusion
Bien que certaines équipes auront l’obligation de faire de la double validation parce que l’environnement de recette et de production seront différente, il est important de bien faire son choix sur « validation continue » ou « validation par lot ». S’imposer de faire de la validation continue dans certains contextes peut-être malheureusement une perte de temps considérable pour l’équipe de développement.
Pour s’épargner la double validation, il existe des méthodes imparable : environnement identiques avec Docker et orchestrateur de conteneurs, de l’intégration continue complète…
Soyez le premier à commenter