Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

Ce lexique est destiné à clarifier et démystifier le jargon de l’agilité et de l’expérimentation d’affaires que vous êtes susceptible d’entendre lors de nos interventions. Si certains termes n’y sont pas, n’hésitez pas à nous le mentionner

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

  • 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 (Developpeurs) : 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.

  • 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)

  • No labels