• Anca Onuta

DOD (User Story Definition Of Done) dans le développement logiciel agile et la dette technique

Mis à jour : 9 juin 2019

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 :

  1. L’implémentation de l’user story répond à TOUS les critères d’acceptation.

  2. Le Product Owner a approuvé l’user story

  3. L’user story est déployée dans l’environnement de production, mais désactivéé (désactivée)

  4. Les tests unitaires ont été écrits, exécutés et réussis

  5. Tous les critères d’acceptation ont au moins un cas de test associé

  6. L’équipe a écrit, terminé des tests unitaires et réussis

  7. La documentation technique est téléchargée par l’équipe de Confluence

  8. La performance est sous X

  9. Il n’y a pas de régression dans la suite de tests d’automatisation

  10. L’user story a été révisée par des pairs

  11. Des tests d’intégration ont été réalisés et compilés

  12. Les configurations manuelles à exécuter après le déploiement en production sont marquées dans l’user story.

  13. Le déploiement vers l’environnement de production comporte des notes de publication.

  14. La documentation pour l’utilisateur final est disponible

  15. L’interface utilisateur est conforme à la conception

  16. Le refactoring du code est terminé

  17. 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.

Contact

+33638790322

Follow

©2020 by MAWIA.