Definition of Done dans Jira : convenir du sens de « terminé »

Un développeur termine une modification et fait avancer le ticket Jira. Une testeuse constate que le nouvel écran fonctionne, mais qu’un parcours existant est cassé. Le support découvre la modification grâce à un client perdu. Tout le monde a utilisé le mot terminé, avec un sens différent.

Une Definition of Done donne à l’équipe un standard commun d’achèvement. Elle rend visibles les contrôles qualité attendus avant le début du travail, pour que la revue dépende moins de la personne qui pense à poser la bonne question.

Dans ce guide, nous construirons un exemple pour une équipe fictive de portail client, distinguerons les contrôles qualité partagés des critères propres à la fonctionnalité, puis placerons les deux à côté d’un ticket avec Definition of Done & AC de Power Pack.

Qu’est-ce qu’une Definition of Done ?

Le Scrum Guide décrit la Definition of Done comme le standard de qualité qu’un incrément doit respecter. Elle crée une compréhension commune du travail achevé. Lorsqu’une organisation a établi un standard, il constitue le minimum pour ses équipes Scrum. Voir le Scrum Guide officiel.

Pour notre exemple pratique, considérez-la comme quelques questions que l’équipe pose à chaque modification pertinente. La réalisation a-t-elle été relue ? Les vérifications convenues ont-elles réussi ? Les informations nécessaires pour accompagner le changement sont-elles disponibles ?

Les questions exactes dépendent du produit et de ses risques. Un portail client public, un rapport interne et un système critique pour la sécurité ont besoin de standards différents. Copier une checklist sans discussion peut laisser des lacunes importantes tout en ajoutant du travail inutile.

Un standard utile décrit un résultat observable. « Haute qualité » exprime une ambition. « Les contrôles de non-régression convenus ont réussi, avec leurs résultats liés depuis le ticket Jira » décrit quelque chose qu’une personne peut examiner.

Séparez la qualité commune du comportement de la fonctionnalité

Notre équipe fictive ajoute des préférences de notification. Les clients pourront activer ou désactiver un e-mail récapitulatif hebdomadaire. Les messages importants du compte restent hors de cette préférence.

La fonctionnalité a besoin de ses propres critères d’acceptation. Par exemple, un choix enregistré doit encore apparaître après déconnexion puis reconnexion. Cette exigence appartient à la fonctionnalité, car elle décrit l’expérience attendue du client.

La Definition of Done couvre le standard plus large d’achèvement. Relire la réalisation, vérifier les comportements existants touchés et actualiser les informations de support peut concerner beaucoup de modifications.

Les deux listes comptent. Une fonctionnalité peut se comporter comme demandé tout en manquant un travail qualité essentiel. Inversement, du code relu et des contrôles de non-régression réussis ne prouvent pas que la fonctionnalité demandée se comporte correctement.

Partez des lacunes réellement observées

Réunissez brièvement les personnes qui développent, vérifient et accompagnent le produit. Utilisez un exemple récent de travail apparemment terminé ayant nécessité un suivi inattendu.

Notre équipe identifie trois problèmes récurrents. Certains commentaires de revue restent ouverts. Les réglages de compte existants sont peu couverts par les tests de non-régression. Les instructions de support arrivent après la mise à disposition de la fonctionnalité.

Ces problèmes suggèrent des contrôles utiles. Ils expliquent aussi pourquoi le standard doit rester court : chaque entrée doit prévenir une défaillance reconnaissable ou établir une condition qualité nécessaire.

Demandez comment chaque proposition sera vérifiée. Si personne ne peut décrire les preuves, améliorez la formulation avant de l’adopter. « Documentation terminée » peut désigner des notes de version, une conception interne ou un article d’aide client. Convenez des informations nécessaires et de leur emplacement.

Convenez aussi de qui réalise habituellement les contrôles. Cette discussion peut avoir lieu dans la planification ordinaire. Une checklist seule n’attribue pas de relecteur et ne réserve aucun créneau dans son agenda.

Rédigez une checklist commune pratique

Voici la première version de l’équipe. Il s’agit d’un accord de travail illustratif, pas d’un standard universel.

• La revue de réalisation est terminée et les commentaires obligatoires sont résolus.
• Les critères d’acceptation convenus du ticket ont été vérifiés.
• Les contrôles de non-régression convenus pour les parcours de compte touchés ont réussi.
• Les contrôles d’accessibilité convenus pour les écrans modifiés ont réussi.
• Les informations de support reflètent le nouveau comportement client.
• Les résultats de vérification et les liens de revue pertinents sont consignés dans le ticket Jira.

Avant d’utiliser cette liste, l’équipe précise ce que comprennent ses contrôles de non-régression et d’accessibilité. Sinon, deux personnes pourraient cocher la même phrase après des travaux différents.

Pour le portail, les contrôles de non-régression comprennent la connexion, l’ouverture des paramètres du compte et la modification d’un champ de profil existant. La revue d’accessibilité des contrôles modifiés comprend le clavier, la visibilité du focus et la clarté des libellés. Ce sont les contrôles choisis par cette équipe, pas un standard complet d’accessibilité.

L’entrée de support nécessite aussi une interprétation pratique. Si une modification n’a aucun effet visible pour les clients, l’équipe doit établir à l’avance un standard adapté. Évitez de faire improviser des exceptions aux relecteurs uniquement pour afficher une liste verte.

Ajoutez le standard à un ticket Jira

Ouvrez le ticket concerné et repérez la carte Definition of Done & AC de Power Pack. Elle comporte deux onglets distincts : Acceptance Criteria et Definition of Done. Choisissez Definition of Done avant d’ajouter les contrôles communs.

Pour une petite liste, saisissez le titre d’un contrôle et sélectionnez Add, ou appuyez sur Entrée. Chaque titre doit porter sur une condition vérifiable. Une longue phrase réunissant trois contrôles indépendants rend difficile la représentation d’un achèvement partiel.

Vous pouvez aussi sélectionner Bulk Import et coller une liste Markdown. Par exemple, collez les six entrées ci-dessus avec un tiret et une espace au début de chaque ligne. Les cases à cocher Markdown ordinaires sont également prises en charge.

L’import ajoute les entrées à l’onglet choisi. Vérifiez cet onglet avant de confirmer, puis inspectez la liste obtenue. Réimporter le même contenu peut ajouter des doublons : utilisez cette action délibérément, pas comme un rafraîchissement.

Utilisez des entrées non cochées pour le travail non vérifié. Les cases Markdown cochées sont importées comme terminées ; des coches copiées d’un ancien ticket ne remplacent pas la revue de la modification actuelle.

Le standard convenu doit être ajouté manuellement à chaque ticket concerné. Conservez une copie de référence dans la documentation habituelle de l’équipe et collez les contrôles adaptés dans les nouveaux tickets. C’est une pratique d’équipe, pas une liaison automatique entre un standard central et chaque ticket.

Parcourez une revue réelle

Supposons que les préférences de notification soient prêtes à être examinées. Maya vérifie les résultats pour le client tandis que Priya effectue les contrôles de non-régression convenus. Leo résout les derniers commentaires de revue et ajoute le lien vers celle-ci.

Le premier passage révèle que la préférence s’enregistre correctement, mais que le focus clavier disparaît après Save. L’équipe laisse le contrôle d’accessibilité incomplet, consigne le problème dans sa discussion Jira habituelle et le corrige avant de répéter le contrôle concerné.

Les informations de support ne sont pas non plus terminées. Cela reste visible même si les critères propres à la fonctionnalité sont remplis. Les listes séparées expliquent pourquoi du travail subsiste.

Lorsqu’un contrôle a réellement réussi, sélectionnez son bouton Done. Sélectionnez-le à nouveau si de nouvelles informations imposent de le rouvrir. Consignez résultats, liens de revue et décisions importantes dans le processus Jira ou documentaire habituel.

Une entrée terminée consigne le jugement de l’équipe. Elle n’exécute pas le contrôle, ne collecte pas ses preuves et n’établit pas l’identité de la personne qui l’a réalisé. Si l’identité ou la date compte, notez-la explicitement dans votre processus de revue.

Lisez attentivement l’indicateur de préparation

L’outil affiche le nombre d’entrées terminées et le total pour chaque onglet. L’indicateur affiche Ready for Release uniquement si les deux listes contiennent au moins une entrée et que toutes sont terminées. Sinon, il affiche In Verification.

Cette règle aide à repérer les entrées inachevées. Elle explique également pourquoi une liste Definition of Done complète ne produit pas l’état global terminé tant qu’Acceptance Criteria reste vide.

Considérez cette formulation comme un résumé de l’état des checklists. Elle ne prouve ni la suffisance des contrôles, ni la solidité des preuves, ni la sécurité d’une publication. On peut marquer terminé un mauvais contrôle aussi facilement qu’un bon.

La checklist ne bloque pas non plus un changement de statut Jira ou la fusion d’une pull request. Continuez à utiliser le processus normal de réalisation et de publication pour ces décisions.

Gardez le standard utile lorsque le travail évolue

Réexaminez le standard lorsqu’un défaut récurrent révèle un contrôle manquant, lorsque le produit change sensiblement ou lorsqu’un contrôle ne fournit plus d’information utile.

Par exemple, l’équipe pourrait découvrir que les préférences fonctionnent immédiatement mais échouent après une synchronisation différée. Cela pourrait mener à une règle plus large pour les fonctionnalités dépendant d’un traitement différé. L’équipe doit d’abord déterminer les modifications concernées et les preuves qui démontreront le succès.

Actualisez le standard de référence et discutez de son application au travail en cours. Les listes existantes n’héritent pas automatiquement de cette révision. Examinez les tickets touchés et ajoutez manuellement les nouveaux contrôles convenus si nécessaire.

Évitez d’allonger la liste après chaque erreur isolée. Parfois, la meilleure réponse est un critère d’acceptation précis, une tâche de réalisation plus claire ou une modification de la revue. Le standard commun doit rester compréhensible et réellement applicable.

Essayez sur un ticket actuel

Choisissez un ticket qui approche de la revue. Convenez d’un court standard qualité commun, placez-le dans Definition of Done et ajoutez les résultats client propres au ticket sous Acceptance Criteria.

Parcourez les contrôles ensemble et liez les preuves à l’endroit habituel. Marquez les entrées terminées seulement après vérification, puis examinez le travail restant dans le processus normal de réalisation.

Le résultat utile est une conversation plus claire. Lorsqu’une personne dit que les préférences de notification sont terminées, l’équipe peut expliquer quels résultats fonctionnent, quels contrôles qualité ont réussi et sur quoi repose cette conclusion.

• Le Scrum Guide — Definition of Done