En développement logiciel agile, il est d’usage de définir le “réalisé pour les user story” afin d’assurer la qualité du travail et de déterminer si l’équipe a bien complété une User story ou non. Si elle est respectée, la définition de “réalisé” en agile éloigne l’équipe de développement de la dette technique.
Pourquoi, en développement logiciel agile, est-il essentiel de ne pas accumuler de dette technique ?
La dette technique dans les projets agiles signifie un travail supplémentaire due à l’implémentation de solutions temporaires ou limitées, voir même de travaux incomplets. Je considère également comme une dette technique le code non déployé qui met à la disposition des utilisateurs des fonctionnalités développées, mais non documentées ni testées. Une fois terminée, le livrable d’une story doit être prêt à être publié. Si ce n’est pas le cas, tout ce qui est en attente s’appelle dette technique.
Imaginez que vous ayez six stories développées par l’équipe dans le sprint 1, 8 dans le sprint 2 et 5 dans le sprint 3. L’équipe a testé ce qu’elle avait fait et tout va bien. Mais tout le développement effectué est stocké localement dans l’environnement de chaque développeur. Vous êtes deux jours avant la date limite de la mise en production ; tout le monde pense qu’il est juste question de déployer tout le travail dans l’environnement de recette et de production. Voici quelques scénarios qui pourraient survenir :
la branche que vous avez localement est ancienne. Elle génère une longue liste d’exceptions lorsque vous essayez de la fusionner.
la configuration des environnements supérieurs n’est pas la même que celle de l’environnement local et vous devez passer du temps à définir des paramètres supplémentaires.
cela fonctionne localement, mais pas en production et le temps de dépannage devient incontrôlable
quand un problème est résolu, il en révèle un autre
Aucun de ces scénarios ne peut être estimée ou contrôlé.
La prévisibilité est la clé de l’agilité. Mais comment la définition du “réalisé” contribue-t-elle à la prédictibilité ?
J’appelle principalement une user story “réalisée” lorsqu’elle est prête à être diffusée aux utilisateurs si on le souhaite. Il n’est plus question de fusion, de documentation ou de tests, rien d’autre. Cela veut dire que :
il existe un inventaire précis de la partie du périmètre que vous avez complétée,
les utilisateurs peuvent commencer à utiliser les résultats des stories et
la société peut commencer à tirer parti du retour sur investissement de cette user story,
l’entreprise peut vendre la fonctionnalité ou l’utiliser pour attirer plus de clients,
il y a place à amélioration et les parties prenantes peuvent déjà proposer de nouvelles fonctionnalités
il y a des progrès
Chaque équipe a sa définition du “réalisé”. Mais chaque fois que je commence à travailler avec une équipe Scrum, je viens avec un DOD générique, ce qui leur permet de définir plus facilement leur Définition agile du “réalisé”.
Une Story peut être marquée comme terminée lorsque :
L’implémentation de l’user story répond à TOUS les critères d’acceptation.
Le Product Owner a approuvé l’user story
L’user story est déployée dans l’environnement de production, mais désactivéé (désactivée)
Les tests unitaires ont été écrits, exécutés et réussis
Tous les critères d’acceptation ont au moins un cas de test associé
L’équipe a écrit, terminé des tests unitaires et réussis
La documentation technique est téléchargée par l’équipe de Confluence
La performance est sous X
Il n’y a pas de régression dans la suite de tests d’automatisation
L’user story a été révisée par des pairs
Des tests d’intégration ont été réalisés et compilés
Les configurations manuelles à exécuter après le déploiement en production sont marquées dans l’user story.
Le déploiement vers l’environnement de production comporte des notes de publication.
La documentation pour l’utilisateur final est disponible
L’interface utilisateur est conforme à la conception
Le refactoring du code est terminé
La communication marketing des modifications est documentée
Conclusion sur la Definition De Done en Agile
Il y a toujours un équilibre entre exagérer les user stories et la vitesse à laquelle l’équipe du développement va. C’est une balance que chaque équipe scrum doit trouver. Utilisez la Définition De Done dans votre équipe agile pour prendre en charge le processus de développement. Soyez ouvert pour le mettre à jour, expérimenter et explorer. La définition de fait est un outil. Servez-vous-en en votre faveur.
コメント