Nous avons vu dans un précédent article que l’objectif premier d’une User Story (US) est de définir un besoin utilisateur recueilli via une expression de besoins qui elle-même adresse un ou des problèmes bien précis. A la différence d’une spécification utilisateur une User Story se veut plus courte, précise et va remplacer la documentation utilisateur que l’on retrouve sur les gros projets.

Afin d’écrire une bonne User Story certains éléments doivent être vérifiés lors de sa rédaction:

• Un titre clair
• Une demande normalisée « En tant que <rôle> je veux <but> pour <raison> »
• Des critères d’acceptation
• Un définition of Done
• Respecter les règles INVEST
  • Independent
    • Les US peuvent être sélectionnées sans dépendre d’autres story dans la même release
  • Negotiable
    • Les US peuvent être modifiées jusqu’au début de l’itération
  • Valuable
    • Les US sont pour les utilisateurs finaux et non pour les développeurs/intégrateurs/testeurs
  • Estimable
    • Les US sont chiffrables et claires
  • Small
    • Les US sont assez petites pour rentrer dans une release courte (sinon il faut redécouper la story)
  • Testable
    • Les US sont testables via les critères d’acceptation et le DoD
• Un mockup si des modifications GUI sont apportées

Introduction

Dans de nombreux projets, on pense à tort que cela suffit alors que non car la US définit des critères de qualité pour un instant T  via les critères d’acceptation et non sur l’ensemble du projet; pour résoudre ce problème il faut utiliser le DoD ou Definition of Done. On va tenter de vous expliquer dans cet article à quoi cela correspond.

Définition

Chaque produit se doit d’avoir son propre Done, un produit interne/externe ou gratuit/payant n’ayant pas les même critères d’exigence vis-à-vis des utilisateurs.
Ces objectifs vont permettre de donner des critères objectifs avant la livraison de celle-ci (via une checklist). Si un des critères n’est pas vérifié alors la User Story ne doit pas être livrée.
Les PO (Product Owner) connaissent ainsi à chaque instant la vie de la US et ont une meilleure perspective sur la date de livraison de celle-ci.
Elle crée également une notion de contrat entre le PO et les équipes techniques (implication des équipes).

On y trouve quoi ?

On retrouve dans un Dod à la fois des exigences

• Fonctionnelles
• Non fonctionnelles
• Ergonomie
• Performance
• Sécurité
• Taux de correction des bugs
• Technique (Code)
• Taux de passage des tests
• Documentation

Qui rédige et valide ?

Même si le rédacteur reste le Product Owner, il est illusoire pour lui d’imposer un DoD sans l’avoir fait partager avec les différents membres des équipes de développements/tests/infras. En effet, ces objectifs contraignants (bloque la livraison de la US) ne doivent pas être trop contraignants ou inatteignables pour les différentes équipes.
Au fur et à mesure du produit le DoD peut être modifié en ajoutant ou retirant des critères mais ces actions doivent être rare et avec une justification business derrière (Passage sur un produit payant par exemple).

Quand vérifier l’avancée du DoD ?

L’ensemble du DoD doit être validé avant la livraison en production, mais il est judicieux que certaines parties soient prêtes avant.
Chronologiquement on peut découper la vie d’une US en 4 phases où l’on va insérer les différentes parties du Done:

• Début des développements
• Fin des développements
• Fin de tests
• Avant la Mise en Prod

Une étape validée en amont de la livraison se doit de l’être tout au long du cycle de la US.

Exemple de Dod (liste non exhaustive)

• Code
  • Le code est revu automatiquement avec un taux de validation de 100%
  • Le code est versionné
  • Le code est couvert par 80% de test unitaires

• Test
  • Les tests unitaires et les tests d’acceptation fonctionnels ne remontent aucune anomalie (BDD/ATDD/GUI Test)
  • Les tests manuels de la story sont joués à 100%
  • Les tests de non régression P0 ne remontent aucune anomalie
  • Les tests de non régression P0 sont automatisés
  • Les critères d’acceptation sont couverts par des tests

• Fonctionnel
  • L’ensemble des critères d’acceptation est implémenté dans l’application
  • Le produit est compatible sur la dernière version du navigateur Chrome lors de la mise en production
  • Le produit est correctement affiché sur un écran FULLHD
  • Le produit est compatible IOS

• Non fonctionnel
  • La version du produit est taguée
  • Aucun bug de priorité Elevé/Très élevé n’est ouvert sur l’application

• Infrastructure
  • Les environnements sont prêts
  • Le produit est automatiquement déployé sur l’environnement de Préproduction sans erreur
  • Le taux de disponibilité du produit est de 99%

• Documentation
  • La documentation est à jour et revue (upgrade guide/changelog)
  • La documentation d’architecture est à jour et revue
  • La communication est préparée
  • Le rapport de livraison est prêt à être envoyé

• Sécurité
  • Les librairies utilisées sont toutes à jour
  • Les tests de sécurité ne remontent aucune faille
  • Les dernières versions des produits techniques sont utilisées

• Performance
  • L’ensemble des écrans du produit est affiché en moins de X secondes
  • Les tests de performances sont mis à jour

Conclusion

La mise en place d’un Dod permet de mieux suivre la qualité d’un produit puisqu’elle permet de rejeter une US si celle-ci n’a pas l’ensemble des critères validés. Malheureusement son caractère contraignant fait que le DoD n’est que suivi rarement et donc fait de cette notion une inconnue pour de nombreux projets agiles.