Agile de niveau intermédiaire : Planifier les versions, diriger les équipes et mesurer les succès

1. Introduction: Bonjour et bienvenue à la master class de gestion de projet agile sur le sprint à grande échelle Si vous avez déjà appris les principes fondamentaux d' Agile et de Scrum, il est temps de passer à l'étape suivante Dans ce cours, nous allons aller au-delà de la gestion d'un seul sprint et commencer à penser comme un chef de projet agile. Je m'appelle Luke Phillips. Je suis chef de projet avec environ sept ans d' expérience à la tête d' équipes agiles et dans la réalisation projets dans divers secteurs d'activité. Tout au long de ma carrière, j'ai utilisé les approches Scrum, Camban et Agile hybride pour aider les équipes à collaborer plus efficacement, à s'adapter à l'évolution des priorités et à créer de la valeur Dans ce cours, je vais partager les techniques pratiques que j'ai utilisées pour gérer des projets au-delà des bases. Nous allons commencer par examiner la situation dans son ensemble, la manière dont les sprints individuels s'intègrent dans route et les plans de publication des projets Vous apprendrez à planifier plusieurs sprints et à organiser les objectifs de projet à long terme à l'aide d'outils tels que Non Ensuite, nous approfondirons les estimations et les prévisions Vous découvrirez comment les équipes agiles estiment le travail, mesurent la vitesse et établissent des prévisions réalistes sans prétendre que chaque estimation est parfaitement précise Nous comparerons également les approches Scrum, Cam Ban et hybrides, vous aider à comprendre quand chaque framework fonctionne le mieux et comment adapter votre flux de travail aux différents types de projets La communication est un autre objectif majeur de ce cours. Vous apprendrez à travailler avec les parties prenantes, à gérer l' évolution des exigences, effectuer des révisions productives et à communiquer avancement du projet de manière claire et efficace. Enfin, nous explorerons les métriques agiles, comprenant ce qu'il faut mesurer, ce qu'il faut ignorer et comment utiliser les données pour améliorer performances de votre équipe au lieu de simplement générer des rapports. À la fin de ce cours, vous aurez les connaissances et l' expérience pratique nécessaires pour gérer des projets agiles de plus grande envergure, communiquer plus efficacement et prendre de meilleures décisions de projet en toute confiance. Commençons. 2. Welcome to the Intermediate Project Management Course: Bonjour, et bienvenue dans le cours intermédiaire de gestion de projet Agile. Si vous avez déjà couru un sprint ou deux et que vous êtes prêt à penser au-delà d'un cycle de deux semaines, ce cours est fait pour vous. Nous expliquerons comment planifier plusieurs sprints, comment faire des estimations honnêtes à grande échelle, quand utiliser Cam Ban au lieu de Scrum et comment tenir les parties prenantes informées sans se noyer dans les mises à informées sans se noyer dans Dans cette courte leçon d'ouverture, nous passerons en revue ce que vous devez déjà savoir avant de commencer ce cours intermédiaire, ce que ce cours couvre et ce que vous devrez suivre. Voici donc un bref résumé de ce que vous devez déjà savoir avant commencer ce cours intermédiaire Vous avez besoin des fondements de l' état d'esprit Agile et du manifeste Agile. Si tout cela ne vous semble pas familier, vous devez renforcer vos bases avant de continuer. Vous devez donc comprendre l'état d'esprit agile et le manifeste, non seulement être capable de réciter les valeurs, mais aussi de les reconnaître dans le fonctionnement réel d'une équipe Vous devez connaître les trois rôles Scrum, le propriétaire du produit, Scrum Master et l'équipe de développement, ce que chaque équipe fait et ce que chaque équipe ne fait pas Vous devez être à l'aise pour écrire des témoignages d'utilisateurs, définir des critères d'acceptation et savoir quand quelque chose est réellement fait. Vous devez également disposer d'un espace de travail Trello et Notion déjà configuré avec un backlog rempli pour le projet sur lequel vous travaillez Et surtout, vous auriez dû exécuter au moins un sprint de bout en bout, le planifier, l'exécuter, revoir, puis faire une rétrospective L'expérience vécue est importante ici, car tout dans ce cours repose sur cette base. Voyons donc ce que couvre ce cours intermédiaire. Nous avons six sections. On passe d'un sprint à plusieurs sprints. Nous aborderons la création de plans de publication qui relient plusieurs sprints entre eux. Nous examinerons comment estimer et suivre correctement la vitesse. Nous examinerons les différences entre Scrum et Caban et verrons comment choisir Nous examinerons comment gérer les parties prenantes sans nous laisser dévorer, et nous examinerons les indicateurs qui comptent réellement et ceux qui ne le sont pas. À la fin de ce cours, vous saurez comment planifier et exécuter une série de sprints qui mènent à quelque chose de plus grand Et c'est la principale étape entre l'organisation de sprints individuels et le développement de quelque chose de significatif grâce à Agile Ce dont tu auras besoin. Voici les outils pratiques. Vous aurez besoin de Trello pour votre tableau. Vous aurez besoin de Notion pour la documentation. Si vous les avez déjà configurés lors de travaux antérieurs, vous êtes prêt à partir. Vous aurez également besoin de votre brief de projet et de votre carnet de commandes existant devant vous La majeure partie de ce cours s'appuie sur un travail réel Vous tirerez donc le meilleur parti de l'application de chaque leçon à un projet réel. Nous sommes donc prêts à commencer. Merci de m'avoir rejoint. Dans la leçon suivante, nous allons faire un zoom arrière à partir d'un seul sprint et examiner la situation dans son ensemble, place des sprints individuels dans les versions et les raisons pour lesquelles cela est important. Je t'y verrai. 3. Du sprint à la publication: Bon retour. Dans le monde réel, aucune équipe ne court un seul sprint. Ils courent des dizaines, des centaines ou se dirigent vers quelque chose de plus grand. Ce quelque chose s' appelle une libération. À la fin de cette leçon, vous comprendrez ce qu'est une version, comment les sprints s'y intègrent et pourquoi le fait de penser au niveau de la version change votre façon de planifier Alors, qu'est-ce qu'une version ? Une version représente une partie significative du travail fourni aux utilisateurs Il n'y a pas qu' un sprint qui vaut la peine d'être raconté aux gens Il peut s'agir d'une nouvelle version du produit, d'une fonctionnalité majeure, d'une campagne en ligne. Quelque chose que le monde extérieur remarque. Pour un produit logiciel, une version peut être une version en deux points, avec le nouveau tableau de bord et la refonte de l'intégration Dans le cas d'un événement, la publication est l'événement lui-même. Pour le commerce électronique, une version peut être la gamme de produits Autumn, les six produits, la nouvelle page de destination et la campagne marketing. Les versions donnent forme à votre travail. Ce sont les étapes clés du voyage. Voici comment les sprints se transforment en versions. Chaque sprint est comme un tremplin. La plupart des versions nécessitent donc plusieurs sprints. Trois, c'est courant, six, ce n'est pas inhabituel. Certaines versions peuvent nécessiter dix sprints. Voici donc la relation. Un sprint fournit un incrément, une petite partie du résultat de travail Une version est un ensemble d' incréments qui, ensemble, permettent d' obtenir quelque chose de plus grand Alors imaginez ça comme ça. Votre objectif de sprint est peut-être que les apprenants puissent gagner des étoiles après avoir terminé les leçons. C'est utile, mais en soi, il s'agit d'une fonctionnalité et non d'une version. Votre objectif de sortie est peut-être la version 2, une expérience d' apprentissage entièrement ludifiée Cette version inclut les étoiles, stries, les badges le tableau de bord parent Vous avez plusieurs sprints à construire ensemble. C'est important car chaque sprint doit être perçu comme une progression vers la sortie. Si vous ne voyez pas en quoi ce sprint est lié à un objectif de publication, c'est soit que vous faites le mauvais sprint. Ou vous n'avez pas d'objectif de publication clair. Alors pourquoi penser au niveau de la publication ? Voyons pourquoi c'est important. Il y a trois raisons pour lesquelles important de penser au niveau de la publication. Premièrement, les parties prenantes se soucient des versions, pas des sprints. Votre manager s'en fout que vous ayez terminé l'histoire 47 mardi dernier. Ils tiennent à ce que la nouvelle fonctionnalité soit disponible dans trois semaines. Talking in releases fait le lien entre votre travail de sprint et ce que les gens attendent réellement. Deuxième raison, il met en évidence les dépendances très tôt. Lorsque vous planifiez trois sprints ensemble, vous vous rendez compte que l'histoire B dépend de la fin de l'histoire A en premier, et que cette dépendance est invisible si vous ne planifiez qu' un seul sprint à la fois La troisième raison est que cela oblige à être honnête en matière de timing. sortie de cette version dans huit semaines est donc bien plus difficile que cet objectif de sprint. Soit tu y crois , soit tu ne le crois pas. La planification des versions est l'endroit où les vœux pieux sont exposés. agit donc d'une planification de lancement ou d'un sprint, cadence légèrement différente et d'une précision différente Une planification rapide du sprint de distinction a donc lieu toutes les deux semaines. La planification des versions a lieu une fois par version. La planification du sprint est donc détaillée. Vous choisissez des histoires spécifiques, vous vous y engagez. Tu sais exactement ce que tu vas faire dans les deux prochaines semaines. La planification des versions est plus approximative. Vous regroupez les articles par thèmes, vous estimez le nombre de sprints dont chaque thème pourrait avoir besoin Vous les séquencez et vous établissez une chronologie approximative. Les deux sont très importants. La planification d'un sprint sans contexte de publication entraîne une charge de travail intense. La planification des sorties sans discipline du sprint produit de la fantaisie. Il y a donc trois pièges à éviter lorsque les versions tournent mal. Voici donc quelques erreurs courantes dans la réflexion sur le release thinking. Le premier est le fluage de la lunette. La version commence par trois thèmes. Au sprint quatre, il y en a six. Maintenant tu es en retard. Tu dois être impitoyable. Tout ce qui est nouveau sera inclus dans la prochaine version, pas celle-ci. Le numéro deux concerne les dépendances masquées. À mi-chemin, vous découvrez que deux thèmes ne peuvent être créés sans un troisième. Faites apparaître les dépendances lors de la planification d'une version, et non en milieu de sprint. Et le troisième, c'est ignorer la réalité. La vélocité de l'équipe indique cinq sprints, mais la direction en veut trois Il est normal de sortir tard. C'est en cachant cette réalité jusqu' au dernier moment que les gens sont renvoyés. Alors ignorez cela. Merci de m'avoir rejoint. Dans la leçon suivante, nous aborderons les trois niveaux de planification utilisés par chaque équipe Agile, à savoir les feuilles de route, versions et les sprints, en quoi ils diffèrent et comment rester connectés. Alors je t'y verrai. 4. Trois niveaux de planification.: Bon retour. Dans la dernière leçon, nous avons présenté les versions. Dans celui-ci, nous élargirons encore l'objectif. Chaque équipe Agile planifie à trois niveaux la feuille de route, le plan de publication et le sprint. Ils se ressemblent de loin, mais ils répondent à des questions très différentes. À la fin de cette leçon, vous saurez à quoi sert chacun d' entre eux et comment les garder connectés sans vous noyer dans les plans Donc, les trois niveaux de planification. Imaginez trois cercles concentriques. De l'extérieur vers l'intérieur, nous avons une feuille de route, un plan de publication et un sprint. La feuille de route est la plus éloignée. C'est la direction de haut niveau sur six mois, 12 mois, parfois même deux ans. Il dit : « C'est là que nous allons aborder dans les grands thèmes ». Il ne s'agit pas de fonctionnalités ou de thèmes spécifiques. Le plan de publication constitue la couche intermédiaire. Il est écrit : « Voici la livraison principale ». Il regroupe des fonctionnalités et des thèmes spécifiques dans une version. Et cela couvre généralement quelques mois. Le sprint est le plus profond. Il dit : « C'est exactement ce que nous allons faire au cours des deux prochaines semaines avec des histoires spécifiques, travail engagé, et chaque niveau répond à une question différente. route répondent «   Où allons-nous », versions répondent : « Quelle est la prochaine grande nouveauté », et les sprints répondent : « Que faisons-nous en ce moment ? Voyons donc ce que contient une feuille de route. Les feuilles de route sont thématiques. Ils indiquent une orientation , mais pas des engagements. Une feuille de route typique peut comporter trois à cinq couloirs de baignade couvrant une période de six à 12 mois. Chaque voie est un thème. À l'intérieur de la voie, vous avez des gros morceaux de travail, classés par trimestre ou par mois Évitez de mettre des dates spécifiques sur les éléments de la feuille de route. route sont une question de direction et les dates créent de fausses certitudes Les deux quartiers vont bien. Le 15 août est l' otage de la fortune. feuilles de route appartiennent au propriétaire du produit ou au chef de produit, et elles sont largement partagées Les parties prenantes examinent la feuille de route pour comprendre ce que fait l'équipe cette année. Plan de sortie, le cercle central. Les plans de sortie sont plus concrets. Ils transforment une feuille de route en un livrable. Ainsi, un plan de publication typique couvre de deux à six mois. Il répertorie les principales fonctionnalités ou articles de la version par ordre de priorité approximatif. Il a une date de sortie cible, mais cette date est une cible plutôt qu'une garantie. Les plans de version incluent également les dépendances des services. Story X dépend de Story Y. Nous ne pouvons pas publier la page de lancement sans les produits Nous ne pouvons pas organiser l'événement sans le lieu. Toutes ces dépendances doivent être visibles au niveau de la version, même si les détails figurent dans le plan de sprint individuel. Ces plans sont revus à chaque sprint. Ce sont des documents évolutifs qui sont mis à jour au fur et à mesure que vous apprenez. Enfin, nous avons le plan du sprint. C'est détaillé, c'est engagé et tout tourne autour du moment présent. Un plan de sprint couvre généralement deux semaines. Il répertorie des histoires spécifiques avec des critères d'acceptation. Il s'engage à atteindre un objectif de sprint. Il inclut la capacité, les risques et les dépendances pour les deux prochaines semaines. Les plans de sprint sont les plus précis des trois niveaux, car le travail est en cours en ce moment, ce qui signifie que vous pouvez également être précis. vous planifiez loin, moins vous pouvez être précis sans vous mentir à vous-même. Oh, quelques conseils pour maintenir ces trois forfaits distincts connectés. Les trois niveaux ne fonctionnent que s'ils sont connectés. Le premier conseil est donc que chaque objectif de sprint doit se traduire par un résultat final. Si un sprint n'avance pas vers la sortie, pourquoi le faites-vous au départ ? Deuxièmement, chaque version doit être associée à un thème de feuille de route. Si une version ne correspond pas à la feuille de route, celle-ci est incorrecte ou la version est incorrecte. Troisièmement, révisez-les à des cadences différentes. Des plans de sprint toutes les deux semaines, plans de révision à chaque révision de sprint, des feuilles de route tous les trimestres Quatrièmement, utilisez le même vocabulaire dans les trois cas. Si votre feuille de route indique l'engagement votre publication indique l'intention et que votre sprint indique les étoiles, vous avez rompu ce lien. Assurez-vous que le langage est cohérent. Et le cinquième conseil est de les garder tous au même endroit, si possible. Notion fonctionne très bien pour cette page par niveau, toutes reliées entre elles. OK, trois niveaux, Roadmap, release et sprint connectés par des objectifs clairs et un langage partagé. Merci de m'avoir rejoint pour cette leçon. Dans la prochaine, nous nous chargerons de l'élaboration d'un véritable plan de publication pour votre projet dans Notion. Je t'y verrai. 5. Building Your Release Plan: Bonjour et bon retour. Dans cette vidéo, nous allons voir comment élaborer votre premier plan de publication. Nous allons le faire dans Notion. Tout d'abord, je vais passer revue les étapes que nous allons suivre pour en revue les étapes que nous allons suivre pour créer cette page, puis je vais vous montrer la page entièrement configurée dans Notion. Je vais également vous montrer comment ajouter vos liens bidirectionnels, qui lieront la publication au sprint Oh, tout d'abord, ce que nous sommes en train de créer, vous allez l'ajouter à votre espace de travail Notion existant. Vous allez ajouter une nouvelle sous-page. Vous allez ajouter une nouvelle base de données. Vous allez potentiellement utiliser des modèles de page. Ensuite, nous verrons également comment vous ajoutez vos liens bidirectionnels, qui relient la version au sprint et le sprint à la version Tout d'abord, la première étape consiste à créer la sous-page de type barre oblique, nommer une nouvelle page appelée plan de publication dans la page principale de votre projet La deuxième consiste à ajouter la base de données à cette page. Donc, avancez la table oblique, puis vous pouvez configurer les colonnes avec les noms, le nom, objectif de publication, la date cible, statut et le sprint prévu La troisième consiste à remplir votre première version. Cliquez donc sur la ligne et indiquez votre premier objectif de publication, votre cible, le statut, etc. quatrième étape consiste à structurer la page de publication en cinq sections, avec vos thèmes, la répartition de votre sprint, les dépendances, les risques et la progression. Ensuite, la cinquième étape consistera à lier votre sprint, qui serait un lien bidirectionnel d'une version à l'autre et d'un sprint à l'autre Jetons donc un coup d'œil à la configuration dans Notion. J'ai donc ajouté le plan de publication de la page ici en bas, donc je vais vous montrer à quoi cela devrait ressembler. J'ai ajouté une base de données. Nous avons la première version ici, qui est la version 1.0 pour mon projet, qui est un projet Ed Tech. La première version est Game Fide Learning. J'ai l'objectif de sortie ici. Le champ que j'ai sélectionné contient du texte, ce qui me permet d'en ajouter d'ici la version 1.0 Les apprenants sont incités à revenir tous les jours grâce aux étoiles, séries et à la personnalisation des avatars La colonne suivante est la date cible, où j'ai sélectionné la date en entrée. C'est le 14 août 2026, dans six semaines, et j'ai cliqué sur statut, qui est le champ de sélection, qui vous permet d' ajouter ensuite les différents J'ai ajouté la version active et la planification, puis les sprints planifiés. Cette entrée serait un nombre. Je viens d'en mettre trois. Nous avons donc prévu trois sprints pour cette version Jetons donc un coup d'œil à la page de publication. Ainsi, si vous ouvrez la page de publication, vous pouvez ensuite structurer votre page de publication de cette manière. Il contient déjà toutes les informations de la base de données ci-dessus et ci-dessous, voici où se trouve la structure. Nous avons donc des thèmes avec le système de récompenses par étoiles, séries et les habitudes, et la personnalisation des avatars Nous avons la répartition des sprints avec le premier sprint et le lien vers le premier tirage. Nous avons la section clé sur les dépendances avec une décision concernant la bibliothèque d'animations si nécessaire avant la fin du premier sprint, des points de terminaison de l'API principale pour Star Assistant, ressources de conception pour les options d'avatar Nous avons quelques risques au bas de l'échelle, complexité de l'animation peut se répercuter sur le troisième sprint L'atténuation consiste à augmenter rapidement, puis à rationaliser la logique, cas extrêmes, les jours manqués, les changements de fuseau horaire, etc. Et en bas, nous avons la progression, que vous devez renseigner pendant que vous faisiez le sprint. Alors, comment ajouter le lien. Ici, j'ai ajouté le lien vers le premier sprint, qui est le système de récompense Star. Pour ce faire, il vous suffit d'ajouter le signe de l'application, puis de commencer à taper le nom de la page , appelé système Star Reward. Vous cliquez dessus, et le lien est ajouté. Ensuite, lorsque vous cliquez sur le lien, vous accédez au sprint du système de récompenses par étoiles. Et comme vous pouvez le constater, nous en avons la capacité. Nous avons les histoires sélectionnées, nous avons les risques et les dépendances, ainsi que l'engagement. Voici le détail du sprint. Et en haut de la page, j'ai mis une partie du plan de sortie. Encore une fois, pour ajouter le lien, il vous suffit de cliquer. Tapez le signe arobase. Ici, vous pouvez rechercher le nom de n'importe quelle page que vous avez, et vous pouvez créer un lien vers cette page. Vous avez donc un plan de sortie. Il suffit donc de cliquer sur le plan de publication et nous verrons qu'il est là. Et cela nous ramène au plan de publication , que nous avons sur cette page. Alors permettez-moi d'y retourner rapidement. Je l'enlève. Il est très facile d'ajouter vos liens bidirectionnels. Je recommande vivement de le faire. Cela permettra à tout de rester bien lié. C'est donc la fin de l'idée, guide étape par étape sur la façon de configurer votre page de publication. Dans la vidéo suivante, nous avons un petit exercice pratique, qui serait votre plan de publication. Rédigez donc un plan en trois sprints pour le brief que vous avez sélectionné. C'est la prochaine étape. Je te verrai dans le prochain. 6. Practice Exercise: 3-Sprint Release Plan: O Bon retour. Il est temps de mettre en pratique tout ce que vous avez appris dans cette section. Dans ce petit exercice, vous allez rédiger un plan de publication en trois sprints pour votre propre brief, et à la fin, vous aurez un véritable plan de publication prêt à être utilisé pour le reste de ce cours. Votre tâche comporte cinq étapes. Prenez votre temps, mais ne vous inquiétez pas à ce sujet. La première étape consiste à définir votre objectif de publication. Il doit s'agir d'une phrase , axée sur les résultats, et c'est ce que vous voulez voir vrai à la fin de trois sprints. La deuxième étape consiste à identifier trois thèmes. Chacun d'entre eux devient le point central d' un sprint et chaque thème doit atteindre l'objectif de publication. La troisième étape consiste à diviser chaque thème en trois à cinq articles, principalement des articles qui existent déjà dans votre carnet de commandes, si vous en avez un La quatrième étape consiste à identifier les dépendances et les risques, ce qui doit être vrai pour que cette version soit publiée. Et la cinquième étape consiste à choisir une date cible et à être réaliste. Six semaines, c'est une bonne idée pour une sortie en trois sprints. Regardons maintenant mon exemple de travail dans le domaine des technologies de l'éducation. Voici à quoi ressemble un bon objectif de publication et à quoi pourrait ressembler un plan final pour mon brief EdTech L'objectif de publication est donc d'ici la version 1.0, les apprenants âgés de quatre à huit ans sont incités à revenir grâce aux étoiles, aux séries et à la personnalisation quotidiennes Le premier thème est le sprint 1, le système de récompense par étoiles, les histoires, les étoiles après les leçons, affichage des étoiles et l'animation. Le thème 2 est le sprint 2, qui comprend des séries et des habitudes Les histoires sont le compteur de séries quotidiennes , récompenses de série et la gestion des séries de tours, puis le thème 3 ou le sprint 3 est la personnalisation de l'avatar. L'histoire est là. Nous avons la sélection des avatars, les avatars persistants et les avatars dans les leçons. Certaines dépendances, la bibliothèque d'animations choisie à la fin du premier sprint, le risque est qu' une logique de série séquences soit plus complexe que prévu, et la date cible est fixée à six semaines. Nous avons quelques erreurs courantes à éviter. Voici les trois grands. La première consiste à rendre la version trop importante. Par exemple, selon la première version, l'application est parfaite, ce qui est inutile. Choisissez un résultat plus petit et plus étroit. Deuxièmement, si les thèmes ne rentrent pas dans un sprint, s'il faut deux sprints, il s'agit en fait de deux thèmes, alors divisez-le Et le troisième est de ne pas tenir compte de la capacité. Ne planifiez pas trois sprints de travail en deux sprints. Vérifiez votre vélocité , que nous aborderons correctement dans la section suivante. Donc, quelques vérifications de santé mentale avant de dire que c'est terminé. La première est de savoir si l' objectif de sortie semble réalisable en trois sprints avec votre équipe ? Tu dois être honnête. Deuxièmement, si je n'expédiais que le premier sprint, cela serait-il utile en soi ? bonnes sorties se traduisent par des victoires anticipées, et pas seulement par une belle fin. Et troisième étape, puis-je expliquer la sortie en une phrase à quelqu'un qui n'a jamais vu le projet ? Si oui, il est clair que si vous vous qualifiez, l'objectif n'est pas assez serré. Enregistrez donc votre notion de planification des versions dans la base de données des plans de publication que vous avez créée lors la dernière leçon et liez-la à vos pages de planification de sprint existantes afin que les niveaux soient connectés. Et ceci est maintenant votre document de référence pour les prochaines sections. Ainsi, chaque estimation ou mesure, leçon destinée aux parties prenantes de ce cours, y fera référence. Ensuite, dans la section deux, nous avons l'estimation et la vitesse. Dans cette section, nous avons fait un petit zoom arrière entre le premier sprint et la sortie, et nous avons le plan des pages Merci donc de m'avoir rejoint. Dans la section suivante, nous aborderons sérieusement l'estimation et vélocité, ainsi que les techniques qui rendent la planification de plusieurs sprints réellement crédible. Je vous verrai dans la section suivante. 7. Why Estimation is Hard, and Often Wrong: Bon retour. Dans le domaine de la gestion de projet, l' estimation est l'une des tâches les plus difficiles à accomplir par une équipe, et l'une des plus mal comprises Avant d'aborder les techniques décrites dans le reste de cette section, nous devons expliquer honnêtement pourquoi estimation est si difficile. À la fin de cette leçon, vous comprendrez les biais qui rendent les estimations peu fiables, pourquoi cela change, et comment vous devez utiliser les estimations en premier lieu Tout d'abord, il y a l'erreur de planification. Commencez donc par le plus gros problème. Les humains ont du mal à estimer le temps que les choses vont prendre. Il existe un biais cognitif bien connu appelé erreur de planification, décrit pour la première fois par Daniel Carnman et Amos Tversky Le constat est simple. Lorsque les gens estiment la durée d'une tâche, ils sous-estiment constamment, pas un peu, mais beaucoup Des études ont révélé que même lorsque les gens sont informés l'erreur de planification et qu'on leur demande de corriger, ils sous-estiment toujours Pourquoi ? Parce que lorsque nous pensons à une tâche, nous imaginons le chemin idéal. Nous nous imaginons travailler sans interruption, sans contretemps, sans découvrir que les exigences n' étaient pas claires Et la réalité n'est rien de tel. Alors pourquoi notre travail est-il pire ? Maintenant, l'erreur de planification s'applique à tout, mais certains types de travail sont plus difficiles à estimer que d'autres Malheureusement, la plupart de nos activités entrent dans la catégorie des plus difficiles. Vous peignez une clôture, par exemple, que vous pouvez estimer assez bien. Tu l'as déjà fait. Il s'agit d'une tâche physique dont les progrès sont visibles et qui comporte quelques inconnues Cependant, si vous créez un logiciel, si vous menez une campagne ou si vous organisez un événement, tout est différent. Chaque tâche est un peu nouvelle. Vous êtes souvent en train de résoudre un problème que vous n'avez jamais résolu auparavant. Les exigences évoluent au fur et à mesure que vous apprenez, des dépendances que vous n'aviez pas prévues apparaissent et vous découvrez à mi-chemin que l'approche que vous avez choisie ne fonctionne pas. Et tu dois essayer autre chose. C'est pourquoi nos estimations ce type de travail sont généralement erronées, non pas parce que nous sommes mauvais en matière d'estimation, mais parce que le travail lui-même est intrinsèquement imprévisible Il y a donc quelques biais courants dans l'estimation. Au-delà de l'erreur de planification, il existe plusieurs autres biais qu'il convient de connaître Le premier est le biais d'optimisme. Nous partons du principe que tout ira bien même si les preuves passées indiquent le contraire, vous oubliez les trois dernières fois où votre estimation a explosé, vous vous concentrez plutôt sur les moments où elle a fonctionné . Vient ensuite l'ancrage. Le premier chiffre mentionné dans une discussion devient le point d'ancrage vers lequel tout le monde gravite Si votre manager vous dit que cela pourrait être fait en deux semaines ? coup, deux semaines semblent raisonnables, que ce soit le cas ou non. La prochaine est la pression sociale. Personne ne veut dire que cela prendra six mois dans une salle remplie de parties prenantes enthousiastes. Les estimations diminuent donc doucement pour s'adapter à ce que les gens veulent entendre. Enfin, il y a le cône d'incertitude. Au début d'un projet, lorsque vous en savez le moins, vos estimations sont les moins fiables. Mais c'est aussi généralement à ce moment-là que les gens en veulent le plus. Le cône se rétrécit au fur et à mesure que vous apprenez, mais les premières estimations sont essentiellement des suppositions Alors, qu'est-ce que cela signifie pour la façon dont vous estimez ? Il y a donc trois implications pratiques. Premièrement, traitez les estimations comme des plages et non comme des points. Cela prendra 2 à 5 sprints, c'est plus honnête que cela ne prendra trois Toute estimation à un seul chiffre masque l'incertitude. Deuxièmement, comparez vos estimations à la réalité. Au fil du temps, vous découvrirez les véritables préjugés de votre équipe. Si vous sous-estimez régulièrement de 40 %, vous pouvez commencer à corriger, mais vous ne pouvez pas corriger ce que vous ne mesurez pas Troisièmement, utilisez les estimations pour planifier et non pour promettre. C'est le changement le plus important. Une estimation est un outil qui permet de prendre des décisions sur quoi travailler. Il ne s'agit pas d'un engagement de livraison à une date précise. Dès qu'une estimation devient une promesse, vous avez rompu l'honnêteté qui la rend utile. Alors pourquoi sommes-nous toujours estimés ? Pourquoi s'embêter ? Compte tenu de tout cela, vous vous demandez peut-être pourquoi vous donner la peine d'estimer une question qui, pour être honnête, est une bonne question, mais la réponse est que même de mauvaises estimations peuvent aider. Ils vous obligent à réfléchir au travail. Ils font apparaître des inconnues. Ils vous donnent un dimensionnement approximatif pour comparer les options. C'est donc certainement plus que cela c'est plus utile que les chiffres exacts. Les techniques que nous aborderons dans le reste de cette section ne visent pas uniquement à produire des estimations précises. Personne ne produit vraiment des estimations précises à tout moment. Il s'agit de produire des estimations utiles, des estimations qui éclairent les décisions qui forcent des conversations honnêtes et qui s'améliorent au fil du temps à mesure que vous les comparez à la réalité. D'accord, l'estimation est difficile, mais être honnête à ce sujet est la première étape pour bien le faire . Merci de m'avoir rejoint. Dans la leçon suivante, nous aborderons de manière approfondie les story points, leur nature, leur utilisation et la manière d' éviter les pièges dans lesquels tombent la plupart des équipes . Je t'y verrai. 8. Story Points: Deep Dive: Bon retour. Les story points sont la technique d'estimation la plus courante dans Agile, mais ils sont également la plus mal comprise Dans cette leçon, nous allons aller un peu plus loin que le niveau de surface. Nous examinerons ce que sont réellement les story points , pourquoi ils fonctionnent et les pratiques spécifiques qui les rendent utiles plutôt que performatifs Quels sont donc les points de l'histoire ? Il s'agit d'une unité permettant de mesurer la taille relative d'une œuvre. Ils combinent trois choses efforts nécessaires à une histoire, sa complexité et son degré d'incertitude. histoire en cinq points est environ cinq fois plus longue qu'une histoire en un point, non cinq fois plus d'heures, cinq fois plus. L'effort, la complexité et les inconnues sont tous réunis en un seul chiffre Le fait est que le cerveau humain est bien meilleur pour comparer des tailles que pour estimer des durées absolues Demandez à quelqu'un combien de temps prendra une tâche en heures, il lui demandera probablement si elle est plus ou moins importante qu'une autre tâche, il fera généralement les choses correctement. La séquence de Fibonacci est donc correctement expliquée. La plupart des équipes utilisent la séquence de Fibonacci un, deux, trois, cinq, huit, 13, 21, parfois 40 et 100 pour les objets très volumineux Cette séquence spécifique s'explique par deux raisons. Tout d'abord, les écarts s'élargissent à mesure que les chiffres augmentent. La différence de 1 à 2 est faible. La différence de 13 à 21 est énorme. Et cela reflète une réelle incertitude. Quand quelque chose est petit, vous pouvez vraiment le voir clairement. Quand quelque chose est grand, vous ne le comprenez probablement pas assez bien pour distinguer un huit d'un neuf. Deuxièmement, les grands écarts forcent les décisions. Vous ne pouvez pas vous asseoir sur la clôture entre deux numéros adjacents. Qu'il s'agisse d'un cinq ou d'un huit, ce choix de force accélère estimation et évite des débats interminables Ancrez donc votre histoire de référence. La pratique la plus importante en matière points narratifs consiste à choisir un bon récit de référence. C'est le point d'ancrage, une histoire que tous les membres de l' équipe connaissent bien, dont vous convenez tous qu'elle est d' une certaine taille, généralement deux ou trois. Toutes les autres estimations sont effectuées par rapport à cette référence. Un petit récit de référence suffisamment petit pour être facilement compris, bien documenté et déjà livré, afin que tout le monde se souvienne de son déroulement. Ensuite, lorsque vous estimez une nouvelle histoire, la question n'est pas de savoir quelle est son ampleur dans l'abstrait. Comment cela se compare-t-il à notre référence ? Si votre équipe est en train de rédiger l'histoire de votre projet sur le fait de gagner des étoiles en terminant une leçon, l' on convient que c'était trois. Ensuite, lorsque vous regardez une nouvelle histoire, comme l'ajout de stries, vous vous demandez si elle est plus grande ou plus petite que les étoiles De combien, deux fois par moitié. Sans récit de référence, les estimations commencent à dériver. chaque sprint, ils signifient quelque chose de légèrement différent et les chiffres cessent d'être comparables au fil du temps. Planifier correctement le poker. Les story points fonctionnent mieux lorsqu'ils sont estimés par l'ensemble de l'équipe. Jouer au poker est une technique classique, mais permettez-moi d'aller plus loin que le niveau de surface. Chaque membre de l'équipe reçoit un jeu de cartes avec les numéros de Fibonacci Le propriétaire du produit lit l'histoire. L'équipe pose brièvement des questions de clarification. Ensuite, chaque personne choisit une carte en secret et tout le monde la dévoile en même temps. Le moment critique est celui où les estimations divergent. Supposons que trois personnes aient dit trois et qu'une personne ait dit huit, ne faites pas une moyenne. Ne vous contentez pas de prendre le plus haut ou le plus bas. Demandez aux personnes aberrantes de s'expliquer. Neuf fois sur dix, la personne qui en a estimé huit sait quelque chose que les autres ignorent. Peut-être qu'ils se souviennent d'une dépendance , d'une complexité ou d'un échec passé, et que ces connaissances doivent faire surface. Une fois qu'ils l'ont partagé, tous les autres le réestiment. Le nombre converge alors généralement. Si vous travaillez seul, vous êtes toute l'équipe, ce qui signifie que vous devez être très rigoureux. Essayez d'estimer la même histoire à un jour d'intervalle et comparez. Recherchez la cohérence. Votre première estimation est souvent assez optimiste. Quels sont les points de l'histoire ou non ? Quelques malentendus courants. Si vous vous trompez, les story points deviendront pratiquement inutiles. Premièrement, les story points ne sont pas des heures. Dix points d'histoire ne signifient pas 10 heures, dix jours ou une durée précise. La relation entre les points et le temps n' apparaît qu' au cours de plusieurs sprints et uniquement pour cette équipe spécifique Deuxièmement, les story points ne sont pas un indicateur de performance. Si tout le monde vous dit que l' équipe devrait obtenir 40 points par sprint, ils ont mal compris Les story points servent à la planification. Ce ne sont pas des bâtons pour battre des équipes. Troisièmement, les story points ne sont pas comparables entre les équipes. cinq de l'équipe A ne sont pas les mêmes que les cinq de l'équipe B car les points de scénario sont associés à l'histoire de référence spécifique d'une équipe, ils n'ont de sens qu' au sein de cette équipe. Quatrièmement, les points de l'histoire ne sont pas fixes. Si une histoire que vous avez estimée à trois s'avère beaucoup plus importante que vous ne le pensiez, vous ne mettez pas l'estimation à jour rétrospectivement Vous laissez l'estimation telle quelle et vous utilisez la différence pour améliorer les estimations futures. Lorsque les story points ne fonctionnent pas, ils ne constituent pas toujours le bon outil pour chaque situation. Il existe trois situations dans lesquelles vous n'en aurez peut-être pas besoin. De très petites équipes effectuant un travail très similaire. Si vous êtes en solo et chaque histoire est à peu près la même, vous n'avez pas besoin de points. Il suffit de compter les histoires. Un travail très variable si un sprint est consacré à de l'ingénierie lourde et le suivant à un polissage léger. Les points ne seront pas comparables, Cam Ban et l'équipe cycliste pourraient mieux fonctionner. Toute situation où l'estimation est utilisée pour promettre une date. Si le leadership prend total de vos points narratifs et le convertit en date limite, c' que la technique est mal utilisée Il vaut mieux ne pas estimer du tout plutôt que d'alimenter un processus défaillant. Les story points correctement rédigés constituent un puissant outil de planification. Mal faites, elles peuvent devenir source de confusion. Merci de m'avoir rejoint dans cette leçon. Dans le prochain chapitre, nous verrons ce que les story points permettent de réaliser au cours de plusieurs sprints et en suivant la vélocité Je t'y verrai. 9. Tracking Velocity Across Sprints: Bon retour. Maintenant que nous avons abordé les points narratifs, nous pouvons parler de l'indicateur qu' ils rendent possible, à savoir la vélocité. La vélocité est l'un des indicateurs les plus puissants et les plus mal utilisés de l'Agile Dans cette leçon, nous verrons ce qu'est la vélocité, comment bien la suivre et comment la garder utile sans la laisser devenir dangereuse. Alors, qu'est-ce que la vélocité ? La vélocité est simple. Il s'agit du nombre total de story points qu'une équipe obtient en un seul sprint. L'équipe a terminé quatre étapes valant trois, cinq, cinq et huit points. Sa vélocité pour ce sprint était de 21. Notez que la vélocité ne compte que les histoires terminées. Tout ce qui reste à faire à la fin du sprint ne compte pas, et c'est délibéré. Le travail terminé est ce qui compte le plus. crédit partiel encourage les comportements exacts que vous ne voulez pas, comme accumuler la moitié du travail accompli Vous calculez la vélocité pour chaque sprint. Au fil du temps, vous obtenez une série de chiffres qui montrent à quel point votre équipe fournit régulièrement des résultats. C'est très utile. Pourquoi c'est important. La vélocité est précieuse pour trois raisons lorsque vous disposez de quelques sprints de données Premièrement, cela facilite la planification des sprints. Si votre vitesse moyenne est de 25 points, ne vous engagez pas à atteindre 40 lors du prochain sprint car vous échouerez. Vous serez surchargé de travail et vos estimations futures seront empoisonnées par ce faux point de données Deuxièmement, il permet de faire des prévisions. S'il vous reste 100 points de travail à lancer et que votre vélocité est de 25, vous reste environ quatre sprints. Exactement, mais assez pour faire de vrais plans. Troisièmement, il répond aux problèmes. Une chute soudaine de la vitesse est un signal. Quelqu'un était-il en congé de maladie ? Avez-vous accepté un travail d' une complexité inhabituelle ? L'équipe est-elle épuisée ? Les données de vélocité suscitent les bonnes conversations. Comment bien le suivre ? Donc des conseils pratiques. Tout d'abord, ignorez les trois premiers sprints. La vélocité initiale de chaque équipe n'est pas fiable. Vous êtes toujours en train de calibrer la taille de vos story points. Votre histoire de référence se stabilise. Trois sprints, c'est donc à peu près le temps qu'il faut pour que les chiffres commencent à prendre tout leur sens Ensuite, utilisez une moyenne mobile, pas un seul sprint. Regardez vos trois ou cinq derniers sprints et prenez la moyenne Cela atténue le bruit d'un sprint à l'autre. Un seul sprint avec une vélocité de 40 ne signifie rien si votre moyenne mobile est de 25. Troisièmement, suivez-le de manière visible. Une simple table fonctionne. Ajoutez un journal de vélocité à votre espace de travail Notion avec une ligne par sprint. Colonnes, numéro du sprint, points prévus, points terminés et toutes les notes expliquant pourquoi le sprint s'est déroulé comme il s'est passé. Au fil du temps, ces données deviennent de l'or. Quatrièmement, révisez-le à chaque sprint. Dans votre rétrospective, examinez votre tendance en matière de vélocité, pas pour calibrer ou réprimander, mais simplement pour simplement pour Nous avons participé à chacun des trois derniers sprints. Pourquoi est-ce le cas ? Tu pourras le découvrir. Ensuite, il y a les dangers de la vélocité. La vélocité est puissante, mais elle est également facilement utilisée à mauvais escient. Il y a quatre dangers à connaître. Premièrement, la vélocité comme cible. Dès que la vélocité devient un objectif, elle cesse de mesurer ce que vous pensiez avoir fait. Les équipes augmentent leurs estimations de points narratifs. Soudain, une histoire qui était un trois est un cinq, la vitesse augmente, même si rien n'a vraiment changé. Deuxièmement, les comparaisons de vélocité entre les équipes. L'équipe A marque 40 points. L'équipe D en fait 25. L'équipe B a l'air paresseuse, mais peut-être qu'elle estime différemment. Peut-être que leur travail est vraiment plus difficile. Ne comparez jamais la vélocité entre équipes. Troisièmement, la vélocité comme productivité. Une vitesse élevée n'est pas la même chose qu'une valeur élevée. Une équipe pourrait fournir 100 points de fonctionnalités que personne n'utilise. Les Story Points mesurent la taille mais pas la valeur. Et pour la vélocité, c'était une honte. Dans de trop nombreuses organisations, la vélocité devient un outil utilisé par les dirigeants pour faire pression sur les équipes. Cela détruit l'honnêteté qui rend la métrique utile en premier lieu. Ajoutez donc de la vélocité à votre espace de travail. Il pourrait s'agir d'une nouvelle sous-page Notion comportant quatre colonnes. Ouvrez donc votre espace de travail Notion, ajoutez une nouvelle sous-page dans la page principale de votre projet, appelez-la Velocity log À l'intérieur de cette page, ajoutez une base de données à quatre colonnes, avec un numéro de sprint sous forme de nombre. Les points sont planifiés sous forme de chiffre, points complétés sous forme de chiffre et les notes sous forme de texte. Remplissez une ligne par sprint au fur et à mesure que vous les terminez. Si vous en avez déjà fait un ou deux, vous pouvez les remplacer dès maintenant, car même les données historiques approximatives sont plus utiles que rien et, au fil du temps, elles deviendront la mémoire de votre équipe Désormais, les membres de l'équipe peuvent voir l'histoire, rétros peuvent pointer du doigt les données et les prévisions peuvent être fondées sur la réalité C'est donc de l'or absolu pour un projet. Cependant, la vélocité peut provoquer des oscillations. Certaines équipes ont des vitesses très variables d'un sprint à l'autre Si c'est vous, ne paniquez pas. Il y a trois causes communes à cela. Premièrement, votre histoire de référence ne cesse de changer. Fixez la référence, ancrez-vous sur une histoire dont tout le monde se souvient. Deuxièmement, la longueur de votre sprint n'est pas uniforme. Si certains sprintent jusqu'à deux semaines et d'autres une semaine, bien sûr, la vitesse variera. Fixez simplement la longueur du sprint. Troisièmement, vous effectuez des types de travail très différents à chaque sprint Certains sprints sont lourds, d' autres sont des tests. Il en va de même pour le vernis. Dans ce cas, les Story Points ne sont peut-être pas le bon outil pour votre équipe. Nous aborderons Caban comme alternative dans la section suivante. Bien utilisé, Velocity est un véritable outil de prévision, mais mal utilisé, il devient du théâtre. Assurez-vous donc de l'utiliser car utilisé correctement, il peut devenir de l'or. Merci de m'avoir rejoint dans cette leçon. Dans la prochaine, nous mettrons la vélocité à l'œuvre prévoyant le nombre de sprints prendra réellement votre publication. Je t'y verrai. O 10. Forecasting the Release: Bon retour. Jusqu'à présent, tout ce qui est contenu dans cette section a servi de base. Maintenant, nous allons le mettre en œuvre. Dans cette leçon, vous allez apprendre à répondre à la question que chaque partie prenante finit par se poser : Combien de temps cela va-t-il prendre ? À la fin, vous saurez comment produire des prévisions défendables et honnêtes sans prétendre voir l'avenir Le calcul de base, cette seule ligne d'arithmétique, est assez simple, en fait, le total points restants divisé par la vitesse moyenne Donc, s'il reste 100 points de travail à accomplir dans votre histoire et que la vitesse moyenne mobile de votre équipe est de 25 points par sprint, vous aurez besoin d'environ 100/25, soit quatre sprints C'est simple et suffisamment fiable pour la plupart des applications. Mais il y a un peu plus que cela, car le calcul repose sur deux nombres qui comportent tous deux un peu d'incertitude. Le total des points et la vélocité. Si vous vous trompez sur l'un ou l'autre de ces points, les prévisions sont également erronées. Nous commençons donc par le nombre total de points. Cela suppose que vous avez estimé chaque histoire contenue dans le communiqué. Dans la pratique, c' est rarement le cas. Certaines histoires sont bien comprises, mais d'autres sont encore vagues et d'autres n'existent peut-être même pas encore. Il existe cette vieille règle dans Agile tout le carnet de commandes n'est pas estimé Seules les histoires qui se situent en haut de l'arriéré font l'objet d'estimations correctes Des articles plus bas ou des espaces réservés, des idées ou même des souhaits Donc, lorsque vous faites des prévisions, soyez honnête quant à ce que représente réellement votre total de points. S'agit-il d'un total d'histoires bien estimées ou d'un mélange d' estimations solides et de suppositions approximatives Pratique utile pour les histoires qui ne sont pas encore estimées ajoutez un espace réservé en utilisant la taille moyenne des histoires de votre équipe Si vos histoires comportent cinq points, utilisez cinq pour tout ce qui est vague. C'est mieux que rien, mais signalez-le explicitement dans les prévisions. Problème de vélocité. Maintenant, pour ce qui est de la vélocité, votre vitesse moyenne n'est utile que si le futur ressemble au passé, n'est souvent pas le cas. Les membres de l'équipe partent en vacances, de nouvelles personnes les rejoignent, le travail devient de plus en plus difficile au fur et à mesure que vous abordez les sujets les plus complexes qui restent en tête de liste. Des dépendances apparaissent qui ralentissent les choses. Une prévision plus honnête utilise une fourchette au lieu d'un chiffre unique. Si vous regardez vos cinq ou six derniers sprints, vous constaterez que vélocité la plus faible est le pire des scénarios Le plus élevé est votre meilleur argument. La moyenne est votre moyenne. Présentez ensuite trois chiffres. Dans le meilleur des cas, trois sprints. Le cas probable est de quatre sprints, et le pire des cas est de six sprints C'est bien plus honnête que de dire quatre sprints et de faire semblant de le savoir Donc, lorsque vous discutez avec les parties prenantes, voici quelques règles pour la conversation avec elles, car la façon dont vous communiquez vos prévisions est tout aussi importante que les chiffres eux-mêmes. Ne donnez pas un seul chiffre. Ne dites pas qu'il sera expédié dans six semaines. Cela finit toujours mal. La réalité ne correspond jamais à une estimation ponctuelle. Donnez cependant une fourchette avec un contexte explicite. Sur la base de notre vitesse actuelle, cette version prendra 4 à 6 sprints, mais probablement cinq Cette fourchette suppose qu' il n'y ait aucun changement d'équipe ni aucune surprise majeure. Nous affinerons l'estimation du sprint chaque sprint au fur et à mesure que nous en saurons plus. Nommez explicitement vos hypothèses. Cela suppose que nous n' adoptons aucune autre priorité. Cela suppose que vous ne perdez personne. Cela suppose que les estimations dont nous disposons sont à peu près correctes, et les parties prenantes peuvent alors contester ces hypothèses, ce qui correspond exactement à la conversation selon laquelle vous mettez à jour les prévisions à chaque sprint. Les nouvelles prévisions vous fournissent des données actualisées, communiquez ouvertement le changement. Par exemple, il y a deux semaines, j'ai parlé de quatre à six sprints. Sur la base de ces données de sprints, il semble maintenant qu'il y en ait cinq à sept, ce qui normalise le changement Personne ne s'attend à ce qu'une prévision faite il y a des mois soit toujours exacte. Voici quelques erreurs courantes à éviter. On suppose que la vitesse est stable, ce qui est le cas. Certains sprints sont moins bons que d'autres, c'est pourquoi nous utilisons des plages et non des moyennes Deuxièmement, oublier le travail qui n'est pas lié à l'histoire , les corrections de bugs, les réunions, l' administration, les dettes technologiques , l'intercapacité, mais cela ne figure souvent pas dans votre total de points d' histoire, vous devez donc vous y ne figure souvent pas dans votre total de points d' histoire, adapter Troisièmement, en supposant que l' équipe puisse aller plus vite, si nous travaillons tous le week-end, nous livrerons en trois sprints. C'est de la pure fantaisie. Le rythme durable est ce que mesure la vélocité. Les heures supplémentaires ne se multiplient pas, et ce n'est pas une réalité. Quatre, ignorer les dépendances extérieures à l'équipe. Si votre publication dépend de la décision d'une autre équipe, d'un fournisseur, d'un client ou d'une partie prenante, vos prévisions ne sont bonnes que si elles sont ponctuelles Rendez la dépendance visible dans les prévisions. Et si vos prévisions ne sont pas les bienvenues ? Dans ce cas, il suffit d'être honnête de toute façon. Il arrive donc que vos prévisions honnêtes entrent en conflit avec ce que veulent les dirigeants, et cela se produit tout le temps. Que faites-vous dans ces situations ? L'honnêteté est la meilleure politique. D'après notre vélocité, cela ressemble à une version en six sprints. Je sais que tu en voulais trois. Parlons de ce que nous pourrions faire pour y parvenir. Ne vous engagez jamais discrètement à une date que vous ne pouvez pas atteindre. Cela ne te fait pas gagner du temps. Cela reporte simplement un échec à plus tard, où cela ne fera que faire plus mal. Si la pression est forte, mettez-la par écrit. Nous avons convenu d'essayer trois sprints. Pour comprendre cela, c'est bien en deçà notre vitesse moyenne et il faudrait réduire X, Y et Z. Cela protège tout le monde en cas de retard dans le calendrier. Une prévision n'est donc pas une promesse. Il s'agit d'une estimation réfléchie faite avec les meilleures données que vous avez communiquées avec honnêteté quant à ses limites. Merci de m'avoir rejoint dans cette leçon. Dans le prochain exercice, nous allons assembler cet exercice, et vous allez estimer votre propre publication et produire une prévision réelle. Je te verrai dans le prochain. 11. et prévisions: Bon retour. Il est temps de passer de cette section à un exercice pratique. Vous allez évaluer les articles contenus dans votre communiqué, produire des prévisions réelles et les communiquer d'une manière qui fonctionne avec de véritables parties prenantes. À la fin, vous disposerez d'une prévision défendable pour votre plan de publication, étayée par des données réelles Alors, tout d'abord, configurez votre espace de travail, ouvrez Notion et Trello Ainsi, sur votre Trello, vous avez votre tableau et espace de travail ou votre documentation Notion, vous travaillerez avec les deux Dans Notion, si ce n'est pas déjà fait, ajoutez une sous-page du journal de vélocité, une base de données simple à quatre colonnes. Nombre de points du sprint, points prévus, points complétés et notes. Si vous avez déjà effectué un ou deux sprints, complétez votre journal de vélocité avec ce que vous avez réellement obtenu lors de ces sprints Les estimations approximatives sont bonnes. Quelque chose vaut mieux que rien. Sur votre tableau Trello, assurez-vous que toutes les histoires de votre version actuelle sont visibles S'ils sont répartis dans le backlog, regroupez-les d'une manière ou d'une autre, par exemple avec un label comme release 1.0 De cette façon, vous pouvez voir l' ensemble du champ d'application en un seul endroit. La prochaine étape consiste à choisir votre histoire de référence. C'est l'ancre sur laquelle repose tout le reste. Il s'agit de la première étape de l'exercice. Alors, regardez les histoires que vous avez déjà terminées et choisissez-en une petite, bien comprise et dont tout le monde se souviendra. Clairement. C'est votre point d'ancrage. Attribuez-lui une valeur en points. Deux est une bonne valeur par défaut. Maintenant, notez ce qui en fait un deux. Il s'agit par exemple d'une simple modification de l'interface utilisateur qui a pris quelques heures sans inconnues ni dépendances. Ce sont nos deux. Cette description vous aidera à calibrer d'autres estimations à l'avenir. Estimez chaque article de votre communiqué par rapport à votre article de référence. Alors parcourez vos histoires une par une. Pour chaque histoire, demandez-vous si elle est plus grande ou plus petite que ma référence. Combien plus grand ? Choisissez un numéro de Fibonacci, un, deux, trois, cinq, huit, 13 ou 21 Quelques conseils. Si vous hésitez entre deux chiffres, choisissez le plus grand Le biais d'optimisme est réel. Donc, si une histoire ressemble à un huit, estimez huit. Si une histoire ressemble à 21 ou plus, arrêtez, elle est trop grande et divisez-la en histoires plus petites , puis estimez-les. Si vous ne comprenez vraiment pas assez bien l'histoire pour l'estimer, marquez-la comme ayant besoin d'être affinée. Ne devinez pas car cela vous donnera une fausse confiance. Visez une estimation de dix ou 20 articles, mais n'essayez pas d'estimer le nombre mais n'essayez pas d'estimer total d'articles en attente dans cette version Ajoutez votre estimation sous forme d'étiquettes dans les descriptions des cartes sur Trello pour qu'elle reste visible La troisième étape consiste à tout additionner. Additionnez les points de toutes vos estimations d'histoires. Il s'agit de votre total pour la sortie. Consultez votre journal de vélocité. Si vous disposez des données des sprints précédents, prenez une moyenne mobile Si vous n'avez pas encore de données, c'est très bien. Vous pouvez faire une estimation approximative en fonction des résultats de votre premier sprint, ou vous pouvez estimer ce que vous pensez qu'un sprint réaliste produira. Divisez le total des points de relâchement par votre vélocité, et voici votre prévision de base. Maintenant, calculez la portée, divisez-la par votre vitesse la plus faible dans le meilleur des cas, par votre vitesse la plus élevée dans le pire des cas, et cela vous donne une plage appropriée. Rédiger les prévisions dans Notion est l'étape suivante, et c'est la partie la plus importante. Ouvrez votre plan de publication dans Notion sous rubrique « Progression » ou ajoutez-en un nouveau appelé forecast. Écrivez ce qui suit. La plage de prévisions en sprints, meilleur des cas, dans le cas probable, dans le pire des cas, la plage de données à laquelle correspondent ces sprints Si un sprint dure deux semaines, quatre sprints correspondent à huit semaines à compter Notez donc les hypothèses que vous avez formulées, la disponibilité de l'équipe, aucun changement de périmètre, aucune surprise majeure, aucun affinement des estimations au fur et à mesure que vous apprenez. Enfin, le niveau de confiance est basé sur trois sprints de données de vitesse, niveau de confiance moyen, ou basé sur un sprint, niveau de confiance faible Il s'agit de votre document prévisionnel, que vous partageriez avec les parties prenantes. C'est vrai, c'est honnête et c'est défendable. Des données dorées. Avant de dire que c'est fait, il y a trois vérifications que vous devez vraiment faire. Premièrement, est-ce que les prévisions sont bonnes ? S'il est question de trois sprints et que votre instinct indique six, vous devriez vraiment vous fier à votre instinct Quelque chose ne va pas dans vos estimations ou dans votre vélocité. Deuxièmement, puis-je défendre cela auprès d'une partie prenante ? Si quelqu'un contestait les chiffres, pourriez-vous lui expliquer l'entraînement ? Si oui, alors c'est bien. Si ce n'est pas le cas, vous devez ajouter plus de détails. Troisièmement, qu'est-ce qui pourrait me faire changer d'avis ? Si une nouvelle dépendance est apparue, si l'équipe rétrécie ou si l'histoire s'est révélée beaucoup plus importante, les nommer les rend visibles. Vous avez donc maintenant une prévision réelle et honnête pour votre libération. Enregistrez donc ceci et mettez à jour chaque sprint. Merci de m'avoir rejoint pour cette section. Dans la section suivante, nous examinerons Scrum, Canban et comment choisir la bonne approche pour le travail que vous effectuez réellement. Je t'y verrai. 12. Scrum révisé : quand ça marche et quand ça ne marche pas.: Bon retour. Dans cette leçon, nous allons jeter un regard honnête sur Scrum et faire un bref résumé de ce que c'est Scrum est le framework Agile le plus utilisé au monde et pour une bonne raison, mais ce n'est pas le bon outil pour chaque situation Ainsi, à la fin de cette leçon, vous saurez dans quels domaines Scrum brille réellement et où il joue discrètement contre vous, et comment détecter les signes avant-coureurs indiquant qu'il ne convient pas à votre projet OK, petit résumé de Scrum condensé en 1 minute Assurons-nous simplement que nous sommes tous sur la même longueur d'onde. Si Scrum est nouveau pour vous, voici le tout en une minute. Scrum organise le travail en blocs de longueur fixe appelés sprints, qui durent généralement une à deux semaines Vous planifiez un sprint, vous vous engagez dans un ensemble de tâches et vous protégez l'équipe des changements survenus au cours de ce sprint À la fin, vous passez en revue ce que vous avez construit et vous réfléchissez déroulement, puis vous recommencez. Trois rôles : un responsable du produit qui décide de ce qui doit être construit et dans quel ordre, Scrum Master qui aide l' équipe à bien travailler et à éliminer les blocages et l'équipe qui fait réellement le Il y a quelques réunions régulières, planification au début, un bref enregistrement quotidien, et un examen et une rétrospective à la fin. C'est Scrum. C'est un rythme fixe avec des rôles clairs et un engagement à chaque sprint. Scrum est donc génial dans de bonnes conditions, et c'est là qu'il fonctionne à merveille abord, lorsque votre travail peut être planifié un sprint à l'avance, si vous pouvez raisonnablement décider lundi de ce que vous allez construire au cours des quinze prochains jours, et que cette décision est généralement valable, Scrum vous donne un rythme très Ensuite, lorsque le travail correspond à des parties de la taille d'un sprint, la création d'une nouvelle fonctionnalité pour notre application d'apprentissage des langues pour enfants, par exemple une série de questionnaires de vocabulaire, se décompose facilement en histoires que vous pouvez terminer au cours d'un sprint Et c'est le terrain idéal pour Scrum. Troisièmement, lorsque vos parties prenantes attachent de l'importance à la prévisibilité, la cadence fixe signifie que tout le monde sait il y aura quelque chose à voir à la fin de chaque sprint Pour une personne nerveuse, ce rythme cardiaque régulier est très rassurant Quatrièmement, lorsque l'équipe est stable et dévouée, Scrum suppose un groupe cohérent de personnes focalisées sur un seul produit Lorsque c'est le cas, l'équipe établit un rythme et partage le même sens du rythme. Voyons où le framework Scrum rencontre des difficultés. Scrum commence donc à vous affronter dans quelques situations courantes. Le premier est le travail axé sur les interruptions. Si votre journée est dominée par choses urgentes qui arrivent de façon imprévisible, comme des problèmes d'assistance ou des incidents en direct, l'idée de s'engager à suivre un plan fixe pendant deux semaines est vouée à l'échec. Le plan est périmé le mardi. La seconde est que le travail ne restera pas immobile. Si les priorités changent réellement plusieurs fois par semaine, non pas parce que vos parties prenantes sont difficiles, mais parce que la situation est vraiment fluide, alors la planification d'un sprint devient une fiction que vous finirez par réécrire constamment Le troisième est un travail qui ne correspond pas à la case du sprint. Certaines tâches sont infimes et constantes. Certaines sont grandes et lentes. Si votre travail est un flux désordonné de tailles très différentes, forcer à prendre des engagements précis sur deux semaines crée plus de friction que Et le quatrième, c'est quand les cérémonies semblent vaines. Si votre contrôle quotidien est devenu un rapport de situation destiné à un responsable et votre rétrospective produit les mêmes plaintes tous les quinze jours sans changement, le cadre ne vous convient plus. Jetons donc un coup d'œil à certains signes avant-coureurs indiquant que Scrum est en train de se battre Comment savez-vous que Scrum ne convient pas ? Observez ces signes révélateurs. Signez-en un, vous reprenez le travail à la fin de presque tous les sprints Il est normal que cela se répercute de temps en temps, mais si des histoires inachevées se reproduisent encore et encore dans le sprint suivant, votre engagement ne veut Deuxième signe, planifier ressemble à du théâtre. Vous suivez les étapes de la planification du sprint, mais tout le monde sait que le plan sera détruit en quelques jours. Si personne n'a confiance dans le plan, pourquoi le faites-vous en premier lieu ? Signez trois. Les changements arrivent constamment au milieu du sprint, et vous continuez à les accepter. Scrum a pour but de protéger le sprint. Si vous renégociez le sprint tous les deux jours, vous n'avez pas vraiment Signez quatre, l'équipe redoute les cérémonies. Les réunions qui ajoutent de la valeur ne suscitent pas de ressentiment. Les réunions devenues rituelles le font. taille de votre équipe sur le site d' une autre session de planification, c'est-à-dire les données. Aucun de ces signes ne signifie que vous avez échoué. Cela signifie que l'outil et le travail ne correspondent plus, ce qui vaut la peine d'être pris au sérieux. Scrum n' est donc en aucun cas le seul moyen. Voici donc des choses qui manquent à de nombreuses équipes. Scrum n'est pas agile. Scrum est une façon d'être agile. agilité est l'état d'esprit qui consiste à créer de la valeur rapidement, à réagir au changement et à s'améliorer continuellement. Scrum est un ensemble de pratiques populaires qui soutient cet état d'esprit Ce n'est pas le seul. Si Scrum correspond à votre projet, tant mieux. Utilisez-le à bon escient. Mais si vous avez hoché la tête aux signaux d'avertissement, il existe une autre approche qui permet de mieux gérer le travail imprévisible, fluide et axé sur les interruptions Cela s'appelle Kanban, et c'est ce que nous allons suivre. Scrum est donc un framework très puissant, mais uniquement lorsque le travail lui convient Savoir quand ce n'est pas le cas est un signe de maturité et non d'échec. Merci de m'avoir rejoint dans cette leçon. Dans le prochain article, nous aborderons en profondeur le Kanban, façon dont il utilise les limites de flux et de progression pour gérer exactement le type de travail auquel Scrum a du mal à faire face. Je t'y verrai. 13. Dans Kanban : Limites et flux WIP: Bon retour. Dans cette leçon, nous allons étudier Caban, l'approche de gestion du travail basée sur les flux Si Scrum est une question de rythme et d'engagement, Cam Ban est une question de fluidité et de limites À la fin de cette leçon, vous comprendrez à quoi ressemble un tableau Cam Ban, quelles sont les limites de progression et pourquoi le fait d'en faire délibérément moins en une fois peut vous aider à obtenir plus de résultats. Allons-y. Camban est donc issu de la fabrication japonaise où cela signifie un signal visuel ou une carte Dans notre monde, c'est une façon de gérer le travail comme un flux continu plutôt que par des sprints fixes Il n'y a pas de sprints à Cam Ban. Il n'y a aucun engagement pour un lot de travail de deux semaines. Au lieu de cela, le travail se déroule de gauche à droite, un élément à la fois, et l'équipe entreprend de nouvelles tâches chaque fois qu'elle en a la capacité . Et c'est le cœur de tout cela. Camban a trois pratiques fondamentales. Visualisez votre charge de travail limitez le volume de travail que vous devez effectuer en une seule fois et gérez le flux de travail de manière à ce que le travail continue. Nous allons prendre chacune d'entre elles à tour de rôle. Commencez donc par visualiser l'œuvre. Un tableau Cam Ban est un ensemble de colonnes, et chaque colonne représente une étape par laquelle passe l'œuvre. Voici un tableau typique à cinq colonnes pour notre application d'apprentissage des langues pour enfants. À l'extrême gauche, nous avons l'arriéré, tout ce que nous pouvons faire par ordre de priorité Ensuite, faites le petit ensemble de choses qui sont prêtes à être ramassées. Ensuite, en cours, ce sur quoi on travaille activement en ce moment, puis passez en revue le travail effectué et en attente d'être vérifié et enfin terminé, c' est-à-dire terminé et vérifié. Chaque œuvre est une carte et elle se déplace vers la droite dans ces colonnes au fur et à mesure En un coup d'œil, tout le monde peut voir exactement où tout se trouve, et cette visibilité en elle-même vaut beaucoup. Mais le véritable pouvoir de Camban vient du suivant. Ce sont les limites de progression des travaux. Alors regardez à nouveau le tableau. Remarquez les petits chiffres sur les deux colonnes. En cours, la limite est de trois. L'évaluation est limitée à deux. Il s'agit des limites de progression du travail ou des limites WIP pour les courts métrages WIP signifie simplement progresser. Tout ce que tu as commencé mais pas encore terminé. Une limite WIP limite le nombre d' éléments pouvant figurer dans une colonne à la fois Si une limite en cours est limitée à trois, l'équipe peut avoir au plus trois choses sur lesquelles travailler activement, non quatre, ni dix. Trois. Maintenant, voici ce que cela signifie en pratique. Si la carte en cours est pleine et que vous terminez une carte, vous ne devez pas commencer tout de suite quelque chose de nouveau. Tout d'abord, vous regardez si quelque chose est bloqué et vous l'aidez à avancer. Vous n'obtenez du nouveau travail lorsqu'il y a vraiment de la place pour cela. La limite permet à l'équipe de terminer les choses avant d'en commencer de nouvelles. Maintenant, cela semble un peu contre-intuitif au début, peut-être Faire plus de choses à la fois signifie certainement en faire plus, mais en réalité, c'est le contraire, et il vaut la peine de comprendre pourquoi. Alors pourquoi moins c'est plus. Trois raisons pour lesquelles le fait de limiter le travail en cours vous rend plus rapide et non plus lent. Le premier, moins de commutation. Chaque fois que vous jonglez avec une autre tâche, vous payez un coût pour passer de l'une à l'autre. Vous perdez votre place, vous rechargez le contexte, vous commettez encore plus d'erreurs Une équipe chargée de cinq tâches change constamment. Une équipe qui termine trois fois plus tôt que prévu. Ensuite, les goulots des bouteilles deviennent visibles. Lorsque l'évaluation est limitée à deux et qu'elle est complète, le travail cesse d'y être consacré Ce n'est pas un problème à cacher. Ce n'est qu'un signal. Vous indique exactement où se trouve l'embâcle afin que l'équipe puisse s'y engouffrer et l'éliminer Sans limites, le travail s'accumule de manière invisible. Et troisièmement, le travail est terminé, une carte à moitié faite donne des résultats, rien. Cela n'a de valeur que lorsqu'il est terminé et qu'il est entre les mains de quelqu'un. limiter le travail et les progrès pousse l'équipe à faire tout ce fait de limiter le travail et les progrès pousse l'équipe à faire tout ce qui est en son pouvoir plutôt que de commencer tout en finissant par peu Même une loi grossière derrière tout cela. Plus vous avez de choses en cours à la fois, plus chacune d'entre elles met du temps à se terminer. Moins d'objets en vol se traduit par une livraison plus rapide, et c'est là tout le jeu de Caban Donc, tirez, ne poussez pas. Cela donne à Caban son rythme caractéristique Tirez, ne poussez pas. Dans un système push, travail vous est confié, que vous soyez prêt ou non. Votre signal ne fait que grandir. Dans un système de traction, vous n'acceptez de nouvelles tâches que lorsque vous en avez la capacité. Les limites du WIP l'appliquent automatiquement. Lorsqu'il y a de la place dans une colonne, vous y insérez l'élément suivant. Quand il est plein, ce n'est pas la différence entre une cuisine où les commandes s'accumulent plus vite que les cuisiniers ne peuvent les gérer et une autre où une nouvelle commande ne commence que lorsqu'un cuisinier est libre Pull permet à l'ensemble du système de fonctionner à un rythme durable. Le changement d'état d'esprit au cœur de Cam Ban est donc le flux et non l'engagement. Cam Ban vous demande de vous concentrer sur la fluidité, pas sur un sprint, mais sur la fluidité et le mouvement fluide et régulier du travail de gauche à droite. n'y a pas de sprints, vous ne vous demandez pas à quoi nous allons nous engager cette quinzaine Vous demandez : je travaille bien, et où est-ce que cela se bloque ? Vous mesurez des éléments tels que le temps qu'il faut à une carte pour franchir le plateau du début à la fin, et nous reviendrons sur ces mesures de débit plus tard dans le cours. Pour l'instant, le changement d' état d'esprit est l'élément le plus important, qu'il s' agisse de s'engager un lot ou de maintenir un flux constant. C'est pourquoi Cam Ban convient si bien au travail impulsé par les interruptions et imprévisible en constante évolution. Il n'y a pas de plan fixe pour exploser. Il y a juste la prochaine chose la plus importante. Il est là quand il y a de la place. Caban est donc d'une simplicité trompeuse. Vous visualisez le travail, vous limitez le travail en cours et vous le maintenez fluide. Mais ces quelques idées peuvent transformer la façon dont une équipe produit ses résultats. Merci de m'avoir rejoint dans cette leçon. Dans la prochaine étape, nous allons construire un véritable plateau Cam Ban dans Trello, étape par étape, afin que vous puissiez voir exactement comment tout cela fonctionne. Je t'y verrai. 14. Setting Up a Kanban Board in Trello: Bon retour. Dans cette leçon, nous allons créer une carte Cam Ban à partir de zéro dans Trello. Trello est donc Il fonctionne dans votre navigateur, et tout ce que nous faisons aujourd'hui fonctionne sur le plan gratuit, sans fonctionnalités payantes ni ajout requis. À la fin de cette leçon, vous disposerez d'un cambabard à cinq colonnes fonctionnel pour votre projet, avec des limites de progression Commençons donc. Voyons rapidement ce que nous allons construire. Voici le plan. Nous allons créer un tableau avec cinq listes, de gauche à droite, avec un carnet de tâches en cours, une révision et une liste terminée Deux de ces listes en cours élaboration et de révision seront soumises à des limites de travail en cours, qui plafonneront le nombre de cartes pouvant y figurer. Je vais l'expliquer étape par étape, puis je vais vous montrer à quoi cela devrait ressembler dans Trello Donc, tout d'abord, la convention de limite WIP. Voici l'un des inconvénients du compte Trello gratuit. Aucune fonctionnalité intégrée ne vous empêchera physiquement d'ajouter une quatrième carte à une colonne limitée à trois. Nous utiliserons donc plutôt une convention simple mais fiable qui n'utilise rien. Nous allons simplement mettre la limite directement dans le nom de la liste. Ainsi, au lieu d'être appelé en cours, il sera appelé en cours WIP trois Voyons donc à quoi devrait ressembler le tableau. Vous avez donc votre carnet de commandes. J'ai ajouté quatre cartes à celle-ci. Pour ce qui est d'une carte, j'ai Ding, qui a une limite de progression de travail de trois. Il y a trois cartes dedans. Nous avons une révision avec une limite de progression de travail de deux, et il y a deux cartes dedans, et j'ai une colonne terminée avec deux autres cartes dedans. C'est ça. C'est une simple planche Caban. Donc, très rapidement, les étiquettes et le tirage se font sentir, c'est probablement la partie la plus importante de toute planche Caban Lorsque l'équipe est prête à commencer quelque chose, elle doit faire glisser la carte de « à faire » vers « en cours » ou « à faire ». Surveillez les limites. Le nombre en cours est limité à trois Ainsi, avant que quelqu' un n'introduise une quatrième carte, s'arrête et demande s'il est possible de terminer ou de bloquer quelque chose qui est déjà là en premier, et le travail se déplace de gauche à droite, un tirage à la fois, et il ne passe dans une colonne que lorsque cette colonne contient de la place Ainsi, par exemple, nous pouvons déplacer le badge de progression de droite à gauche depuis le backlog vers to do C'est aussi simple que cela. C'est une application très intuitive. C'est très simple à utiliser, Trello, heureusement. Mais encore une fois, Caban est un concept assez simple. Avant de terminer quelques erreurs courantes à retenir, abord, ne sautez pas la limite. Un tableau sans limite de progression n'est fait qu'une liste sophistiquée avec des colonnes supplémentaires. La limite de progression de travail est un concept de Caban, alors ne la sautez pas, sinon il ne s'agit plus d'une planche Caban Deuxièmement, laisser le travail accompli devenir un cimetière. Donc fait signifie vraiment terminé et vérifié. S'il n'est pas coché, il doit rester en cours de révision, et il ne doit être déplacé que lorsqu' il a été vérifié et approuvé par le propriétaire du produit ou le chef de projet. Et enfin, trop de colonnes. Cinq, c'est donc suffisant pour commencer. Il n'est pas nécessaire d'ajouter une colonne pour chaque petite étape. N'ajoutez une étape que plus tard s'il en manque une vraie, sinon les colonnes supplémentaires créeront du travail et rendront le tableau un peu sinon les colonnes supplémentaires créeront du travail et rendront le tableau un peu plus confus. Donc, c'est tout. Nous avons vu comment créer un cambmbard simple à partir de zéro C'est un concept très simple. C'est également une chose très simple à intégrer dans Trello. Sur le plan gratuit, c'est très, très facile à faire. Dans les comptes professionnels, vous obtenez les limites du WIP pour chaque colonne, et vous bénéficiez évidemment d'autres fonctionnalités sur le compte payant Dans la prochaine leçon, nous examinerons les modèles hybrides, c' est-à-dire un peu des deux. donc d'un mélange de Scrum et de Caban, agit donc d'un mélange de Scrum et de Caban, également connu sous le nom de Scrumban, et nous l'adapterons à la méthode Agile pour qu'elle corresponde réellement à la façon dont votre C'est donc la prochaine étape. Merci de m'avoir rejoint dans cette leçon. Je te verrai dans le prochain. 15. Modèles hybrides : Scrumban et approche personnalisée.: Bon retour. Dans cette leçon, nous allons parler des hybrides, mélange et de l'appariement de pratiques agiles adaptées à votre équipe. Nous examinerons en particulier Scrumban, le mélange le plus populaire de Scrum et À la fin, vous comprendrez ce qu' Scrumban lorsqu'il est utile et la seule règle qui empêche approches hybrides de se transformer en un véritable gâchis. Commençons par un point de vue mental. Scrum et Cam Ban ne sont pas des religions. Ce sont des trousses à outils. Personne ne vous décerne une médaille pour parfaitement suivi un cadre, et personne sensé ne vous dira que votre façon de travailler est mauvaise simplement parce qu' elle contient un peu des deux. Les vraies équipes sont confrontées à des situations réelles et spécifiques, parfois purement adaptées à Scrum, parfois purement adaptées à Caban, et très souvent, la meilleure solution se situe quelque part entre les deux Le rythme de Scrum et le contrôle du flux de Camban qui se situent entre les espaces sont l'endroit où vivent les hybrides, et le plus courant porte un nom Scrumban est exactement ce à quoi ressemble Scrum plus Caban. Vous conservez une partie de la structure utile de Scrum et vous ajoutez les outils de flux de Cam Ban Dans la pratique, une équipe de Scrumban suit généralement un rythme régulier, comme un rythme de deux semaines, et organise les cérémonies utiles, comme une conversation de planification et une rétrospective Mais au lieu de s'engager un lot fixe de travail pendant deux semaines complètes, ils suivent un tableau de style Cam Ban avec des limites d'avancement, et ils ajoutent continuellement de nouvelles tâches au fur et à mesure que les capacités se libèrent Vous pouvez ainsi suivre le rythme de Scrum grâce à une planification et à une réflexion régulières, ainsi qu'à la flexibilité de Cam Ban, le flux basé sur le pull qui fait face Pour de nombreuses équipes, cette combinaison est vraiment idéale. Alors, quand Scrumban est vraiment utile, quand devriez-vous opter pour Scrumban Il existe trois situations courantes. Tout d'abord, lorsque votre équipe a besoin d'un rythme, mais que votre travail est imprévisible. Supposons, par exemple, que l'équipe de notre application d'apprentissage des langues aime se réunir toutes les deux semaines pour planifier et réfléchir, mais que la moitié de son travail consiste à corriger des bogues urgents sans préavis. Scrumban leur permet de garder le rythme bimensuel tout en gérant les interruptions grâce à un tableau basé sur le flux grâce Ensuite, lorsque vous passez de Scrum à Cam Ban, il est bouleversant de changer le couloir de travail d'une équipe pendant la nuit Scrumban est un pont doux. Vous maintenez les cérémonies habituelles tout en introduisant des limites de progression et de traction, et l'équipe s'adapte progressivement Troisièmement, lorsque l' engagement de Scrum ne cesse diminuer mais que vous ne voulez pas perdre sa structure, si vous vous entraînez à chaque sprint, mais que vous manquez la planification de la rétrospective, Scrumban vous permet de laisser tomber cet engagement rigide tout en conservant les éléments qui vous ont réellement aidés au départ Donc, au-delà du Scrumban, le Scrumban est le célèbre hybride, mais la confection Voici quelques autres ajustements judicieux que les équipes font souvent. Vous pouvez exécuter Scrum mais ajouter des limites de progression à votre tableau, afin que l'équipe termine son travail avant d'en commencer d'autres, même au cours d'un sprint Vous pouvez lancer Cam Ban mais ajouter une cadence légère et régulière, comme une courte critique tous les vendredis Les parties prenantes ont donc toujours un moment prévisible pour voir les progrès réalisés, et vous pouvez annuler des cérémonies qui ne leur valent pas la peine. Si votre enregistrement quotidien n'apporte vraiment rien à une petite équipe co-localisée qui parle déjà constamment, alors vous pouvez y aller deux fois par semaine et voir ce qui se passe. Le but est de conserver ce qui aide et de supprimer discrètement ce qui n'aide pas. Il y a donc une règle, celle de l'adapter délibérément. Cela permet de maintenir tout cela en bonne santé. Changez les choses délibérément et inspectez le résultat. Il y a une grande différence entre le tailoring et le drift. La confection est une décision consciente. Nous abandonnons l'engagement fixe parce qu'il ne cesse d'échouer, et nous vérifierons une fois par mois si le flux s'est amélioré. Drift, c'est simplement abandonner discrètement les points difficiles parce qu'ils sont mal à l'aise sans plan ni révision Ainsi, chaque fois que vous ajustez votre processus, effectuez trois choses. nom au changement, déterminez pourquoi vous le faites et fixez un moment pour regarder en arrière et demander si cela vous aide réellement. Si c'est le cas, gardez-le , sinon changez-le à nouveau. Cette habitude, le fait de changer délibérément et inspecter le résultat, c'est l'Agile lui-même. Le cadre n'est que le point de départ, mais l'agilité est l'état d'esprit. Les hybrides tels que Scrumban One sont donc un compromis. Ce n'est pas une sortie de flic. Lorsqu'elles sont faites délibérément, elles sont souvent la solution la plus honnête pour le travail réel de notre équipe. Merci de m'avoir rejoint dans cette leçon. Dans le prochain article, nous allons rassembler tout cela, et nous verrons comment choisir le bon framework pour votre propre projet. Je te verrai dans le prochain. 16. Choosing the Right Framework for Your Brief: Bon retour. Nous avons examiné Scrum chez Camban et les modèles hybrides tels que Maintenant, la question pratique, comment choisissez-vous réellement ? Dans cette leçon, je vais vous poser une courte série de questions à vous poser à propos de n'importe quel projet, puis nous les aborderons ensemble pour l'application d'apprentissage des langues pour nos enfants afin que nous puissions obtenir une véritable recommandation. Donc, tout d'abord, il n' y a pas de réponse universelle. Mettons fin à ce mythe dès le départ. Quiconque vous dit que Scrum a toujours raison ou que Cam Ban a toujours raison vous vend quelque chose Le cadre approprié dépend entièrement de votre contexte, du type de travail que vous effectuez, sa prévisibilité et des besoins de vos parties prenantes. La même équipe peut utiliser Scrum pour un projet et Cam Ban pour un autre Ainsi, au lieu de choisir un favori et de forcer votre œuvre à y correspondre, nous commençons par des questions sur l'œuvre et laissons les réponses nous indiquer le cadre approprié. Voici les quatre questions les plus importantes. Première question : votre travail est-il planifiable ou est-il motivé par des interruptions ? Pouvez-vous raisonnablement décider quelques semaines de travail à l'avance ou est-ce que des choses urgentes arrivent constamment et que tout est remanié ? Deuxième question : votre travail correspond-il à des pièces de la taille d'un sprint ? Vos tâches sont-elles d'une ampleur assez uniforme se terminent-elles en quinze jours, ou sont-elles un mélange effréné de petites et d'énormes Troisième question : vos parties prenantes ont-elles besoin de dates prévisibles ? Comptent-ils sur le fait de savoir que quelque chose arrive à un rythme fixe, ou veulent-ils simplement un flux constant de progrès ? Quatrième question : la priorité est-elle stable dans un court laps de temps ? Une fois que vous êtes d'accord sur ce qui est important cette quinzaine, est-ce que cela tient ou est-ce que cela change vraiment tous les deux ou trois jours ? Dans l'ensemble, beaucoup de choses planifiables, régulières, prévisibles et stables vous orientent vers Scrum De nombreuses interruptions , une taille mixte, un flux constant et des vous orientent vers Camban Un mix vous oriente vers le Scrumban. OK, appliquez-le à notre application d'apprentissage des langues pour nos enfants répondant à ces quatre questions. Question 1, planifiable ou axée sur les interruptions. Cette application est principalement planifiable. Nous développons des fonctionnalités telles que des quiz et des badges de progression qui peuvent nous permettre de décider à l'avance Mais il y a quelques bugs. Il y a également un petit nombre de corrections de bugs apportées par les utilisateurs en direct . C'est donc en grande partie planifiable, mais avec quelques interruptions Deuxième question : les tâches conviennent-elles à des tâches de la taille d'un sprint ? Oui, en grande partie un quiz de vocabulaire, un badge, un e-mail récapitulatif. Chacune d'elles se décompose en histoires que nous pouvons terminer en quinze jours. Troisième question : les parties prenantes ont-elles besoin de dates prévisibles ? Oui Nos parties prenantes, y compris les parents et l'ensemble de l'entreprise, apprécient l'assurance de découvrir quelque chose de nouveau à un rythme régulier priorité de la question 4 est stable en quinze jours. La plupart du temps, mais pas parfaitement, un vilain bogue affectant apprentissage de vrais enfants peut se retrouver dans la file d'attente Enfin, nous avons le verdict. Quel est donc le verdict pour notre application ? Les réponses penchent vers Scrum. Le travail est généralement de la taille d'un sprint planifiable, et les parties prenantes apprécient le rythme Mais ce flot de corrections de bogues urgentes que Scrum pur serait perturbé. La meilleure solution est donc Scrum avec une touche de discipline en matière de cam ban. Donc, bannissez Scrum Nous maintenons le rythme bimensuel, nous maintenons le planning et la rétrospective parce qu'ils conviennent au travail, et ils rassurent également les et ils Mais nous gérons un tableau avec des limites d'avancement des travaux, et nous réservons une petite capacité tous quinze jours pour les correctifs urgents qui, nous le savons, arriveront Non Faites de même pour votre propre projet. Répondez honnêtement aux quatre questions. Ne choisissez pas le framework parce que vous aimez le son ou parce que vous le préférez. Choisissez celui vers lequel les réponses pointent. Et n'oubliez pas que vous pourrez toujours l'ajuster plus tard, délibérément au fur et à mesure de votre apprentissage. Bon, maintenant, choisir un cadre n'est pas une question de mode ou de dogme Il s'agit de faire correspondre l'outil à l'œuvre qui se trouve juste devant vous. Répondez aux questions , suivez leur cours et soyez prêt à changer d'avis. Merci de m'avoir rejoint dans cette leçon. Dans la leçon suivante, vous allez mettre tout ce travail en pratique et vous allez convertir vous-même votre projet en tableau Cam Ban. Je t'y verrai. 17. : parlez de votre projet à Kanban.: Mm. Bon retour. Il s'agit d'une leçon pratique, c'est donc à votre tour de travailler. Nous allons prendre un projet qui s'est déroulé sous forme de sprints et le convertir en une planche Cam Ban fluide dans Trello Tout fonctionne sur la version gratuite de Trello. Aucune fonctionnalité payante n'est requise. OK, voici ce que tu vas faire. Reprenez votre tableau actuel, conservez les cartes que vous avez déjà écrites et restructurez les listes dans un flux Caban Ajoutez des limites de progression de travail aux colonnes actives. Réorganisez ensuite votre carnet de commandes par priorité et vérifiez que le travail peut se dérouler sans heurts de gauche à droite Ensuite, il faut fixer les limites. N'oubliez pas que la version gratuite de Trello n' appliquera pas ces listes pour vous Nous utilisons donc la convention de dénomination Changez le nom de doing en doing en wip three. Les limites sont désormais visibles par toute l'équipe. Enfin, assurez-vous également de mettre de l'ordre dans votre carnet de commandes et de faire glisser la carte la plus importante vers le haut, le reste en dessous par ordre Et puis un contrôle de santé mentale s'est fait sentir. Y a-t-il une carte transparente prête à être insérée ou prête à être utilisée ? Est-ce que quelque chose est bloqué ? Un tableau d'interdiction des caméras en bonne santé permet de travailler régulièrement vers la droite, et aucune colonne ne dépasse ses limites . quoi ressemble le bien. Lorsque vous avez fini de convertir votre tableau, vérifiez-le par rapport à ces trois éléments. Vos listes cartographient l'étape réelle au fur et à mesure que votre travail passe. Vos colonnes actives sont soumises à des limites d'avancement visibles , et votre carnet de commandes est classé par ordre de priorité, le travail le plus important figurant en haut Si les trois sont vrais, vous avez un tableau Cam Ban qui fonctionne. Bien fait. Vous avez maintenant fait passer un projet du sprint au flow et vous avez une carte Cam Bn que vous pouvez réellement exécuter. Merci de m'avoir rejoint. Dans la leçon suivante, nous nous tournerons vers les personnes qui entourent votre projet et commencerons à cartographier et à gérer vos parties prenantes. Je t'y verrai. 18. Identifying and Mapping Your Stakeholders: Bon retour. Dans cette leçon, nous allons examiner les personnes qui entourent votre projet. Chaque projet a des parties prenantes, des personnes qui sont touchées par ce que vous construisez ou qui peuvent avoir une incidence sur celui-ci, et les mener à bien fait fait souvent la différence entre un projet réussi et un projet pénible. À la fin de cette leçon, vous saurez comment identifier toutes vos parties prenantes, comment les classer en fonction de leur importance et de l'attention dont chacune a réellement besoin. Alors, qui est partie prenante ? Commençons par la définition car elle est plus large que ce que la plupart des gens pensent. Une partie prenante est toute personne qui a un intérêt dans ce que vous construisez. Ils sont affectés par le résultat ou ils peuvent le façonner, et très souvent, ce sont les deux. Certains font partie de l'équipe, personnes qui créent le produit, ainsi que de votre propriétaire de produit et de votre Scrum Master, mais la plupart sont extérieurs à celle-ci Donc, votre sponsor qui paie le travail des utilisateurs de notre application d'apprentissage des langues pour enfants, c' est-à-dire les enfants, mais aussi leurs parents et leurs professeurs. Et ceux qu'il est facile négliger sont le personnel d' assistance et les personnes chargées des questions juridiques ou de conformité dont vous n'avez de nouvelles qu'en cas de problème. Si le travail les touche, ils sont parties prenantes. Avant de pouvoir gérer les parties prenantes, vous devez savoir qui elles sont, et l'objectif est de ne laisser passer personne. pose deux questions simples Presque tout le monde se pose deux questions simples. abord, qui est concerné, qui utilise le produit, qui le paie, qui le soutient ou qui doit vivre avec le résultat. Deuxièmement, qui peut nous affecter ? Qui peut vous accélérer, vous ralentir, vous financer ou bloquer une sortie ? Ensuite, troisième invite, car ce sont elles qui vous mordront plus tard. Qui oublie facilement les parties prenantes silencieuses. Vous, les utilisateurs finaux qui assistent rarement à vos réunions, votre équipe d'assistance, cette personne chargée de la conformité qui ne dit rien pendant des mois, puis au pire moment , refuse, notez toutes ces personnes. Un nom figurant sur votre liste peut être géré. Une partie prenante que vous avez oubliée ne peut pas être gérée. Maintenant, une longue liste n'est pas un plan. Vous ne pouvez pas accorder à tout le monde la même attention, et vous ne devriez pas vraiment essayer. Nous les trions donc à l'aide d'un outil simple et très connu, le réseau électrique et d'intérêt. Imaginez un carré divisé en quatre. La verticale en tant qu'axe représente le pouvoir, l'influence de cette personne sur le projet. L' accès horizontal, c'est l'intérêt, quel point ils s'y intéressent. Cela vous donne quatre groupes, et chacun souhaite être traité différemment. En haut à droite se trouvent une puissance élevée et un intérêt élevé. Gérez ces personnes de près. Ce sont vos principaux acteurs, alors impliquez-les souvent. En haut à gauche, la puissance est élevée, mais l'intérêt est faible. Faites en sorte que ces personnes soient satisfaites. Rendez-les heureux et rassurés, mais ne les noyez pas dans des détails qu'ils ne En bas à droite, la puissance est plus faible, mais l'intérêt est élevé. Tenez-les informés. Ils s'en soucient beaucoup, alors tenez-les au courant. Et en bas à gauche se trouvent une faible puissance et un faible intérêt. Surveillez simplement ces personnes. Une touche légère suffit. Concrétisons donc tout cela avec notre application d'apprentissage des langues. Votre chef de produit a à la fois du pouvoir et un vif intérêt. Ils vont donc en haut à droite. Vous les gérez étroitement et vous les impliquez dans vos évaluations et votre plan. Le fondateur de l'entreprise contrôle le budget, mais ne le fait pas au quotidien. Ils sont donc en haut à gauche, les satisfont, mais leur épargnent les détails. Les enseignants et les parents ont peu de pouvoir formel sur votre feuille de route, mais ils s'en soucient énormément. Ils vont donc en bas à droite, les tiennent informés, et les questions juridiques et de conformité surveillent la majeure partie du projet, faible implication, mais attention, ils ne doivent jamais être surpris. Une partie prenante silencieuse peut toujours empêcher une publication. Alors, qu'est-ce que chaque groupe obtient réellement de vous ? Adaptez l'effort au quadrant et vous dépenserez votre énergie là où elle compte Gérer étroitement signifie des contacts fréquents et bidirectionnels. Ils sont présents lors des évaluations et de la planification. Pour rester satisfait, cela signifie un résumé court et régulier, ainsi qu'un avertissement anticipé avant toute décision importante. rester informé, il suffit d'une simple mise à jour qu'ils peuvent lire quand ils le souhaitent, et surtout, pas de réunions Vous informez, vous ne consultez pas, et surveiller signifie un léger toucher, un petit mot lorsque quelque chose les touche vraiment et rien d'autre. Si vous le faites bien, deux choses se produiront : les parties prenantes se sentiront bien prises en charge et vous arrêterez de consacrer des heures à des personnes qui n'en ont ni besoin ni ne veulent. Donc oui, il est très important de prendre en compte la quantité et la fréquence. Trouvez donc tout le monde, triez-les par pouvoir et intérêt et accordez à chaque groupe la bonne quantité d'attention. Cette carte est à la base de tout le reste de cette section spécifique. Merci de m'avoir rejoint. Dans la leçon suivante, nous allons prendre en compte vos principales parties prenantes et leur montrer le travail réel en effectuant une évaluation rapide qu'elles apprécient réellement. Je t'y verrai. 19. Running a Productive Sprint Review: Bon retour. Dans cette leçon, nous allons effectuer une révision du sprint, c'est-à-dire la réunion à la fin d'un sprint au cours de laquelle vous montrez vos parties prenantes ce que vous avez construit et collectez leurs commentaires. Si cela est bien fait, cela peut devenir l'une des demi-heures les plus précieuses de tout votre processus. Mais si c'est mal fait, cela devient comme une réunion ennuyeuse de mise à jour de l' état laquelle personne ne veut assister. À la fin de cette leçon, vous saurez comment effectuer une évaluation de sprint qui vous permettra de gagner confiance et de vous donner un feedback que vous pourrez utiliser. Voyons donc à quoi sert une évaluation de sprint, car c' est là que certaines personnes peuvent se tromper. La revue Sprint montre un véritable produit fonctionnel. C'est un aperçu en direct de ce qui a été construit. Ce sprint a été suivi d'une conversation honnête sur son déroulement. Ce n'est pas un diaporama, ce n'est pas une cérémonie de signature, ni une cérémonie d' approbation automatique L'ancienne expression Agile désigne le logiciel fonctionnel par rapport à une documentation complète. Et c'est dans la critique que vous êtes à la hauteur. Tu as montré le truc, pas un diaporama sur le sujet. L'important, ce sont les commentaires sur lesquels vous pouvez agir, et non les applaudissements Une bonne critique nécessite environ 10 minutes de préparation. Et il y a trois choses principales. Préparez d'abord la démo. Préparez la fonctionnalité fonctionnelle sur un appareil réel et testez d' abord le happy path vous-même afin ne pas avoir à débugger en direct devant votre sponsor Ensuite, invitez les bonnes personnes, les parties prenantes qui s'intéressent à ce travail en particulier, l'ensemble de l'entreprise. Et troisièmement, fixez-vous un objectif connaître la seule question à laquelle vous voulez le plus répondre avant que la pièce soit vide Peut-être que le nouveau quiz convient à un professeur ou quelque chose comme ça, entrer en sachant ce que vous êtes là pour apprendre. Voici donc un programme simple et rapide qui fonctionne . Il ne comporte que quatre étapes et durera environ une demi-heure au total. La première consiste à récapituler l' objectif du sprint sur une seule ligne. Qu'avons-nous prévu pour ce sprint ? deuxième consiste à faire une démonstration du travail, à le montrer en direct et, là où vous le pouvez, les laisser essayer eux-mêmes. La troisième consiste à inviter des commentaires, poser des questions ouvertes, puis à écouter bien plus que vous ne parlez. Quatrièmement, parlez brièvement des prochaines étapes. Qu'est-ce que ce que nous venons de voir signifie pour le plan, et c'est tout. Récapitulatif, démonstration, commentaires et prochaines étapes. Si vous avez pris une habitude dans cette leçon, prenez celle-ci. Démo, ne vous présentez pas. Montrez la réalité sur un appareil, n'en parlez pas sur une diapositive. Un questionnaire pratique, par exemple, sur lequel votre partie prenante peut réellement répondre vaut dix points pour le décrire à chaque fois. n'y a nulle part où se cacher dans une démo en direct, et c'est exactement le but. Cela permet à tout le monde d'être honnête quant à ce qui est réellement fait. Deux choses font qu'une démo atterrit les laisser conduire, leur remettre l'appareil et regarder où ils hésitent, là où une vraie personne fait une pause ou fronce les sourcils vaut plus que n'importe quel rapport de situation, et sauter le vernis Des rythmes rudes mais réels, lisses mais faux. Vous ne vendez pas, vous apprenez. Montrez ce qui fonctionne vraiment, quoi et ainsi lorsque le feedback arrive et il arrivera, trois habitudes le rendent utile. Tout d'abord, capturez les commentaires, ne les défendez pas, notez-les et résistez la puissante envie d' expliquer pourquoi ils se trompent. Vous leur avez demandé leur avis, alors laissez-les vous le donner. Deuxièmement, il y a les modifications de la portée du parc. Quand quelqu'un dit : « Oh, est-ce que ça pourrait aussi faire ça ? » C'est une bonne idée pour le backlog, pas une modification de ce sprint Alors prenez-en note, remerciez-les et passez à autre chose. Troisièmement, remerciez-les sincèrement. Les gens qui se présentent et prennent la parole vous rendent vraiment service même lorsque les commentaires vous font mal, surtout lorsqu'ils gèrent la pièce comme ça, et les gens repartent en se sentant écoutés, ce qui signifie qu' ils reviendront et qu'ils vous diront la vérité la prochaine fois également. Donc, une bonne évaluation de sprint est vraiment simple. Montrez du vrai travail, écoutez très bien, puis agissez en fonction de ce que vous entendez. Merci donc de m'avoir rejoint dans cette leçon. Dans le prochain article, nous verrons ce qui se passe lorsque les commentaires modifient le plan et comment intégrer l' évolution des exigences sans perdre votre concentration. Je te verrai dans le prochain. 20. Gérer les exigences changeantes: Bon retour. Dans cette leçon, nous allons aborder un problème auquel chaque projet est confronté. Les exigences changent. Une partie prenante veut quelque chose de nouveau, un utilisateur fait quelque chose auquel vous ne vous attendiez pas , alors les priorités changent. Dans un processus rigide, un tel changement est une crise, mais en mode Agile, c'est normal. Cependant, il existe une véritable capacité à absorber le changement sans votre projet ne sombre dans le chaos, et c'est cette compétence que nous allons examiner dans cette leçon Tout d'abord, un changement d'état d'esprit en mode Agile, changer d'avis est autorisé. C'est même attendu et encouragé. L'intérêt de travailler selon des cycles courts et présenter des produits réels est que vous apprenez des choses, et l'apprentissage devrait changer ce que vous ferez ensuite. L'objectif n'est donc pas de geler le plan et de le défendre. L'objectif est de modifier délibérément le plan plutôt que de paniquer chaque fois que quelqu'un vous envoie une nouvelle idée par e-mail. Accueillir le changement et perdre le contrôle ne sont pas la même chose, et cette leçon porte sur cette différence essentielle. Il est donc utile de savoir d'où vient le changement car aucune de ces sources n'est un échec de votre part. C'est juste la réalité. Les parties prenantes changent d' avis une fois qu'elles ont vu le travail. Souvent, ils ne découvrent ce qu'ils veulent réellement qu'en regardant ce qu'ils ont. Les vrais utilisateurs se comportent différemment ce que vous aviez imaginé Le marché évolue, un concurrent expédie autre chose, une règle change, une priorité passe au-dessus de vous et votre propre équipe apprend au fur et à mesure qu'elle construit, et le dernier point important. L' information n'est pas un bogue dans votre plan. C'est la raison pour laquelle vous planifiez en cycles courts en premier lieu. Alors, où devraient se retrouver tous ces changements dans votre carnet Imaginez le backlog comme l'amortisseur qui empêche chaque nouvelle demande de bouleverser l'ensemble du projet Donc trois étapes. Tout d'abord, capturez-le calmement. Une nouvelle demande devient une note dans le backlog, non un tour de main instantané Deuxièmement, n'agissez pas par réflexe. Presque rien ne doit changer à cette seconde. Laissez la poussière retomber avant de vous déplacer. Troisièmement, laissez le propriétaire du produit redéfinir ses priorités. Le propriétaire du produit ou le bon de commande évalue la nouvelle demande rapport à toutes les autres attente et décide où elle se situe réellement. C'est leur travail, et cela empêche l'équipe de se faire bousculer par celui qui a crié quelque chose le plus récemment façon dont vous absorbez un changement dépend donc un peu du cadre que vous utilisez, et nous avons abordé ces deux points plus tôt dans ce cours. Ainsi, dans Scrum, vous protégez le sprint en cours. De nouveaux travaux seront attendus lors de la prochaine session de planification. L'engagement d'aujourd'hui reste intact, afin que l'équipe puisse réellement terminer ce qu'elle a commencé. Dans Cam Ban, il n'y a aucun sprint à protéger, vous suffit donc de réorganiser la file d'attente Vous pouvez attribuer le nouveau travail à la bonne priorité et respecter vos limites d' avancement, qui sont les limites de progression pouvant être effectuées simultanément. Les outils sont différents, mais le principe est identique. Le changement est géré délibérément à un moment raisonnable, non en abandonnant tout dès qu'une nouvelle demande arrive. Voici une seule phrase qui vous permettra d'économiser plus de projets que presque toute autre chose. Dites oui au quoi et négociez le quand. Dites oui à l'idée, puis soyez honnête quant au compromis. Donc, au lieu d'un non catégorique ou d'un oui imprudent qui ruinerait discrètement votre plan, vous dites quelque chose comme « oui, nous pouvons ajouter le tableau de bord parent », et voici ce qui se déplace vers le bas de la liste pour faire de la place à cela Vous ne refusez pas le changement. Vous en rendez le coût visible et vous laissez les parties prenantes vous aider à choisir. Neuf fois sur dix, une fois qu'ils ont compris le compromis, ils prennent une décision sensée, et c'est désormais leur décision plutôt qu'une dispute. Restez flexible sans dériver, quelques rambardes peuvent vous aider Gardez un ordre de priorité clair, un seul carnet de commandes classé, afin que le mot important ait toujours un sens Conservez une définition de « fait » valable. Vos normes de qualité ne peuvent pas changer simplement parce qu'elles sont plantées. Gérez les modifications lors de la révision par défaut, répartissez les commentaires à un moment donné, plutôt que de les laisser arriver sous forme de flux constant d' interruptions et de refuser le placage à l'or Dites non aux belles choses que personne n' a demandées concentration n'est pas quelque chose que vous avez, c'est quelque chose que vous choisissez encore et encore. Le changement ne constitue donc pas une menace pour un bon projet Agile. C'est en fait le carburant. La compétence consiste à absorber volontairement ces changements en le carnet de commandes au bon moment. Merci de m'avoir rejoint. Dans la leçon suivante, nous examinerons les mises à jour du statut et la manière de tenir vos parties prenantes informées sans faire perdre de temps à personne. Je t'y verrai. 21. Des mises à jour qui respectent votre temps.: Bon retour. Dans cette leçon, nous allons voir comment rédiger des mises à jour de statut que les utilisateurs lisent réellement. La plupart des mises à jour sont donc bien trop longues trop vagues ou ignorées, mais les vôtres n'ont pas à l'être. À la fin de cette leçon, vous disposerez d'une structure simple que vous pourrez réutiliser chaque semaine, et vous saurez également à quel moment une mise à jour de statut nécessite une réunion et quand elle ne nécessite qu'une simple note écrite. Commençons par expliquer pourquoi tant de mises à jour échouent, car si vous évitez ces quatre pièges, vous le ferez correctement. Tout d'abord, ils sont trop longs, un mur de texte que personne ne termine, où la seule ligne importante se noie dans les détails. Deuxièmement, ils sont trop vagues. Réaliser de bons progrès ne dit absolument rien à une partie prenante. Troisièmement, ils n'ont pas de demande claire. Si tu as besoin d'une décision, dis-le. Et si ce n'est pas le cas, demandez-vous pourquoi cette personne le lit. Et quatrièmement, ce n'est pas le bon public. Des détails techniques approfondis ont été envoyés à un sponsor qui ne veut que le titre Si vous corrigez ces quatre points, vous êtes déjà en avance sur la plupart des équipes. Voici donc la structure. Tout ce qui est important se trouve sous trois titres, et ils commencent tous par P, donc c'est plus facile à retenir. Progrès, planification et problèmes. Progrès. Ce qui a réellement été fait depuis la dernière fois, terminer les choses, pas les choses en cours. Planifiez ce que vous allez faire ensuite et indiquez approximativement à quel moment ils verront le problème, ce qui est bloqué ou ce qui nécessite une décision précise par une demande claire. Et c'est le modèle complet. Si quelque chose ne correspond pas au plan de progression ou s' il présente des problèmes, il n'a probablement pas sa place dans la mise à jour du statut. Voici donc un modèle que vous pouvez réutiliser, et remplissons-le pour notre application d'apprentissage des langues afin que vous puissiez voir à quel point une mise à jour de statut peut être courte. En cours, le quiz sur les animaux a été expédié et badges de progression sont désormais disponibles pour 40 % des utilisateurs. Planifiez, l'e-mail de synthèse pour les parents est le prochain, et nous ferons une démonstration lors de l'examen de vendredi. Problèmes, il y a un bogue audio dans la leçon de chiffres, et nous devons décider si cela retarde la sortie. Il s'agit d'une mise à jour complète et utile en trois lignes. n'y a rien à ajouter, et la seule chose dont vous avez besoin de la part du lecteur, il est impossible de passer à côté d' une décision La plupart des mises à jour ne nécessitent pas de réunion. Donc, l'une des décisions que vous devez prendre est de savoir comment l'envoyer. La réponse honnête est que la plupart des mises à jour ne nécessitent aucune réunion, car votre valeur par défaut doit être écrite et asynchrone ou asynchrone, ce qui signifie simplement que les utilisateurs les lisent à leur rythme plutôt que de les rassembler en même temps agit donc d'une courte note qui arrive dans une boîte de réception ou une page partagée, et qui couvre la grande majorité des mises Une réunion ne vaut la peine d'être réservée que lorsque vous avez besoin d'une discussion ou d'une décision, ce que on ne peut pas très bien gérer par écrit. En règle générale, une réunion dont le but est uniquement de partager des informations est généralement un e-mail envoyé au-dessus de son poste, informant de la rédaction et de la réunion pour prendre des décisions. Vous avez donc trois rubriques, les progrès, plan et les problèmes, abrégés et envoyés via le canal le plus récent qui fait le travail Merci donc de m'avoir rejoint. Dans la leçon suivante, c'est votre tour. Nous rédigerons ensemble une véritable mise à jour des parties prenantes pour votre propre projet, et nous la documenterons dans Notion. Je t'y verrai. 22. Pratique : Rédiger une mise à jour concernant les parties prenantes: Bon retour. Dans cette leçon pratique, vous allez effectuer le travail. Nous allons rédiger une véritable mise à jour sur les parties prenantes de votre projet en utilisant la structure en trois parties de la dernière fois. Je vais vous montrer sur un écran dans Notion First, puis vous pourrez mettre la vidéo en pause et écrire la vôtre. Commençons donc. Voici donc l'exercice en quatre étapes. Choisissez le public, choisissez une seule partie prenante ou un groupe dans votre carte des parties prenantes et écrivez spécialement pour eux. Deuxièmement, utilisez les trois parties, progrès, le plan et les problèmes, et rien d'autre. Troisièmement, soyez bref et doux. S'il ne tient pas bien sur l'écran d'un téléphone, c'est probablement trop long. Et quatrièmement, l'étape la plus importante, c'est de l'envoyer. L'envoi d'une mise à jour de vos brouillons ne vaut rien. L'écrire est donc une pratique. C'est le travail de l'envoyer. Jetons donc un coup d'œil à notre page Notion. Nous avons d'avant la page de mise à jour des parties prenantes. Je vais ouvrir cette page ici, et je vais vous montrer le rapport d'état que j'ai ajouté ici pour le premier sprint. J'ai ajouté la date du 22 mai 2026 un vendredi, généralement une bonne journée pour faire un rapport de situation Et le public est le responsable du produit, ce que j'ai ajouté ici dans cette chronique envoyée à. Et si nous ouvrons cette page, regardez le titre du rapport d'état de Sprint One avec toutes les informations importantes en haut. Et dans le corps, nous avons la date, 22 mai 2026, le rapport d' étape avec les progrès réalisés avec deux puces, plan avec deux balles et les problèmes avec deux Et c'est aussi simple que cela. Maintenant, évidemment, c'est le rapport de situation qui a été rédigé. Maintenant, nous devons envoyer. Si vous cliquez sur Partager en haut de la page, si vos parties prenantes utilisent Notion, elles ont des comptes Notion, vous pouvez l'envoyer à leur compte Notion via ce champ ou vous pouvez copier le lien et vous pouvez simplement leur envoyer le lien directement. Et tout cela est disponible dans le plan gratuit de Notion. Vous n'avez pas besoin d'abonnement payant pour cela. Donc c'est à peu près tout. Donc oui, le plus important est que vous envoyiez la page gratuite que vous avez ajoutée dans Notion. Vous pouvez donc suspendre la vidéo et écrire dès maintenant votre propre page pour l'une de vos parties prenantes. Lorsque vous avez terminé, vérifiez qu'il tient sur un seul écran, qu' il est suffisamment court pour être lu en moins d'une minute et que chaque ligne mérite sa place, donc qu' il n'y ait pas de remplissage, et si une ligne renseigne ou demande quoi que ce soit , supprimez-la La demande est évidente. Si vous avez besoin de quelque chose, il est impossible de le rater, et cela convient au lecteur qui s'intéresse réellement à ce public en particulier, non à tout ce que vous savez Toutes les quatre sont vraies, alors vous avez écrit une mise à jour que les gens liront réellement. Une dernière remarque : la partie la plus difficile de la communication avec les parties prenantes n'est pas vraiment la rédaction. C'est l'habitude. Une mise à jour courte et honnête envoyée chaque semaine crée régulièrement plus de confiance qu' un beau rapport n'en envoie une fois par trimestre. Gardez donc la même structure à chaque fois, et cela deviendra un travail de cinq minutes que vous continuerez à faire Vous transmettrez une attitude de compétence et de proactivité en le faisant chaque semaine, et cela montre une bonne discipline dans la gestion de projet C'est donc la fin de cette leçon. Bravo pour cet exercice d'entraînement. Ensuite, nous devons mesurer ce qui compte le plus, à savoir les indicateurs. Donc, les chiffres qui comptent. Bravo d'avoir atteint la fin de cette leçon. Merci de vous joindre à moi, je vous verrai dans le prochain. 23. et graphiques d’épuisement expliqués: Bon retour. Dans cette leçon, nous allons examiner deux graphiques de progression les plus courants dans Agile, le graphique de combustion et le graphique de combustion Les deux regroupent une pile de travail désordonnée en une seule ligne que vous pouvez lire en quelques secondes. À la fin de cette leçon, vous saurez comment lire chacune d'entre elles , ce que la forme de la ligne indique et quel graphique choisir en fonction de la personne qui les regarde. Alors, pourquoi suivre visuellement les progrès ? Tout d'abord, pourquoi s'embêter ? Parce qu'une photo vaut mieux qu'une réunion de suivi. Un coup d'œil à un bon graphique devrait vous indiquer si le sprint est sur la bonne voie, et cela remplace discrètement 100 messages indiquant comment ça se passe. Il y a donc deux choses qui font que ces graphiques valent un très petit effort. Ils sont rapides. Une courbe de tendance vous indique en quelques secondes quel est l'état de mise à jour d'un paragraphe toute honnêteté, la ligne ne tourne pas. Il montre le vrai travail, qu' il s'agisse d'une lecture confortable ou non. Voici donc le graphique de burndown. Commençons par celui-ci. L'idée est dans le nom. Le travail s'épuise à mesure qu'il approche de zéro. L'axe vertical représente le travail restant, généralement exprimé en points narratifs ou en nombre de tâches, et l'axe horizontal représente le temps, c' est-à-dire les jours restants de votre sprint. Au début, il reste tout le travail La ligne commence donc en haut sur la gauche. Au fur et à mesure que l'équipe termine les choses, la ligne baisse. Si tout est fait, il atteindra zéro le dernier jour. Le tableau de bord est votre idéal, une course en ligne droite de tout le travail à zéro au rythme dont vous avez besoin pour terminer exactement à temps. Et la ligne continue est exactement ce qui s'est passé. L'ensemble de la compétence consiste à lire l'écart entre les deux Voyons donc comment nous interprétons un graphique de burn-down Alors, que vous dit exactement cette ligne ? Il y a quatre formes à reconnaître. Si la limite réelle correspond à l'idéal, alors vous respectez à peu près le calendrier. Tu peux continuer. S'il reste au-dessus de l'idéal, il reste plus de travail que prévu et vous êtes donc en retard. Si ce n'est pas l'idéal, c'est que vous êtes en avance sur le planning, ou tout aussi probablement que vous avez planifié et que vous ne vous êtes pas engagé à travailler suffisamment. Et celle à surveiller, qui est une ligne plate où la ligne cesse de descendre pendant un jour ou deux. Cela signifie que rien n'est terminé , que quelque chose est bloqué, que ce qui vaut la peine d'être demandé, vaut la peine de le demander lors du prochain stand up. Maintenant, le graphique de combustion montre la même progression, mais dans l'autre sens. Ainsi, au lieu d'un compte à rebours, le travail terminé augmente. La ligne continue ascendante représente le travail que vous avez terminé, en partant de zéro, et il y a une deuxième ligne au-dessus, qui représente l'étendue totale, la quantité totale de travail que vous souhaitez accomplir. progression est le rétrécissement de l'écart entre la ligne de montée et la ligne supérieure. Lorsque la ligne terminée rencontre la ligne de portée, vous avez terminé. L'un des grands atouts du Burnup Chart est donc du Burnup Chart est La première ligne peut sembler un petit ajout, mais c'est le super pouvoir du burnup, car elle vous indique quand les poteaux Voici la différence. Lors du burndown, si quelqu'un ajoute du travail au milieu du sprint, la ligne s'abaisse ou s' aplatit et vous ne comprenez pas aplatit et vous ne comprenez Les modifications de portée dans cette instance sont masquées. Lors d'une combustion, lorsque la lunette s'agrandit, la ligne supérieure saute visiblement Le changement est là, c' honnête et évident pour tout le C'est exactement pourquoi de nombreuses équipes préfèrent le burnup lorsqu'elles discutent avec les parties prenantes Si le délai est dépassé parce que quelqu' un n'arrêtait pas d'ajouter des demandes, le graphique montre que ce n'est pas l'équipe qui a pris du retard J'ai été la cible qui s'est déplacée. La photo a la conversation qu'il vous faut. Alors, lequel devriez-vous utiliser et quand ? Honnêtement, les deux sont très utiles il suffit de les choisir en fonction de votre public. Vous pouvez donc vous concentrer sur le burndown sein de l'équipe, car il s'agit d'un simple contrôle quotidien Sommes-nous sur le point de terminer le sprint et d'aborder ensuite le sujet avec les parties prenantes, car cela montre à la fois les progrès et la portée, ce qui signifie beaucoup moins de surprises gênantes quant à la raison pour laquelle une date a été Mais le vrai problème est le suivant : l' un ou l'autre graphique ne vaut aucun graphique. Une ligne de tendance visible fait passer la conversation d' opinions à des preuves Il suffit donc d'en utiliser un. Ainsi, le burndown compte le travail à la baisse, le fait monter, et c'est la forme de la ligne qui parle Merci de m'avoir rejoint dans cette leçon. Dans la prochaine section, nous examinerons deux indicateurs clés pour le travail basé sur le flux, le diagramme de flux cumulé et le délai de livraison. Je t'y verrai. 24. Flux cumulé et temps de réalisation.: Bon retour. Dans cette leçon, nous allons mesurer un système Cam Ban. Cam Ban n'a donc pas de sprints, donc les diagrammes de burndown et de burnup ne correspondent pas tout à fait ici Nous surveillons donc plutôt le flux de travail. Nous aborderons deux outils qui font la majeure partie du travail, le diagramme de flux cumulatif et le délai de livraison. À la fin, vous serez en mesure de repérer un goulot d'étranglement en un coup d'œil et de dire, honnêtement, combien de temps prend réellement votre travail Donc deux bilans de santé de Caban. Comme Caban n'a pas de limite de sprint, il mesure plutôt le flux, est-à-dire la fluidité du travail sur tous les plans, de gauche à droite Deux outils supportent la majeure partie de la charge. Le premier est le diagramme des flux cumulatifs qui montre que le travail s'accumule ou se déplace sans problème à tous les niveaux Le second est le délai de livraison, qui indique le temps réellement nécessaire pour être effectué. Ensemble, ils répondent aux deux questions les plus importantes dans le cadre d'un travail basé sur les flux. Est-ce que quelque chose est bloqué et combien de temps cela prend-il ? Jetons donc un coup d'œil au diagramme de flux cumulé, également connu sous le nom de CFD, qui signifie diagramme de flux cumulé Cela semble un peu compliqué au début, mais l'idée est assez simple. Le temps passe en bas, et sur le côté se trouve le nombre de cartes. Et chaque bande colorée est une scène de votre plateau, et elles sont toutes empilées les unes sur les autres La bande du bas est terminée, il ne vous reste plus qu'à le faire en haut. Chaque jour, vous comptez le nombre de cartes qu'il y a dans chaque étape, et cela définit la hauteur de chaque bande. Ainsi, dans son ensemble, vous pouvez voir votre travail se déplacer vers le haut et vers le haut. De nouvelles cartes rejoignent le groupe de choses à faire en haut, puis elles redescendent à travers le cours jusqu'à Dunn au fur et à mesure qu'elles ont terminé Dans un système de bandes à cames sain, les bandes s'assemblent en bandes à peu près parallèles. C'est lorsque les bandes cessent d'être parallèles que vous apprenez réellement quelque chose. Voici comment lire la forme de ces bracelets. Les bandes parallèles signifient que tout croît de manière uniforme, et cela signifie que le flux de travail sain et régulier entre et sort à un rythme similaire. Une bande qui s'élargit soudainement est votre signe d'avertissement. Cela montre un goulot d'étranglement : le travail s'accumule en une étape plus vite qu'il n' Si dans le groupe de progression des ballons, vous avez commencé le formulaire bien plus que vous n'en avez terminé Une bande plate en forme de dôme en bas est la pire de toutes. Rien n'est réellement en cours d'achèvement. Et un toit plat sur lequel aucun nouveau travail arrive est généralement acceptable , même si cela indique parfois que votre carnet de travail est épuisé. Examinons maintenant le délai de livraison et le temps de cycle, qui constituent le deuxième outil. Ils sont faciles à mélanger, alors repérons-les à l'aide du tableau. délai correspond donc à l' ensemble du trajet entre le moment où une demande arrive dans votre carnet de commandes et le moment où elle est traitée. C'est l'horloge que le client ressent, car elle démarre dès qu'il le demande, et le temps de cycle est plus court. C'est l'horloge qui commence lorsque l'équipe commence réellement à travailler sur la carte en cours, et elle court jusqu'à ce que tout soit terminé. Le délai correspond à ce que ressentent vos parties prenantes et le temps de cycle correspond à la vitesse de travail de l'équipe une fois qu'elle le temps de cycle correspond a choisi quelque chose. Si vos cartes restent en attente pendant des semaines avant que quelqu'un ne commence à les recevoir, votre durée de cycle peut sembler excellente alors que votre délai de livraison est nul, mais seul le client s'en apercevra Alors, qu'est-ce que le délai vous indique ? Le délai de livraison est un chiffre unique, mais il est conservé de différentes manières. Le premier est la prévisibilité. Une fois que votre délai est stable, vous pouvez faire des promesses honnêtes, comme la plupart des demandes sont traitées dans un délai de deux semaines. Le deuxième est l'alerte précoce. Si le délai commence à s' allonger, c'est que quelque chose obstrue le flux, et vous le verrez souvent ici avant qu' il n' apparaisse ailleurs Et troisièmement, il y a les prévisions. Vos délais antérieurs sont le meilleur indicateur dont vous disposez pour savoir quand un nouveau travail sera terminé de manière réaliste Il est donc impossible de deviner ce qui a tendance à se produire dans ces cas Ainsi, le diagramme de flux cumulatif vous indique où le travail est bloqué, et le délai vous indique le temps que cela prend réellement. Maintenant, ces deux éléments transforment un forum occupé en quelque chose lequel vous pouvez réellement raisonner. C'est donc la fin. Merci de m'avoir rejoint dans cette leçon. Dans la prochaine, nous allons prendre recul et poser une question plus large. Mesurons-nous la quantité que nous produisons ou la différence que cela fait réellement ? Je vous verrai lors de la prochaine leçon. 25. Mesures de résultats vs mesures de sortie: Bon retour. Dans cette leçon, nous allons prendre la décision la plus importante en matière de mesure, à savoir la différence entre le résultat et le résultat. C'est la différence entre être occupée et avoir de la valeur, et en se trompant, les équipes finissent par travailler d'arrache-pied alors que rien de ce qui compte ne s'améliore. À la fin de cette leçon, vous serez capable de différencier les deux et de les associer manière à ce que vos chiffres indiquent réellement une valeur. distinction la plus importante dans cette section est donc que le résultat est ce que vous produisez, et le résultat est la différence qu'il fait. Le résultat, c'est ce que vous expédiez , comme les fonctionnalités, les tickets, story points, et le résultat, c'est ce qui change dans le monde réel grâce à cela. Les gens apprennent davantage, reviennent plus souvent, payent avec bonheur. Et la triste vérité, c'est que vous pouvez expédier de nombreuses offres sans rien changer qui compte. Beaucoup de résultats sans résultat. Le but de cette leçon est de séparer ces deux idées . Examinons donc d'abord les indicateurs de sortie. Ils mesurent votre activité, la quantité de travail produite par l'équipe. Elles sont très utiles, mais elles sont légèrement limitées. Velocity est un classique. C'est le nombre de points d'histoire qu'une équipe termine par sprint, et c'est une mesure du rendement Les fonctionnalités expédiées comptent le nombre d'articles que vous avez publiés et le nombre de tickets fermés, ainsi que le volume de travail. C'est ce qu'ils ont tous en commun. Ils vous disent que l'équipe était occupée, mais ils ne vous disent pas si tout cela a vraiment aidé. Alors produisez des réponses, avons-nous construit des choses ? Non, ils avaient de l'importance. Passons maintenant aux indicateurs de résultats, qui constituent l'autre moitié, et c'est là que réside la valeur réelle. Ils sont plus difficiles à mesurer, mais ils ont bien plus de valeur. Ainsi, pour notre application d'apprentissage des langues pour enfants, les indicateurs de résultats pourraient être moins complets. Les apprenants terminent-ils réellement les leçons qu' ils commencent, les apprenants actifs chaque semaine ou les personnes qui reviennent semaine après ou sont-ils en train de s'éloigner Ou la satisfaction des parents. Les personnes qui payent pensent-elles que cela en vaut la peine ? Aujourd'hui, ils sont plus difficiles à déplacer et à falsifier car ils permettent de déterminer si le produit fait son travail ou non. Le résultat répond donc à la question qui compte en fin de compte. Cela vous a-t-il aidé ? Maintenant, c'est le piège, car il est facile de tomber dans ce piège. Lorsque vous ne mesurez que le résultat, vous commencez à l'optimiser et vous pouvez être très occupé à ne rien faire. Imaginez donc la revue trimestrielle. Par exemple, nous avons livré dix nouvelles fonctionnalités ce trimestre. Tout le monde hoche la tête et l' équipe semble productive, mais aucune de ces fonctionnalités n' a été reportée avant d'être terminée Cela représente donc beaucoup de mouvement sans aucun progrès. Les fonctionnalités étaient réelles, mais la valeur ne l'était pas. Donc, deux habitudes pour vous tenir à l' écart de ce piège, la solution consiste à associer chaque indicateur de sortie à un résultat qu'il est censé déplacer, de sorte que l'expédition ait toujours un objectif au-delà de l' expédition et du test. Pour chaque chiffre que vous suivez, demandez s'il a augmenté et si rien ne s'est réellement amélioré, pourquoi est-ce que je le mesure ? La solution n'est donc pas de rejeter les indicateurs de sortie. Velocity et le reste sont vraiment utiles pour diriger une équipe. La réponse est d'associer chacune d'elles au résultat qu'elle est censée servir. Les fonctionnalités expédiées doivent servir à compléter les leçons. Velocity doit proposer des dates de livraison prévisibles. Les bogues corrigés devraient servir votre note sur l'App Store et la confiance qui en découle. Le contenu ajouté doit être destiné aux apprenants actifs chaque semaine. Vous les suivez donc côte à côte, et dès que le résultat augmente alors que le résultat reste inchangé, vous vous surprenez à être occupé au lieu d'être utile, ce qui est exactement l' avertissement que vous souhaitez résultats sont donc ce que vous faites, et les résultats sont ce à quoi ils servent, et les équipes les plus saines gardent ces deux points à l'esprit Merci de m'avoir rejoint dans cette leçon. Dans le prochain article, nous verrons comment même de bons indicateurs peuvent être réutilisés et ce que vous devez faire attention à ne jamais mesurer Je te verrai dans le prochain. 26. Éviter les mauvais usage des mesures - Ce qu'il ne faut pas mesurer: Bon retour. Il s'agit d'une leçon courte mais importante car une métrique peut être une arme à double tranchant. Nous allons examiner comment les bons chiffres se transforment en mauvais chiffres et les éléments spécifiques que vous devez veiller à ne pas mesurer, ainsi qu'une manière plus saine de conserver les indicateurs afin qu'ils aident votre équipe au lieu de lui faire du mal Commençons donc. Commencez donc par une loi des métriques qui vaut la peine d'être mémorisée C'est ce qu'on appelle la loi de Goodhart, et elle stipule que lorsqu'une mesure devient une cible, elle cesse d'être une bonne mesure Donc, en termes clairs, dès que vous transformez un chiffre en un objectif pour lequel les gens sont récompensés ou punis, ils commencent à jouer le numéro au lieu de faire le vrai travail qui le sous-tend. La mesure était donc utile précisément parce que personne n' essayait de la déplacer directement. Si vous faites de cette métrique une cible, vous dépassez exactement ce qui en valait la peine au départ. Voici donc quatre manières courantes dont les indicateurs peuvent mal tourner, afin que vous puissiez les détecter. Le premier est la vélocité en tant que cible. Si vous vous fixez un objectif de points d'histoire et que les estimations augmentent rapidement, les points augmentent, mais pas le travail réel Viennent ensuite les résultats individuels, mesurent les personnes plutôt que les équipes, ce qui met fin à la collaboration de manière fiable, car aider un collègue vous coûte désormais de l'argent sur votre propre tableau de bord. Indicateurs de vanité sont des chiffres qui ont l'air magnifiques et qui ne signifient rien de tel que téléchargements d' applications au lieu de savoir si quelqu'un les utilise réellement. Et enfin, ses indicateurs militarisés. Les chiffres blâmaient donc les gens, qui enseignent simplement à tout le monde à cacher les problèmes plutôt que de les faire apparaître et de les résoudre. L'important est donc de mesurer l' équipe, pas la personne. L'un des moyens les plus rapides de mesurer une équipe est de mesurer un individu plutôt que l'équipe. Les métriques agiles sont conçues pour décrire le système d'une équipe, et non la valeur d'un individu. La vélocité, le délai, le débit cumulé décrivent le fonctionnement du flux, et non les efforts déployés par quelqu'un cette semaine. Le moment est une métrique utilisée pour classer les gens les uns par rapport aux autres. Cela cesse de dire la vérité parce que chacun commence à optimiser pour son propre chiffre au lieu d'optimiser pour le résultat partagé. Vous mesurez donc le système et soutenez les individus. Alors, comment utilisez-vous bien les mêmes chiffres ? Il y a trois changements d'esprit. Utilisez-les pour apprendre, pas pour juger. Demandez-vous ce que les chiffres vous enseignent, non qui en est responsable. Nous observons les tendances, pas les instantanés. Un seul point de données est un bruit, et la direction prise sur plusieurs semaines constitue le véritable signal, et considérez une métrique comme une question et non comme un verdict. Un nombre surprenant devrait démarrer une conversation non la terminer. Mêmes données, effet complètement différent sur votre équipe. Les indicateurs peuvent donc vous guider, mais lorsqu'ils sont manipulés de manière imprudente, ils peuvent vous induire en erreur et nuire à l'équipe Il faut donc qu'ils pointent du doigt le système et ils restent curieux au lieu de les accuser. Merci de m'avoir rejoint dans cette leçon. Dans le suivant, c'est ton tour. Nous allons créer un tableau de bord simple pour créer des métriques pour votre projet dans Notion. Je t'y verrai. 27. : créer un tableau de bord des métriques: Bon retour. Dans cette leçon pratique, vous allez créer votre propre base de données de métriques dans Notion. Nous allons donc l'assembler pour votre projet. Je vais en créer un à l'écran, puis vous pourrez faire une pause et en créer un vous-même. Donc, comme toujours, Notion est gratuit, fonctionne dans votre navigateur, et tout fonctionne aujourd'hui sur le plan gratuit sans aucun ajout requis. Alors allons-y. Voici l'exercice en quatre étapes. Premièrement, choisissez trois ou quatre indicateurs, une combinaison délibérée de résultats et de résultats, et résistez à l' envie de tout suivre. Deux, pour chacun, dites à quoi ça sert. Il est là pour répondre à cette question. Troisièmement, créez une page, qui n'est qu'un simple tableau, et quatrièmement, l'étape qui compte vraiment est de la mettre à jour chaque semaine. Un tableau de bord que personne ne met à jour n' est qu'une décoration. Donc, une petite note sur le choix de vos indicateurs. Choisissons un équilibre configuré pour notre application d'apprentissage des langues afin que vous puissiez voir le mix. La vélocité, qui est une métrique de sortie, répond à la question suivante : livrons-nous à un rythme soutenu ? L'achèvement des leçons, qui est un résultat, les réponses sont les apprenants qui terminent ce qu'ils ont commencé avec des apprenants actifs chaque semaine, un autre résultat, les réponses sont les personnes qui reviennent. Ensuite, le nombre de bogues ouverts, qui est une réponse en sortie, indique que la qualité est contrôlée. Donc non, il s'agit de trouver le juste équilibre entre deux chiffres sur ce que nous faisons et deux sur le fait que cela fonctionne. Quatre indicateurs, c'est suffisant. Ainsi, un tableau de bord que vous garderez vaut mieux qu' un beau tableau de bord que vous abandonnez. Alors, restez simple. OK, donc construisez-le dans Notion. Vous pouvez le créer dans votre compte gratuit en suivant les étapes suivantes. Vous allez donc ajouter un tableau avec les colonnes correspondant à la métrique de cette semaine, la semaine dernière et à la tendance, puis vous aurez une ligne par métrique dans le tableau. Ensuite, dans la dernière, nous aurons la flèche de tendance, qu'elle soit vers le haut, vers le bas ou plate, et c'est la flèche de tendance la plus rapide de la page. D'accord ? Voyons donc à quoi cela ressemblera dans Notion. J'ai ajouté une nouvelle page en bas intitulée Tableau de bord des métriques, puis j'ai ajouté un nouveau tableau à l'intérieur . Dans celui-ci, nous n'allons pas utiliser de base de données. Nous allons juste utiliser une table normale. Et j'ai les quatre titres des colonnes en haut, les statistiques de cette semaine, semaine dernière et les tendances. J'ai la vélocité, qui montre une augmentation par rapport à la semaine dernière. J'ai constaté une augmentation du pourcentage d' achèvement des leçons. Encore une fois, en utilisant la flèche vers le haut. nombre hebdomadaire d'apprenants actifs a augmenté cette semaine par rapport à la semaine dernière Il y a donc une autre flèche vers le haut. Enfin, nous avons des bugs ouverts, sept cette semaine, neuf la semaine dernière, donc la tendance est à la baisse. C'est un tableau de bord de mesures plutôt positif, je dois dire que tout se passe très bien dans ce projet. Revenons-en à l'émission. Maintenant, vous pouvez mettre la vidéo en pause et créer la vôtre. Lorsque c'est fait, vérifiez-le par rapport à ces quatre éléments. Nous avons donc quelques indicateurs bien choisis, trois ou quatre auxquels vous faites confiance, que 20 que vous ignorez. Vous avez un mélange de résultats et de résultats, non seulement ce que vous avez fait, mais aussi la question de savoir si cela vous a réellement aidé. La troisième est que chaque métrique a un objectif. Si vous ne pouvez pas dire à quoi il sert, supprimez-le. Et le dernier, c'est qu' il a vraiment suivi le rythme. Les chiffres sont donc mis à jour selon un calendrier que vous respecterez de manière réaliste. Si vous répondez à ces quatre critères, vous obtenez un tableau de bord qui fera vous un excellent décideur. C'est tellement bien fait. Vous pouvez désormais suivre progression grâce au burndown et au burnup Vous pouvez lire un système Cam Band avec le débit et le délai cumulés, différencier le résultat du résultat, éviter les pièges courants et regrouper le tout dans un tableau de bord simple. C'est tellement bon travail. Merci de m'avoir rejoint. Dans la section suivante, nous allons résumer l'ensemble du cours intermédiaire d'Agile, et nous allons rassembler ces thèmes . Je t'y verrai. 28. Pièges intermédiaires courants: M C'est donc une étape dangereuse. Tu en sais juste assez. Voici donc le truc à propos de cette étape. Les bases de l'Agile sont faciles à apprendre et, malheureusement, faciles à falsifier. Vous pouvez parfaitement organiser chaque cérémonie, vous rendre à chaque réunion, remplir tous les tableaux, tout passant complètement à côté de l'essentiel. C'est donc le piège intermédiaire. Effectuez les mouvements parfaitement pendant que la valeur s'échappe silencieusement Alors que nous traversons ces écueils, remarquons que presque aucun d' entre eux ne consiste à faire le mauvais choix. Il s'agit de faire le bon choix, mais pour la mauvaise raison ou pour une raison complètement oubliée. Commencez donc par le processus lui-même. Le rituel peut survivre de quatre manières, mais le but est mort. Les premières sont des cérémonies de culte du cargo, où les réunions sont organisées par cœur, où l' on passe en revue la chorégraphie sans vraiment savoir à quoi sert chacune Ensuite, il y a le stand up avec les zombies, un rapport de situation quotidien remis au manager au lieu que l' équipe se synchronise réellement les unes avec les autres Des sprints qui sont secrètement des mini-cascades. Donc, une semaine de design, puis une semaine de construction, puis une semaine de test, selon l'ancien processus séquentiel port d'un costume Agile Enfin, une définition du terme «   fait » qui s'adapte discrètement à fait » signifie à peu près la même chose chaque fois qu' une date limite approche. Dans chaque cas, la forme est bonne, mais la substance a disparu. Ensuite, il y a les pièges liés aux personnes. Ce sont les défaillances les plus subtiles et les plus coûteuses. Le preneur de commande PO, le Product Owner , qui se contente relayer ce qui est demandé au lieu de les prioriser, afin que le backlog soit le reflet des demandes préférées de chacun Ensuite, il y a la culture du héros où une personne sauve chaque sprint à la dernière minute, ce qui semble impressionnant mais qui est en fait extrêmement fragile car le jour congé, tout est terminé. La partie prenante oubliée est la personne silencieuse que vous n'avez jamais cartographiée, qui fait surface au pire moment pour vous bloquer, puis qui vous fait part de son feedback. Il faut donc demander consciencieusement des commentaires à chaque évaluation, puis les ignorer tous, ce qui apprend aux gens à arrêter de qui apprend aux gens à arrêter Ensuite, nous avons les pièges des métriques , que nous avons examinés dans la section précédente et que vous remarquerez désormais partout. Le premier est donc la vélocité en tant que cible. Dès que les points deviennent un objectif, estimations augmentent pour l'atteindre, et le nombre augmente alors que le travail réel ne le fait pas résultat plutôt que le résultat, célébrant dix fonctionnalités livrées qui ne bougent rien, personne ne se souciait vraiment des indicateurs de vanité, donc des chiffres qui apparaissent bien sur une diapositive mais qui ne veulent vraiment rien dire en dessous, comme le téléchargement sans utilisation Et enfin, mesurer les gens. Il faut donc prendre des indicateurs conçus pour décrire un système d'équipe et les transformer en tableaux de bord individuels, ce qui empoisonne de manière fiable n'importe quelle Donc, le remède est généralement le même, donc il y a de bonnes nouvelles. Et il ne s'agit essentiellement que d'une seule question. Donc, quel que soit le rituel, la métrique, l'habitude, demandez-vous si cela nous aide réellement à créer de la valeur. Si la pratique ne vous y aide pas, vous êtes autorisé à le modifier. Le cadre est à votre service. Vous ne sauvegardez pas le cadre. Donc, en dessous, se trouvent les deux habitudes sur lesquelles repose le Hall of Agile, inspectez. Alors regardez honnêtement ce qui se passe, et non la version ordonnée qui vous trotte dans la tête, et adaptez-vous Changez donc une chose, observez ce qui se passe, puis conservez ce qui fonctionne. Si vous faites ces deux choses à plusieurs reprises et honnêtement, vous éviterez presque tous les pièges de cette liste Le danger intermédiaire n'est pas l'ignorance. Il est en train de suivre les mouvements. Demandez-vous donc si chaque pratique mérite sa place. Merci de m'avoir rejoint. Dans la prochaine leçon, nous vous regarderons dans cette optique grâce à une auto-évaluation honnête. Êtes-vous réellement prêt à diriger une équipe ? Je te verrai dans le prochain. 29. Auto-évaluation : êtes-vous prêt à diriger ?: Bon retour. Cette leçon sera donc un regard honnête dans un miroir. Nous allons procéder à une auto-évaluation afin que vous puissiez voir clairement ce que vous pouvez déjà faire et dans quels domaines vous devez vous entraîner. Il ne s'agit donc pas d'un test avec note de passage. Il s'agit plutôt d'une façon de transformer une vague sensation «   suis-je prêt » en une réponse précise et utile. Alors, prenez un stylo si vous le souhaitez, et procédons ensemble à l' auto-évaluation. Comme je l'ai déjà dit, il s'agit d'un enregistrement et non d'un examen. Règle numéro un, soyez honnête et précis. Pour chaque élément, répondez par un exemple concret, sans espoir peut-être. Donc oui, j'ai fait ce dernier sprint qui compte, mais je pense que je ne pouvais pas compter. La valeur de cet exercice réside entièrement dans l' honnêteté avec laquelle vous y répondez. Ainsi, un score généreux que vous n'avez pas obtenu ne fait que vous priver d'un plan d'amélioration clair, si nécessaire Oh, savez-vous gérer les mécanismes, les éléments mobiles d'un sprint ? Pouvez-vous courir un sprint complet de bout en bout ? Pouvez-vous le planifier, le gérer, le revoir et organiser une rétrospective ? Peux-tu configurer ton tableau ? Pouvez-vous créer un tableau Scrum ou Caban que d'autres personnes pourront réellement utiliser, et pas seulement Pouvez-vous prioriser un carnet de commandes en classant le travail en fonction de sa valeur et en le maintenant dans l'ordre au fur et à mesure que les choses changent ? Et pouvez-vous estimer le travail de manière raisonnable avec des points ou tailles de tee-shirts sans prétendre à une fausse précision ? Si vous avez quatre « oui », cela signifie que vous maîtrisez parfaitement le concept de sprint agile Ensuite, pouvez-vous gérer les gens ? C'est plus important que la dernière section. C'est dans ce domaine qu'il revient décider si les projets aboutissent ou non. Pouvez-vous donc cartographier vos parties prenantes et indiquer qui compte et quelle attention chacune a besoin ? Pouvez-vous effectuer une évaluation de sprint qui montre travail réel et recueille des commentaires que vous pouvez réellement utiliser ? Pouvez-vous absorber le changement en intégrant une nouvelle exigence sans faire dérailler l'équipe ? Enfin, pouvez-vous rédiger une mise à jour claire indiquant à une partie prenante ce dont elle a besoin en moins d'une minute ? Elles sont plus difficiles que les mécaniques d'un sprint, et elles sont plus importantes. La prochaine est : pouvez-vous lire les signaux ? Ce sont donc les chiffres qui vous permettent de rester honnête. Pouvez-vous regarder un diagramme de combustion ou un diagramme de flux cumulatif et dire en termes simples ce qui se passe réellement ? Pouvez-vous distinguer le résultat d'un résultat ? Pouvez-vous faire la différence entre être occupé et être vraiment utile ? Et pouvez-vous détecter une mauvaise utilisation des métriques ? Donc, si vous remarquez qu' un chiffre est obtenu ou qu'on le transforme discrètement en arme, si vous pouvez lire ces signaux, vous pouvez vous fier aux preuves plutôt qu'à votre instinct Alors additionnez vos oui honnêtes. Si c'est généralement le cas, alors vous êtes prêt à diriger une équipe. Vous pouvez exécuter les processus, vous pouvez gérer les personnes et lire les signaux, ce qui est exactement ce que le travail exige. Alors vas-y et fais-le. Si vous avez des lacunes, ce n'est pas un échec. Ce n'est qu'une carte. Chacun d'entre eux n'a donc aucun point pour une section de ce cours qui mérite d'être revisitée Personne ne commence donc par un oui complet. Le but de cet exercice est de savoir lequel est lequel, afin que vous sachiez exactement où placer vos efforts ensuite. Une auto-évaluation honnête bat vraiment la fausse confiance à chaque fois, car elle vous indique les domaines dans lesquels vous devez vous améliorer. Merci de m'avoir rejoint. Dans la leçon suivante, nous allons le mettre en pratique sur votre projet actuel, revue votre plan de publication et les indicateurs que vous avez obtenus jusqu'à présent. Je te verrai dans le prochain. 30. Examen du projet : Plan de publication et paramètres: Bon retour. Il s'agit d'une leçon pratique, c'est donc à vous de travailler sur votre projet. Nous allons passer en revue vos projets réalisés jusqu'à présent, votre plan de publication et vos indicateurs, et nous allons les rassembler en un seul endroit, et ce sera dans Notion. Voici donc l'exercice en quatre étapes. d'abord, rassemblez vos artefacts, votre tableau de bord, votre carnet de commandes, votre plan de sortie et vos indicateurs, et conservez-les tous au même endroit Deuxièmement, passez en revue le plan de publication et demandez-vous s'il est toujours réaliste ou si le champ d'application a légèrement changé. troisième consiste à examiner les indicateurs et lire ce que les tendances vous disent réellement, fois sur les résultats et sur les résultats. Et quatrièmement, notez ce que vous voudriez changer. Donc juste un ou deux ajustements honnêtes pour la prochaine fois. Maintenant, examinons un peu plus en profondeur les deux du milieu. Commencez donc par revoir votre plan de publication. Si vous n'êtes pas familier avec le plan de publication temporaire, il s'agit simplement d'une carte approximative de ce qui sera expédié et non d'un calendrier rigide, c'est une attente partagée. Donc, pour notre application d'apprentissage des langues , cela pourrait ressembler à ceci. Première version, les principales leçons sont déjà fournies. deuxième version était un e-mail récapitulatif de Badgers plus parents actuellement en cours de préparation, et la troisième version est le tableau de bord pour parents prévu mais pas démarré La question de révision ici est simple et importante. Cela correspond-il toujours à la réalité ? Donc les plans dérivent, alors peut-être que la deuxième version a grandi ou peut-être que la troisième s'est révélée plus importante que vous ne le pensiez. C'est en révisant le plan que vous détectez volontairement cette dérive plutôt que en laisser surprendre ultérieurement. Nous allons donc passer en revue vos statistiques à l'aide du tableau de bord que nous avons créé lors de la dernière leçon. Ne vous contentez donc pas de jeter un coup d'œil aux chiffres, lisez-les comme une histoire. Une vitesse constante vous indique donc que votre rythme de livraison est prévisible, ce qui est une bonne nouvelle pour toute promesse que vous faites. L'achèvement des leçons vous indique que le produit de base est réellement apprécié des apprenants. utilisateurs actifs chaque semaine vous indique que les gens reviennent, non pas qu'ils s'éloignent, et les bugs ouverts indiquent que la qualité est sous contrôle Lus ensemble comme ça, ces quatre chiffres vous donnent une image étonnamment honnête de l'état de santé de l'ensemble du projet. Voici donc un format d' évaluation simple à suivre. Pour capturer tout cela, vous n'avez vraiment besoin que de quatre rubriques honnêtes Qu'est-ce qui va bien ? Nommez donc clairement les victoires, car elles sont vraiment faciles à oublier lorsque vous êtes sous pression. Qu'est-ce qui est bloqué ? Donc, vous continuez à contourner les blocages et les blocages Ensuite, c'est ce qui a changé. Est-ce la portée, les priorités ou les personnes qui ont changé depuis vos débuts ? Et enfin, quelle est la prochaine étape ? Donc, une ou deux choses que vous ferez délibérément différemment lors du prochain sprint. C'est votre structure d'évaluation. Donc, tout cela sur une seule page dans Notion. Sur cette seule page, vous devriez avoir un plan de publication. Vous devriez avoir votre journal de vélocité , puis quelques notes de révision. Je vais vous montrer exactement à quoi cela ressemblerait dans Notion. J'ai donc ajouté une revue de projet. Maintenant, vous n' aurez probablement pas d' examen de projet au cours de la première semaine, mais comme nous n'en avons fait qu' une semaine, présent, je vais simplement mettre la première semaine. Sur cette page, j'ai deux liens vers le plan de publication et le tableau de bord des métriques. Pour ce faire, vous pouvez donc copier le lien, puis le coller. Montre-toi à quoi ça ressemble. Donc, si vous le collez, le lien sera directement collé. Ensuite, si vous cliquez simplement sur mentionner, vous obtiendrez le lien direct vers cette page. Sur cette page, j'ai également ajouté le lien vers les statistiques, le bord, puis ci-dessous, j'ai indiqué ce qui s'est bien passé, ce qui est bloqué, ce qui a changé et ce qui va suivre. Donc, sous ces rubriques, c'est la deuxième rubrique, d'ailleurs Vous pouvez mettre une liste à puces et vous devez répondre à ces quatre questions Voilà à quoi devrait ressembler le squelette de cette page Maintenant, voyons à quoi ressemble le bien. Alors mettez la vidéo en pause, créez votre propre critique. Lorsque c'est fait, vérifiez-le par rapport à ces quatre éléments. Premièrement, pour être honnête, la colonne bloquée n'est pas vide car un avis sans friction n'est pas un véritable avis. Il utilise des preuves. Vos affirmations sont étayées par le conseil d'administration et les indicateurs, et pas seulement par vos sentiments. C'est court. Une page peut être lue avant une réunion. Enfin, cela se termine par une action, au moins une chose concrète que vous changerez pour la prochaine fois. Si vous avez atteint ces quatre points, vous avez fait quelque chose que plupart des équipes ne parviennent pas à faire , à savoir s'arrêter et tirer des leçons véritables de leur propre projet et de l'état de santé de leur propre projet. Une bonne évaluation transforme donc quelques semaines bien remplies en leçons que vous pouvez réellement utiliser, et c'est cette habitude qui distingue les personnes qui répètent leurs erreurs de celles qui améliorent leurs compétences. Merci donc de m'avoir rejoint. Dans la dernière leçon, nous verrons ce que vous allez faire à partir de maintenant et ce qu'il vous reste à faire en matière de gestion de projet Agile. On se voit donc pour le prochain. 31. Prochaines étapes : le chemin à suivre: Bienvenue à la dernière leçon de ce cours. Dans cette dernière leçon, nous allons simplement effectuer un zoom arrière. Nous allons examiner le chemin que vous avez parcouru, nommer le prochain quart de travail et vous indiquer la voie à suivre. C'est donc une question courte, alors faisons-en sorte qu'elle compte. Donc, tout d'abord, il suffit de regarder le chemin que vous avez parcouru. Accordez-vous donc du mérite, car vous avez beaucoup abordé dans ce cours. Et permettez-moi de vous le résumer très rapidement. Vous avez donc maintenant étudié les frameworks. Vous pouvez choisir et exécuter Scrum ou Cam Ban ou un hybride judicieux des deux plutôt que d'en suivre un par défaut Avec les parties prenantes, vous pouvez cartographier les personnes autour de votre projet. Vous pouvez effectuer des évaluations avec eux et les tenir à jour sans faire perdre de temps à personne. Enfin, en ce qui concerne les indicateurs, vous pouvez mesurer honnêtement les progrès, le flux et les résultats réels, et vous pouvez également détecter les cas où un chiffre vous induit en erreur. Il s'agit donc de la boîte à outils de quelqu'un qui peut réellement gérer un projet Agile. Bravo. Donc, de l'action au leadership, c'est le changement qui vient ensuite. Ce n'est donc pas simplement la même chose. Jusqu'à présent, vous avez appris à bien gérer un projet Agile. L'étape suivante est d'une nature différente. Il s'agit de diriger le personnel et améliorer le fonctionnement de toute une équipe au fil du temps. Courir un bon sprint est donc une compétence, mais constituer une équipe qui organise bons sprints sans que vous ne vous retrouviez au-dessus d'elle et qui continue de s'améliorer elle-même est une compétence différente et plus approfondie Passer de la pratique Agile à la direction de celle-ci est la prochaine étape de votre croissance en tant que leader Agile. À partir de là, votre parcours Agile, après un niveau intermédiaire, c'est tout d' abord la mise à l'échelle, alors comment coordonner plusieurs équipes sans noyer tout le monde au cours du processus Ensuite, il y a la qualité et le risque, comment intégrer la qualité dès le départ et gérer les risques de manière judicieuse sans trop de paperasse Vient ensuite l'amélioration continue. C'est donc la fin de Kai, de garder un œil sur la santé de l'équipe et de rester alerte sans épuiser les gens. Enfin, il y a le coaching, développement d'une équipe qui s'améliore et le leadership sans contrôle. En d'autres termes, il s'agit de la moitié leadership de l' Agile et de la moitié livraison que vous venez de maîtriser C'est donc la fin de ce cours. Félicitations. Vous l'avez lancé, capable de suivre un processus Agile, et vous êtes en train de le terminer, capable de le gérer avec bon jugement avec les personnes présentes et en vous appuyant sur des chiffres honnêtes. C'est donc une véritable réussite, et vous devriez en être fier. Merci donc beaucoup de m'avoir rejoint et pour tout le travail que vous avez accompli Bonne chance dans votre parcours de gestion de projet Agile. 32. Vous avez choisi de créer un portrait unique : planifier une version multi-sprint et créer un tableau de bord de gestion de projet.: Il est maintenant temps d'étendre votre projet Agile. Pour votre projet de classe, vous vous basez sur le projet que vous avez développé tout au long du cours en planifiant une version complète en plusieurs sprints et en créant un tableau de bord de gestion de projet simple. Commencez par définir un objectif de publication et divisez votre travail en plusieurs sprints. Estimez ensuite votre carnet de commandes, hiérarchisez votre travail et prévoyez l'évolution de votre projet au fil du temps. Choisissez ensuite le cadre qui convient le mieux à votre projet. Vous pouvez continuer à utiliser Scrum, convertir votre travail en Caban ou créer une approche hybride en fonction des besoins de votre projet Vous identifierez également vos principales parties prenantes et préparerez une mise à jour du projet qui communiquera les progrès, les priorités et tout changement important. Enfin, créez un tableau de bord de métriques simple à l'aide de Notion ou de tout autre outil de votre choix. Incluez des indicateurs qui vous aident à comprendre l'avancement de votre projet et à prendre de meilleures décisions. Vous avez terminé, téléchargez des captures d'écran de votre plan de publication, tableau de projet et de votre tableau de bord des indicateurs la galerie de projets, et n'hésitez pas à expliquer brièvement pourquoi vous avez choisi votre flux de travail et comment vous avez abordé la planification de votre projet. L'objectif n'est pas de construire un projet parfait. Il s'agit simplement de démontrer que vous pouvez penser au-delà d'un simple sprint et gérer un projet dans une perspective plus large et plus stratégique. 33. Félicitations ! Quoi faire ensuite ?: Félicitations pour avoir terminé le cours. Vous avez maintenant dépassé les principes fondamentaux de l' Agile et développé une compréhension beaucoup plus large de la façon dont les projets réussis sont planifiés, gérés et livrés au fil du temps. Tout au long de ce cours, vous avez appris à élaborer des plans de publication, estimer le travail de manière plus efficace, choisir entre Scrum et MBA, communiquer avec les parties prenantes et à utiliser des indicateurs pertinents pour guider vos décisions N'oubliez pas qu'Agile ne consiste pas suivre parfaitement un cadre, mais à apprendre, à s'adapter et à choisir en permanence les pratiques qui soutiennent le mieux votre équipe et votre projet. Si ce n'est pas déjà fait, assurez-vous de télécharger votre projet dans la galerie. J'adorerais voir comment vous avez planifié votre sortie et structuré votre flux Si vous avez apprécié le cours, pensez à nous laisser un commentaire. Cela nous aide à améliorer les cours à venir et aide les autres apprenants à découvrir le cours. Merci de vous joindre à moi et j'espère vous voir au prochain cours.