L’agilité privilégie la flexibilité, les commentaires des clients et les itérations rapides, mais naviguer dans le jargon peut être écrasant pour les nouveaux arrivants et même les praticiens chevronnés.
Ce glossaire Agile complet est conçu pour démystifier les termes et les pratiques les plus couramment utilisés dans Agile, des concepts fondamentaux tels que les user stories et les sprints, aux techniques plus avancées telles que le développement piloté par le comportement (BDD) et le déploiement continu.
Que vous soyez développeur, propriétaire de produit, scrum master ou simplement curieux de connaître Agile, ce glossaire vous servira de référence pratique pour clarifier la terminologie et améliorer votre compréhension des processus Agile.
Chaque terme est expliqué à l’aide d’exemples pratiques et d’un contexte, ce qui permet de s’assurer que vous ne connaissez pas seulement les mots, mais aussi la façon dont ils sont appliqués dans des environnements Agile réels.
Explorez le glossaire ci-dessous et acquérez les connaissances nécessaires pour naviguer en toute confiance dans votre parcours Agile.
A
Développement piloté par les tests d’acceptation (ATDD)
L’ATDD implique que toute l’équipe (clients, développeurs, testeurs) travaille ensemble pour créer des tests d’acceptation qui définissent le comportement attendu du système avant l’écriture du code. Ce processus garantit que tous les membres de l’équipe ont une compréhension commune des exigences et améliore la collaboration et la qualité des produits.
Tests d’acceptation (Acceptance Testing)
Les tests d’acceptation vérifient si un produit répond aux exigences de l’entreprise et est prêt à être livré. Il est généralement mené par les parties prenantes pour s’assurer que le système fonctionne comme prévu dans des scénarios réels. Ces tests peuvent inclure des tests d’acceptation par l’utilisateur (UAT), des tests d’acceptation opérationnelle (OAT) et des tests d’acceptation de contrat.
Anti-motif (AntiPattern)
Un antimodèle semble être une solution couramment suivie, mais produit en réalité plus de problèmes qu’il n’en résout.
Il s’agit de pratiques qui semblent bénéfiques au départ, mais qui aboutissent à des résultats négatifs, comme la dette technique ou une mauvaise dynamique d’équipe.
Des exemples courants incluent « Marche de la mort » et « Classe Dieu ».
Construction automatisée (Automated Build)
Un processus de génération automatisé assemble l’application logicielle, compile le code, exécute des tests automatisés, empaquette et déploie dans un environnement de test ou de production.
Il s’intègre dans les pipelines d’intégration continue (CI), garantissant la fiabilité et réduisant le risque d’erreur humaine.
B
Raffinement du backlog (toilettage)
L’affinement du backlog est un événement récurrent dans Agile où le propriétaire du produit et l’équipe examinent et hiérarchisent les éléments du backlog du produit.
Cela permet de préparer les stories pour les sprints à venir, de s’assurer que les éléments sont prêts pour le développement et d’identifier les dépendances ou les blocages dès le début.
Développement piloté par le comportement (BDD: Behavior Driven Development)
BDD étend TDD en se concentrant sur la spécification du comportement du système en langage naturel, ce qui le rend compréhensible pour les membres de l’équipe technique et non technique.
Les scénarios sont rédigés au format Given-When-Then pour décrire les conditions préalables, les actions et les résultats.
Graphique d’avancement (Burndown Chart)
Un graphique d’avancement représente visuellement la quantité de travail restante au fil du temps dans une itération ou un projet. Il permet de suivre la progression par rapport à l’objectif d’itération. Un graphique connexe, le graphique d’achèvement, montre le travail achevé au fil du temps et la portée totale du projet.
Agilité d’entreprise (Business Agility)
L’agilité commerciale fait référence à la capacité d’une organisation à s’adapter rapidement aux changements du marché, aux besoins des clients et aux opportunités émergentes tout en continuant à se concentrer sur la création de valeur grâce à des processus flexibles et réactifs.
C
Propriété collective (Collective Ownership)
En Agile, la propriété collective signifie que tous les membres de l’équipe partagent la responsabilité de la base de code. Aucun individu ne possède une zone spécifique, et n’importe qui peut modifier n’importe quelle partie du code pour corriger des bogues, refactoriser ou ajouter des fonctionnalités, encourageant ainsi la collaboration et réduisant les goulets d’étranglement.
Déploiement continu (CD: Continuous Deployment)
Le déploiement continu est l’extension de l’intégration continue (CI), garantissant que toutes les modifications qui réussissent les tests automatisés sont automatiquement déployées en production. Cela nécessite des tests rigoureux, l’automatisation et des pratiques de surveillance pour garantir la stabilité.
Intégration continue (CI: Continuous Integration)
L’IC est la pratique qui consiste à créer et à tester automatiquement un logiciel dès que des modifications sont apportées. En intégrant fréquemment les modifications, les équipes peuvent identifier et résoudre les problèmes plus tôt, réduisant ainsi le risque de problèmes d’intégration plus tard dans le développement.
Cartes CRC (Classe-Responsabilité-Collaborateur)
Les cartes CRC aident à concevoir des systèmes orientés objet en décrivant les responsabilités des classes et leurs collaborations avec d’autres classes. Il s’agit de fiches physiques ou de représentations numériques qui facilitent les discussions d’équipe lors des sessions de conception.
Développement de la clientèle (Customer Development)
Le développement client est un processus introduit par Steve Blank pour découvrir, valider et mettre à l’échelle des produits qui répondent aux besoins des clients. Il se concentre sur la collecte précoce des commentaires des clients afin d’orienter l’orientation du produit.
D
Réunion quotidienne (Daily Standup)
La réunion quotidienne, également connue sous le nom de stand-up, est un événement court et limité dans le temps (généralement 15 minutes) au cours duquel les membres de l’équipe partagent des mises à jour sur leurs progrès, leurs plans pour la journée et les obstacles auxquels ils sont confrontés. Cela améliore la communication et permet à tout le monde de rester aligné.
Définition de Done (DoD)
La définition de Terminé est une compréhension partagée au sein de l’équipe de ce qui doit être terminé pour qu’un incrément de produit soit considéré comme terminé. Cela inclut souvent des étapes de codage, de test, de documentation et de révision. Le DoD assure la cohérence de la qualité des fonctionnalités livrées.
Définition de Ready (DoR)
La définition de Ready décrit les critères auxquels une user story doit répondre avant d’être acceptée dans un sprint. En règle générale, il doit être clair, bien défini et suffisamment petit pour être réalisé au cours d’un sprint, avec toutes les dépendances résolues.
E
Épopée
Une épopée est un travail de haut niveau et volumineux qui peut être décomposé en histoires d’utilisateurs plus petites. Les épopées représentent souvent des objectifs généraux du projet et sont divisées en incréments plus petits et gérables à aborder sur plusieurs sprints.
Estimation
L’estimation dans Agile aide les équipes à prédire le temps nécessaire à l’exécution des tâches ou des user stories. Des méthodes telles que le Planning Poker ou la taille des t-shirts sont utilisées pour parvenir à un consensus sur la complexité d’une tâche, qui peut être mesurée en story points, en heures ou en d’autres unités.
Essais exploratoires
Les tests exploratoires sont une approche de test non scénarisée dans laquelle les testeurs explorent activement le logiciel, en tirant parti de leurs compétences et de leur intuition pour découvrir des bogues. Il complète les tests automatisés et scriptés en découvrant des problèmes qui peuvent ne pas être anticipés dans les cas de test formels.
Programmation extrême (XP)
XP met l’accent sur l’excellence technique et les versions fréquentes dans le développement de logiciels. Les principales pratiques comprennent le développement piloté par les tests (TDD), la programmation en binôme, l’intégration continue et l’accent mis sur la simplicité.
XP vise à améliorer la qualité des logiciels et la productivité des développeurs.
F
Facilitation
L’animation est l’acte de guider des réunions d’équipe, des ateliers ou d’autres activités de groupe.
Un bon animateur s’assure que les discussions restent sur la bonne voie, que les décisions sont prises et que tout le monde a la possibilité de contribuer, favorisant ainsi la collaboration et le consensus.
Sorties fréquentes (Frequent Releases)
Les mises à jour fréquentes sont essentielles à Agile, car elles permettent aux équipes de fournir fréquemment des morceaux de fonctionnalités plus petits et plus faciles à gérer.
Cette approche permet aux équipes de réagir rapidement aux commentaires, de réduire les risques et de rester concentrées sur la valeur client.
G
Donné-Quand-Alors (Given-When-Then)
Il s’agit d’un format courant pour écrire des critères d’acceptation et des cas de test dans BDD.
Il décrit le contexte (donné), l’action (quand) et le résultat attendu (alors), ce qui facilite la communication du comportement du système aux parties prenantes techniques et non techniques.
H
Rétrospective des battements de cœur (Heartbeat Retrospective)
Les rétrospectives des battements de cœur ont lieu à intervalles réguliers (généralement à la fin de chaque sprint) pour permettre aux équipes de réfléchir à ce qui s’est bien passé, à ce qui n’a pas fonctionné et à ce qui peut être amélioré. Il favorise l’amélioration continue et la cohésion d’équipe.
I
Développement incrémentiel (Incremental Development)
Le développement incrémentiel fournit des logiciels en plusieurs parties, chaque incrément fournissant un sous-ensemble des fonctionnalités globales du système. L’objectif est d’avoir un produit fonctionnel après chaque incrément qui peut évoluer et grandir.
Informations Radiateurs
Les radiateurs d’information sont des affichages visuels (par exemple, des tableaux de tâches, des graphiques) qui fournissent des informations à jour sur les progrès et la santé de l’équipe.
Ces radiateurs favorisent la transparence et permettent aux parties prenantes de comprendre facilement l’état actuel du projet en un coup d’œil.
Intégration
L’intégration fait référence au processus de combinaison de morceaux de code individuels en un tout fonctionnel. Les pratiques agiles telles que l’intégration continue (CI) aident les équipes à identifier rapidement les problèmes d’intégration en fusionnant régulièrement le code.
INVEST
L’acronyme INVEST signifie Independent, Negotiable, Valuable, Estimable, Small et Testable, qui sont des critères pour la rédaction de témoignages d’utilisateurs de haute qualité.
Chaque user story doit répondre à ces critères pour s’assurer qu’elle est exploitable et livrable.
Itération
Une itération est une période limitée dans le temps, généralement de 1 à 4 semaines, au cours de laquelle une équipe développe et livre une incrémentation de travail du logiciel.
La durée de l’itération reste cohérente tout au long du projet afin de fournir un retour d’information et une réflexion réguliers.
Développement itératif (Iterative Development)
Le développement itératif consiste à répéter le cycle de développement de la planification, de la conception, du codage et des tests pour affiner le produit au fil du temps.
Il permet aux équipes de s’adapter aux retours d’expérience et d’apporter des améliorations continues.
J
Jidoka
Jidoka est un concept Lean, souvent utilisé dans Agile, qui met l’accent sur « l’automatisation avec une touche humaine ». Il s’agit d’arrêter le processus lorsqu’un problème survient, ce qui permet une correction immédiate plutôt que de laisser le problème passer par la chaîne de production.
Dans le développement de logiciels, cela peut signifier l’arrêt des travaux lorsqu’un défaut important est détecté, afin que l’équipe puisse se concentrer sur la résolution du problème avant de continuer.
Juste-à-temps (JAT)
Le juste-à-temps consiste à ne livrer des matériaux, des informations ou des ressources que lorsqu’ils sont nécessaires pour la prochaine étape du processus. En Agile, ce principe s’applique à la planification et à la conception : les équipes reportent la prise de décision et l’engagement sur des fonctionnalités ou des conceptions spécifiques jusqu’au dernier moment responsable, en s’assurant qu’elles sont basées sur les informations les plus récentes.
Histoires d’emploi (Job Stories)
Les Job Stories sont une alternative aux User Stories, qui se concentrent sur la motivation derrière une tâche. Au lieu de décrire une fonctionnalité comme « En tant que [role]Vouloir [feature] Et alors [benefit]», une Job Story prend le format « Quand [situation]Je veux [action], afin que je puisse [outcome].” Ce format déplace l’attention de l’utilisateur vers le travail qu’il doit accomplir et pourquoi.
K
Kanban
Kanban est une méthode visuelle de gestion du flux de travail. Il limite les travaux en cours (WIP) pour améliorer l’efficacité et aide les équipes à visualiser les tâches passant par les étapes, de « À faire » à « Terminé », tout en visant une livraison continue.
Tableau Kanban
Un tableau Kanban est un outil visuel qui représente l’état des éléments de travail à travers des colonnes telles que « À faire », « En cours » et « Terminé ». Il aide les équipes à suivre visuellement le travail, garantissant ainsi transparence et fluidité.
L
Delai
Le délai d’exécution mesure la durée entre le lancement d’une tâche (par exemple, lorsqu’une story est ajoutée au backlog) et son achèvement (lorsque la story est terminée).
Cela permet aux équipes d’évaluer l’efficacité et la rapidité de livraison.
M
Rétrospective des jalons (Milestone Retrospective)
Une rétrospective des jalons est une réunion de réflexion plus approfondie menée aux étapes importantes du projet (par exemple, la fin d’un cycle de publication) pour examiner les progrès globaux et les principaux apprentissages.
Caractéristique minimale commercialisable (MMF)
MMF fait référence à la plus petite fonctionnalité qui peut être fournie qui ajoute de la valeur au client et qui peut se suffire à elle-même. Les FMM sont souvent utilisées pour déterminer la portée minimale requise pour une version.
Produit minimum viable (MVP)
Un MVP est un produit doté de juste assez de fonctionnalités pour satisfaire les premiers clients et fournir des commentaires pour le développement futur du produit.
Il permet un apprentissage rapide et évite d’investir trop d’efforts dans des fonctionnalités qui ne sont peut-être pas nécessaires.
Programmation de foule
Le Mob Programming est une approche où toute l’équipe collabore sur une tâche en même temps et sur le même poste de travail. Cette approche hautement collaborative s’appuie sur les connaissances collectives, réduisant les silos et accélérant la résolution de problèmes.
Objets fictifs
Les objets fictifs simulent le comportement d’objets réels de manière contrôlée lors de tests automatisés. Cela permet d’effectuer des tests unitaires isolés des composants sans avoir besoin des dépendances réelles, ce qui garantit que les tests s’exécutent rapidement et de manière fiable.
N
Calendrier Niko-niko
Le calendrier Niko-niko (ou « smiley ») est utilisé pour suivre l’humeur des membres de l’équipe chaque jour. Cet outil visuel permet de révéler les tendances émotionnelles au fil du temps, ce qui permet aux équipes de résoudre les problèmes de moral potentiels et d’améliorer le bien-être général de l’équipe.
O
Espace ouvert (Open Space)
L’espace ouvert est un type de format de réunion ou d’atelier où les participants établissent l’ordre du jour et dirigent des sessions en fonction de sujets d’intérêt. Il favorise la créativité, l’innovation et l’apprentissage entre pairs en permettant aux participants de décider ce qui est le plus pertinent pour eux.
P
Programmation en binôme
La programmation en binôme est une technique de développement logiciel Agile où deux programmeurs travaillent ensemble sur un même poste de travail.
L’un écrit le code (pilote), tandis que l’autre examine chaque ligne de code au fur et à mesure qu’elle est écrite (navigateur).
Les deux programmeurs échangent fréquemment leurs rôles pour améliorer la qualité du code et le partage des connaissances.
Personas
Les personas sont des personnages fictifs créés pour représenter différents types d’utilisateurs susceptibles d’utiliser un service, un produit ou un site.
Ces personas sont basés sur la recherche utilisateur et aident à guider les décisions concernant les fonctionnalités du produit, les interactions et la conception visuelle en gardant l’équipe concentrée sur l’utilisateur.
Planification du poker
Planning Poker est une technique d’estimation basée sur le consensus utilisée par les équipes Agiles. Les membres de l’équipe utilisent un ensemble de cartes numérotées pour fournir leur estimation d’une tâche.
Les chiffres représentent la taille relative ou l’effort nécessaire pour terminer le travail.
Après discussion, les membres de l’équipe votent jusqu’à ce qu’un consensus soit atteint.
Points (en estimations)
Les points en Agile font référence à l’unité de mesure utilisée pour estimer l’effort requis pour réaliser une user story. Les story points reflètent la complexité et l’incertitude du travail plutôt que le temps qu’il lui faudra.
Produit Backlog
Le Product Backlog est une liste ordonnée de tout ce qui pourrait être nécessaire dans le produit, et c’est la source unique de travail pour l’équipe Scrum.
Il évolue au fur et à mesure que de nouvelles exigences, de nouveaux commentaires ou des changements sont identifiés.
Propriétaire du produit (Product Owner)
Le Product Owner est la personne chargée de gérer le backlog du produit et de s’assurer que l’équipe de développement travaille sur les fonctionnalités les plus précieuses.
Ils représentent les intérêts du client et fournissent des conseils sur ce qu’il faut construire ensuite.
Affrètement de projet (Project Chartering)
L’affrètement de projet est le processus qui consiste à définir les objectifs clés, la portée, les parties prenantes et les critères de réussite d’un projet.
Il permet aux membres de l’équipe et aux parties prenantes de bien comprendre l’objectif du projet.
Q
Séance de conception rapide
Une session de conception rapide est une réunion impromptue au cours de laquelle les membres de l’équipe discutent d’une petite décision de conception qui a des conséquences importantes pour le système. Il s’agit généralement d’un processus informel qui se produit lorsque cela est nécessaire pour résoudre un problème particulier.
R
Refactorisation
Le refactoring est le processus de restructuration du code existant sans modifier son comportement externe.
L’objectif est d’améliorer la lisibilité du code, de réduire sa complexité et de le rendre plus facile à maintenir et à étendre à l’avenir.
Relative Estimation
L’estimation relative consiste à comparer les user stories les unes aux autres en fonction de leur complexité ou de l’effort requis plutôt que d’estimer directement le temps.
Il aide les équipes à évaluer le travail à l’aide d’une approche plus intuitive en classant les tâches en petites tâches, moyennes ou grandes les unes par rapport aux autres.
Règles de simplicité
Les Rules of Simplicity, proposées par Kent Beck dans le cadre de l’Extreme Programming (XP), définissent des critères pour maintenir un code simple et propre.
Les règles sont les suivantes :
1) Le code exécute tous les tests ;
2) Il ne contient aucun doublon ;
3) Il exprime toutes les idées nécessaires ;
4) Il minimise le nombre d’entités (classes, méthodes, etc.).
S
Mêlée
Scrum est un cadre Agile pour la gestion de projets complexes.
Il divise le travail en itérations appelées sprints, qui durent généralement de 2 à 4 semaines.
Les équipes se concentrent sur la livraison d’un incrément de produit potentiellement livrable à la fin de chaque sprint.
Scrum comprend des rôles clés tels que Scrum Master, Product Owner et l’équipe de développement.
Scrum Master
Le Scrum Master est chargé de s’assurer que l’équipe Scrum adhère aux valeurs, aux pratiques et aux principes Agile.
Ils animent les événements Scrum, éliminent les obstacles et agissent en tant que coach pour aider l’équipe à donner le meilleur d’elle-même.
Scrum des mêlées
Scrum of Scrums est une technique utilisée lors de la mise à l’échelle de Scrum entre plusieurs équipes.
Les représentants de chaque équipe se réunissent régulièrement pour discuter des progrès et coordonner leurs efforts, en veillant à ce que toutes les équipes soient alignées et travaillent vers les mêmes objectifs.
Scrumban
Scrumban est un hybride des méthodologies Scrum et Kanban.
Il combine les sprints structurés de Scrum avec le flux continu de travail de Kanban.
Scrumban est particulièrement utile pour les équipes qui passent de Scrum à un processus plus basé sur les flux.
S’inscrire aux tâches
Dans Agile, les membres de l’équipe « s’inscrivent » volontairement à des tâches en fonction de leurs compétences, de leurs capacités ou de leurs intérêts plutôt que d’avoir des tâches assignées par un responsable.
Cette pratique favorise la responsabilisation et l’appropriation du travail.
Conception simple
La conception simple fait référence à une pratique de développement où la solution la plus simple qui fonctionne est choisie.
L’objectif est de réduire la complexité, en facilitant la compréhension, la maintenance et la modification du système.
Sprint Backlog
Le backlog de sprint est une liste de tâches que l’équipe de développement s’engage à accomplir au cours du sprint en cours.
Il s’agit d’un sous-ensemble du backlog de produit, sélectionné lors de la planification du sprint, et contient les user stories les plus prioritaires que l’équipe pense pouvoir réaliser au cours du sprint.
Story Mapping
Le Story Mapping est une technique utilisée pour visualiser et organiser les user stories selon deux dimensions : la séquence des activités de l’utilisateur et l’importance de ces activités.
Il aide les équipes à comprendre le parcours de l’utilisateur et à hiérarchiser le travail de développement en conséquence.
Découpage de l’histoire (Story Splitting)
Le fractionnement des histoires consiste à décomposer les histoires d’utilisateurs plus grandes (souvent des épopées) en histoires plus petites et plus faciles à gérer.
Chaque petite histoire doit toujours apporter une valeur commerciale mesurable et être testable de manière indépendante.
Rythme durable (Sustanable Pace)
Le rythme durable fait référence à la pratique consistant à travailler à un rythme constant et gérable qui peut être maintenu à long terme sans conduire à l’épuisement professionnel.
Les équipes évitent de travailler des heures excessives pour assurer une productivité stable et à long terme.
T
Tableau des tâches
Un tableau des tâches est un outil visuel, généralement physique ou numérique, qui affiche l’état actuel des travaux en cours. Il comporte généralement des colonnes telles que « À faire », « En cours » et « Terminé », avec des cartes ou des post-it représentant les tâches.
TDD (développement piloté par les tests)
Le développement piloté par les tests (TDD) est une pratique dans laquelle les développeurs écrivent d’abord un test pour un petit élément de fonctionnalité, puis écrivent le code pour que ce test réussisse, et enfin refactorisent le code. TDD permet de s’assurer que le code est fiable et répond aux exigences dès le départ.
Team
Dans un contexte Agile, une équipe est un groupe interfonctionnel de personnes travaillant ensemble vers un objectif commun. Les équipes agiles s’auto-organisent, c’est-à-dire qu’elles décident de la meilleure façon de terminer leur travail dans les délais impartis.
Salle d’équipe (Team Room)
Une salle d’équipe est un espace de travail dédié aux équipes Agile pour collaborer.
Il permet une communication en face à face, un accès facile à des outils visuels tels que des tableaux de tâches ou des radiateurs d’information, et favorise un environnement ouvert et collaboratif.
Trois C
Les trois C d’Agile signifient Carte, Conversation et Confirmation. C’est une formule utilisée pour écrire des user stories. La « Carte » représente la brève histoire d’utilisation, la « Conversation » fait référence à la discussion entre l’équipe et les parties prenantes, et la « Confirmation » définit les critères d’acceptation.
Trois Amigos
Les Trois Amigos font référence à une collaboration entre trois rôles (analyste commercial (ou Product Owner), développeur et testeur, qui discutent d’une fonctionnalité ou d’une user story sous trois angles : valeur commerciale, faisabilité technique et testabilité.
Trois questions
Dans les standups quotidiens Agile, les membres de l’équipe répondent généralement à trois questions : Qu’avez-vous fait hier ?
Qu’allez-vous faire aujourd’hui ?
Quels sont les obstacles qui se dressent sur votre chemin ?
Cela permet de garder tout le monde informé et aligné.
Boîte de temps (Time Box)
Une boîte de temps est une durée fixe pendant laquelle une activité ou un événement doit être terminé. En Agile, les itérations (sprints) sont limitées dans le temps, ce qui signifie qu’elles durent une période de temps déterminée, généralement de 1 à 4 semaines, et que le travail doit être terminé dans ce délai.
U
Langage omniprésent (Ubiquitous Language)
Le langage ubiquitaire est un vocabulaire partagé utilisé par les développeurs, les experts du domaine et les parties prenantes d’un projet. Il garantit que tout le monde parle le même langage lorsqu’il s’agit de discuter des exigences, de la conception et de la mise en œuvre du système, ce qui réduit les malentendus.
Test unitaire (Unit Testing)
Les tests unitaires consistent à tester des unités ou des composants individuels d’une application logicielle pour s’assurer qu’ils se comportent comme prévu. Chaque test unitaire est conçu pour valider la fonctionnalité d’une petite partie isolée du code.
Tests d’utilisabilité (Usability Testing)
Les tests d’utilisabilité sont une technique d’évaluation où de vrais utilisateurs interagissent avec le logiciel pour voir à quel point il est facile à utiliser. Les commentaires permettent d’identifier les problèmes d’utilisabilité, ce qui permet aux équipes d’apporter des améliorations qui améliorent la satisfaction des utilisateurs.
Témoignages d’utilisateurs (User Stories)
Les User Stories sont des descriptions courtes et simples d’une caractéristique ou d’une fonctionnalité, rédigées du point de vue de l’utilisateur final. Ils suivent généralement le format : « En tant que [role], je veux [feature] que [reason]». Ils aident à communiquer les exigences d’une manière facile à comprendre.
Modèle de récit utilisateur (User Story Template)
Le modèle de User Story suit un format spécifique : « En tant que [user role], je veux [goal] que [benefit]. » Ce format garantit que les user stories se concentrent sur les besoins de l’utilisateur et la valeur qu’une fonctionnalité apporte.
V
Vitesse
La vélocité est une mesure de la quantité de travail qu’une équipe peut accomplir au cours d’un sprint. Il est généralement calculé comme la somme des story points de toutes les user stories réalisées au sein d’un sprint, et permet de prévoir les performances futures.
Contrôle de version (Version Control)
Le contrôle de version est un système qui enregistre les modifications apportées à un fichier ou à un ensemble de fichiers au fil du temps afin que des versions spécifiques puissent être rappelées ultérieurement. En Agile, les systèmes de contrôle de version (comme Git) permettent une intégration continue et permettent aux équipes de collaborer sur la même base de code.
W
WIP (Travail en cours)
Les travaux en cours font référence à la quantité de travail sur laquelle l’équipe travaille actuellement. Limiter les travaux en cours est un principe important dans les méthodologies Agile telles que Kanban, où l’accent est mis sur l’achèvement des tâches avant d’en commencer de nouvelles. La réduction des en-cours améliore le flux et réduit les changements de contexte, ce qui permet d’améliorer l’efficacité et la qualité du travail.
Wireframe
Un wireframe est une représentation visuelle basse fidélité ou un plan d’une interface utilisateur.
Les wireframes montrent la structure et la mise en page de base d’une page ou d’un écran sans inclure d’éléments de conception détaillés tels que des couleurs ou des graphiques.
Ils aident les parties prenantes à visualiser les fonctionnalités du produit dès le début du processus de développement.
X
XP (programmation extrême)
XP est un cadre de développement logiciel Agile qui se concentre sur l’amélioration de la qualité des logiciels et la réactivité aux exigences changeantes des clients. XP promeut des pratiques techniques telles que le développement piloté par les tests (TDD), la programmation en binôme et l’intégration continue, en mettant l’accent sur les versions fréquentes et une collaboration étroite avec les clients.
Y
YAGNI (Vous n’en aurez pas besoin)
YAGNI est un principe de XP qui encourage les développeurs à ne pas créer de fonctionnalités avant qu’elles ne soient absolument nécessaires. Cela permet de réduire la complexité, d’éviter la suringénierie et de s’assurer que les efforts de développement se concentrent uniquement sur la fourniture de ce qui est nécessaire.
Z
Zéro défaut
Le zéro défaut est un principe d’assurance qualité qui vise à réduire autant que possible les défauts grâce à des pratiques telles que les tests continus, le refactoring et des normes de codage de haute qualité. Bien que cela ne soit peut-être pas entièrement réalisable, la philosophie encourage les équipes à s’efforcer d’obtenir la meilleure qualité possible.