Glossaire Agile

Pourquoi ce sujet. Une même expression peut désigner une pratique, un document, une réunion ou un indicateur. Ce glossaire fixe le sens retenu pendant cette journée. Il ne remplace pas les échanges : il évite seulement de repartir de zéro chaque fois qu'un mot arrive dans la conversation.

À la fin de ce chapitre

Retrouver un terme dans l'index, sans parcourir toute la page.
Comprendre son usage dans une situation de travail concrète.
Distinguer les termes voisins quand la confusion change une décision.

Les définitions ne sont pas des lois. Une équipe peut nommer ses objets autrement. Quand ce vocabulaire varie, le point utile est de demander ce que le mot désigne chez elle, qui le tient à jour et à quel moment il sert.

Approches et cadres

Agile: Une façon de travailler quand on ne connaît pas complètement la bonne solution au départ. On avance par petites livraisons, on observe ce qui se passe, puis on change la suite.; Exemple. L'équipe montre une première version de la prise de rendez-vous après 2 semaines. Les retours font changer les priorités du backlog.
Cadre de travail: Un ensemble de règles qui donne une structure à une équipe : rôles, rendez-vous et objets de travail. Scrum est un cadre. Il ne dit pas quelle solution construire.; Exemple. Le cadre prévoit une revue toutes les 2 semaines. La façon de conduire cette revue reste à choisir par l'équipe.
Scrum: Un cadre de travail qui organise le travail en sprints. Il pose des rôles, des rendez-vous et des objets de référence pour rendre les décisions et les problèmes visibles.; Exemple. Le Product Owner remet le backlog en ordre. L'équipe choisit ensuite ce qu'elle pense pouvoir terminer pendant le sprint.
Kanban: Une approche qui pilote le travail par le flux. Le tableau rend visible ce qui attend, ce qui est en cours et ce qui est terminé. L'équipe limite surtout le nombre de sujets commencés en même temps.; Exemple. Si 8 demandes sont bloquées en validation, l'équipe traite ce blocage avant de démarrer 8 nouvelles demandes.
Scrumban: Un mélange de pratiques issues de Scrum et de Kanban. Le mot décrit des choix d'équipe, pas un cadre officiel avec une règle unique.; Exemple. Une équipe garde la revue de sprint et utilise un tableau avec des limites de travail en cours.
Lean Startup: Une démarche pour construire quand on ignore encore si le besoin existe. On formule une hypothèse, on met le plus petit produit possible dans de vraies mains, on mesure l'usage réel, puis on continue ou on change de direction. La réponse vient du terrain, pas de la réunion.; Exemple. Plutôt que d'écrire le module de téléconsultation, l'équipe propose 20 rendez-vous par visioconférence classique. Trois soignants sur 20 en redemandent : l'hypothèse ne tient pas encore.
Running Lean: La mise en pratique du Lean Startup proposée par Ash Maurya. Elle donne un ordre : cadrer le problème sur une page, aller parler aux personnes concernées, puis seulement construire. Sa règle centrale est de traiter le problème le plus risqué en premier.; Exemple. Avant tout développement, l'équipe mène 15 entretiens de soignants pour vérifier que la préparation de consultation est bien le point douloureux, et non la facturation.
SAFe: Un cadre destiné à coordonner l'Agile à l'échelle de nombreuses équipes. Il ajoute des niveaux de planification, de synchronisation et de gouvernance.; Exemple. Plusieurs équipes planifient ensemble un trimestre. Il faut ensuite vérifier que ce calendrier ne ralentit pas leur capacité à changer d'avis.

Rôles

Product Manager, ou PM: La personne qui décide sur quel problème le produit se place : marché visé, position face aux autres, modèle économique. Elle regarde vers l'extérieur, quand le Product Owner regarde vers l'équipe. Le titre n'existe pas dans Scrum ; dans une petite structure, une même personne tient souvent les deux.; Exemple. Le PM décide de viser les cabinets de kinésithérapie plutôt que l'hôpital. Le PO en tire ce que l'équipe construit ce sprint pour ces cabinets.
Product Owner, ou PO: La personne responsable de l'ordre du backlog produit et des choix de valeur. Elle décide ce qui mérite d'être traité avant le reste. Elle ne dicte pas la solution technique ni la taille du travail.; Exemple. Face à une date fixe, le PO retire une fonction moins utile du périmètre. L'équipe garde ainsi le niveau de qualité prévu.
Scrum Master: La personne qui veille à ce que Scrum soit compris et pratiqué. Elle fait apparaître les obstacles et travaille sur les conditions qui empêchent l'équipe d'avancer.; Exemple. La validation juridique bloque chaque sprint. Le Scrum Master met le problème sur la table et cherche avec les personnes concernées une autre façon de travailler.
Équipe de développement: Les personnes qui transforment un besoin en incrément utilisable. Dans Scrum, l'équipe s'organise pour décider comment faire le travail.; Exemple. Le PO exprime le besoin de simplifier l'inscription. L'équipe choisit les changements de code, de tests et d'interface nécessaires.
Stakeholder, ou partie prenante: Toute personne concernée par le produit sans le construire : direction, service juridique, support, financeur, ou personne qui l'utilise. Chacune arrive avec un besoin légitime et une vue partielle. Les écouter n'oblige pas à les satisfaire toutes : l'arbitrage revient au Product Owner.; Exemple. En revue de sprint, le service juridique demande une trace des consentements et le support demande un export. Le PO tranche l'ordre des deux.

Choisir et décrire le travail

Vision produit: Une formulation courte de ce que le produit doit apporter et à qui. Elle permet de juger si une idée mérite d'entrer dans le backlog.; Exemple. « Réduire le temps de préparation des consultations pour les soignants » donne un critère pour écarter une idée qui ne sert que le reporting interne.
Backlog produit: La liste ordonnée des choses qui pourraient améliorer le produit : besoins, problèmes à résoudre, corrections ou apprentissages à mener. Son ordre change quand l'équipe apprend.; Exemple. Après une démonstration, une demande de correction remonte avant une fonction prévue, car elle bloque les personnes qui utilisent le produit.
Backlog de sprint: Ce que l'équipe prévoit de traiter pendant le sprint, avec son plan de travail. Il est plus précis que le backlog produit et appartient à l'équipe de développement.; Exemple. Le sprint contient la simplification de l'inscription, les tests associés et une adaptation de la base de données.
User story: Une courte formulation d'un besoin vue par la personne qui en bénéficie. Elle ouvre une conversation. Elle n'est pas une spécification complète.; Exemple. « En tant que secrétaire, je veux retrouver un patient par son numéro afin de préparer son dossier plus vite. »
Les 3 C : card, conversation, confirmation: Les 3 éléments d'une user story : une carte qui rappelle le besoin, une conversation qui précise ce qu'il faut faire, une confirmation qui dit comment vérifier le résultat.; Exemple. La phrase sur la carte tient en 3 lignes. Les détails viennent de l'échange entre PO, équipe et personnes concernées.
Critères d'acceptation: Les conditions propres à une user story qui permettent de dire si le besoin est couvert. Ils précisent le comportement attendu par la personne qui utilise le produit.; Exemple. Pour la recherche de patient : le système trouve un dossier à partir d'un numéro valide et indique clairement quand aucun dossier ne correspond.
Story mapping: Une façon de placer les user stories selon le parcours d'une personne qui utilise le produit. Elle rend visible ce qu'il faut faire en premier pour obtenir une première version utile.; Exemple. Sur le parcours d'un soignant, on place d'abord « trouver un patient », puis « consulter son dossier », puis « ajouter une note ».

Livrer avec le même niveau d'exigence

Sprint: Une période courte et de durée fixe, souvent 2 semaines, pendant laquelle l'équipe vise un objectif concret. Le sprint crée un rythme de livraison et de retour.; Exemple. Pendant 2 semaines, l'équipe cherche à rendre l'inscription praticable sans assistance téléphonique.
Objectif de sprint: La phrase qui donne une cohérence au sprint. Elle décrit le résultat recherché, pas la liste de chaque tâche.; Exemple. « Permettre à un secrétariat de retrouver un patient sans passer par le support. »
Incrément: La partie du produit réellement terminée à la fin d'un sprint, qui peut être utilisée ou mise en production. Elle respecte la Definition of Done.; Exemple. La recherche de patient fonctionne, est testée et peut être montrée à des utilisateurs. Ce n'est pas seulement une maquette.
Definition of Done, ou DoD: L'accord partagé sur ce que « terminé » veut dire pour tout le travail de l'équipe. Elle couvre la qualité de livraison : tests, revue, sécurité, documentation ou mise en production selon le contexte.; Exemple. Une fonctionnalité n'est terminée que si les tests passent, qu'elle a été relue et que son comportement est vérifié sur l'environnement prévu.
Release: Une livraison d'une version du produit à ses destinataires. Une release rassemble un ou plusieurs incréments. Un incrément terminé peut attendre : c'est une décision de PO, pas une contrainte technique.; Exemple. Trois sprints produisent la recherche, la fiche patient et l'export. Les trois partent ensemble en une release, pour ne former qu'une seule formation des secrétariats.
Plan de release, ou release plan: Une prévision de ce que les prochaines semaines pourraient contenir, construite à partir de la vélocité observée. Il donne une fourchette, pas une date ferme, et se révise à chaque sprint. Le Scrum Guide ne le compte pas parmi ses artefacts : il vient de la pratique.; Exemple. À 25 points par sprint, les 120 points restants tiennent en 4 à 6 sprints. La fourchette se resserre à mesure que les sprints passent.
Mise en production: Le moment où une version devient accessible aux personnes qui utilisent réellement le produit. C'est là que le retour le plus concret commence.; Exemple. La nouvelle recherche est disponible pour 10 secrétariats. Leurs usages et leurs difficultés servent au sprint suivant.
Code legacy: Du code qui existe déjà et dont l'équipe doit tenir compte. Il peut être ancien ou récent, propre ou difficile à modifier. Le mot ne dit pas à lui seul que le code est mauvais.; Exemple. Une fonction écrite l'an dernier gère l'identité des patients. Toute nouvelle inscription doit composer avec elle, car elle est déjà en production.
Dette technique: Le coût futur créé par un choix technique fait pour aller plus vite aujourd'hui. Elle rend les changements suivants plus lents, plus risqués ou plus chers. Elle peut être volontaire ou subie.; Exemple. Pour tenir une date, l'équipe copie une règle de calcul à 4 endroits. La prochaine modification impose de changer les 4, avec un risque d'oubli.

Observer et apprendre

Daily Scrum: Un rendez-vous court, tenu chaque jour ouvré pendant le sprint, où l'équipe de développement ajuste son plan. Il sert à se coordonner, pas à rendre compte à un manager.; Exemple. Un développeur signale que la validation externe bloque la recherche. L'équipe modifie son ordre de travail pour ne pas attendre sans rien faire.
Revue de sprint: Un moment où l'équipe et les personnes concernées regardent ce qui a été produit et ce qui a changé autour du produit. Les échanges peuvent modifier le backlog.; Exemple. En voyant la recherche de patient, les secrétariats disent que le numéro n'est jamais utilisé. Le nom devient prioritaire.
Rétrospective: Un rendez-vous où l'équipe examine sa façon de travailler et choisit un changement à essayer. Elle concerne le travail de l'équipe, pas le contenu du produit.; Exemple. Après 3 sprints avec des tests en retard, l'équipe décide de ne plus considérer une story terminée sans ses tests.
Boucle de feedback: Le délai entre une décision et le moment où l'on voit son effet. Plus cette boucle est courte, plus l'équipe peut corriger tôt.; Exemple. Montrer une version utilisable à la fin du sprint donne un retour en 2 semaines. Attendre la recette finale peut le repousser de plusieurs mois.
Estimation: Une prévision sur l'effort, la taille ou le délai d'un travail. Elle exprime une incertitude à partir de ce que l'équipe sait au moment où elle répond.; Exemple. L'équipe estime qu'une amélioration prendra entre 3 et 5 jours, car elle ne connaît pas encore l'état d'un service externe.
Engagement: La décision de faire un travail ou d'atteindre un objectif. Il ne transforme pas une estimation en certitude. Si les faits changent, le périmètre ou le plan doit pouvoir changer aussi.; Exemple. L'équipe s'engage sur l'objectif « simplifier l'inscription », puis retire une option secondaire quand un problème de sécurité apparaît.
Story point: Une unité relative utilisée par certaines équipes pour comparer la taille de leurs user stories. Elle n'est ni une heure ni une mesure universelle de productivité.; Exemple. Une équipe considère qu'une story à 8 points est environ deux fois plus grande qu'une story à 3 points, pour elle et à ce moment-là.
Vélocité: La quantité de travail qu'une même équipe termine habituellement sur un sprint, souvent exprimée en story points. Elle sert à prévoir sa capacité future, jamais à comparer des équipes.; Exemple. Après plusieurs sprints autour de 25 points terminés, l'équipe s'en sert pour éviter d'en prévoir 60 au sprint suivant.
Burndown chart: Un graphique qui montre ce qu'il reste à terminer au fil du temps dans un sprint ou une release. Il peut rendre un écart visible, il n'explique pas sa cause.; Exemple. La courbe reste plate pendant 5 jours. L'équipe découvre qu'une validation externe bloque plusieurs stories et ajuste son plan.