Qu'est-ce que la définition de « Terminé » ?

Atlassian Par Atlassian
Parcourir les rubriques

« Cette tâche est-elle terminée ? »

Pour répondre à cette question apparemment simple, il faut vérifier si un incrément d'élément ou de produit est terminé ou en cours. Mais cela ne fonctionne que si une équipe et ses parties prenantes l'ont expressément défini comme « terminé ».

Dans les méthodologies de gestion de projet Agile qui utilisent Kanban ou le framework Scrum, « terminé » fait référence à une colonne sur un tableau visuel indiquant les éléments terminés. Le fait de choisir une définition claire de « Terminé » permet aux équipes Agile, y compris les équipes DevOps et Scrum, de terminer leurs éléments plus efficacement.

Chronologie JSW

Ce guide explique la définition de la notion « Terminé » dans les méthodologies Agile et indique comment l'utiliser pour augmenter l'efficacité et la valeur des projets.

Comprendre la définition de « Terminé » dans Agile

Un DoD est un ensemble de critères auxquels un incrément de produit doit répondre pour que l'équipe le considère comme terminé et prêt à être livré aux clients. Les membres de l'équipe savent tous à quel moment un incrément de produit est prêt à être livré, même s'il est conséquent et comprend de nombreuses tâches. En définissant clairement le sens de « Terminé » pour le projet, une équipe Agile peut se concentrer sur la création de valeur à chaque sprint et réduire le nombre de révisions.

Il est important de noter que ce n'est pas une seule personne qui crée la définition de « Terminé ». Elle est plutôt établie par l'ensemble de l'équipe du projet, y compris les développeurs, les testeurs, les Product Owners et les autres parties prenantes. Cela garantit un processus plus fluide pendant les sprints, car toutes les personnes impliquées utilisent le DoD comme guide, parallèlement aux listes de contrôle, avant de noter une tâche comme terminée.

Quelques exemples de la définition de « Terminé »

Le DoD d'un projet varie en fonction du type de projet et de l'équipe qui travaille dessus. Les exemples suivants de DoD montrent en quoi ces définitions diffèrent selon les types de projets :

Dans le cadre d'un projet de développement d'applications mobiles, voici des éléments que le DoD peut inclure :

  • Toutes les images sont compressées.
  • L'ensemble du code est minifié et compressé.

Dans le cadre d'un projet de développement logiciel, les critères du DoD peuvent inclure les points suivants :

  • L'ensemble du code a été minutieusement testé par des tests unitaires, des tests d'intégration et des tests de bout en bout.
  • L'incrément de produit a été déployé dans un environnement de staging et testé par l'équipe.

Un projet générique peut inclure ces éléments dans le cadre du DoD :

  • Toutes les erreurs ont été résolues.
  • Toute la documentation de publication a été rédigée et éditée.

Définition de « Terminé » et définition de « Prêt ».

La DoD est un ensemble de critères de haut niveau qui définit quand un incrément de produit est terminé. Cela garantit la qualité et la cohérence d'un livrable. Les équipes ont généralement recours au DoD à la fin d'un sprint pour vérifier la qualité d'un incrément de produit.

En revanche, la définition de « Prêt » (DoR) est un ensemble de critères spécifiques et de bas niveau qui s'appliquent uniquement aux tâches du backlog produit. Le DoR définit le moment où une tâche du backlog est prête à être traitée par une équipe lors d'un prochain sprint. Une équipe a recours au DoR pour l'affinement du backlog au début d'un sprint.

Pourquoi la définition de « Terminé » est-elle importante ?

Il est essentiel d'avoir un DoD pour fournir un produit de qualité correspondant aux attentes des clients, car cela permet de savoir à quel moment une tâche peut être considérée comme terminée et peut être intégrée à un incrément de produit. Un DoD bien conçu offre les avantages suivants :

Amélioration de la qualité: Le fait de vérifier chaque élément d'un incrément de produit par rapport aux critères du DoD garantit que les équipes Agile gardent à l'esprit les objectifs de qualité tout au long du développement d'un produit. Cela permet de s'assurer que les standards de qualité requis sont toujours respectés avant la livraison.

Minimiser les risques: se conformer au DoD minimise le besoin de révision et les retards qui en découlent, dans la mesure où l'équipe sait exactement quels sont les critères à respecter pour qu'une tâche soit considérée comme terminée. Cela assure un niveau de qualité à tous les stades du projet.

Favoriser l'alignement des équipes : étant donné que le DoD est une compréhension commune de la signification du terme « Terminé » dans le contexte du projet, les équipes peuvent plus facilement se concentrer sur les exigences des clients et apporter de la valeur à chaque sprint.

Mesurer les avancements accomplis: le fait d'avoir un DoD clair permet aux équipes de suivre le nombre d'incréments de produit qui répondent aux critères pour être considérés comme « Terminé ». Par exemple, les métriques Scrum peuvent inclure la vélocité, qui indique le nombre d'incréments de produit livrés par une personne dans un délai défini.

Étapes pour définir les critères de la notion « Terminé »

Bien que les étapes précises pour définir la notion « Terminé » varient en fonction de l'équipe et du projet, le processus respecte un schéma similaire. Voici les étapes pour créer un DoD:

1. Travailler avec la bonne équipe

Il est important de collaborer avec les bons membres de l'équipe lors de l'élaboration d'un DoD, étant donné que les critères retenus sont le fruit d'une compréhension commune entre tous les participants. Cela signifie que toutes les personnes qui pourraient avoir leur mot à dire sur la définition de « Terminé » pour un projet doivent être impliquées : les Product Owners, le Scrum Master, les membres de l'équipe Scrum, les testeurs, les responsables produits, les sponsors et les autres parties prenantes concernées.

Chaque membre de l'équipe contribue au projet par ses connaissances dans le domaine et peut déterminer les critères pertinents dans son domaine d'expertise. Si la composition de l'équipe n'est pas la bonne ou si des membres clés de l'équipe sont absents, les critères du DoD risquent de ne pas être complètement respectés, ce qui entraînera une baisse de la qualité du produit.

2. Établir les critères

La tâche la plus importante pour qualifier un projet de « Terminé » est de définir les critères que l'équipe appliquera au projet. Il est crucial de définir les paramètres du DoD, car cela aura une incidence sur la qualité du travail effectué.

Comment savoir si chaque composant du projet est terminé ? Quelles sont les conditions qui indiquent que l'incrément du produit est terminé ? Les critères doivent être spécifiques, mesurables, accessibles, pertinents et limités dans le temps. Pour choisir les critères appropriés, l'équipe doit se poser deux questions fondamentales :

  1. Les critères sont-ils suffisamment précis ? Il ne faut pas être vague (l'intégralité du code est testé), mais précis (l'intégralité du code est testé de manière approfondie via des tests unitaires, des tests d'intégration et des tests de bout en bout).
  2. Les critères sont-ils axés sur le client ? Voici un bon exemple de critère : « Toute la documentation a été rédigée et mise à jour », ce qui devrait permettre à l'utilisateur final de trouver facilement des indications lors de l'utilisation du produit.

3. Générer une checklist

Bien que le critère DoD semble relever du bon sens lorsqu'il s'agit de préparer une plus importante quantité d'incréments de produit à livrer, les équipes devraient également l'appliquer aux tâches, problèmes ou erreurs de moindre importance sur lesquels elles travaillent au cours du sprint. Le fait d'établir une checklist pour chaque tâche ou problème permet à l'équipe de fournir constamment un travail de haute qualité.

4. Attribuer des critères d'acceptation aux user stories

Les critères d'acceptation (AC) font référence aux conditions que les user stories doivent remplir pour être acceptées par les clients. Cela diffère des critères du DoD car il s'agit d'user stories ou de fonctions plutôt que d'incréments de produit.

Mais à l'instar du DoD, les AC relèvent également de critères convenus pour déterminer si une user story ou une tâche individuelle est terminée. Si, par exemple, une user story se présente comme suit : « En tant qu'utilisateur, je veux pouvoir utiliser un champ de recherche pour trouver un produit. » Les critères d'acceptation peuvent être les suivants :

  • Le champ de recherche se trouve dans la barre de navigation supérieure.
  • La recherche démarre lorsque l'on appuie sur le bouton « Rechercher ».
  • Le champ de recherche contient un texte générique « Que recherchez-vous ? »

5. Réviser et mettre à jour le DoD

Le DoD n'est pas un document statique. Tout bug ou erreur constatés au cours d'un sprint est un problème de qualité qui peut avoir été causé par une mauvaise définition de la notion « Terminé ». Il devient alors crucial de mettre à jour le DoD pour que le bug ne se reproduise pas.

Réviser et mettre à jour le DoD lors des revues de sprint pour rester pertinent par rapport au projet. Dans la mesure où les projets évoluent et que les équipes en apprennent davantage sur les exigences des clients, il se peut que le DoD nécessite une révision pour pouvoir être réalisable. Veiller à ce que les membres de l'équipe puissent proposer des changements au DoD lors des revues de sprint ou des réunions d'affinement du backlog.

Garantir un DoD bien défini avec Jira Software

Atlassian et Jira Software vous permettent de définir facilement la notion de « Terminé » . Pour créer un DoD avec Jira Software, il suffit d'ajouter des critères au DoD dans un menu. Il est possible de limiter les critères en fonction du type de ticket. Cela est possible grâce à la création de checklists comportant des cases à cocher ou des listes à puces, et en choisissant l'endroit où ces checklists doivent être affichées.

Jira Software propose également d'autres outils pour tous vos besoins en matière de gestion de programmes et de projets, de la planification Agile aux sprints « stand-up » et toutes les autres étapes intermédiaires. Essayez gratuitement.

Définition de « Terminé » : foire aux questions

Qui est chargé de créer la définition de « Terminé » ?

L'équipe de développement, dirigée par le Scrum Master, est généralement à l'origine de la création d'un DoD. Toutefois, il convient de demander l'avis des Product Owners, des testeurs et autres parties prenantes.

Qu'est-ce qui différencie la notion de « Terminé » des critères d'acceptation ?

Le DoD est un ensemble de critères de haut niveau permettant de déterminer si un incrément de produit est terminé. Il s'applique à tous les incréments de produit et définit la qualité globale d'un produit.

En revanche, les critères d'acceptation sont des conditions de bas niveau qui ne s'appliquent qu'à des user stories ou à des fonctions spécifiques. Les AC permettent de définir si une user story est acceptable pour un client. Un exemple de DoD pourrait être « Toute la documentation est rédigée et mise à jour ». Un exemple d'AC pourrait être « Le lien vers la documentation pour les utilisateurs est accessible depuis le menu de navigation ».

Quelles sont les meilleures pratiques pour créer une définition de « Terminé » ?

Définir les critères avec son équipe: La définition du DoD doit être le fruit d'un effort de collaboration impliquant toute l'équipe, y compris les développeurs, les testeurs, les Product Owners et les parties prenantes concernées. La création d'un DoD garantit une compréhension commune de ce que signifie la notion de « Terminé » pour un incrément de produit.

Garantir sa visibilité : la définition de « Terminé » doit être disponible et visible pendant la planification du sprint ou lors des discussions sur l'estimation du nombre d'éléments du backlog produit. L'équipe devrait pouvoir s'y référer régulièrement. Imprimez cette définition et accrochez-la au mur, ou incluez-la dans un wiki ou dans le plan de projet.

Rester pratique et réaliste : la définition de « Terminé » doit être réalisable dans les délais et avec les ressources disponibles. Plus important encore, elle doit correspondre aux besoins réels des clients.