Quand on change le “Done” doit-on revenir sur les développements passés ?

Quand on change le "Done" doit-on revenir sur les développements passés ?

Est-ce que, lorsque l’on revoit la définition du “Done“, il faut revenir sur les développements passés ?

Découvrir nos formations en ligne

Une problématique de la qualité des développements passés

Lorsque l’on parle du “Done” on parle de critères de qualité. A partir du moment où le niveau de qualité change, il y a une problématique sur la qualité des développements passés, qui normalement, n’est plus au niveau des attentes. Etant donné qu’à la fin de notre sprint, on doit livrer quelque chose qui fonctionne, on ne peut pas se permettre de dire : “écoutez, on va griller un sprint ou deux, pour récupérer tout le travail qui a été fait avant ce changement de manière à ce que tout soit au niveau attendu.”

Il faut remettre à niveau les développements passés

Dans la méthodologie Scrum, on attend qu’à la fin d’une itération, il y ait quelque chose qui soit montrable et qui puisse être mis en production. Il est donc nécessaire d’établir ce travail de “refactoring“. Cela signifie qu’au fur et à mesure des itérations, il faudra procéder de manière à remettre à niveau les développements qui ont été faits avant, et qui ne correspondent plus au niveau de qualité attendu. Donc oui, bien-sûr, il faut remettre à niveau les développements qui ont été réalisés, mais on va le faire de manière progressive, continuelle, de façon à ne pas bloquer une itération ou ne pas mobiliser en une seule fois, les forces pour faire ce travail là, ce qui serait contre-productif.

Découvrir nos formations en ligne

Table des matières

Vous appréciez cet article. Merci de le partager !

Articles recommandés

S’inscrire à la newsletter