Glossaire Agile et Expérimentation d'affaires

A

• Agilité : philosophie basée dans l’empirisme qui augmente la capacité à gérer la complexité grâce à la collaboration et aux itérations afin de diminuer le risque en s’adaptant au changement constant des exigences.

• Amélioration continue : consiste en un effort continu pour améliorer les produits, les services ou les processus . Ces efforts peuvent viser à apporter des petites améliorations à intervalles réguliers (de façon incrémentale) ou, au contraire, à regrouper toutes les améliorations dans une implémentation globale. L'efficience, la praticabilité et la flexibilité des processus ayant un impact sur le client sont constamment évalués et améliorés.

• Antipattern : comportement ou tendance considéré comme une mauvaise pratique.

• Artefact : informations qu'une équipe agile et les parties prenantes utilisent pour détailler le produit en cours de développement, les actions pour le produire et les actions réalisées au cours du projet. Par exemple, les principaux artefacts du cadre de travail Scrum sont le “carnet de produit” (Product Backlog), le “carnet de sprint” (Sprint Backlog) et les incréments (Increment).

• Assez bon (principe, eng. = good enough) : Action la plus petite et rapide pour aller chercher un apprentissage ou travail minimum pour aller chercher le plus de valeur d'apprentissage.

• Autogestion : les équipes Scrum sont interfonctionnelles, ce qui signifie que les membres ont toutes les compétences nécessaires pour créer de la valeur à chaque sprint. Ils sont également autogérés, ce qui signifie qu'ils décident en interne qui fait quoi, quand et comment.

B

• Backlog d’intervention : plan d’activités de formation expériencielle, des coachings de groupe et individuelles et d’autres actions à exécuter lors du déroulement des cliniques agile-hybrides. Ne pas confondre avec “Product backlog”, cf. entrée spécifique.

• BMC (business model canvas) : Le BMC, créé par Alexandre Osterwalder et Yves Pigneur, est un outil simple et visuel qui vous permet de présenter les différentes composantes de votre modèle d’affaires lors du processus de démarrage de votre nouvelle entreprise ou lors de l’ajout d’un projet à votre entreprise existante. Représenté sous forme de tableau, il permet rapidement de vérifier la désirabilité de la solution ainsi que la cohérence et la viabilité d’un modèle d’affaires, mais surtout d’assurer sa pérennité. Contrairement à l’approche plus traditionnelle, le BMC est orienté davantage sur l’expérimentation plutôt que sur l’intuition. En savoir plus : vidéo explicative (EN).

• BME (board de mesures empiriques) : modèle d’évaluation des équipes basé sur l’observation de comportements lors de leurs quotidien pour évaluer leur maturité dans quatre aspects : le fonctionnement de l’équipe, la structure organisationnelle ainsi que la synergie des équipes et optimisation des processus; la valeur livrée par le produit ou service développé et l’influence du contexte dans la performance de l’équipe. Le BME est utilisé plusieurs fois lors de l’exécution du Backlog d’intervention pour tracer l’évolution de l’équipe et pour determiner des opportunités d’amélioration et des interventions futures.

• Boucle d’apprentissage (EN : learning/feedback loop) : Une boucle d'apprentissage (rétroaction) axée sur l'accroissement de l'apprentissage. Suit généralement ces étapes : faire une hypothèse (ou fixer un objectif), construire quelque chose (effectuer certaines activités), obtenir des commentaires sur ce qui a été construit, puis utiliser ces commentaires pour inspecter ce qui a été fait par rapport à ce qui était supposé.

• Burn-down Chart : graphique qui montre la quantité de travail que l'on pense qu'il reste dans un backlog. Le temps est indiqué sur l'axe horizontal et le travail restant sur l'axe vertical. Au fur et à mesure que le temps avance et que les éléments sont tirés de l'arriéré et terminés, une ligne de tracé indiquant le travail restant peut tomber. La quantité de travail peut être évaluée de plusieurs manières, telles que les points de user story ou les heures de tâche. Le travail restant dans les Sprint Backlog et le Product Backlog peut être communiqué au moyen d'un burn-down chart.

• Burn-up Chart : graphique qui montre la quantité de travail qui a été accomplie. Le temps est indiqué sur l'axe horizontal et le travail effectué sur l'axe vertical. Au fur et à mesure que le temps passe et que les éléments sont tirés de l'arriéré et complétés, une ligne de tracé montrant le travail effectué peut s'élever. La quantité de travail peut être évaluée de plusieurs manières, telles que les points de user story ou les heures de tâche. La quantité de travail considérée comme étant dans le champ d'application peut également être tracée sous forme de ligne ; on peut s'attendre à ce que le burn-up se rapproche de cette ligne à mesure que les travaux sont terminés.

• Business experimentation : cf “Expérimentation d’affaires”.

C

• Critères d'acceptation (Acceptance Criteria") : sont les conditions ou les exigences spécifiques qu'une user story ou un élément du backlog de produit doit satisfaire pour être considéré comme terminé et accepté par le Product Owner. Les critères d'acceptation définissent les attentes claires et mesurables qui doivent être remplies pour qu'une fonctionnalité soit considérée comme complète et prête à être livrée. Ils permettent de définir les conditions nécessaires pour que le travail soit considéré comme accompli et répondant aux besoins de l'utilisateur. Les critères d'acceptation aident l'équipe Scrum à comprendre les exigences spécifiques du Product Owner et à valider si une fonctionnalité est correctement mise en œuvre. Ils servent également de base pour les tests et les validations lors du développement itératif et incrémental.
  
  

• Continuous Discovery : Continuous discovery refers to a sustained practice of product discovery to inform product development decisions continuously.

• Culture d’expérimentation : désigne la propension d’un contexte à favoriser la mise en place d’expérimentation d’affaires (par exemple : dans une équipe souhaitant développer ou améliorer un produit innovant).

D

• Daily Scrum (Mêlée Quotidienne/ Daily Meeting / Stand-Up Meeting) : événement Scrum Event est limité à 15 minutes organisé chaque jour pour les développeurs. Le Daily Scrum a lieu tous les jours du Sprint. Chez lui, les plans des développeurs fonctionnent pour les prochaines 24 heures. Cela optimise la collaboration et les performances de l'équipe en inspectant le travail depuis le dernier Daily Scrum et en prévoyant le travail de Sprint à venir. Le Daily Scrum se tient à la même heure et au même endroit chaque jour pour réduire la complexité.

• Definition of Ready : une compréhension partagée par le Product Owner et les Développeurs concernant le niveau préféré de description des éléments du Product Backlog introduits lors de la planification du Sprint.

• Definition of Done (FR : Définition de fini) : est une description formelle de l'état de l'incrément lorsqu'il répond aux mesures de qualité requises pour le produit. Au moment où un élément du backlog produit (PBI) répond à la définition de terminé, un incrément est né. La définition de terminé crée de la transparence en fournissant à chacun une compréhension partagée du travail effectué dans le cadre de l'incrément. Si un élément du backlog produit ne répond pas à la définition de terminé, il ne peut pas être publié ni même présenté lors de la revue de sprint.

• Déploiement (Release) : Une version du produit qui est livrée à l’utilisateur final. À ne pas confondre avec une version intermédiaire livrée au promoteur à la fin de chaque Sprint. La relâche se déroule sur plusieurs Sprints.

• Design Thinking (FR : Pensée Design) : présentation rapide de la méthode

• Dette Technique (eng. : Technical Debt) : les frais généraux généralement imprévisibles liés à la maintenance du produit, souvent causés par des décisions de conception moins qu'idéales, contribuant au coût du produit. La dette technique peut exister involontairement dans l'incrément ou être introduite délibérément pour réaliser de la valeur plus tôt.

E

• Early adopter (trad : primo-adoptant) : Personne comprenant le problème à résoudre et la valeur potentielle du produit à un stade précoce. Attention : les early adopters ne sont pas forcément la cible à moyen-long terme d’un produit, ce sont ceux qui vont permettre de se “lancer”.

• Émergence : le processus d'apparition ou de proéminence de nouveaux faits ou d'une nouvelle connaissance d'un fait, ou la connaissance d'un fait devenant visible de manière inattendue.

• Empirisme : type de contrôle de processus dans lequel seul le passé est accepté comme certain et dans lequel les décisions sont basées sur l'observation, l'expérience et l'expérimentation. L'empirisme repose sur trois piliers : la transparence, l'inspection et l'adaptation.

• Épique/Epopée (eng. : Epic) : Une Epic est une User Story qui est trop volumineuse pour être complétée en un seul Sprint. Dans ces circonstances, on doit la subdiviser en multiples Stories. Par exemple, pour une application on pourrait avoir la situation suivante : Interface utilisateur (Epic) => Écran principal (Epic) => Animation arrière-plan (Story)

• Équipe autogérée : groupe de personnes qui travaillent ensemble vers un objectif commun et qui sont redevables et responsables de tous ou de la plupart des aspects qui tournent autour des tâches qu’ils effectuent

• Équipe autonome : groupe de personnes qui travaillent ensemble vers un objectif commun et qui sont capables de répartir leur travail en prenant soin d’identifier quelles sont les forces et les compétences de chaque membre. Ils mettent l’accent sur l’individualité de chacun (connaissances, compétences, tempérament) et la manière dont la personne sera capable de synergiser avec le reste de l’équipe.

• Équipe de développement (Développeurs) : tout membre d'une équipe Scrum, qui s'engage à créer n'importe quel aspect d'un incrément utilisable à chaque sprint, quelle que soit sa spécialité technique, fonctionnelle ou autre. Tous les autres membres de l’équipe Scrum sont considérés des développeurs, sans égard à leur métier ou leur niveau hiérarchique. Tous les développeurs, dans le cadre Scrum toujours, sont considérés égaux et ainsi personne n’a d’autorité sur les autres, les emmenant à collaborer. Cette dualité d’autorité et d’absence de poste spécifique peut créer des incompréhensions, un sujet que je réserve pour un autre article.

• Estimation Agile : C'est le processus qui cherche à évaluer et estimer votre effort pour accomplir une tâche prioritaire dans le backlog du produit. D'habitude les estimations sont faites selon la complexité de la tâche, les ressources disponibles et les connaissances pour compléter et le temps pour l'accomplir. Les estimations ne doivent pas être prises comme des "absolus", car elles peuvent varier selon la complexité du contexte ou la maturité de l'équipe qui estime.

• Évidence (d’affaires) : ensemble de faits ou d'informations resultants de vos expérimentations indiquant si une croyance ou une proposition (hypothèse) est valide.

• Evidence-based management (Scrum / abrév. “EBM”) : L’Evidence-Based Mangement (EBM) est une approche empirique qui aide les organisations à améliorer continuellement les résultats clients, les capacités organisationnelles et les résultats commerciaux dans des conditions d'incertitude. Il fournit un cadre aux organisations pour améliorer leur capacité à créer de la valeur dans un monde incertain, à la recherche d'un chemin vers des objectifs stratégiques. En utilisant des expérimentations intentionnelles et des preuves (mesures), l'EBM permet aux organisations d'améliorer systématiquement leurs performances au fil du temps et d'affiner leurs objectifs en fonction de meilleures informations.
  Plus d’information dans le Guide Evidence Based Management de Scrum.org

• Expérimentation d’affaires (EN : business experimentation) : Ensemble de methologies et techniques qui permettent d'appliquer des techniques de recherche pour tester différentes hypothèses et les soumettre à des mesures, des validations et des analyses, afin que nous puissions arriver à une conclusion fondée sur des preuves. Si les conclusions sont positives, continuez avec le produit/service. Si ce n'est pas le cas, abandonnez ou restructurez et retestez.

• Expérimentation (test) : sont des actions ou des processus dans lesquels des méthodes et des techniques de recherche sont appliquées à des suppositions ou à des hypothèses. En testant ces hypothèses et en les soumettant à une analyse, des mesures et une validation, une conclusion peut être formée sur la base de faits. Si la conclusion est positive, la décision est prise de continuer avec le produit ou le service. En savoir plus sur les types d’expérimentations : voir (lien liste expérimentations)

F

• Forecast (de fonctionnalité) : la sélection d'éléments du Product Backlog que les Développeurs jugent réalisables pour une implémentation dans un Sprint.

I

• Incrément : artefact Scrum qui définit le travail complet et de valeur produit par les développeurs lors d'un sprint. La somme de tous les incréments forme un produit.

• Innovation en continu : cf. “Amélioration continue”

• Itération : à définir

K

• Kanban : c’est une stratégie pour optimiser le flux de livraison de valeur à travers un processus qui utilise un système qui :

  • Montre le flux du travail visuellement

  • Établi une mécanique “pull” choisir le travail en cours

  • Limite la quantité du travail en cours de réalisation (WIP limit)

• Key Result (fr., Mesure clé de résultats) : Un résultat clé est un résultat mesurable requis pour atteindre l'objectif. Il contient une métrique avec une valeur de départ et une valeur cible. Les résultats clés mesurent les progrès vers l'objectif - comme un panneau indiquant à quel point vous êtes proche de votre objectif.

L

• Lean Startup : méthodologie de développement d'entreprises et de produits qui vise à raccourcir les cycles de développement de produits et à découvrir rapidement si un modèle commercial proposé est viable ; Ceci est réalisé en adoptant une combinaison d'expérimentation basée sur des hypothèses commerciales, de versions itératives de produits et d'apprentissage validé. Le Lean startup met l'accent sur les commentaires des clients plutôt que sur l'intuition et la flexibilité plutôt que sur la planification. Cette méthodologie permet de récupérer plus souvent des défaillances que les méthodes traditionnelles de développement de produits. La méthode Lean Startup est :

  • Itérative : une étape à la fois. Poser une hypothèse, la valider avec des utilisateurs avant de continuer

  • Évolutive : le BM (business model) se construit via l'expérimentation, l'apprentissage et l'adaptation

  • Simple : on imagine et on teste un produit avec le minimum de fonctionnalités (Minimum Viable Product ou MVP)

  • Rapide : on teste le plus vite possible directement avec les clients et des utilisateurs réels.
    
    
    

• Lean Canvas :  est une évolution du BMC (Business Model Canvas) adaptée aux start-ups et basée sur la méthodologie Lean Startup. C’est Ash Maurya qui a créé l’outil Lean Canvas en 2010, avec pour objectif la mise en œuvre de la méthode du Lean Startup d’Eric Ries.À la fois simple et efficace, il permet de poser très rapidement des hypothèses, de construire petit à petit, de valider puis itérer votre business.

  La méthode Lean Startup est adaptée aux innovations technologiques (nouveau produit, logiciel) ou aux innovations d’usage ou d’habitudes. Dans ces cas, vous n'avez pas de références sur lesquelles vous baser pour vérifier qu'il y a des personnes/entreprises qui ont le problème (ou le besoin) que votre solution résout.

M

• Manifeste Agile : est une déclaration rédigée par des développeurs en 2001 qui avaient pour objectif de révolutionner les processus de développement de logiciels. De par leur expérience, ils ont convenu de 4 valeurs et 12 principes pour le développement en mode agile.
  Plus d’information dans la page Manifeste pour le développement Agile de logiciels
  
  

• Mesures de performance (KPI) : cf. Key Result (mésures clés de résultats)

P

• Planning Poker : Technique d'estimation d’effort collective. Chaque élément du Product Backlog est estimé collectivement en se basant généralement sur l'unité appelée « Story Point ». Cette estimation va notamment aider le Product Owner à prioriser son Product Backlog
  
  

• Product Backlog (carnet/backlog de produit) : un artefact Scrum qui consiste en une liste ordonnée du travail à effectuer pour créer, maintenir et maintenir un produit. Le Product Backlog est la liste de toutes les User Stories que notre produit idéal pourrait contenir, et ce en ordre de priorité. Ces Stories ne sont pas encore subdivisées en tâches et leur description est sommaire sauf pour les plus prioritaires qui feront partie du prochain Sprint (pour éviter d’investir des efforts où ce n’est pas nécessaire). Le Product Owner est en charge de prioriser et de gérer le Backlog au fil du temps et des changements qui surviennent.
  
  

• Product Backlog Item (PBI) : voir User story (récit d’utilisateur/Story)
  
  

• Product Backlog refinement (Raffinement du Product Backlog) : l'activité dans un Sprint par laquelle le Product Owner et les Développeurs ajoutent de la granularité au Product Backlog.
  
  

• Product Discovery : Product discovery refers to research that aims to identify what a product team should build—the solution, features and improvements—based on the customer’s needs.
  
  

• Product Goal (objectif produit) : décrit un état futur du produit qui peut servir de cible à l'équipe Scrum pour planifier. L'objectif de produit se trouve dans le backlog de produit. Le reste du Product Backlog émerge pour définir "ce qui" remplira l'objectif du produit.
  
  

• Product Owner (Propriétaire/Responsable du produit ou PO) : rôle dans Scrum responsable de la maximisation de la valeur d'un produit, principalement en gérant et en exprimant progressivement les attentes commerciales et fonctionnelles d'un produit aux développeurs. Le Product Owner est le représentant du promoteur au sein de l’équipe. Il se doit d’avoir une excellente connaissance du produit à réaliser et de la vision du promoteur. Par contre, contrairement à ce dernier, il est présent au quotidien et se charge de la priorisation des fonctionnalités, du respect du budget et de l’échéance. Il se peut que ce rôle soit assumé par le promoteur directement advenant qu’il comprenne bien la différence entre les deux fonctions (particulièrement le compromis entre fonctionnalités, temps/budget et qualité)
  
  

• Production en cascade (Waterfall) : Waterfall est la méthode «classique» de gestion de projets où l’on planifie toutes les étapes et les tâches à accomplir en amont et en élaborant des plans de gestion des risques afin de contrer les imprévus qui pourraient survenir. Cette façon de faire comporte ses lacunes auxquelles Scrum tente de pallier par une plus grande réactivité au changement. À noter que la méthode Waterfall a aussi ses avantages et peut être adéquate dans de multiples circonstances
  
  

• Promoteur (Stakeholder) : Le promoteur est le commanditaire du projet, celui qui le finance et qui en a la vision. Ultimement, il s’agit de celui qui tirera bénéfice du projet que vous réalisez. Tout projet a un promoteur, celui-ci n’est pas considéré faire partie de l’équipe même s’il est encouragé à participer.
  
  

• “Puriste” (ou “religieux”) : Désigne une attitude qui insiste sur la définition théorique des concepts d’une méthode au lieux de leur implication pratique et donc de leur potentiel d’adaptation dans le contexte d’une équipe.

S

• Scrum : est un cadre léger qui aide les personnes, les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives pour des problèmes complexes tels que définis dans le Scrum GuideTM.
  
  

• Scrum Board : un tableau physique pour visualiser les informations pour et par l'équipe Scrum, souvent utilisé pour gérer le Sprint Backlog. Les tableaux Scrum sont une implémentation facultative dans Scrum pour rendre les informations visibles.
  
  

• Scrum Master : rôle au sein d'une équipe Scrum responsable de guider, d'encadrer, d'enseigner et d'aider une équipe Scrum et ses environnements dans une bonne compréhension et utilisation de Scrum. Il s’agit d’un rôle très important pour le succès des projets Scrum, surtout lorsque l’équipe a peu d’expérience. Son mandat consiste en l’application, selon les règles de l’art, des pratiques Scrum. De plus il s’assure, de par la nature de son mandat, de protéger l’équipe des éléments extérieurs en s’imposant comme un tampon opérationnel entre le Product Owner (PO) et les développeurs. Ses tâches consistent en l’assistance au PO pour prioriser les fonctionnalités, la modération et le bon déroulement des cérémonies, l’accompagnement des développeurs vers une plus grande autonomie et la levée de toute entrave au travail de l’équipe. Il n’a pas d’autorité hiérarchique, mais il a la responsabilité d’un meneur-serviteur (servant-leader)
  
  

• Scrum Team (équipe Scrum) : une équipe autogérée composée d'un Scrum Master, d'un Product Owner et de Développeurs.
  
  

• Sprint : événement Scrum limité à un mois ou moins, qui sert de conteneur pour les autres événements et activités Scrum. Un Sprint contient un ensemble de cérémonies et culmine en la livraison d’un produit intermédiaire fonctionnel démontrant ce qui a été développé durant l’itération. Les sprints se font consécutivement, sans intervalles intermédiaires.
  
  

• Sprint Backlog : Le Sprint Backlog consiste en la liste des User Stories qui composent le Sprint, tel que déterminé durant la planification du Sprint, en plus d’un «plan» pour comment atteindre l’objectif du Sprint. Ce plan est, à toute fin pratique, les tâches qui composent les Stories. Le Sprint Backlog est la «propriété» des développeurs et ils sont les seuls à pouvoir le modifier. Ceci évite l’ingérence de la part du Product Owner afin d’assurer une stabilité minimale. Ce dernier peut par contre négocier les changements et vice-versa. Le Sprint Backlog évolue en cours de Sprint pour représenter l’avancement du travail.
  
  

• Sprint Goal (objectif du Sprint): une brève expression de l'objectif d'un Sprint, souvent un problème métier qui est traité et le plant pour le resoudre. Ce dernier peut être ajustée pendant le Sprint afin d'atteindre l'objectif du Sprint.
  
  

• Sprint Planning (planification du Sprint) : événement Scrum limité à 8 heures ou moins pour démarrer un Sprint. Il permet à l'équipe Scrum d'inspecter le travail du backlog de produit qui a le plus de valeur à faire ensuite et de concevoir ce travail dans le backlog de Sprint.
  
  

• Sprint Retrospective : événement Scrum défini sur une plage horaire de 3 heures ou moins pour terminer un Sprint. Il permet à l'équipe Scrum d'inspecter la maturité de l’équpe et les processus mises en place lors du Sprint passé et de planifier les améliorations à mettre en œuvre lors des Sprints futurs.
  
  

• Sprint Review (revue de sprint) : événement Scrum défini sur une durée limitée à 4 heures ou moins pour conclure le travail d'un Sprint. Il permet à l'équipe Scrum et aux parties prenantes d'inspecter l'incrément de produit résultant du sprint, d'évaluer l'impact du travail effectué sur la progression globale vers l'objectif du produit et de mettre à jour le backlog du produit afin de maximiser la valeur de la prochaine période.
  
  

• Story point : unité d’estimation couramment utilisée sur les projets agiles. Permettant de faciliter l’estimation en soi ainsi que la planification des Releases ou des Sprints. Tout en évitant de tomber dans l’illusion de la précision des estimations ou l’amalgame entre les jours/hommes et le délai de réalisation.
  
  

• Subject Matter Expert (SME) : est un expert dans un domaine spécifique. Il s'agit d'une personne qui possède une connaissance approfondie, une expertise et une expérience pratique dans un domaine particulier. Les SME sont souvent sollicités pour fournir des informations, des conseils et des orientations sur des sujets spécifiques, en raison de leur expertise et de leur compréhension approfondie du domaine concerné. Ils peuvent être des professionnels chevronnés, des consultants ou des membres d'une équipe possédant une expertise spécialisée. Les SME jouent un rôle crucial dans le partage de connaissances, la résolution de problèmes et l'aide à la prise de décisions éclairées dans leur domaine d'expertise.

U

• User story (récit d’utilisateur/Story) : est une description d'une fonctionnalité telle que souhaitée par le client et définie par le Product Owner. L'objectif est de décrire la fonctionnalité du point de vue de l'utilisateur final. Par exemple «En tant que promoteur je désire un espace pour ranger mes dossiers dans mon bureau» ou «En tant qu’usager je désire une interface pour sélectionner une couleur». On y inclut souvent aussi une description un peu plus complète et des conditions de succès qui doivent être résolues pour que la Story soit complétée. Une Story doit absolument pouvoir être complétée dans une seule itération, sinon il s’agit d’une Epic.
  
  

• User story points (points d’effort) : sont des unités de mesure permettant d'exprimer une estimation de l'effort global requis pour implémenter entièrement un élément du backlog produit ou tout autre élément de travail. Les équipes attribuent des points d'histoire en fonction de la complexité du travail, de la quantité de travail et du risque ou de l'incertitude.

V

• Valeurs Scrum : un ensemble de valeurs et de qualités fondamentales qui sous-tendent le cadre Scrum ; engagement, concentration, ouverture, respect et courage.
  
  

• Vélocité : est un indicateur utilisé sur des projets gérés à l’aide d’une méthode agile, qui permet de déterminer l’effort qu’est capable de fournir une équipe de développement pour la réalisation des tâches programmées dans un sprint. Elle est exprimée en nombre de points. La vélocité est un outil de planification macro. Elle permet à l'équipe de développement, au Product owner et au Scrum Master d'estimer le nombre d'itérations nécessaires pour aller au bout d'une fonctionnalité ou d'un projet.

• Références

  • Scrum Glossary

  • Professional Scrum Developer Glossary

  • Lexique Agile Scrum