Masterclass sur la gestion de projet pour débutants : réalisez votre premier projet agile

1. pour débutants dans la masterclass de gestion de projet agile !: Mmm, hum. Bienvenue dans le cours de gestion de projet agile pour débutants. Vous êtes-vous déjà demandé comment les équipes performantes organisaient les projets, géraient les priorités changeantes et produisaient régulièrement des résultats ? Si c'est le cas, vous êtes au bon endroit. m'appelle Luke Phillips et je suis chef de projet avec sept ans d' expérience dans le domaine des méthodologies agiles dans le cadre de différents types de projets et d'équipes. Dans ce cours, je vais vous aider à comprendre gestion de projet agile d'une manière pratique et conviviale pour les débutants. L'un des plus grands défis l'apprentissage de la gestion de projet est que bon nombre de ces cours se concentrent sur la théorie sans montrer comment les projets fonctionnent réellement dans la pratique. C'est pourquoi ce cours est conçu autour de la construction d'un véritable projet étape par étape. Ensemble, nous explorerons l'état d'esprit agile. Nous apprendrons les principes de Scrum, comprendrons comment fonctionnent les backlogs de produits et les user stories, et nous utiliserons des outils populaires tels que Trello et Notion pour Vous apprendrez à planifier des sprints, à prioriser le travail, à estimer les tâches, à organiser des réunions, gérer les changements et à évaluer les progrès, comme le font les équipes agiles dans de vraies organisations Tout au long du cours, vous appliquerez tout à un brief de projet de votre choix, qui vous aidera à acquérir une expérience pratique au lieu de simplement mémoriser des concepts À la fin de ce cours, vous comprendrez le mode de vie complet des projets Agile et vous aurez votre propre espace de travail de projet, votre carnet de commandes et votre plan de sprint prêts à être présentés. Commençons. 2. La mentalité agile : introduction à la gestion de projet agile: Bonjour et bienvenue. Dans les 5 prochaines minutes, je vais vous présenter l'une des idées les plus discutées en matière de gestion de projet moderne. Agile. À la fin de cette vidéo, vous saurez exactement ce qu'est l'Agile, où il vient et pourquoi tant d'équipes, bien au-delà du monde des logiciels, l' ont adopté. Je m'appelle Luke, et j'ai passé les sept dernières années travailler en tant que chef de projet dans Edtech s'agit de la technologie éducative, projets d'apprentissage numérique avec équipes interfonctionnelles et internationales . L'agilité fait partie de ma vie professionnelle quotidienne depuis tout ce temps, et je souhaite vous le démystifier Alors, qu'est-ce qu'Agile ? Commençons simplement. L'agilité est une façon de gérer des projets qui divise le travail en petits morceaux gérables et qui apporte de la valeur étape par étape, plutôt que tout à la fin Pour comprendre pourquoi cela est important, imaginez l' alternative traditionnelle, appelée cascade. Dans les projets en cascade, vous planifiez tout à l'avance, puis vous exécutez chaque phase dans l'ordre, les exigences, la conception, la construction, les tests et le lancement Cela fonctionne à merveille, mais seulement tant que rien ne change. Et dans le monde réel, les choses changent constamment. Les clients peuvent donc changer d' avis, les marchés peuvent changer, nouvelles informations peuvent apparaître à mi-chemin, et Agile a été conçu exactement pour répondre à cette réalité. Ainsi, au lieu d'un grand plan et d'un grand lancement, vous travaillez par cycles courts, généralement d'une à quatre semaines. Et à la fin de chaque cycle, vous avez quelque chose de concret à montrer, obtenir des commentaires et à améliorer. Alors, d'où vient Agile ? En février 2001, 17 développeurs de logiciels se sont rencontrés dans un chalet de ski de l'Utah, et ils ont été déçus par le fait que gestion de projet traditionnelle contenant beaucoup de documents ne fonctionnait pas pour les logiciels. Au cours de ce week-end, ils ont donc écrit le Manifeste Agile. Il s'agit de quatre valeurs abrégées et de 12 principes sous-jacents. Et les quatre valeurs courtes méritent d'être mémorisées. Agile valorise donc les individus et les interactions plutôt que les processus et les outils. Elle privilégie les produits fonctionnels par rapport à une documentation complète. Elle privilégie la collaboration avec les clients plutôt que la négociation de contrats, et elle privilégie la réponse au changement plutôt que le suivi d'un plan. Maintenant, remarquez le mot terminé. Les éléments de la deuxième ligne sont toujours importants. Vous avez besoin de processus, de documentation et de plans, mais lorsque vous devez choisir, vous devez prioriser les éléments prioritaires. Aujourd'hui, bien que l'agilité ait débuté dans les logiciels, ces valeurs s'appliquent presque partout où vous créez quelque chose de nouveau avec certitude, qu'il s'agisse du marketing, de la conception de produits, l'éducation ou même des soins de santé. Alors, à quoi ressemble réellement l'Agile au quotidien ? En son cœur, il s'agit d'une boucle. Vous planifiez un petit travail, vous le créez, vous le passez en revue avec les parties prenantes, vous tirez des leçons des commentaires, puis vous recommencez. Agile, ce cycle court est souvent appelé sprint et dure généralement deux semaines. Au début, vous choisissez un petit ensemble d' éléments parmi une tâche prioritaire appelée backlog Ensuite, l'équipe construit ces éléments, affiche les résultats, puis réfléchit à ce qui s'est bien passé et à ce qu'il convient d'améliorer. Et puis le cycle se répète. L'agilité est un état d'esprit, mais pour l'appliquer, la plupart des équipes utiliseront un cadre spécifique. Les deux plus courants dont vous entendrez parler sont Scrum et Cam Ban Scrum utilise ces sprints fixes de deux semaines avec des rôles de produit définis, tels que propriétaire du produit et le Scrum Vous organisez régulièrement des cérémonies, telles que la planification, des stands quotidiens, des critiques et des rétrospectives Cam Ban, en revanche, est plus continu, le travail se déroule sur un tableau visuel et l'accent est mis sur le fait de limiter le nombre de tâches en cours à la fois. De nombreuses équipes utiliseront un véritable mélange des deux. Pourquoi c'est important. Pourquoi l' agilité est-elle devenue si dominante ? Il y a trois raisons. Premièrement, cela réduit les risques car les problèmes apparaissent tôt, et non à la fin. Deuxièmement, cela permet aux équipes de rester en phase avec les clients, car vous communiquez constamment avec eux au lieu de deviner Et troisièmement, elle respecte les personnes en faisant confiance à de petites équipes pour organiser leur propre travail Parfait pour le travail à distance. résumé, l'agilité est un état d'esprit qui consiste à exécuter travail selon de courts cycles axés sur le feedback Il est issu du Manifeste Agile de 2001, donne la priorité aux personnes, aux résultats du travail, à la collaboration et à l'adaptabilité. Dans la pratique, il prend généralement la forme de Scrum, Cam Ban ou d'un hybride Je vais donc vous laisser parler d' Agile, ce n'est pas vraiment une question de sprints, de stand-up ou notes autocollantes accrochées au mur. Ce ne sont que des outils. Au fond, l'agilité est une façon d'admettre quelque chose d'honnête Nous ne connaissons pas toujours la réponse dès le départ, et la chose la plus intelligente que nous puissions faire est de construire un peu, apprendre un peu et de continuer à Ainsi, que vous deviez gérer équipes logicielles, mener des campagnes marketing ou coordonner des programmes d'apprentissage, cet esprit agile vous sera utile. Merci de votre attention et bonne chance votre parcours de gestion de projet. 3. À qui s'adresse ce cours et ce que vous allez construire: Bonjour, et bon retour. Dans la dernière vidéo, nous avons examiné une vue d'ensemble de ce qu'est l'Agile et nous l'avons comparée au style traditionnel de gestion de projet en cascade. Dans cette vidéo, je souhaite faire deux choses. Tout d'abord, je veux vous aider à vérifier que c'est le bon cours pour vous. Ensuite, je veux te montrer ce que tu vas repartir avec quoi tu vas repartir d'ici la fin. Ce n'est pas un de ces cours où vous vous contentez de regarder un tas de théorie et de vous demander quoi en faire. À la fin de ce cours, vous aurez construit quelque chose de réel. Alors, ce cours est pour toi ? Ce cours a été conçu pour quatre types de personnes. Tout d'abord, il a été conçu pour les débutants complets. Si vous avez entendu le mot Agile au travail ou dans des offres d'emploi et que vous ne savez pas exactement ce que cela signifie, vous êtes exactement au bon endroit. Vous n'avez pas besoin de connaissances préalables pour suivre ce cours. Deuxièmement, ce cours a été conçu pour les personnes qui se lancent dans la gestion de projet ou dans un rôle dans le domaine des produits. Peut-être que vous avez été promu ou que vous essayez de percer sur le terrain. agilité est le langage parlent la plupart des équipes modernes, vous en aurez donc besoin, et vocabulaire joue un rôle important dans la gestion de projet. Cela montre que vous êtes au moins au courant du concept. Le troisième type de personnes est celui des personnes qui gèrent déjà des projets de manière traditionnelle qui pensent qu'il existe une meilleure solution. Il y en a un, et vous allez en apprendre davantage ici. Et le quatrième type de personnes est celui des personnes qui ne travaillent pas du tout dans le domaine des logiciels. Ainsi, dans les domaines du marketing, de l'événementiel, de l'éducation, des soins de santé, des propriétaires de petites entreprises, méthode Agile s'applique à presque tous les domaines dans lesquels vous créez quelque chose de nouveau et où vous n'avez pas toutes les réponses dès le départ Donc, si c'est vous, c' est la bonne solution. Une petite remarque sur les personnes auxquelles ce cours n'est pas destiné. Si vous êtes déjà un Scrum Master certifié avec des années d'expérience, ce cours vous semblera assez basique C'est bon. Les cours intermédiaires et avancés cette série sont beaucoup plus approfondis. Assurez-vous donc de commencer là où vous êtes réellement. Regardons donc ce que vous construisez. Vous avez trois véritables artefacts dignes d'un portfolio, et pas simplement des notes d'un cours. Alors, qu' allez-vous réellement construire ? Ce cours est basé sur des projets du début à la fin. Vous allez choisir un brief de projet dans la vidéo suivante. Vous en aurez le choix entre trois . Ensuite, tout ce que tu apprendras, tu l'appliqueras à ce projet. À la fin du cours, vous aurez trois choses vraiment dignes d'un portfolio. La première chose que vous aurez est un carnet de produits entièrement rempli C'est la liste des tâches prioritaires à partir de laquelle toute véritable équipe Agile doit commencer Deuxièmement, vous aurez un tableau de sprint montrant un cycle de sprint complet que vous avez réellement couru, et troisièmement, vous aurez un document rétrospectif écrit lequel vous réfléchirez à ce qui s'est bien passé et à ce que vous changeriez la prochaine fois Ce sont les mêmes artefacts que équipe produit en activité produit toutes les deux semaines. Et vous pouvez mettre ces choses dans un portefeuille. Vous pourriez les montrer lors d'un entretien d'embauche, et vous pouvez les utiliser comme modèles pour votre prochain projet réel. Ce sont les vôtres. Voyons donc ce dont vous aurez besoin. Ce sont tous des outils gratuits. Aucun forfait payant n'est requis. n'y a pas de procès. Il n'y a aucun problème d'inscription. Les deux outils gratuits que nous utiliserons sont Trello et NS, tous deux dotés de niveaux gratuits. Nous ne vous demanderons jamais de payer quoi que ce soit ni de vous inscrire à un essai. Ensuite, la troisième chose dont vous aurez besoin est un stylo et du papier. Il arrive donc que l'option technologique la moins coûteuse soit la meilleure idée à prendre en compte. Ensuite, choisissez votre projet. Vous aurez le choix entre trois slips. Vous n'aurez qu'un seul choix, puis nous construirons. Choisissez donc celui qui vous convient le mieux. Ne réfléchissez pas trop au choix. Dans la vidéo suivante, je vais vous aider à définir votre brief. Je t'y verrai donc. 4. Choisissez votre dossier de projet : Edtech, E-commerce ou Événements: Bon retour. Passons maintenant à la partie amusante. Dans cette vidéo, vous allez choisir le projet sur lequel vous allez travailler pour le reste de ce cours. Je vous ai préparé trois slips différents. Ils couvrent délibérément des secteurs très différents, principalement pour montrer que l'Agile n'est pas uniquement destiné aux projets logiciels. Vous verrez ce que je veux dire dans une minute. Ne vous inquiétez donc pas à propos de ce choix. Choisissez celui qui vous passionne le plus ou celui qui se rapproche le plus de votre vrai travail Il n'y a pas de bonne ou de mauvaise réponse ici. N'importe lequel de ces slips vous sera très utile pour ce cours. Donc bref A est technologie éducative Edtech pour créer une fonctionnalité pour une application d'apprentissage des langues pour enfants Imaginez donc que vous êtes le chef de produit ou le chef de projet d' une petite start-up Edtech Votre équipe développe une application d'apprentissage des langues pour enfants, et la première version est en ligne, mais l'engagement diminue après la deuxième semaine. Votre travail consiste à planifier et à exécuter un sprint qui intègre une nouvelle fonctionnalité conçue pour ramener les enfants. Il s'agit peut-être d'un système de séries d'un nouveau mode de jeu ou de récompenses. Ça dépend de toi. Choisissez donc celui-ci si vous aimez les produits de consommation ou les applications. Vous êtes étudiant ou proche de l'école et vous souhaitez réfléchir à la motivation et à l'engagement des utilisateurs. Brief B est le commerce électronique pour lancer une nouvelle gamme de produits pour un détaillant durable. Donc, pour celui-ci, vous travaillez avec un petit détaillant en ligne qui vend des articles ménagers durables. Ils veulent lancer une nouvelle gamme de produits, par exemple une cuisine écologique, à temps pour les fêtes de fin d'année. Maintenant, avec celui-ci, vous avez de nombreuses pièces mobiles. Nous avons la photographie, les descriptions des produits, les prix, les négociations avec les fournisseurs, le marketing et même le site Web. Votre travail consiste donc à planifier et à exécuter un sprint qui prépare le lancement. Je choisirais celui-ci si vous aimez les activités non commerciales ou si vous vous intéressez au marketing ou à l'entrepreneuriat en général, ou si vous voulez un brief contenant de nombreux éléments interfonctionnels et mobiles. Si C est un événement industriel. Organisez donc une conférence hybride de deux jours. conférence hybride signifie que des personnes y assistent en personne et en ligne. Avec ce projet, il y a donc une salle à réserver. Il y a des conférenciers à inviter. Il y a des sponsors à rechercher. Nous avons un site Web à créer. Vous avez la technologie à configurer et une campagne marketing à lancer. L'événement aura lieu dans trois mois, et votre travail consiste à planifier et à exécuter un sprint qui fera avancer le projet. Je choisirais celui-ci en particulier si vous ne travaillez pas dans le domaine de la technologie. Les événements sont le brief qui prouve qu' Agile fonctionne en dehors du logiciel. Si vous travaillez dans les opérations marketing, ressources humaines ou dans tout autre domaine non informatique, celui-ci est probablement votre meilleur choix. Alors, comment choisir. Telles sont les trois questions si vous êtes bloqué. Premièrement, quel secteur est le plus proche de votre emploi actuel ? Si votre travail quotidien est dans le commerce de détail, choisissez le commerce électronique. Si ce n'est pas dans le domaine de la technologie, choisissez les événements. Plus le brief se rapproche de votre réalité ou de ce que vous voulez faire, plus vous tirerez profit de ce cours. Deuxièmement, lequel vous excite le plus sincèrement ? Vous allez y passer au moins 3 heures, alors choisissez celle qui vous plaira. Et troisièmement, si vous êtes toujours bloqué, choisissez les événements. C'est le plus accessible aux débutants, et c'est probablement le meilleur qui présente tous les avantages de la gestion de projet agile. Alors, mettez la vidéo en pause, choisissez un brief, notez-le. Dans la vidéo suivante, nous aborderons le Manifeste Agile lui-même, les quatre valeurs et les 12 principes qui sous-tendent tout le reste. Je t'y verrai. 5. Le manifeste Agile : quatre valeurs et douze principes: Bon retour. Dans la vidéo d' introduction, j'ai mentionné le Manifeste Agile, le document que 17 développeurs ont écrit sur le chalet de ski de l'Utah, si vous vous en souvenez. Dans cette vidéo, nous allons examiner ce qu'il dit réellement. Nous allons examiner les quatre valeurs et les 12 principes sous-jacents. Maintenant, c'est une vidéo importante. C'est le cœur philosophique de tout reste du cours et des questions de vocabulaire. Vous devriez donc prendre votre stylo et votre papier pour cette vidéo. Alors tout d'abord, pourquoi un manifeste ? Eh bien, il y avait un problème qui devait être résolu. Et voici votre contexte. Ainsi, à la fin des années 90, projets logiciels échouaient, importants ou coûteux, principalement parce que les équipes passaient des mois et des mois à rédiger des spécifications détaillées, puis des mois supplémentaires élaborer ce que ces spécifications indiquaient dans le seul but de fournir quelque chose dont le client ne voulait plus. Ils n'en voulaient pas parce que les marchés avaient évolué et que les exigences avaient changé. Le plan était donc parfait, mais le résultat était inutile. C'était le principal problème. Aujourd'hui, en février 2001, 17 développeurs se sont rencontrés dans une station de ski de l'Utah. Maintenant, ils n'étaient pas d'accord sur les méthodes, mais ils étaient tous d'accord sur le fait qu' il devait y avoir une meilleure solution. Au cours du week-end, ils ont donc rédigé un document très court, qui, étonnamment, ne compte que 68 mots. Jetons-y donc un coup d'œil. Maintenant, ce document se compose principalement des quatre valeurs, et nous valorisons les éléments de gauche plus que les éléments de droite. Le manifeste se lit comme suit : « Nous découvrons de meilleures façons de développer des logiciels en le faisant et en aidant les autres à le faire Grâce à ce travail, nous avons acquis de la valeur, puis nous avons les quatre énoncés. Privilégiez donc les individus et les interactions plutôt que les processus et les outils. Cela signifie qu'une bonne équipe dotée d' outils médiocres surpassera une équipe médiocre dotée d' Il est donc très important de se parler. Ne vous cachez pas derrière le logiciel. Privilégiez un logiciel fonctionnel par rapport à une documentation complète. Cela signifie donc que 100 pages de magnifiques spécifications que personne ne lit valent bien moins qu' un petit prototype fonctionnel que les gens peuvent réellement utiliser et essayer. Construisez donc quelque chose de réel dès que possible. Troisième valeur, la collaboration avec le client plutôt que la négociation des contrats. Cela signifie qu'il ne faut pas gaspiller votre énergie discuter exactement de ce qui a été convenu dans le brief initial. Travaillez avec votre client, collaborez avec lui, découvrez ce dont il a réellement besoin. Et la quatrième valeur est la réponse au changement selon un plan. Cela signifie qu'un plan n'est pas une hypothèse. Ce n'est pas un contrat. Lorsque la réalité contredit le plan, modifiez-le Et voici ce qui manque aux gens. Le Manifeste se termine ainsi même si les éléments de droite ont de la valeur, nous valorisons davantage les éléments de gauche. Ces éléments traditionnels tels que les processus et la documentation, les contrats et les plans sont donc tels que les processus et la documentation, toujours importants. Ce n'est pas une mauvaise chose, mais ils ne sont pas la priorité lorsque la pression se fait sentir. Examinons donc les 12 principes. Maintenant, le fait de regrouper les principes les rend un peu plus mémorables. Je ne vais donc pas lire les 12 principes les uns après les autres. Ce serait assez fastidieux. De plus, vous pouvez les lire vous-même en quelques minutes. N'oubliez pas qu'il ne compte que 68 mots. Donc, au lieu de passer en revue un à douze, je vais les regrouper en quatre thèmes différents. Maintenant, le premier thème générer de la valeur tôt et souvent. Le premier principe est de satisfaire le client grâce à une livraison rapide et continue. Et la troisième valeur est de fournir des logiciels fonctionnels fréquemment, semaines plutôt que des mois. La traduction, ce que cela signifie réellement, c' présenter quelque chose de réel aux utilisateurs le plus rapidement possible, puis continuer. Le deuxième thème, le changement bienvenu. Le deuxième principe des 12 dit littéralement «   bienvenue » en cas d'évolution des besoins, même à un stade avancé du développement. Maintenant, cela semble fou si vous venez de la gestion de projet traditionnelle en cascade. Mais le pari agile est que le changement se produira de toute façon, alors autant vous préparer à ce changement. Le troisième thème est celui des personnes d'abord. Plusieurs principes peuvent être regroupés dans ce thème. Vous construisez des projets autour personnes motivées et vous leur faites confiance pour accomplir leur travail. conversation en face à face est le moyen le plus efficace de partager des informations, et les meilleurs architectes et designers sont issus d'équipes auto-organisées. Si vous remarquez une tendance, Agile fait confiance aux personnes travaillant sur les projets. Le quatrième thème est la durabilité et la réflexion, deux principes que j'adore. Les processus agiles favorisent le développement durable. Les sponsors, les développeurs et les utilisateurs devraient être en mesure de maintenir un rythme constant indéfiniment. En d'autres termes, pas de marches de la mort. Et dernier principe : à intervalles réguliers, l'équipe réfléchit à la manière de devenir plus efficace. Vous avez intégré l'amélioration continue. Voyons donc ce que cela signifie dans pratique et ce que le manifeste signifie pour votre projet. Alors, qu'est-ce que cela signifie lorsque vous rédigez le brief de votre projet ? Cela signifie donner la priorité à l'expédition quelque chose de petit plutôt que de planifier quelque chose de parfait. Cela signifie que lorsque votre partie prenante change d'avis, considérez cela comme une information utile, non comme un problème sur lequel vous devriez vous attarder. Cela signifie faire confiance à votre équipe, réfléchir souvent à ce que vous avez fait, vous améliorer constamment. Maintenant, rien de tout cela n' est de la science des fusées. C'est surtout le bon sens qui a été oublié par ces grandes organisations qui sont très coincées dans leurs habitudes. Le but du manifeste est de nous le rappeler. Dans la prochaine vidéo, nous aborderons les idées fausses sur gestion de projet agile car, vous savez, étant donné son utilisation si répandue , ces idées fausses apparaissent Il est surprenant de constater à quel point un document de 68 mots peut être mal compris Dans la prochaine vidéo, nous examinerons les mythes de l'Agile, démystifiés. On se voit là-bas. 6. Mythes et idées fausses sur l'agile tions: Bon retour. Si vous ne vous souvenez que d'une chose de cette vidéo, faites-en ceci. La plupart de ce que les gens appellent Agile ne l'est pas. Aujourd'hui, il y a un énorme écart entre ce que dit le manifeste et ce que font réellement les équipes. Examinons donc les idées fausses et démystifions les mythes. Mythe numéro un, Agile signifie qu'il n'y a pas de planification. Celui-ci me rend fou, c'est pourquoi il est numéro un. Le manifeste dit que répondre au changement plutôt que suivre un plan, ne jamais suivre un plan. Les équipes agiles planifient en permanence. Ils planifient simplement en petits morceaux plus souvent, et ils sont prêts à modifier ces plans au fur et à mesure qu'ils apprennent Si quelqu'un vous dit que nous ne planifiez pas, que nous sommes agiles, ils ne le sont pas. Ils sont simplement désorganisés. Alors méfiez-vous. Mythe numéro deux, Agile signifie qu'il n'y a pas de documentation. Encore une fois, ça me rend dingue aussi. Le manifeste privilégie un logiciel fonctionnel plutôt qu' une documentation complète, mais cela ne signifie pas qu'il n'y a aucune documentation. Cela signifie qu'il ne faut pas écrire 200 pages que personne ne lit. Rédiger de la documentation permet en fait d'avoir un récit utilisateur clair, un simple journal des décisions, un schéma d'architecture d'une page , tous ces éléments sont les bienvenus. Mythe numéro trois, Agile n'est que Scrum. Non. Scrum est un framework agile Il existe d'autres frameworks, notamment Caban, Extreme Programming, Lean et Scrumban, qui est agilité est l'état d'esprit, les valeurs et les principes que nous venons d'aborder, et Scrum est un moyen spécifique d'appliquer ces principes Donc, quand quelqu'un dit : «   Faites-vous de l'Agile », la réponse la plus honnête est généralement que nous utilisons Scrum, qui est une variante de l'Agile Nous approfondirons cette question dans le deuxième cours. M numéro quatre, Agile ne concerne que les logiciels. Le manifeste a été écrit par des développeurs, mais les principes et les valeurs sont universels. Les équipes marketing utilisent Agile, les hôpitaux utilisent Agile, les écoles utilisent Agile. Même les entreprises de construction l'utilisent. Donc, si vous créez quelque chose de nouveau l'incertitude existe et que vous avez de nombreuses parties prenantes, alors la méthode Agile s'applique et elle est très efficace. C'est pourquoi l'un de vos dossiers de projet sur ce cours est un projet événementiel et non un projet logiciel Mon numéro cinq, Agile signifie plus rapide. C'est probablement le mythe le plus dommageable car c'est ainsi que les dirigeants sont convaincus des projets agiles. Cela nous permettra d'expédier plus rapidement. Je veux dire, c'est parfois le cas, mais le véritable avantage de l' Agile n'est pas la rapidité. C'est l'adaptabilité. Vous vous concentrez sur les choses les plus importantes, car vous les avez apprises tout au long du projet. Vous pourriez en fait faire moins de travail dans l'ensemble à cause de cela. La vitesse est donc un effet secondaire. Ce n'est pas le but. Maintenant, dans la vidéo suivante, nous allons identifier le comportement agile. Vous aurez l'occasion de le tester vous-même. Nous allons faire un exercice pratique rapide. Je vais vous montrer quelques scénarios, et c'est à vous de décider lesquels sont réellement agiles et lesquels sont simplement conçus pour paraître agiles d'un point de vue superficiel. Alors je te verrai alors. 7. Exercice pratique : Repérer le comportement agile vs non agile: Bon retour. Passons maintenant à notre premier exercice d'entraînement, qu'il soit agile ou non. Je veux que tu repéres le comportement agile. Je vais vous donner cinq courts scénarios. Pour chacun, mettez la vidéo en pause et décidez s'il s'agit d'un comportement agile ou non. Ensuite, je te donnerai la réponse. Tout d'abord, dans le premier scénario, une équipe rédige un document de spécification détaillé de 80 pages avant qu'une seule ligne de code ne soit écrite. Maintenant, fais une pause si tu veux. Est-ce agile ou non ? Ce n'est pas Agile. Il s'agit donc d'une approche classique en cascade, planifier à grande échelle dès le départ, puis à construire, ce qui va à l'encontre de la méthodologie Agile Dans le deuxième scénario, une équipe publie une petite fonctionnalité toutes les deux semaines, reçoit les commentaires d'utilisateurs réels et les utilise pour décider de la prochaine fonctionnalité à développer. Pause ici si tu veux. Est-ce agile ou non ? C'est Agile. Nos cycles sont courts. Nous avons de vrais commentaires des utilisateurs et des décisions basées sur ce qui a été appris au cours de ce projet pilote, c'est ce que l'on pourrait appeler cela. OK, scénario 3. Le client demande un changement à mi-chemin du projet. L'équipe répond : « Désolé, cela ne figure pas dans le brief original ». Pause ici, si tu veux. Est-ce agile ou non ? Ce n'est pas Agile. N'oubliez donc pas que nous avons la troisième valeur pour la collaboration avec le client par rapport à la négociation de contrats. Accueillez ce changement. Ne le combattez pas. Maintenant, dans le quatrième scénario, l'équipe tient une réunion de 15 minutes tous les matins au cours de laquelle chaque personne partage ses progrès, ses plans et les éventuels obstacles. Ils parlent également de ce qu'ils ont fait hier, ce qu'ils font aujourd'hui, de choses comme ça. Est-ce agile ou non ? C'est Agile. Il s'agit du stand up quotidien classique, qui soutient le sixième principe. conversation en face à face est le moyen le plus efficace de partager des informations. Et dans le scénario 5, une équipe réunit tous les vendredis pour discuter de ce qui s'est bien passé, ce qui ne s'est pas passé et de ce qu'il faut essayer ensuite. Faites une pause ici. Est-ce agile ou non ? C'est Agile. C'est ce que l' on appelle une rétrospective Il s'agit du directeur 12 Lors d'entretiens réguliers, l'équipe réfléchit à la manière de devenir plus efficace. Ils examinent donc les choses qui se sont bien passées, les choses qui ont échoué. Alors marquez-vous. Combien en avez-vous reçu ? Ne vous inquiétez pas si vous en avez raté deux. Ces concepts et ces valeurs seront intégrés au fil du temps. Mais c'est la fin de la première section. 8. Les éléments de base : les sprints, les incréments et la boucle empirique et: Dans cette section, nous allons entrer dans la salle des machines d'Agile. Dans la dernière section, nous avons parlé de l'état d'esprit, et dans celle-ci, nous allons parler de la mécanique. À la fin de cette vidéo, vous saurez ce qu'est un sprint, ce qu'est un incrément, et vous connaîtrez également la boucle simple en trois étapes que les équipes agiles utilisent pour créer de la valeur Alors allons-y. Qu'est-ce qu'un sprint ? Un sprint est un conteneur de longueur fixe destiné au travail. Il s'agit d'une période fixe pendant laquelle une équipe travaille pour effectuer une petite quantité de travail convenue. La longueur est constante. C'est généralement une, deux, trois ou quatre semaines. Deux semaines, c'est de loin le plus courant. Et le mot clé y est corrigé. Un sprint commence toujours le même jour et se termine le même jour. Vous ne le prolongez pas parce que le travail n'est pas terminé et vous ne le raccourcissez pas parce que quelqu'un est en vacances. La boîte horaire est sacrée. Pourquoi est-ce important ? Parce que la prévisibilité est l'une des choses qu' Aja vous apporte Après quelques sprints, vous commencez à découvrir ce que votre équipe peut accomplir de manière réaliste en deux semaines, et ces informations sont essentielles pour la planification. Donc, vous ne l'étendez pas, vous ne le raccourcissez pas. Ce délai est fixe. Ensuite, qu'est-ce qu'un incrément ? C'est ce que vous produisez à la fin de chaque sprint. C'est un élément de valeur petit mais complet qui pourrait être publié ou utilisé, quelque chose de réel. Le point crucial ici est que le mot fonctionne. Ce n'est pas un long métrage à moitié terminé. Ce n'est pas un wireframe. Il ne s'agit pas d'une pile de notes ou de documentation. Il s'agit d'une œuvre petite mais complète qui, en termes de valeur, pourrait être publiée ou utilisée. Pour votre projet Edtech, une augmentation peut être un compteur de temps de travail dans le cas du commerce électronique, il peut s'agir d'une page de produit fini Pour les événements, une réservation de salle confirmée et une date publiée, des choses comme ça. Tellement réel, fini et utilisable. Ensuite, nous avons la boucle empirique. Nous avons trois mots. C'est le moteur complet d'Agile. C'est probablement le concept le plus important de cette vidéo. Cela semble sophistiqué, mais il ne s'agit que de trois étapes simples qui se répètent encore et encore. Transparence, inspection et adaptation. La transparence signifie que tout le monde peut voir ce qui se passe. Le travail est visible sur un tableau, dans un backlog, à un endroit où tout le monde peut le consulter Nous n'avons aucun progrès caché ni aucune surprise. L'inspection signifie que nous examinons régulièrement ce que nous avons produit et comment nous travaillons. Nous ne nous contentons pas d'avancer, nous nous arrêtons pour vérifier. Est-ce ce que le client souhaitait ? Sommes-nous sur la bonne voie ? Est-ce que quelque chose est bloqué ? Et l'adaptation signifie que nous changeons en fonction de ce que nous voyons. Donc, si quelque chose ne fonctionne pas, nous le changeons. Si une partie prenante nous fournit nouvelles informations, nous mettons à jour le plan. Nous ne continuons pas à faire la mauvaise chose simplement parce que c'était prévu dans le plan initial. Nous devons nous adapter. Transparence, inspection, adaptation. C'est le moteur complet d'Agile. Voyons donc comment cela s'intègre. Vous avez votre sprint incrémenté, et vous recommencez. C'est essentiellement ce qu'est Agile. Tu fais un sprint. Disons que cela dure deux semaines. Pendant le sprint, vous rendez le travail transparent sur un tableau. À la fin du sprint, vous avez produit un incrément de travail Ensuite, vous inspectez. Tu le montres aux gens. Vous leur demandez ce qu'ils pensent, vous réfléchissez à la façon dont l' équipe travaille ensemble, puis vous vous adaptez pour le sprint suivant et vous recommencez. C'est le rythme fondamental du travail agile. Sprint, boucle d'incrémentation, sprint, incrémentation, boucle. Oh. Ensuite, nous avons les trois rôles qui le font fonctionner propriétaire du produit, le Scrum Master et l'équipe de développement. Je te verrai pour le prochain. 9. Rôles : propriétaire de produit, Scrum Master, équipe de développement Il reste de l': Bon retour. Dans cette leçon, nous allons examiner les trois rôles qui permettent aux équipes agiles de fonctionner. À la fin de cette vidéo, vous saurez qui fait quoi et pourquoi chaque rôle existe. Nous nous concentrons ici sur le framework Scrum , car c'est le plus courant et les définitions des rôles les plus claires. Commençons donc. Tout d'abord, nous avons le propriétaire du produit, également connu sous le nom de PO. C'est la voix du client au sein de l'équipe. Leur travail consiste à décider ce que l'équipe construit et dans quel ordre. Ils sont responsables du carnet de produits, c' est-à-dire de la liste des tâches prioritaires, et c'est eux qui disent : «   C'est ce qui compte le plus ». Faites-le ensuite. Surtout, le PO n'est pas le patron de l'équipe. Ils ne disent pas à l'équipe comment faire le travail. Ils indiquent à l'équipe ce qu'elle doit faire et pourquoi c'est important. C'est à l'équipe de décider comment. Un bon Product Owner passe du temps avec ses clients. Ils comprennent le métier et prennent des décisions difficiles concernant les priorités. Ils disent « non » parce qu'il y a toujours plus de demande qu'ils n'en ont la capacité. Votre brief de projet, vous jouez peut-être ce rôle vous-même, ce qui est très bien. Souvenez-vous simplement de l'état d'esprit du propriétaire du produit , définissez clairement les priorités , parlez à vos utilisateurs et faites des compromis. Le rôle suivant est le Scrum Master, également connu sous le nom de SM Ce rôle aide l' équipe à bien travailler. Aujourd'hui, c'est l'un des rôles les plus méconnus de l'Agile Scrum Master n'est pas le chef de projet. Ils n'assignent pas de tâches. Ils ne savent pas qui a fait quoi. Ils ne poursuivent pas les gens pour obtenir des mises à jour ou des livrables, et ils ne sont pas les chefs. En fait, ils aident l'équipe à bien travailler. Ils facilitent les réunions. Ils éliminent les obstacles, les obstacles qui empêchent l' équipe de progresser, et ils l'encadrent sur les pratiques agiles Ils protègent également l'équipe de toute ingérence extérieure. L'une des meilleures analogies ici est que le Scrum Master est comme un entraîneur de football. Ils ne jouent pas le jeu. Ils ne disent pas aux joueurs comment botter le ballon, mais ils créent les conditions dans lesquelles l'équipe peut donner le meilleur d'elle-même. petites équipes, le Scrum Master assume souvent un autre rôle, par exemple celui de développeur senior Toutes les responsabilités sont partagées, ce qui est parfaitement normal. Tant que le travail est fait, cela n'a pas vraiment d'importance. Le rôle suivant est celui de l'équipe de développement. Ce sont ces personnes qui fabriquent réellement le produit. Malgré le nom, il ne s'agit pas uniquement de développeurs de logiciels ou de programmeurs L'équipe de développement est composée tous ceux qui créent réellement le produit. Des logiciels, qui seraient des développeurs, mais aussi des concepteurs et des testeurs. Pour un projet marketing, il s'agirait de rédacteurs, de concepteurs, de spécialistes du marketing Pour un événement, ce sont les responsables des opérations, les coordinateurs des conférenciers, le responsable du site, deux éléments clés de l'équipe de développement La première est qu'ils s'auto-organisent. Personne ne leur dit comment répartir le travail. Ils le découvrent eux-mêmes. Et deuxièmement, ils sont interfonctionnels. L'équipe possède toutes les compétences dont elle a besoin pour effectuer une augmentation sans dépendre de personnes extérieures La taille habituelle est de trois à neuf personnes, suffisamment grandes pour que vous ayez toutes les compétences nécessaires et suffisamment petites pour que tout le monde sache ce qui se passe et qui fait quoi. Voyons donc comment ces trois rôles fonctionnent ensemble. Nous avons trois responsabilités qui se recoupent très peu. Le propriétaire du produit décide de ce qu'il doit construire. L'équipe de développement décide comment le construire, et le Scrum Master veille bon déroulement du processus Ces trois rôles et responsabilités se recoupent très peu. Et cette clarté est l'une des raisons pour lesquelles Scrum fonctionne. Tout le monde sait à qui appartient la décision. Si une partie prenante souhaite une nouvelle fonctionnalité, s'adresse au propriétaire du produit. Si un développeur est bloqué, le Scrum Master aide à le débloquer. L'équipe doit décider d'une approche technique, elle la décide elle-même. Maintenant, dans la vraie vie, en particulier dans les petites équipes, une personne peut jouer deux rôles. Vous êtes peut-être le propriétaire du produit et un Scrum Master. Ou, comme je l'ai déjà dit, le développeur senior peut également être le Scrum Master, ce qui est tout à fait normal Les rôles concernent les responsabilités et ne concernent pas spécifiquement les titres de poste. Merci donc de m'avoir rejoint dans cette leçon. Ensuite, nous examinerons le carnet de produits. Nous verrons ce qu'il contient, comment il est structuré et comment en créer un bon. Je te verrai dans le prochain. 10. Le backlog de produits expliqué: Bon retour. Dans cette leçon, nous allons examiner le backlog des produits Il s'agit probablement de l'artefact le plus important du travail agile Et une fois que vous l'aurez compris, beaucoup d' autres choses commenceront à se mettre en place. Ainsi, à la fin de cette vidéo, vous saurez ce qu'est un arriéré, ce qu'il contient et ce qui en fait un bon Alors, qu'est-ce qu'un backlog de produits ? Regardons une définition simple avec trois mots clés. Le carnet de produits est une liste hiérarchisée unique de tous les travaux susceptibles d'être effectués sur un projet ou un Maintenant, il y a trois mots clés dans cette définition. Le premier est célibataire. Il n'y a qu'un seul arriéré. Il n'y en a pas un par membre de l'équipe. Il n'y en a pas un par partie prenante. Nous avons un arriéré. Le mot clé suivant est priorisé. Les éléments figurant en haut de la liste sont les plus importants. Et le troisième est commandé. Il n'y a pas de cravate. Si deux éléments sont d' égale importance, le propriétaire du produit choisit l' un comme étant plus prioritaire que l'autre. Pensez-y comme une liste de souhaits avec une commande. Tout ce que chacun souhaite l'équipe fasse figure finalement dans cette liste, et l'ordre indique à l' équipe ce sur quoi elle doit travailler ensuite. Alors, qu'est-ce qui constitue un arriéré ? En général, nous avons trois types d'articles en attente. Ils figurent tous dans la même liste. Les premiers sont les fonctionnalités. Ce sont donc de nouvelles choses que vous voulez construire. Ainsi, par exemple, ajoutez un compteur de séries, créez une page de paiement ou réservez le lieu. Le deuxième élément serait les correctifs. Ce sont donc des choses qui ne fonctionnent pas ou qui doivent être améliorées. Par exemple, le bouton de connexion ne fonctionne pas sur les appareils Android. Les photos du produit sont trop sombres. Les troisièmes sont les corvées. Ce sont donc des éléments techniques. Ce sont des choses que l' équipe doit faire qui ne produisent pas directement une fonctionnalité mais qui sont nécessaires. Ainsi, par exemple, configurez l'outil d'analyse, renouvelez le nom de domaine, tous les trois vivent dans le même backlog, établissez des priorités ensemble, ce qui est important Vous êtes donc obligé de comparer une nouvelle fonctionnalité une solution critique en fonction d'une dette technique. Aucune liste séparée ne masque les compromis. Vous les classez tous par ordre de priorité dans la même liste. Donc, pour définir un bon carnet de produits, souvenez-vous de l'acronyme Deep À l'heure actuelle, tous les articles d'un backlog ne sont pas définis de la même manière. Nous avons donc ici un acronyme utile pour décrire ce que devrait être un bon carnet Donc, profond ou profond. D est pour les détails appropriés. Les articles situés en haut du carnet de commandes qui seront bientôt traités devraient contenir beaucoup de détails Les éléments situés près du bas peuvent être vagues. Ne perdez donc pas votre temps à perfectionner quelque chose qui ne sera peut-être jamais fait E est pour une estimation. Chaque article doit avoir une sorte d'estimation de la taille. Il n'est pas nécessaire que ce soit des heures ou des jours. Nous parlerons des story points plus tard, mais l'équipe devrait avoir une idée approximative de la taille de chaque objet. Le E suivant est pour Emergent. Le backlog n'est jamais terminé. De nouveaux articles sont ajoutés en permanence. Les anciens éléments sont modifiés ou supprimés. Maintenant, c'est bon pour la santé. Ce n'est pas un signe d'échec. Enfin, P est priorisé. Il y a un ordre clair. Les articles les plus importants sont prioritaires. Le propriétaire du produit est responsable du maintien de ce flux de courant. Pour constituer votre carnet de commandes. Nous avons trois étapes. Cela prend, oui, une heure ou deux de travail, selon la taille du projet. La première des trois étapes est donc le brainstorming. Sortez tout de votre tête et mettez-le dans une liste. Ne vous inquiétez pas pour une commande pour l'instant. Ne vous inquiétez pas pour la taille. Il suffit de tout déposer sur votre page. Chaque fonctionnalité, chaque correction, chaque corvée. Visez au moins 20 objets. Deuxième étape, le regroupement et le nettoyage. Regardez votre liste. Certains articles peuvent être des doublons. Les objets seront donc trop gros pour être exécutés en un seul sprint et devront être décomposés. Certaines seront trop petites et pourront être combinées à d'autres tâches. La troisième étape consiste à établir des priorités. Placez l' élément le plus important en haut. plus important signifie celui qui offre le plus de valeur à l'utilisateur, le plus tôt et avec le moins d'effort, puis faire de même pour l'article suivant et le Et à la fin, vous aurez un carnet de commandes. Tout cet exercice devrait vous prendre une heure, peut-être deux. Nous le ferons pour de vrai dans la section suivante. Ensuite, nous avons les user stories, qui sont le format de chaque article de votre backlog Merci de m'avoir rejoint dans cette leçon. Je te verrai dans le prochain. 11. Histoires d'utilisateurs : Écrire dans le « En tant que..., je veux..., Alors que... » format: Bon retour. Dans cette leçon, nous allons découvrir le modèle le plus utile d'Agile, la user story. À la fin de cette vidéo, vous serez en mesure de rédiger une histoire utilisateur pour n'importe quel élément de votre backlog, et vous saurez ce qui constitue une bonne histoire d'utilisateur et ce qui en fait une mauvaise C'est donc un aspect absolument essentiel des projets agiles. Le modèle classique, commençons par ce qu'une user story n'est pas. Un user story n'est pas une spécification détaillée. Il ne s'agit pas d'un contrat ou d'une liste d'exigences. Une user story est une courte déclaration qui décrit ce que veut un utilisateur et pourquoi. Le modèle classique, que vous verrez partout, ressemble à ceci. En tant qu'utilisateur, je veux un objectif. C'est donc une raison. Il y a trois parties : qui, quoi et pourquoi. Par exemple, en tant qu'apprenant qui revient, je veux voir combien de jours d'affilée je me suis entraînée afin de me motiver à continuer Notez les trois éléments l'utilisateur, le but et la raison. Alors pourquoi ce format fonctionne-t-il ? Il y a trois raisons pour lesquelles la structure rigide vaut le coup. Premièrement, cela vous oblige à identifier l'utilisateur. De nombreuses fonctionnalités sont créées de nos jours sans que personne ne se demande à qui elles sont destinées. Créez un tableau de bord, mais pour qui et pour quoi, le format de l'histoire utilisateur rend cette question incontournable Deuxièmement, il se concentre sur l' objectif et non sur la solution. Notez donc que l'histoire ne le dit pas, ajoutez un widget de compteur de séries sur la page d'accueil. Ça dit : « Regarde combien de jours d' affilée je me suis entraînée. Désormais, l'équipe est libre de trouver la meilleure solution pour atteindre cet objectif. C'est peut-être un compteur, peut-être une vue du calendrier, peut-être une notification. L'histoire ne dicte rien. Et troisièmement, il explique pourquoi cette partie est souvent la plus ignorée, mais c'est la plus importante Sans cela, vous ne pouvez même pas dire si l'histoire vaut la peine d'être racontée. Si vous n'arrivez pas à rédiger un article convaincant à ce sujet, peut-être que l'histoire ne devrait pas du tout être en retard Examinons donc quelques exemples pour chaque brief de projet. Donc, dans Edtech, en tant que parent, je veux voir les rapports hebdomadaires sur les progrès mon enfant afin de savoir si l'application fonctionne réellement Dans le commerce électronique, l'histoire d'un utilisateur peut être celle d'un visiteur pour la première fois Je souhaite connaître les frais d'expédition clairs avant d'ajouter un article à mon panier, afin de ne pas être surpris lors du paiement. Et dans le cas des événements, une user story peut ressembler à celle d'un sponsor Je veux avoir une description claire de ce que comprend chaque niveau de parrainage afin de pouvoir décider dans lequel m'engager. Maintenant, remarquez que dans chaque cas, il y a un utilisateur réel , un objectif clair et une raison raisonnable pour cet objectif. Aucune d'entre elles n'est technique. Aucun d'entre eux ne prescrit de solution, et c'est le point idéal. Maintenant, qu'est-ce qui caractérise une mauvaise histoire ? Examinons quatre modes de défaillance courants. Tout d'abord, l'échec est trop vague. Par exemple, en tant qu'utilisateur, je souhaite bénéficier d'une meilleure expérience pour être heureuse. Maintenant, ce n'est pas une histoire. C'est comme un souhait. Que signifie encore « mieux » ? C'est totalement irréalisable. Un deuxième échec masquerait une solution. En tant qu'utilisateur, je veux un bouton rouge dans le coin supérieur droit pour pouvoir cliquer dessus. Maintenant, ce n'est pas une histoire. Ce n'est qu'une spécification de conception déguisée en une seule. Nous n'avons aucun objectif ni aucune raison si aucune solution n'est prescrite. Troisième échec trop important. En tant qu'utilisateur, je souhaite disposer d'un système de gestion de compte complet afin de pouvoir gérer mon compte. Ce n'est pas une histoire. C' est comme un projet complet. Une bonne histoire doit être suffisamment petite pour être terminée en un seul sprint, et si ce n'est pas le cas, elle doit être décomposée. Le quatrième échec est l'absence du « tel », de l'absence de la raison. Donc, en tant qu'utilisateur, je souhaite me connecter. Pourquoi ? Sans cela, vous ne pouvez pas juger si cela vaut la peine de le faire en premier lieu. Il existe donc un acronyme utile que nous pouvons utiliser ici pour désigner ce que devrait être une bonne histoire d'invest INVEST. Indépendant, négociable, précieux, estimable. Petit et testable. Indépendant signifie que cela ne dépend pas rédaction préalable d' une autre histoire, dans la mesure du possible. Négociable signifie que les détails peuvent changer au fur et à mesure que nous en apprenons davantage. Précieux signifie qu'il fournit quelque chose qui intéresse l'utilisateur. Estimable signifie que l'équipe peut approximativement le dimensionner. Petit signifie qu'il tient en un seul sprint, et testable signifie que vous pouvez savoir quand c'est terminé Maintenant, ne mémorisez pas cela maintenant. Écrivez-le peut-être, mais souvenez-vous simplement de l'acronyme. Et si vous êtes bloqué sur une user story, vous pouvez parcourir cet acronyme pour essayer de l'améliorer. Oh, merci de m'avoir rejoint dans cette leçon. Dans la leçon suivante, nous ajouterons les derniers éléments d' une bonne histoire utilisateur, savoir les critères d'acceptation et la définition de Done. Ce sont les éléments qui vous indiquent que le sprint est réellement terminé. Je te verrai donc dans le prochain. 12. Critères d'acceptation et définition de « fait »: Bon retour. Dans cette leçon, nous aborderons l'une des questions les plus délicates Comment savons-nous que quelque chose est terminé ? Nous utiliserons deux outils clés pour comprendre cela : les critères d'acceptation et la définition de terminé. Commençons donc. Maintenant, que signifie même Done ? Si vous n'êtes pas d'accord, l'équipe se disputera à chaque sprint. Voici donc une question. Quand est-ce qu'une fonctionnalité est terminée ? C'est à ce moment que le code est écrit ? C'est à ce moment-là qu'il a été testé ? Est-ce fait une fois qu'il a été déployé ? Est-ce terminé lorsque l' utilisateur peut l'utiliser ? Est-ce que c'est fait lorsque la documentation est mise à jour ? Si vous n'êtes pas d'accord sur ces points, vous vous retrouverez avec des arguments à chaque étape. Quelqu'un pourrait dire : « Oui, c'est fait », et quelqu'un d'autre dira «   non, ce n'est pas fait ». Les tests n'ont pas été effectués. Cette ambiguïté peut donc anéantir l'élan. C'est pourquoi les équipes agiles utilisent deux outils complémentaires, les critères d'acceptation. Ils sont spécifiques à une seule histoire et à la définition de Done, qui s'applique à tout. Examinons donc d'abord les critères d'acceptation. Il s'agit de déclarations courtes et spécifiques qui peuvent décrire ce qu'une histoire doit faire pour être acceptée par le propriétaire du produit. Ils vont de pair avec l'histoire de l'utilisateur. Prenons donc le contre-récit que nous avons écrit plus tôt. Donc, en tant qu'apprenant qui revient, je veux voir combien de jours d'affilée je me suis entraînée afin de me motiver à continuer Les critères d'acceptation peuvent être les séries d'émissions sur l'écran d'accueil. La séquence est remise à zéro si une journée est manquée. La séquence indique le chiffre actuel, et non les records historiques La séquence s'affiche correctement sur le téléphone et la tablette. Notez maintenant qu' elles sont spécifiques, qu'elles sont testables et qu'elles sont liées à cette histoire utilisateur unique Ils ne prescrivent pas le design, mais ils vous indiquent exactement ce que doit faire le produit fini. En règle générale, voici trois à cinq critères d'acceptation par histoire. Si vous en avez plus que cela, votre histoire est probablement trop longue. Regardons maintenant la définition de Done. agit d'une liste de contrôle qui s'applique à chaque travail produit par l'équipe Ce n'est pas qu'une histoire. C'est pour chacun d'entre eux. Une définition typique de Terminé peut inclure le travail qui a été évalué par des pairs, le travail a été testé. Le travail a été documenté le cas échéant. L'œuvre a été déployée à un endroit où les utilisateurs peuvent la voir. Tous les critères d'acceptation pour l'article en question ont été remplis, et l'équipe rédige cette liste et l'applique de manière cohérente. Il s'agit du filet de sécurité qui permet de détecter les éléments que les critères d'acceptation des critères pourraient ne pas détecter. Les critères d'acceptation diront que cette histoire précise fait ce qu'elle doit faire. Une définition de Done indique que ce travail répond à nos exigences de qualité. Pour un brief non logiciel, la définition de done serait différente. d'un événement, il se peut que la tâche soit documentée dans le journal du projet. Tous les contrats sont signés et déposés. Et les coûts sont enregistrés dans le suivi du budget. Les parties prenantes concernées ont été informées. Voici donc la définition de «  terminé » pour un événement, par exemple. Alors, comment s'adaptent-ils ? Une histoire est vraiment terminée lorsque ses critères d'acceptation sont remplis et que la définition du fait est satisfaite. Les deux, pas l'un ou l'autre, les deux. C'est la norme. Une fois que vous avez mis ces deux outils en place, les arguments, que cela soit fait ou non devraient disparaître à la fin d'un sprint. Voilà pour les critères d'acceptation et la définition de Done. Ensuite, nous avons un petit exercice pratique, qui consistera à rédiger trois témoignages d'utilisateurs pour le brief de projet que vous avez choisi, avec des critères d' acceptation. Je te verrai donc dans le prochain. 13. Exercice pratique : rédigez trois histoires d'utilisateurs pour votre brief: Bonjour, et bon retour. la dernière vidéo de cette section. Nous allons faire de l'exercice d' entraînement. Dans la dernière vidéo, nous avons examiné témoignages des utilisateurs et les critères d'acceptation. Dans cette vidéo, nous allons faire un petit exercice dans lequel vous pouvez écrire vos propres user stories. À la fin de cette période, vous aurez vos premiers articles de carnet de commandes prêts à être utilisés Donc, tout ce dont vous aurez besoin, c'est d'un endroit où écrire, alors utilisez votre stylo et votre papier. Ou si vous avez déjà configuré Trello, vous pouvez utiliser Trello et utiliser une carte Trello, ou vous pouvez utiliser une page Notion si vous préférez taper, mais l'outil ici n'a pas vraiment ou vous pouvez utiliser une page Notion si vous préférez taper, mais l'outil C'est davantage sur le contenu que nous devons nous concentrer. Donc, première étape, première étape. Avant d'écrire un article, identifiez trois types d'utilisateurs différents pour votre projet. Les utilisateurs ont des besoins différents, et un bon carnet de commandes devrait en tenir compte Donc, pour Edtech, vous pourriez avoir un enfant apprenant, un parent et un enseignant E, ce sont trois personnes très différentes, d'ailleurs, donc elles auront trois objectifs différents. Pour le commerce électronique, vos trois personnes peuvent être un nouveau visiteur, un client fidèle et un client retournant un produit. Et pour les événements, vous pourriez avoir un participant, un conférencier et un sponsor Et encore une fois, chacun d'entre eux se soucie de choses différentes. Choisissez donc trois personnes, notez-les et mettez la vidéo en pause maintenant. Tu as besoin de temps pour réfléchir. Passons à la deuxième étape. Il est donc temps d' écrire les histoires. Vous avez une histoire par utilisateur. Utilisez donc ce modèle en tant qu'utilisateur. Je veux un objectif, c'est pour ça. Une histoire par utilisateur, respectez strictement ce format. Cela semble rigide au début, mais cette force est une pensée claire. Et oui, il n'est pas nécessaire que ce soient les histoires les plus intelligentes. Pense juste à ceux qui sont évidents. Quelle est la chose la plus élémentaire que souhaite chaque utilisateur et commencez par là. Vous pouvez donc suspendre la vidéo maintenant et écrire vos trois histoires si vous avez besoin de quelques minutes pour le faire. Troisième étape, pour chaque histoire, écrivez trois à cinq critères d'acceptation. Alors, souvenez-vous, spécifique, testable et lié à cette histoire Par exemple, si vous racontez que, en tant que participant, je souhaite un calendrier de conférence clair afin de pouvoir planifier ma journée Vos critères d'acceptation ici peuvent être que le calendrier indique toutes les sessions avec les heures. L'horaire est disponible en ligne avant l'événement, et chaque section indique le nom du conférencier. Le programme peut être filtré par piste ou par sujet. Alors, mettez la vidéo en pause maintenant. Vous pouvez ajouter des critères, désolé, à vos trois articles maintenant. Alors, on y va. Vous devriez maintenant avoir vos trois user stories et vos critères d'acceptation. Maintenant, gardez-les en sécurité. Nous allons les utiliser à nouveau dans la troisième section. Nous les utiliserons pour compléter votre carnet de commandes. Bravo, vous êtes arrivés la fin de la deuxième section. Dans la section suivante, nous verrons comment configurer correctement l' espace de travail de votre projet. Bravo pour être arrivé aussi loin, je vous verrai dans la troisième section. Bon retour. Dans cette leçon, nous examinerons les trois rôles qui permettent aux équipes agiles de fonctionner. À la fin de cette vidéo, vous saurez qui fait quoi et pourquoi chaque rôle existe. Nous nous concentrons ici sur le framework Scrum, car c'est le plus courant et les définitions des rôles les plus claires Commençons donc. Tout d'abord, nous avons le propriétaire du produit, également connu sous le nom de PO. C'est la voix du client au sein de l'équipe. Leur travail consiste à décider ce que l'équipe construit et dans quel ordre. Ils sont responsables du carnet de produits, c' est-à-dire de la liste des tâches prioritaires, et c'est eux qui disent : «   C'est ce qui compte le plus, passez Surtout, le PO n'est pas le patron de l'équipe. Ils ne disent pas à l'équipe comment faire le travail. Ils indiquent à l'équipe ce qu'elle doit faire et pourquoi c'est important. C'est à l'équipe de décider comment. Un bon Product Owner passe du temps avec ses clients. Ils comprennent le métier et prennent des décisions difficiles concernant les priorités. Ils disent « non » parce qu'il y a toujours plus de demande qu'ils n'en ont la capacité. Pour le brief de votre projet, vous jouez peut-être ce rôle vous-même, ce qui est tout à fait normal. N'oubliez pas l'état d'esprit du propriétaire du produit , définissez clairement les priorités , parlez à vos utilisateurs et faites des compromis. Le rôle suivant est le Scrum Master, également connu sous le nom de SM Ce rôle aide l' équipe à bien travailler. Aujourd'hui, c'est l'un des rôles les plus méconnus de l'Agile Le Scrum Master n'est pas le chef de projet. Ils n'assignent pas de tâches. Ils ne savent pas qui a fait quoi. Ils ne poursuivent pas les gens pour obtenir des mises à jour ou des livrables, et ils ne sont pas les chefs. En fait, ils aident l'équipe à bien travailler. Ils facilitent les réunions. Ils suppriment les obstacles, les objets qui empêchent l' équipe de progresser. Encadrez l'équipe sur les pratiques agiles. Ils protègent également l'équipe de toute ingérence extérieure. L'une des meilleures analogies ici est que le Scrum Master est comme un entraîneur de football. Ils ne jouent pas le jeu. Ils ne disent pas aux joueurs comment botter le ballon, mais ils créent les conditions dans lesquelles l'équipe peut donner le meilleur d'elle-même. Dans les petites équipes, le Scrum Master souvent un autre rôle, par exemple celui de développeur senior Toutes les responsabilités sont partagées, ce qui est parfaitement normal. Tant que le travail est fait, cela n'a pas vraiment d'importance. Le rôle suivant est celui de l'équipe de développement. Ce sont ces personnes qui fabriquent réellement le produit. Malgré le nom, il ne s'agit pas uniquement de développeurs de logiciels ou de programmeurs L'équipe de développement est composée tous ceux qui créent réellement le produit. Pour les logiciels, il s' agirait de développeurs, mais aussi de concepteurs et de testeurs. Pour un projet marketing, il s'agirait de rédacteurs, de concepteurs, de spécialistes du marketing Pour un événement, ce sont les responsables des opérations, les coordinateurs des conférenciers, le responsable du site Deux points essentiels à propos de l'équipe de développement. La première est qu'ils s'auto-organisent. Personne ne leur dit comment répartir le travail. Ils s'en aperçoivent eux-mêmes. Et deuxièmement, ils sont interfonctionnels. L'équipe possède toutes les compétences dont elle a besoin pour augmenter ses effectifs sans dépendre de personnes extérieures La taille habituelle est de trois à neuf personnes, suffisamment grandes pour que vous ayez toutes les compétences nécessaires et suffisamment petites pour que tout le monde sache ce qui se passe et qui fait quoi. Voyons donc comment ces trois rôles fonctionnent ensemble. Nous avons trois responsabilités qui se recoupent très peu. Le propriétaire du produit décide de ce qu'il doit construire. L'équipe de développement décide comment le construire, et le Scrum Master veille bon déroulement du processus Ces trois rôles et responsabilités se recoupent très peu. Et cette clarté est l'une des raisons pour lesquelles Scrum fonctionne. Tout le monde sait à qui appartient la décision. Si une partie prenante souhaite une nouvelle fonctionnalité, s'adresse au propriétaire du produit. Si un développeur est bloqué, le Scrum Master aide à le débloquer. Et si l'équipe doit décider d'une approche technique, elle la décide elle-même. Maintenant, dans la vraie vie, en particulier dans les petites équipes, une personne peut jouer deux rôles. Vous êtes peut-être le propriétaire du produit et un Scrum Master. Ou, comme je l'ai déjà dit, le développeur senior peut également être le Scrum Master, ce qui est tout à fait normal Les rôles concernent les responsabilités et ne concernent pas spécifiquement les titres de poste. Merci donc de m'avoir rejoint dans cette leçon. Ensuite, nous examinerons le carnet de produits. Nous verrons ce qu'il contient, comment il est structuré et comment en créer un bon. Je te verrai dans le prochain. 14. Configurer votre projet : Visiter de Trello : tableaux, listes, cartes, étiquettes: Bonjour, et bienvenue dans la troisième section de notre cours de gestion de projet. Dans cette section, nous allons examiner certains des outils gratuits que vous pouvez utiliser pour gérer votre projet. Le premier que nous allons examiner s'appelle Trello. Il s'agit d'un outil gratuit et assez simple que nous pouvons utiliser pour gérer nos arriérés de produits, et nous pouvons également gérer nos sprints donc dans cette section certains des concepts que nous avons examinés précédemment utiliserons donc dans cette section certains des concepts que nous avons examinés précédemment. Alors allons-y. Tout d'abord, je vais passer en revue les quatre composants principaux de Trello, puis je vais ouvrir Trello et vous montrer un exemple de son utilisation et, oui, vous montrer à quel point c'est et, oui, vous montrer Tout d'abord, Trello se compose principalement d'une carte, d'une carte Cam band Nous avons un tableau par projet. L'ensemble de votre projet sera affiché ici. Toutes les histoires d'utilisateurs seraient donc affichées ici. Le tableau est composé de listes. Dans notre exemple, nous allons utiliser quatre colonnes ou quatre listes qui représentent les étapes du travail. Nous avons donc le backlog, qui serait composé de toutes les tâches et de toutes les histoires d'utilisateurs Nous devons le faire, ce qui serait des éléments engagés dans le sprint. Alors, combien allons-nous en faire au cours de cette période de deux semaines ? Quelqu'un travaille activement à accomplir, puis toutes les tâches qui sont terminées et prêtes à être célébrées sont terminées. Donc oui, le travail se déroule de gauche à droite. C'est assez simple. Maintenant, dans chaque liste, nous aurons des cartes individuelles. Il s'agit donc d'éléments de travail ou de tâches individuels. Nous avons un user story par carte. Donc, dans une carte, nous avons mis le titre qui serait la user story. Dans ce cas, nous allons simplement le mettre en tant que personne, je le souhaite, puis nous mettrons cette section comme titre. La description inclura l'intégralité du témoignage de l'utilisateur, et nous collerons également un lien vers Notion , car Notion est un autre outil gratuit que nous allons examiner dans cette section, et il est possible de lier Notion à Trello C'est donc très utile. Nous avons la liste de contrôle, que nous allons appeler critères d'acceptation Ce sont les tâches qui doivent être effectuées pour que la carte soit considérée comme terminée. Ensuite, nous avons des étiquettes avec type de priorité, puis la catégorie d'utilisateur. Je vais donc vous montrer les différentes étiquettes. Ce sont les étiquettes colorées qui rendent le tableau lisible en un coup d'œil. Nous avons les étiquettes de priorité, lesquelles nous utiliserons le rouge, le jaune et le vert. Nous avons les étiquettes de type, et nous n'allons pas les utiliser pour l'instant, puis nous avons les étiquettes d'utilisateur. C'est une bonne idée de choisir, vous savez, couleurs distinctes dans ces sens Et encore une fois, je vais vous le montrer lorsque nous regarderons la visite. Encore une fois, rester simple est une bonne idée. C'est une bonne pratique. Cinq à huit étiquettes, Max. Tout cela devient assez complexe, et vous aurez probablement besoin d'une clé pour comprendre ce que sont toutes les couleurs. Passons donc à Trello. Dans Trello, vous pouvez vous inscrire gratuitement, puis une fois que vous êtes inscrit et que vous avez créé In Trello, vous accédez aux tableaux des sections, et vous verrez tous vos vous accédez aux tableaux des sections, et vous verrez tous Il y en aura un par défaut ici, comme un modèle par défaut Mais nous voulons créer un nouveau conseil d'administration. Donc, si vous cliquez sur Créer un nouveau tableau, le titre du tableau est ici, nous allons donc simplement le mettre. L'exemple que je vais utiliser est Edtech. Nous allons donc le mettre ici. Nous allons simplement l'appeler exemple. Puis cliquez sur Créer. Et c'est aussi simple que cela. Maintenant, ici, nous devons remplir le tableau avec nos listes Nous avons donc un arriéré. Si vous cliquez sur Ajouter une liste, nous devons le faire, nous l'avons fait et nous l'avons fait. C'est ça. Nous avons donc les quatre, les quatre listes. Je vais maintenant vous montrer le tableau que j'ai préparé plus tôt. C'est donc exactement pareil, mais j'ai rempli le backlog avec quelques user stories Alors oui, pour ce faire, ajoutons une nouvelle carte. Je vais donc créer une nouvelle histoire d'utilisateur. En tant qu'apprenant, je souhaite gagner des accessoires pour mon avatar. OK ? Ajoutez donc cette carte. Maintenant, si vous cliquez sur la carte pour l'ouvrir, vous disposez désormais de ces différentes options. Mettons dans la description, tout d' abord, intégrons l'intégralité de l'histoire de l'utilisateur. OK. En tant qu'apprenant, je veux gagner des accessoires à partir de mon avatar afin de pouvoir les personnaliser. J'ai l'impression que c'est le mien, et nous allons les enregistrer Et puis pour les étiquettes, j'ai donc renseigné les étiquettes ici. Vous pouvez cliquer sur «   Créer une nouvelle étiquette , désolé », pour modifier l'étiquette. Il suffit de cliquer dessus. Vous pouvez ensuite choisir le titre, puis vous pouvez choisir n'importe quelle couleur. J'ai opté pour des couleurs assez faciles à distinguer. Changeons simplement celui-ci aussi. Voilà. Donc, pour celui-ci, disons que c'est une priorité moyenne et que c'est l'apprenant OK ? Nous avons donc ces deux étiquettes, et nous pouvons les voir ici. Ensuite, nous allons ajouter la liste de contrôle. Cette liste de contrôle s' appellerait donc critères d'acceptation. Ensuite, nous cliquons sur Ajouter, et nous ajouterons ici les éléments qui doivent être complétés pour que les critères d'acceptation soient considérés comme remplis. Pour cela, nous aurons besoin d' une bibliothèque d' accessoires. Signé. Nous aurons besoin d'animations pour les nouveaux accessoires, et nous aurons également besoin d'une bibliothèque de sons pour les accessoires. Donc, bibliothèque d'effets sonores. OK ? Nous avons donc ces trois choses, et c'est tout. Nous avons donc ajouté toute l'histoire de l'utilisateur, nous avons ajouté les critères d'acceptation, et voilà. Maintenant, si c'est dans le cadre du prochain sprint, vous devez le mettre ici. Encore une fois, suffit de cliquer dessus et de le faire glisser, et c'est aussi simple que cela. Ou vous pouvez passer à l' action. Maintenant, si c'est le cas, vous pouvez commencer à cocher certaines de ces cases pour montrer que c'est fait Et puis, une fois que les trois sont terminés, nous pouvons voir que cela passe à 100 %. Si on le ferme. Trois éléments sur trois sont complétés ici, les éléments de la liste de contrôle, vous pouvez donc voir ici les éléments de la liste de contrôle Si vous cliquez dessus, il s'agrandira. Tu peux en montrer plus si tu veux. Oui, c'est très simple. Très intuitif. Et puis, oui, une fois que c'est terminé, nous le déplaçons sur Terminé. C'est ça. C'est ainsi que vous gérerez votre carnet de produits et, vous savez, que vous allez y transférer les user stories Maintenant, si vous êtes le propriétaire du produit, vous confiez peut-être ces tâches à l'équipe de développement Dans ce cas, vous devez cliquer ici, membres, puis rechercher les membres qui feront partie de votre équipe, les ajouter et les affecter à la tâche. Voilà pour Trello. Dans la section suivante, nous allons avoir un bref aperçu de Notion. 15. Tour de Notion : pages, bases de données, modèles: Bonjour, et bon retour. Dans cette vidéo, nous allons voir Notion , un autre outil gratuit que nous pouvons utiliser. Dans ce cas, nous allons l'utiliser pour gérer nos sprints. Encore une fois, comme nous l'avons fait dans la vidéo précédente, je vais vous donner un bref aperçu de Notion et de ses concepts, puis je vais vous présenter Notion et vous montrer exactement ce qu'il puis je vais vous présenter Notion et vous montrer faut faire pour créer ces pages. Donc, Notion est très simple. Il s'agit essentiellement d'un document qui peut contenir d'autres documents. La structure recommandée serait donc quelque chose comme ça. Nous avons le titre My Agile Project, puis en dessous, nous avons différentes sous-pages pour chaque type de document. Je vais vous montrer exactement comment procéder lorsque vous regarderez la visite. Vous pouvez également ajouter des tables ou des bases de données. C'est donc comme une feuille de calcul, mais chaque ligne est une page Vous pouvez donc ouvrir, par exemple, là où il est écrit dans la colonne sprint, vous avez obtenu le sprint 1. Lorsque vous cliquez dessus, nous accédons à la page du premier sprint, vous trouverez plus de détails. Et je vais vous montrer comment procéder sous peu. Vous cliquez donc sur n'importe quelle route pour l' ouvrir en pleine page. Il s'agit des mêmes données. Il y a deux manières de voir les choses. Il s'agit d'un tableau scannable et d'une collection de pages détaillées Les bases de données sont extrêmement utiles dans Notion, et ce sera l'une des principales choses que vous utiliserez lorsque vous l'utiliserez. Ensuite, nous allons également examiner les modèles. Ainsi, par exemple, avec les user stories, cela aurait probablement la même structure à chaque fois. Nous pouvons donc préremplir la structure de chaque nouvelle entrée. Pour un modèle de planification de sprint, par exemple, nous aurions l'objectif du sprint, les éléments du backlog sélectionnés et le contrôle de capacité Et cette structure serait la même à chaque fois qu'elle serait répétée pour chaque sprint. Nous pouvons donc créer ce modèle et l' utiliser encore et encore. Nous allons donc examiner un modèle de planification de sprint, ainsi qu'un modèle rétrospectif, qui sont les réunions que vous organisez après chaque sprint et où vous discutez de ce qui s'est bien passé, à améliorer et points à améliorer et des mesures à prendre pour le sprint suivant Ensuite, vous pouvez tout connecter en utilisant le signe arobase. Vous pouvez donc taper « nous en avons décidé ainsi » lors des Decision Streak Awards, et cela vous dirigera vers une page spécifique , et il vous suffira de cliquer sur OK . Passons maintenant à Notion. Il ne s'agit pas d'une explication détaillée de l' utilisation de la vidéo Notion, car cela dépasserait de loin le cadre de ce cours. Notion possède de très nombreuses fonctionnalités, dont beaucoup, vous savez, vous n'utiliserez probablement jamais, mais les plus élémentaires sont celles que vous utilisez probablement. Vous pouvez donc trouver des vidéos en ligne pour apprendre à l'utiliser. Même le site Web de Notion lui-même propose des didacticiels assez basiques, et c'est tout ce que vous devez vraiment savoir faire pour bien utiliser Notion. Voici donc un exemple du sprint de projet Edtech que j'ai créé dans Notion Il se compose de quatre pages. Nous avons un plan de sprint. Nous avons des rétrospectives, des décisions et des mises à jour avec les parties prenantes Dans le cadre de la planification du sprint, j'ai créé une nouvelle base et j'ai ajouté différentes colonnes. J'ai donc le nom. J'ai le numéro du sprint. J' ai la plage de dates. J'ai l'objectif du sprint, et j'ai le statut. Maintenant, lorsque j'ouvre cette page, je peux également voir différents détails concernant cette étape du sprint. Je peux voir la capacité, et je peux voir certaines histoires. Ici, il y a un lien vers Trello que je vous montrerai dans une vidéo ultérieure J'ai ici une chronique sur les risques et les dépendances. Donc, tous les problèmes que vous prévoyez et qui pourraient vous bloquer dans le sprint, vous devez les inscrire ici, puis aussi une section ici pour les engagements, car oui, l'équipe s'engage à suivre ce plan, puis à fixer la date de début Vous pourriez donc le remplir avec différents sprints si vous participez à des rétrospectives Il s'agit donc, encore une fois, une autre base de données qui peut utiliser les réunions. Maintenant, je recommande d'apprendre à utiliser modèles, car rétrospectivement, ce sera la même structure de réunion encore et encore Vous pouvez donc créer un modèle de rétrospective de sprint. Et là, vous pouvez mettre ce qui s'est bien passé. Vous pouvez mettre ce qu'il faut améliorer et vous pouvez mettre en place des actions. Je viens donc de mettre quelques exemples ici. L'objectif du sprint était clair dès le premier jour, les étoiles apparaissaient à temps. Les stand-ups sont restés moins de 10 minutes, ce qu'il fallait améliorer, nous avons sous-estimé la complexité de l' animation, besoin d'une définition claire de Done pour peaufiner le visuel, et les actions ajoutent une animation revue par le designer à Definition of Done et ont ajouté des informations sur les bibliothèques d'animations avant Vous pouvez donc avoir ici une base de données de toutes vos rétrospectives de sprint, ce qui est très, très important dans la gestion de projet agile est très, très Il est très important que vous utilisiez ces rétrospectives pour prendre des décisions éclairées en matière de produits La page suivante s' intitule « décisions ». Voici donc les décisions que nous avons prises après le sprint précédent. J'ai donc créé ici une nouvelle base de données. J'ai ajouté deux nouvelles décisions. J'ai ajouté quelques colonnes différentes. J'ai pris la décision. J'ai la date. J'ai le pourquoi, et j'ai le qui. Donc, si nous l'ouvrons, nous pouvons déjà voir que la date était le 12 mai. Qui a décidé que c'était l'équipe ? L'équipe a décidé d'utiliser la plateforme Lottie pour les animations, car celles-ci sont plus légères et plus faciles à mettre à jour Nous avons donc le consensus de l'équipe ici. Il est donc bon de garder une trace de toutes vos décisions, car vous pouvez tenir les gens responsables de leurs décisions. Encore un autre exemple : le bord parent différé au sprint trois, ce qui va prendre plus de temps que prévu. Nous avons la date, nous savons qui a décidé du PO, du propriétaire du produit, pourquoi les capacités limitées fonctionnalités destinées aux apprenants sont une priorité absolue Donc, les décisions, les raisons pour lesquelles elles ont été prises et qui a décidé, ont toutes été conservées ici. Ensuite, la dernière page que vous devriez probablement créer est celle des mises à jour des parties prenantes. J'ai donc ajouté, encore une fois, une autre base de données avec le sprint numéro un, la date à laquelle elle a été envoyée et à qui elle a été envoyée. J'ai donc créé une nouvelle page, mise à jour rapide sur le leadership. Il est envoyé à l'équipe de direction. L'objectif du sprint a-t-il donc été atteint ? Oui, les objets envoyés au système Star Reward et à la sélection des avatars ont été expédiés . Ce sont les produits de travail qui sont expédiés. expédié le résumé de l'e-mail parent, que nous avons déplacé vers le sprint Oh, sprint trois, pas le sprint deux. Et lors du prochain sprint, des séries de points focalisés et des rappels quotidiens, d'accord ? Donc, les parties prenantes avec qui vous avez informé de l' avancement du projet. Vous pouvez enregistrer tout cela ici. Donc, oui, c'est la fin de notre visite de Notion. Prochaine étape : constituer votre premier carnet de commandes. Nous allons donc créer un nouveau backlog à partir de zéro dans Trello. C'est très pratique, donc je vous verrai pour la prochaine vidéo. 16. Créer votre premier backlog de produit dans Trello: Bonjour, et bon retour. Dans cette section, vous allez créer votre premier backlog de produits dans Trell Vous allez le faire à partir de zéro. Vous pouvez maintenant utiliser la vidéo précédente comme référence, mais je vais vous donner le guide étape par étape pour créer votre premier backlog de produits dans Trell La première étape consiste donc à configurer votre tableau, le créer, à le nommer d'après le brief que vous avez choisi au début de ce cours. La deuxième étape consiste à ajouter quatre listes, votre carnet de tâches en cours et terminé Et puis, si vous le souhaitez, vous pouvez choisir une couleur de fond. Vous pouvez le personnaliser. Cela dépend de vous. La deuxième étape consiste à réfléchir. Maintenant, vous voulez faire un braindump de tout ce dont votre projet pourrait avoir besoin. Désormais, vous n'avez pas encore besoin de le filtrer ou de l'affiner. Visez donc environ 15 à 20 matières premières. Je veux dire, si tu ne peux en avoir que dix, c'est bon. Ou moins, c'est bon. Assurez-vous simplement d'en avoir plusieurs. Tapez chacune d'elles sous forme de fiche trellcard rapide dans la liste du backlog. Et puis ne vous inquiétez pas encore pour le format de l'histoire, découvrez tout. Ensuite, l'étape suivante serait d'écrire les user stories. Transformez donc ces éléments bruts en histoires appropriées avec les critères. Dans ce cas, deux éléments bruts se combineraient peut-être deux éléments bruts se combineraient pour former une histoire utilisateur. Pour ce faire, ouvrez chaque carte, réécrivez le titre dans le en tant qu'utilisateur Je le veux pour pouvoir le formater. Dans la description, ajoutez les détails complets de l'histoire. Comme vous l'avez vu dans la vidéo précédente, j'ai juste utilisé les sections ASA et I Want comme titre, puis j'ai utilisé le tout dans la description. En dessous, vous ajouterez vos critères d'acceptation avec les deux ou trois éléments testables. Cela pourrait être plus. Dans la vidéo précédente, nous avions quatre objets. Ce sont les choses qui doivent être faites pour que cette histoire utilisateur soit considérée comme complète. Ensuite, la dernière chose que vous pouvez faire est d' affiner d'abord les cinq à sept principaux éléments. Les autres peuvent attendre, en faire autant que vous le souhaitez, mais n'en faites pas trop. Encore une fois, nous sommes en train d'apprendre à utiliser Trello. La quatrième étape serait d'étiqueter et de prioriser chaque carte Créez donc vos étiquettes de priorité, haute, rouge, moyenne, jaune ou orange, et la priorité basse est généralement verte. Ajoutez des libellés de type ou d'utilisateur si nécessaire. Pour mon projet EdTech, les trois personnes impliquées dans le projet EdTech étaient l'enseignant, l'élève et le parent Vous ne pouvez avoir qu'un ou deux utilisateurs ici. Ou plus. Vous devez ensuite faire glisser vos cartes les plus prioritaires vers le haut de la liste du backlog C'est, vous savez, le rôle typique d'un Product Owner. Vous hiérarchisez les tâches en conséquence. Et puis souvenez-vous de la matrice valeur-F lorsque vous établissez des priorités, les tâches les plus rapides l' emportent généralement, puis, enfin, cinquième étape consiste à affiner et à vérifier le bon sens. Alors, tout d'abord, mes cinq principaux articles répondent-ils à l'acronyme Invest ? Si je ne faisais que figurer parmi les cinq premiers, est-ce que les utilisateurs s'en porteraient mieux, oui ou non, et y a-t-il manifestement quelque chose qui manque ? Assurez-vous donc de vérifier ces trois éléments avant de considérer que votre journal est terminé Il existe certains pièges courants que vous devez éviter. Le premier est d'être trop gros. Encore une fois, il n'est pas nécessaire de créer un énorme arriéré ici Donc oui, ne créez pas un carnet de 80 articles que vous ne reverrez plus jamais Vous savez, viser 15 à 25, c' est peut-être un peu trop. Dix est un bon chiffre. Ne soyez pas trop vague, soyez très précis sur qui, quoi et pourquoi. Et enfin, oui, avoir gravé dans le marbre. Il s'agit d'un écueil courant Vous ajouterez, supprimerez et réorganiserez chaque semaine. Le carnet de commandes de produits est en constante évolution. Ce n'est jamais gravé dans le marbre. Les choses vont toujours changer. Vous allez toujours modifier même les noms de colonnes que vous pourriez changer à un moment donné. Ensuite, nous verrons comment lier Notion à Trello. Il s'agit donc de relier les deux outils en un seul système connecté. Je te verrai pour le prochain. 17. Lier Notion à Trello pour la documentation: Bonjour, bon retour. Dans cette courte vidéo, nous allons voir comment associer Notion à Trello À présent, votre exemple de carnet de produit devrait donc être intégré dans Trello, et votre squelette de documentation devrait également être intégré Je vais vous montrer rapidement comment et pourquoi nous associons les deux outils. Tout d'abord, pourquoi les lier ? Trello et Notion sont tous deux très utiles pour la gestion de projet, mais ils établissent tous deux des liens et s'alignent sur différents modes de pensée Trello se concentre donc plutôt sur quel travail ? Où se trouve-t-il, qui le fait, donc l' avancement réel des projets au jour le jour. Alors que Notion s'apparente davantage à des informations sur les décisions qui ont été prises. Pourquoi en avons-nous décidé ainsi ? Qu' avons-nous appris et quel est le plan ? Notion, en tant qu' outil de documentation convient généralement mieux réflexion et à la planification à long terme, tandis que Trello est destiné à la planification à court terme et à la gestion à court terme de projets et de sprints Il existe donc deux méthodes pour lier Notion et Trello. Tout d'abord, il y a les liens Trello de Notion, qui sont un peu plus sophistiqués que les liens Notion Et je vais vous montrer ce que je veux dire dans une minute. Mais tout d'abord, vous cliquez sur une carte dans Trello, vous avez copié l'URL depuis le navigateur Collez-la dans votre page Notion, puis Notion vous montrera un aperçu en direct de cette carte. C'est donc un peu plus sophistiqué : lorsque vous collez un aperçu de la carte, il est chargé à l'endroit où vous avez collé cette URL Deuxième méthode, les liens Notion dans Trello ne sont pas aussi sophistiqués, et il ne s'agit que du Pour ce faire, vous ouvrez la page Notion que vous souhaitez lier. Vous cliquez sur Partager et copiez le lien vers cette page, puis vous pouvez le coller dans la description de la carte dans Trello, ce qui est très utile Cependant, ce n'est pas le cas, il n'y a aucun aperçu d'une carte ou de quoi que ce soit d'autre, mais toute personne ayant accès à la carte peut cliquer directement sur le lien et accéder à cette page. Donc, si vous n'avez pas encore construit votre structure de notions, faites-le maintenant. Vous devriez donc avoir quatre sous-pages, une pour la planification du sprint, une pour les rétrospectives, une pour les décisions et une pour les mises à jour des parties prenantes En réalité, au fur et à mesure de l'avancement de vos projets, ces sous-pages s' agrandiront ces sous-pages s' agrandiront de plus en plus, de plus en plus de détails y seront ajoutés. Il est donc très important que vous ayez, vous savez, le squelette de cette structure pour commencer. Donc oui, dans le prochain exercice, nous verrons comment assembler tout cela, mais avant de passer je vais rapidement vous montrer exactement comment ajouter ce que nous devons ajouter pour lier les deux outils. Nous avons donc notre tableau Trello. Nous avons notre document Notion. Et ce que je vais faire, c'est lier Trello à Notion. Je vais donc copier un lien depuis Trello et le mettre dans Jetons donc un coup d'œil à la planification du sprint. Nous avons ce système de récompenses par étoiles, le sprint. Je vais ouvrir cette page. Et vous vous souvenez peut-être dans la vidéo précédente lorsque j'ai ouvert cette page, il y avait un aperçu d'une carte ici. Il s'agit du lien Trello. Je vais vous montrer comment procéder maintenant. Je dois donc trouver cette histoire sur mon tableau Trello, et je l'ai ici En tant qu'apprenant, je souhaite gagner des étoiles en terminant les leçons Pour créer un lien, il suffit de cliquer avec le bouton droit sur cette carte, puis de cliquer sur ce bouton ici, Copier le lien. Une fois que c'est copié, nous pouvons revenir à Notion puis le coller ici. Et comme vous pouvez le constater, nous avons maintenant le choix. Nous pouvons le coller comme aperçu. Vous pouvez le coller sous forme de mention ou nous pouvons simplement coller l'URL. Nous allons coller un aperçu. Et c'est tout. Ainsi, lorsque vous cliquez dessus , la carte s'ouvre directement dans Trello C'est donc très, très utile. Voyons maintenant comment ajouter le lien entre Notion et Trello Donc, si nous ouvrons cette carte, comme vous pouvez le voir, j'ai déjà le lien ici. Je viens de le copier-coller dans la description. C'est donc assez simple avec Notion pour copier-coller. Cliquez sur ce bouton. Ainsi, quelle que soit la page que vous souhaitez lier dans Trello, vous l'ouvrez, cliquez sur les trois points, puis sur Copier le lien. C'est aussi simple que ça. Ensuite, dans la description, vous le collez ici. Et comme vous pouvez le voir, c'est exactement le même lien. Donc oui, je vais le supprimer. Et c'est tout. C'est aussi simple que cela. Il vous suffit de copier des liens et de les coller aux bons endroits Ensuite, configurez votre espace de travail, assemblez le tout. Je te verrai alors. 18. Exercice pratique : aménager votre espace de travail de projet: Bon retour. Il est donc temps de passer l'exercice pratique qui clôt toute cette section. Si ce n'est pas déjà fait, vous allez configurer l'espace de travail complet que vous utiliserez pour le reste du cours, votre tableau Trello, votre structure de notions À la fin de cette vidéo et de cette section, vous serez donc prêt pour la planification du sprint décrite dans la section 4. Donc, si vous ne l'avez pas encore fait, voici votre liste de huit points Voici ce que vous devez avoir fait à la fin de l' exercice, huit éléments. Je vais les parcourir rapidement, puis vous pourrez faire une pause et les parcourir à votre rythme. Le premier, le tableau Trello créé et nommé d' après votre brief Ensuite, au moins 15 éléments sont en attente sous forme de témoignages d'utilisateurs, étiquettes de priorité créées et appliquées Donc, les listes avec un arriéré à faire et à faire, cinq meilleurs articles contenant des listes de contrôle des critères d'acceptation page principale d'une notion intitulée My Agile Project ou quelque chose comme ça. Et au moins une page de notions possède un lien Trello, et au moins une carte Trello contient un Cela devrait donc être votre liste de contrôle des huit points. Pour la configuration de Trello, juste un petit rappel si vous avez fait le dernier exercice de la leçon, devriez tout faire de toute façon Mais, tout d'abord, assurez-vous que votre tableau existe. Ça s'appelle. Vous avez les quatre listes en place. Votre carnet de commandes est rempli et vos cinq meilleures histoires d'utilisateurs ont été affinées avec des critères d'acceptation et des étiquettes En fait, je recommanderais de mettre des étiquettes sur chacun d'entre eux car c'est ce que vous devrez faire. Configuration des notions. Assurez-vous donc d'avoir créé quelques modèles et d'avoir votre structure en place, vous devriez avoir votre page principale avec le titre, et c'est la maison de tout. Ensuite, vous devriez avoir vos quatre sous-pages avec la planification du sprint, les rétrospectives, les décisions et les mises à jour des parties prenantes Encore une fois, si vous voulez structurer cela d'une manière différente, c'est très bien. La structure que j'ai utilisée n'est qu'un moyen simple de le faire. Si vous voulez le rendre plus chic ou plus sophistiqué. Allez-y. C'est ta prérogative Enfin, essayez de créer au moins deux modèles. Donc, un pour la planification des sprints et un pour la rétroactivité Ils sont donc prêts à être utilisés, car il s'agira de deux modèles que vous utiliserez encore et encore Vous devez planifier les sprints, et vous devez faire votre rétrospective sur ces donc très important pour la planification du sprint est donc très important pour la planification du sprint d'avoir ces deux modèles déjà configurés et prêts à être utilisés. Donc, trois questions avant de terminer. Ouvrez les deux outils côte à côte et passez de l'un à l'autre en un clic. La deuxième chose à vérifier est une personne nouvelle dans le projet pourrait comprendre votre projet en 5 minutes, simplement regardant le tableau et en regardant la notion. Et puis vous pourriez aussi vous demander s' il manque manifestement quelque chose dont vous pensez avoir besoin la semaine prochaine ? Probablement les modèles. Les modèles peuvent être quelque chose que vous pourriez oublier. Assurez-vous d'avoir au moins deux modèles prêts à être utilisés pour notre section de planification des sprints. C'est tout pour la fin de la section 3. Nous avons terminé Trello. Nous avons terminé Notion. Vous savez, nous avons quelques bases sur lesquelles travailler dans notre prochaine section, laquelle nous planifierons votre premier sprint. Voici donc notre plongée dans le véritable travail de planification de projet. Je vous verrai dans la section 4. 19. Planifier votre premier sprint : Prioriser le backlog : Moscou et valeur vs effort: Bonjour, et bienvenue dans la quatrième section de notre cours de gestion de projet. Dans la troisième section, nous avons examiné la configuration de vos espaces de travail dans Trello Nous arrivons maintenant au cœur de l'Agile, qui consiste à décider quoi faire réellement et dans quel ordre. Dans cette leçon, nous aborderons les deux techniques de priorisation simples et puissantes que vous pouvez utiliser immédiatement, Moscow et la matrice valeur-effort . Alors pourquoi la priorisation est-elle difficile ? Maintenant, cette priorisation est probablement la compétence la plus difficile en gestion de projet en gestion de projet agile Ce n'est pas parce que les techniques sont compliquées. C'est parce que le dire peut être douloureux. Ainsi, chaque élément de votre carnet de commandes compte pour quelqu'un, et chacun d'entre eux a été ajouté pour une bonne raison Mais la vérité, c'est qu' on ne peut pas tout faire. Si tu essaies de tout faire, tu ne livreras rien de bon. La priorisation est la discipline qui consiste à accepter cela et à choisir où passer votre temps limité. Les techniques que nous aborderons ne sont que des outils destinés à rendre ces choix plus faciles et plus défendables La première technique est donc la méthode de Moscou. La première technique porte l'abréviation MoSCoW. Les lettres majuscules désignent quatre catégories. Les indispensables auraient dû, auraient pu et n' auront pas les éléments indispensables. Sans ceux-ci, le sprint ou la publication échoueront Ils ne sont pas négociables. Ainsi, par exemple, si vous lancez un système de paiement, la capacité de prendre de l'argent est indispensable. Si votre événement a des conférenciers, il est indispensable d'avoir une scène. Si oui, ils sont importants, mais le sprint ou la sortie peuvent réussir sans eux. Ils peuvent être mal à l'aise de les laisser de côté, mais cela ne cassera rien. Ainsi, par exemple, un bon message d'erreur sur un formulaire de connexion est un must. C'est bien, mais vous pouvez expédier sans le produit ou travailler sans lui. J'aurais pu les avoir. C'est bien de les avoir. Ils sont moins prioritaires. Si vous avez le temps, vous pouvez les inclure. Ainsi, par exemple, une animation de chargement plus sophistiquée ou une intégration bonus, choses qui font plaisir, comme une cerise sur le gâteau, pour qu'elles ne réussissent pas ou ne se cassent pas Enfin, nous n' aurons pas de décisions explicites de ne pas inclure quelque chose dans un sprint ou dans une version. Les plus fortunés sont donc un choix actif pour déprioriser. Le fait de les documenter permet d' éviter un glissement de la portée par la suite. La discipline est donc qu' un arriéré prioritaire en bonne santé à Moscou compte environ 60 % des arriérés obligatoires, 20 % devraient, 20 % pourraient le faire Si vous avez 80 % d'éléments indispensables, vous n'avez pas établi de priorité. Vous venez de tout rebaptiser «   urgent ». Examinons maintenant la matrice valeur-effort. Nous en avons parlé un peu dans la section deux. Jetons maintenant un coup d'œil à ce qu'il est utilisé correctement. Donc, pour cela, vous pouvez dessiner une grille rapide deux par deux. L'axe vertical représente la valeur. Comment cet article aidera-t-il vos utilisateurs ou votre entreprise ? Maintenant, l' axe horizontal est l'effort. Combien de travail faudra-t-il pour livrer ? Et cela vous donne quatre quadrants. En haut à gauche se trouvent une valeur élevée, un faible effort, des gains rapides, faites-le en premier. Ils créent une dynamique. Ils débloquent des choses, et ils sont assez bon marché Il n'y a aucune raison de les retarder. En haut à droite se trouvent une valeur élevée, un effort élevé, de gros paris, passez-les en deuxième position. Ils sont très importants, mais ils demandent un vrai travail. Planifiez-les, décomposez-les et faites-le délibérément. En bas à gauche, nous avons une faible valeur mais un faible effort. Ce sont donc des fillers. Ils ne sont pas essentiels, mais ils sont peu coûteux en temps et en ressources. Placez-les entre vos objets les plus gros là où l'équipe a de la capacité inutilisée. Et puis en bas à droite, nous avons une faible valeur et un effort élevé. Il suffit de les jeter, de les supprimer. Ils ne gagnent pas le temps qu'ils coûtent. S'ils comptent vraiment, ils reviendront et vous pourrez reconsidérer votre position. Mais l'un des pièges dans lesquels tombent la plupart des équipes est passer beaucoup de temps dans le quadrant Big Bet fonctionnalités importantes qui prennent des mois à être livrées, vous obligent à trouver les gains rapides, à faire des compromis. Cela permettra de maintenir l' élan pendant les gros paris. utilisant tous les deux ensemble, vous devriez maintenant les compléter l'un avec l'autre. Vous ne devriez pas les utiliser en compétition. Ils travaillent très bien ensemble. Commencez donc par Moscou pour classer l'ensemble de votre carnet de commandes. Cela vous donne une idée rapide des progrès réalisés. Maintenant, prenez vos éléments indispensables et ceux que vous devriez avoir et placez-les sur la matrice valeur-effort Et cela vous donnera l'ordre dans lequel vous les aborderez. Maintenant, pourquoi les combineriez-vous ? Parce que Moscou vous indique ce qui compte, la valeur par rapport à l'effort vous indique ce qu'il faut faire en premier. Combiné, vous obtenez un backlog classé par ordre d'importance et également séquencé par ordre d'importance et également séquencé Maintenant, appliquez-le à votre brief. Ouvrez donc votre tableau Trello. Prenez vos 15 meilleurs articles, vos dix ou 15 meilleurs articles. Faites-les d'abord passer par Moscou. Utilisez les étiquettes que vous avez définies dans la section 3. Ajoutez donc quatre étiquettes de Moscou, rouge pour moût, orange pour chaussure, jaune pour cud, grise pour wont, puis prenez vos moûts et vos shuds et classez-les Le joueur rapide gagne en tête de votre liste de backlog, gros pari à la deuxième place, les joueurs entre les deux Tout ce qui tombe dans le champ. Archivez-le dès maintenant. Ne soyez pas attaché à ces choses-là. Donc, deux outils simples appliqués transformeront honnêtement votre façon de planifier et de prioriser. Merci donc de m'avoir rejoint dans cette leçon. Dans le prochain article, nous examinerons les estimations sans mentir, avec quelques exemples utilisant des tailles de t-shirts et des points narratifs. Je te verrai dans le prochain. 20. Les bases de l'estimation : les tailles de t-shirts et les points de l'histoire Points Points Points: Bonjour, bon retour. L'estimation est l'un des aspects de la gestion de projet agile lesquels beaucoup de gens se trompent. Ils le considèrent comme une prédiction, mais ce n'est pas le cas. Dans cette leçon, nous allons donc examiner deux méthodes honnêtes pour estimer la taille de l'œuvre, la taille des t-shirts et les points de l'histoire. Vous saurez ainsi comment augmenter votre carnet de commandes sans vous mentir ni mentir à vos parties prenantes Donc, d'abord, ce qu'est une estimation et ce qu'elle n'est pas, commençons par une chose dès le départ. Une estimation est une estimation basée sur ce que vous savez maintenant. Il ne s'agit ni d'une promesse , ni d' un engagement, ni d'une date limite. Cela semble évident, mais la plupart des équipes l'oublient. Quelqu'un demande combien de temps cela va prendre, et l'équipe répond trois semaines. Et trois semaines deviennent un rendez-vous. Cela devient un engagement. Maintenant, l'équipe panique, travaille tard, réduit les coûts ou parce que quelqu'un confondu une estimation avec un contrat Une bonne estimation est honnête en ce qui concerne l'incertitude. Il dit : « Cela semble petit ou cela semble grand », puis il utilise cela pour planifier, et non pour promettre. Les tailles de t-shirt sont donc floues exprès. Les humains sont mauvais pour les chiffres absolus. Donc, la première et la plus simple technique d'estimation, tailles de t-shirt : très petit, petit, moyen, grand, très grand. C'est ça. Pas de chiffres, pas d'heures, pas de jours. Mais pourquoi est-ce si vague ? C'est parce que c'est le but. Les humains sont très mauvais pour estimer en unités absolues. Demandez à n'importe quel développeur combien de temps prendra quelque chose en jours, et vous obtiendrez probablement une mauvaise réponse. Mais si vous leur demandez s'il s'agit d'une petite ou moyenne taille, vous obtiendrez une réponse précise. Voici donc comment l'utiliser. Pour chaque article de votre carnet de commandes, l'équipe convient d'une taille de t-shirt. Très petit, c'est banal, petit, peut-être une demi-journée de travail, moyen, un jour ou deux, un sprint de grande envergure, c' est trop gros, c'est trop gros, il faut le décomposer Maintenant, ce dernier point est important. Si quelque chose continue d'être étiqueté L, c'est un signe qu'il doit être divisé en petits morceaux. Et tout ce qui est plus important qu'un simple sprint n'est pas une histoire, c'est une épopée. Cela doit être décomposé. Les tailles de t-shirt sont parfaites pour les débutants et pour les travaux non logiciels. Si vous rédigez les événements en bref, c'est probablement la technique que je commencerais par utiliser. Ensuite, il y a les Story Points. C'est un peu plus structuré, et c'est plus courant dans les équipes de développement. Story Points sont des nombres qui suivent généralement la séquence de Fibonacci Un, deux, trois, cinq, huit, 13, 21, selon Fibonacci, c'est parce que les écarts s'accroissent à mesure que les chiffres augmentent, ce qui reflète le fonctionnement La différence de 1 à 2 est faible. La différence de 13 à 21 est énorme parce que vous ne savez pas vraiment quelle est la taille de l'un ou l'autre Les story points ne nous appartiennent pas. Les points narratifs représentent la taille relative d'une œuvre par rapport aux autres. Cinq, ce n'est pas cinq heures ou cinq jours. Cela représente cinq fois plus d'efforts qu'un article en un seul point pour votre équipe. Pour utiliser les points d'histoire, choisissez un petit récit de référence selon votre équipe, vaut, disons, deux points. Ensuite, estimez que tout le reste est deux fois plus long que cela. C'est un cinq, deux fois moins grand, c'est un. À peu près de la même taille, c'est un deux. La magie des story points, c'est qu'ils permettent votre équipe de mesurer ce qu'elle livre généralement par sprint, c'est ce que l'on appelle la vélocité. Nous approfondirons la vélocité dans le deuxième cours. Alors, comment faire une estimation en équipe ? Quelle que soit la technique que vous choisissez, la façon dont vous effectuez réellement l'estimation est importante. La technique classique s'appelle le planning du poker. L'équipe se réunit, lit une histoire. Tout le monde choisit secrètement une taille ou un chiffre, et au bout de trois, tout le monde le révèle en même temps. Si vous êtes tous à peu près d'accord, alors l'estimation est celle que vous choisirez tous. Terminé. S'il y a désaccord, c'est ce qui est intéressant. Ne fais pas la moyenne. Vous demandez aux estimateurs les plus élevés et aux plus bas d' expliquer leur Souvent, l'un d'entre eux sait quelque chose que les autres ignorent. Par exemple, vous ne saviez pas que l'API n'a pas ce champ, nous devrons le créer nous-mêmes. Donc, après la discussion, votez à nouveau, puis généralement vous convergez Si vous travaillez seul sur votre projet pour ce cours, vous pouvez toujours le faire, estimez honnêtement. Et chaque fois que vous terminez une histoire qui s'est révélée très différente de votre estimation, vous pouvez en prendre note. C'est comme ça que tu t'améliores. Oh, les estimations sont des êtres vivants. Un dernier principe est que les estimations ne sont pas gravées dans le marbre. Au fur et à mesure que vous en apprendrez davantage, vous les modifierez. Encore une fois, c'est un concept fondamental de la gestion de projet agile, donc c'est très sain. Un article que vous avez écrit comme moyen la semaine dernière peut sembler petit maintenant que vous en avez fait un similaire. Une histoire que vous pensiez très petite s'est révélée énorme une fois que vous avez commencé à en gratter la surface. Donc tu es une estimation. Ce n'est pas un échec. Apprendre et s'adapter. Les équipes qui obtiennent la bonne estimation sont celles qui traitent leurs estimations comme des hypothèses, comme tout le reste dans Agile. Donc, des objectifs de sprint qui comptent. Ce sera dans notre prochaine leçon, une phrase, mais elle est très axée sur les résultats. Merci donc de m'avoir rejoint pour cette leçon, et je vous verrai dans la prochaine. 21. pour fixer un objectif de sprint: Bonjour et bon retour. Jusqu'à présent, nous avons parlé de priorisation et d'estimation, et nous arrivons maintenant à un concept modeste mais assez puissant, l'objectif du sprint À la fin de cette très courte leçon, vous saurez ce qu'est un objectif de sprint, pourquoi chaque sprint en a besoin et comment en rédiger un qui concentre les efforts de votre équipe. Des choses très importantes ici. OK, qu'est-ce qu'un objectif de sprint ? Il s'agit d'une phrase unique mais concise sur le résultat d'un sprint. Il s'agit d'une phrase qui décrit ce que votre équipe essaie de réaliser dans ce sprint spécifique. Ce n'est pas le travail que tu vas faire. C'est le résultat que tu souhaites. L'objectif du sprint est la réponse à cette question. À la fin de ce sprint, ce qui sera vrai n'était pas vrai au départ. Il ne s'agit donc pas d'une liste ou d'un jalon. Il s'agit d'un changement réel et significatif. Pourquoi sont-ils importants ? Nous avons donc trois raisons principales pour lesquelles chaque sprint a besoin d'objectifs de sprint. Ces objectifs sont donc très importants, même si de nombreuses équipes les ignorent. Premièrement, ils concentrent l'équipe. Sans objectif, chaque histoire du carnet de sprints semble tout aussi importante Lorsque vous avez un objectif, vous pouvez voir quelles histoires le font réellement progresser et lesquelles ressemblent à des quêtes secondaires. Deuxièmement, ils vous aident à prendre des décisions à mi-sprint. Les choses changent toujours. Sans objectif, chaque changement devient un débat avec votre équipe. qui concerne un objectif, vous vous demandez si ce changement nous aide à l'atteindre ? Si oui, vous le faites, sinon, passez au sprint suivant ou vous ne le faites pas du tout. Et la troisième raison pour laquelle ils créent un objectif commun . Les gens travaillent plus fort et mieux lorsqu'ils comprennent pourquoi. Un backlog de sprint sans objectif n'est qu'une liste de tâches. Un objectif de sprint soutenu par un backlog est comme une mission principale Alors, qu'est-ce qu'un bon objectif de sprint ? Nous avons quatre qualités, toutes importantes. Le premier est axé sur les résultats. Décrit ce qui change, et non ce que vous allez créer. Expédier la fonctionnalité de connexion est donc une tâche. Les utilisateurs récurrents peuvent ainsi accéder à l'historique de leurs commandes. Pour être précis, c'est suffisamment précis pour savoir que vous l'avez atteint. Des objectifs vagues tels que l'amélioration de l'application n'aident personne. Bien trop vague. Cependant, quelque chose comme augmenter la rétention dès le deuxième jour en simplifiant l'embarquement Tu as quelque chose à viser vraiment. La troisième est réalisable. C'est réalisable au sprint. Si votre objectif prend trois mois, il ne s'agit pas d'un objectif de sprint. C'est comme l'objectif de sortie. Réduisez-le pour que ce soit réalisable. Et le quatrième, c'est que c'est une seule chose. Un but par sprint, sans exception. Si vous avez trois objectifs, vous n'en avez aucun car aucun d' entre eux n'est prioritaire. Il est donc très important que vous n'ayez qu'un seul objectif par sprint. Permettez-moi donc de vous montrer à quoi ressemble un bon objectif de sprint pour chaque brief d'Edtech À la fin de ce sprint, élèves de 6 ans peuvent gagner et voir des étoiles après avoir terminé les leçons C'est spécifique, c'est axé sur les résultats et c'est réalisable en deux semaines Notez qu'il ne dit rien sur les fonctionnalités que vous allez créer. Les articles sur le carnet de sprints répondent à cette question. Pour le commerce électronique, à la fin du sprint, nos trois meilleurs nouveaux produits écologiques seront disponibles sur le site avec des descriptions complètes, des photos et des prix. Encore une fois, il s'agit d'un résultat clair, facilement vérifiable lors du projet d'événements. À la fin du sprint, les cinq conférenciers confirmés et le voyage et l' hébergement réservés Vous avez un résultat précis et mesurable. Donc, si vous remarquez le schéma ici, chaque objectif commence par la fin de ce sprint , puis décrit un changement réel et observable dans le monde Maintenant, où le mettez-vous ? La partie pratique consiste donc à écrire votre objectif de sprint en haut de votre description Trello ou épingler sous forme de carte en haut de votre liste de tâches En fait, mettez-le haut de la page de planification de votre sprint, comme je vous l'ai déjà montré, toute l'équipe devrait le voir en permanence. S'il est masqué, il se peut qu'il n'existe pas. OK, c'est donc la fin de cette leçon. Objectifs de sprint. Une phrase bien pensée peut transformer un sprint. Il est donc très, très important que vous écriviez des sprints clairs et concis à tout moment. Ensuite, nous allons organiser la réunion de planification du sprint. Donc, un sprint de deux heures avec cinq étapes, un modèle, et c'est la prochaine étape. Alors je te verrai alors. 22. Exécution d'une réunion de planification de sprint (avec modèle): Mmm, hum. Bon retour. À ce jour, vous avez priorisé votre carnet Vous avez fait une estimation, vous avez réfléchi à votre objectif de sprint. Il est donc temps de réunir tous ces éléments lors d' une réunion de planification du sprint. À la fin de cette leçon, vous saurez exactement comment organiser une réunion et vous disposerez d'un modèle que vous pourrez utiliser pour chaque sprint encore et encore. Tout d'abord, qu' est-ce que la planification des sprints ? C'est de loin le rendez-vous le plus important du sprint. Vous l'avez au début de chaque sprint, car c'est là que l'équipe décide sur quoi elle va travailler au cours des deux prochaines semaines. Tout ce qui suit cette réunion dépend des décisions que vous prendrez ici. C' est donc extrêmement important. Le conseil classique ici est donc de rester limité dans le temps. 2 heures pour un sprint de deux semaines, c'est la norme. Si c'est plus long, vous avez probablement un peu trop planifié. Il y a un objectif de sprint convenu, et nous avons cinq étapes à l'ordre du jour. Il y a donc deux questions auxquelles chaque planification de sprint doit répondre dans cet ordre. Première question : quel est l'objectif de ce sprint ? C'est ici que vous convenez de l'objectif de sprint que nous avons abordé dans la leçon précédente. Maintenant, c'est généralement le propriétaire du produit qui le propose, puis toute l' équipe discute puis s'engage à le faire Ensuite, la deuxième question est quel travail nous permettra d'atteindre cet objectif. C'est donc vous qui extrayez des éléments de votre backlog et les déplacez dans la liste de tâches Trello Et vous ne faites avancer que les objets qui font avancer l'objectif. Sois donc impitoyable ici. Tout ce qui ne contribue pas directement à l'objectif doit rester dans le backlog pour le sprint suivant Et c'est tout. La réunion répond à ces deux questions et s'achève. Tout le reste ne serait qu'une distraction. Examinons donc le programme en cinq étapes, que vous devriez utiliser pour chaque sprint. Vous pouvez l'utiliser encore et encore. Il s'agit de cinq étapes très simples. La première étape consiste à revoir l'objectif du sprint, prenez environ cinq à dix minutes pour le faire. Le propriétaire du produit propose un objectif, puis l'équipe en discute , et vous êtes tous d'accord. La deuxième étape consiste à évaluer les capacités de l'équipe. Cela prend donc environ 5 minutes. Soyez honnête quant au nombre d' équipes qu'il possède réellement. Donc, s'il y a des vacances ou des jours de maladie, des réunions d'autres engagements, vous ne devez jamais planifier comme si tout le monde travaillait à 100 %, car ce n'est jamais le cas. La plupart des équipes prévoient généralement une capacité d' environ 70 à 80 %. La troisième étape consiste à sélectionner les articles du backlog. Cela devrait prendre entre une demi-heure et une heure. Vous pouvez parcourir chacun des éléments de votre carnet de commandes prioritaires Pour chaque histoire, vous vous demandez si cela permet d'atteindre l'objectif du sprint ? Dans l'affirmative, pouvons-nous l'adapter à nos capacités ? Si vous le pouvez, alors mettez-vous au travail, et vous vous arrêtez lorsque vous aurez atteint votre capacité maximale. La quatrième étape consiste à vérifier le plan, prenez environ dix à 15 minutes. Alors prends du recul. Est-ce que ce produit que vous avez sélectionné fonctionne réellement Atteint-il réellement l'objectif ? Si ce n'est pas le cas, vous devriez échanger quelques histoires. Existe-t-il des dépendances évidentes ? Faites-les apparaître maintenant, pas le cinquième jour. Ensuite, la cinquième étape est de confirmer et de valider. Tout le monde est d'accord, cela prend environ 5 minutes. Toute l'équipe dit oui. C'est ce que nous sommes en train de faire. Tout le monde quitte la salle en connaissant l'objectif, sachant exactement sur quoi il doit travailler et en connaissant son rôle dans ce travail. Regardons donc quelques pièges courants. Ce sont quatre pièges que je vois tout le temps dans lesquels les équipes tombent lorsqu'elles planifient. Essayez de les éviter. Le premier est donc le surengagement. L'équipe se sent obligée d'en faire plus Elle met donc trop d'articles dans la section « à faire », puis elle ne parvient pas à les livrer. Ensuite, ils le surmontent à nouveau lors du sprint suivant pour le rattraper, ce qui constitue un cercle vicieux. Il est donc préférable de s'engager moins et de livrer de manière cohérente. Le deuxième piège consiste à planifier à la perfection. La planification du sprint est une réunion de travail, pas un interrogatoire. Si vous passez 15 minutes à débattre du libellé exact d'un critère d' acceptation, c'est que vous êtes au mauvais rendez-vous Ce serait du raffinement et non de la planification. Alors passez à autre chose. Le troisième piège est de sauter l'objectif il suffit de ramasser les objets et de les atteindre. Non, non, non, non. Sans objectif, le sprint n' est qu'une liste de choses à faire. L'objectif est donc de savoir ce qui fait d'un sprint un sprint. Et le quatrième piège consiste à planifier de manière isolée. Le propriétaire du produit ne doit pas rédiger le plan et le présenter à l'équipe. L'équipe doit planifier ensemble. Ils s'engagent ensemble. C' est cette propriété partagée qui est essentielle. Encore une fois, la gestion agile repose sur le fait que les personnes assument elles-mêmes la responsabilité de leur propre travail. Maintenant, le modèle. Ouvrez donc votre base de données de planification des sprints et créez une nouvelle entrée, une nouvelle page. Remplissez ces sections pour chaque sprint. Donc, votre section 1, que vous pouvez utiliser, titre trois ou titre deux, numéro de sprint et plage de dates juste pour le suivi. La deuxième section serait l'objectif du sprint, qui n'est qu'une phrase. N'oubliez pas de vous concentrer sur le résultat. La troisième section porte sur la capacité. Il n'y a donc aucun congé de maladie, aucun jour férié, aucun engagement de temps connu, le total des heures ou des jours disponibles pour l'équipe. Section quatre histoires sélectionnées, paie les liens de la carte Trello pour tout ce que vous vous engagez à faire avec les estimations, si vous en avez La section 5 porte sur les risques et les dépendances. Donc, quoi que ce soit qui pourrait bloquer l'équipe , des poids externes, des inconnues, dépendances à l'égard d'autres équipes ou fournisseurs ? Ensuite, la section six serait l'engagement. Donc, juste une ligne qui dit : Oui, nous nous engageons à respecter ce plan avec la date. Cela peut sembler inutile, mais cela fait une réelle différence. Le fait de le mettre par écrit crée une responsabilisation. Alors oui, voici votre modèle. Enregistrez-le dans Notion afin de pouvoir l'utiliser chaque fois que vous créez une nouvelle entrée de planification de sprint. 5 minutes d'installation, ce qui vous permettra d'économiser de très nombreuses minutes et probablement des heures plus tard. Maintenant, si vous travaillez seul, la discipline s'applique toujours. Si vous n'avez pas d'équipe avec laquelle planifier, c'est très bien. Organisez vous-même la réunion, bloquez 30 minutes, suivez les cinq étapes, parlez à haute voix, si cela vous aide. Cela peut sembler stupide, mais cela aide. Cela fonctionne. L'objectif de la planification en solo est le même. Vous êtes d'accord sur ce que vous faites, pourquoi et dans quelle mesure. La discipline qui consiste à l'écrire s'applique toujours, et à l'avenir, vous remercierez le présent. Il s'agit donc de planifier un sprint pour deux questions, cinq étapes, un modèle. Dans la section suivante, nous examinerons le backlog des sprints dans Trello Nous examinons comment configurer votre tableau de sprint pour le travail à venir, ce qui est décrit dans la vidéo suivante. Je te verrai alors. 23. Créer votre backlog de sprint dans Trello: Bon retour. Vous avez donc déjà planifié votre sprint. Configurons-le sur votre Trello. Dans cette leçon, je vais donc vous expliquer exactement quoi faire et dans quel ordre. Ainsi, à la fin, vous avez un carnet de sprints prêt à être utilisé. Maintenant, tout d'abord, le backlog produit par rapport au backlog sprint. Il est important de ne pas confondre les deux. Il est donc important que nous fassions une distinction rapide. Il existe en fait deux backlogs dans Agile Même si nous ne disons que le mot backlog, le backlog produit représente tout ce qui pourrait être créé . Il figure donc dans votre liste de backlog sur Trello. Nous l'avons construit dans la section trois. Ce serait tout ce dont vous aurez besoin pour terminer. Votre projet. Le carnet de sprint est un sous-ensemble beaucoup plus restreint que vous vous êtes engagé à respecter au cours de ce Cela se trouve dans vos listes de choses à faire, à faire et à faire. C'est un instantané d'un sprint. Construire votre carnet de sprints ne revient donc pas à créer de nouvelles cartes. Il s'agit de transférer les bonnes cartes du carnet de produits à la liste des tâches première étape consiste donc à ajouter l'objectif du sprint, toujours épinglé dans le champ visible, à créer une nouvelle carte, à ajouter votre objectif de sprint en haut de votre liste de tâches, puis à le faire glisser vers le haut Dans Trello, vous pouvez cliquer sur Ajouter une carte, la déplacer en haut de votre liste de tâches, créer une carte appelée objectif de sprint, coller votre objectif en une phrase dans le titre, ajouter une étiquette de couleur, quelque chose de distinctif, afin qu' elle se démarque des story cards classiques Vous pourriez utiliser un objectif orange vif appelé objectif, par exemple, ou peut-être un noir. Certaines personnes préfèrent plutôt mettre l'objectif du sprint dans la description du tableau, ce qui est bien. L'un ou l'autre fonctionne. L'important, c' est qu'il soit visible. La deuxième étape consiste à transférer les histoires à faire. Donc, la plus haute priorité est au sommet. N'oubliez pas ceci, vous les retirez de votre backlog. Vous allez donc déplacer ces cartes pour toutes les histoires que vous vous êtes engagées dans la planification de votre sprint . Accédez donc à votre liste de backlog, trouvez chaque carte que vous vous êtes engagée à utiliser, faites-la glisser du backlog vers la case à faire L'ordre dans lequel vous les mettez est important, placez votre plus haute priorité au premier plan. Ainsi, lorsque quelqu'un termine une carte et doit récupérer la suivante , le choix est évident. N'apportez pas uniquement ce que vous vous êtes engagé à faire. Le reste reste dans le backlog pour le sprint futur. La troisième étape consiste à mettre à jour les détails de la carte Vous pouvez également créer un lien avec Notion et Trello Alors, troisième étape, ouvrez chaque carte de votre liste de choses à faire, vérifiez tous les détails Le titre comporte-t-il une histoire d'utilisateur appropriée ? La description contient-elle un contexte supplémentaire dont l'équipe a besoin ou les critères d'acceptation figurant dans la liste de contrôle ? Si vous avez ajouté des estimations, sont-elles enregistrées quelque part sous forme d'étiquette ou comme dans la description de la carte ? C'est donc votre dernière chance de faire un bilan de santé mentale et de peaufiner avant le début des travaux Donc, ne sautez pas cette partie. Une carte dont les critères d'acceptation sont faibles devient un argument plus tard, et ce n'est qu'un exemple de mauvaise planification. La quatrième étape consiste à appliquer vos étiquettes si vous ne l'avez pas déjà fait. Encore une fois, souvenez-vous que dans les sections précédentes, nous avons examiné les tailles de t-shirts à Moscou . Appliquez vos étiquettes pour plus de visibilité, ajoutez des étiquettes de Moscou si vous les utilisez, si vous devez, si vous le souhaitez ou si vous le pouvez. Si vous avez une estimation, vous pouvez également ajouter les étiquettes des tailles de t-shirt, SML ou L ou les étiquettes Story Point deux, trois, cinq et huit, si vous optez la séquence de Fibonacci Ces étiquettes vous permettent de voir en un coup d'œil à quoi ressemble le sprint. S'il y a beaucoup d'étiquettes indispensables et de grandes tailles, vous avez surengagé, si vous avez beaucoup de petites cartes, vous avez peut-être une capacité supplémentaire Étape 5 : prenez une capture d'écran de votre carnet de sprints dès maintenant avant de commencer à travailler, enregistrez-la quelque part Les meilleures adresses de Notion. Et pourquoi ? Parce qu'à la fin du sprint, vous voulez comparer ce à quoi vous vous êtes engagé avec ce que vous avez réellement livré. La capture d'écran permet cette comparaison très facilement. C'est également un excellent artefact de portfolio. C'est ce que nous avions prévu, et voici ce que nous avons expédié. Oh, c'est très important. Voilà pour cette section. L'exercice d'entraînement est à venir. Vous allez planifier votre premier sprint maintenant que vous avez décroché la médaille d'or et que vous disposez d'une série d' histoires motivantes avec des étiquettes de visibilité et une capture d'écran. Nous sommes maintenant prêts à tout assembler et à terminer la quatrième section. Je vous verrai donc dans la dernière vidéo de la quatrième section. 24. Exercice de pratique : planifier votre premier sprint: Bonjour, et bon retour. Il est temps de tout mettre en place. Dans cet exercice, vous allez planifier votre premier sprint pour le brief que vous avez choisi, de bout en bout. fois que vous aurez terminé, vous aurez un objectif de sprint, un backlog estimé et hiérarchisé, un backlog de sprint engagé dans Trello ainsi qu'un document de planification du sprint Il s'agirait d'un plan de sprint complet, et vous êtes prêt à l'exécuter lors de la prochaine détection. Donc, tout d'abord, cinq étapes. Donc, le bout en bout devrait prendre environ 45 minutes. Cela vous en prendra peut-être moins. Peut-être en avez-vous déjà fait certaines également. La première étape serait donc de prioriser vos dix principaux articles en retard en utilisant Moscow, en ajoutant vos étiquettes La deuxième étape consiste à faire une estimation avec des tailles de t-shirts ou des story points, selon votre préférence. La troisième étape serait d' écrire votre objectif de sprint avec une phrase concise et axée sur les résultats. La quatrième étape consiste à intégrer toutes les histoires qui font avancer l'objectif dans votre liste de tâches sur Trello et à vous engager à atteindre un montant réaliste Et la dernière étape consiste à remplir votre modèle de planification de sprint en un clin d'œil. Ne sautez pas ceci. C'est l'artefact qui prouve que vous avez fait le travail Voyons donc rapidement à quoi ressemble le bien Voici un exemple concret tiré d'un brief de Ed Tech, afin que vous sachiez ce que vous visez. Objectif du sprint À la fin de ce sprint, les élèves de 6 ans pourront voir étoiles après avoir terminé chaque leçon La liste des tâches contient quatre histoires. Première histoire : les apprenants voient animation après la fin de la leçon. Deuxième histoire, les étoiles sont enregistrées dans le profil de l'apprenant. troisième histoire, les étoiles s'affichent sur l'écran d'accueil, et dans la quatrième histoire, les parents peuvent voir combien d'étoiles leur enfant a obtenu cette semaine. Tous les quatre contribuent à l'atteinte de l'objectif. Ensemble, cela représente environ deux semaines de travail, et la capacité est honnête. L'objectif est très précis et les récits le confirment. Voilà à quoi ressemble le bien. Et il existe également des contrôles de santé mentale que vous pouvez effectuer avant de tout terminer Donc, ces trois questions à me poser, la première si j'avais livré toutes les histoires de ma liste de choses à faire, aurais-je atteint mon objectif de sprint ? Sinon, c'est que vous avez les mauvaises histoires ou que vous avez le mauvais objectif. Deuxièmement, ai-je été honnête quant à mes capacités ou est-ce que je me fais des illusions ? Il vaut mieux s'engager à faire moins et surlivrer plutôt que de trop s'engager et de décevoir les gens N'oubliez pas ceci, c'est essentiel. Et troisièmement, est-ce que quelqu'un de l'extérieur qui regarde mon tableau Trello comprend ce sprint en 30 secondes ? Si la réponse est non, cela signifie que votre objectif n'est pas suffisamment visible ou qu'il n'est pas assez clair. Les erreurs à éviter à ce stade. La première consiste à sauter l'objectif. Je rate l'objectif car les histoires parlent d'elles-mêmes. Non, ils ne le font pas, ils ne le font pas. Sans but, vous ne pouvez pas savoir quand vous gagnez. Ne sautez donc jamais le but. Deuxièmement, inscrire tous les éléments essentiels dans la liste des choses à faire sans penser à la capacité est un non. n' est pas parce que quelque chose est indispensable qu'il doit être fait dans ce sprint. Il faut parfois attendre le futur. Et troisièmement, le fait de remplir le sprint à 100 % de sa capacité laisse toujours de la place aux imprévus. Les vrais sprints ne se déroulent presque jamais comme prévu. donc quelque chose d'autre à retenir il n'a jamais été rempli à 100 %. Et voilà nous sommes arrivés à la fin de la section quatre C'est donc un excellent travail pour rester avec moi jusqu'à présent. Dans la section 5, nous examinerons les tenants et les aboutissants de la course au sprint. Nous examinerons les stands, les critiques, les rétros et l'œuvre elle-même. Bravo pour avoir atteint la fin de la section quatre, je vous verrai dans la section cinq. 25. Exécuter le sprint : le stand up quotidien : format, calendrier et pièges courants: Bienvenue à la section 5 de notre cours de gestion de projet. Donc, jusqu'à présent, vous avez planifié votre sprint. Maintenant, le travail commence. Dans cette leçon, nous aborderons la cérémonie agile la plus connue, appelée le stand up quotidien. À la fin de cette section, vous saurez comment en courir un en 15 minutes, quoi dire, quoi éviter et pourquoi tant d' équipes se trompent. Alors, qu'est-ce qu'un stand ? Il s'agit d'un court bain d'équipe quotidien. Ce n'est pas un rapport de situation. C'est généralement environ 15 minutes. D'habitude, vous l'avez à la même heure, au même endroit, tous les jours du sprint. Et le nom vient de l'idée originale selon laquelle tout le monde se lève littéralement parce que le se lève littéralement parce rester debout réduit la durée de la réunion. Asseyez-vous et vous parlerez pendant une heure. Il ne s'agit donc pas d'un rapport de situation. Ce n'est pas une réunion où le patron surveille les gens. Il s'agit d'une étape rapide où l'équipe s'aligne sur ce qui se passe Surmonte tout problème et prend la bonne direction si nécessaire. Donc, aux trois premières questions, chaque personne répondra à tour de rôle à ces questions en 60 secondes chacune. Il s'agit du format classique. Chacun parle donc à tour de rôle. La première question est : qu' est-ce que j'ai fait hier ? Un bref récapitulatif de vos progrès. Deuxièmement, que vais-je faire aujourd'hui, qu'est-ce que vous allez apprendre ? Trois, c'est ce qui me bloque. Donc, s'il y a des obstacles, des questions ou des dépendances, cela est réglé sur place. Et chaque personne devrait répondre aux trois en 60 secondes environ. Avec une équipe de cinq, cela prendra 5 minutes. Et les 10 minutes restantes sont consacrées aux conversations proprement dites, aux choses qui découlent de ce que les gens viennent de dire, et c'est là que réside la véritable valeur de ces réunions. Les nouvelles directives du guide Scrum se concentrent donc moins sur les trois questions et davantage sur l'objectif Comment pouvons-nous, en tant qu'équipe, progresser le plus possible vers l'objectif du sprint aujourd'hui ? Ces deux approches fonctionnent. Les trois questions sont plus faciles lorsque vous débutez. Vous pourrez développer votre propre approche au fil du temps . Nous aurons le calendrier et la logistique. Voici quelques éléments pratiques qui permettent aux stand-ups de fonctionner. Donc, tout d'abord, chronométrez 15 minutes maximum, réglez un chronomètre lorsqu'il se déclenche, vous vous arrêtez, même si c'est au milieu de la phrase. La pression du chronomètre vous oblige à faire preuve de discipline. Tu devrais le prendre tous les jours à la même heure. Choisissez un moment qui convient à tout le monde. est courant de le faire à 9 h 30 ou 10 h, car cela donne le temps aux personnes qui commencent tôt de s'installer, sans pour autant perdre la matinée Et ne le dites pas à 16 h 00. ici là, la majeure partie de la journée sera terminée Il doit se trouver au même endroit, qu'il soit physique ou virtuel, un emplacement prévisible est très important. La plupart des équipes distantes utilisent généralement un appel vidéo quotidien. En personne, vous devriez tous vous rassembler autour du Cambanbard Et ou pour la télécommande, gardez au moins vos caméras allumées. L'énergie est un peu différente de cette façon, et les gens restent concentrés lorsqu'ils sont debout. Enfin, c'est parcourir le tableau, pas les personnes. Il s'agit d'un changement subtil mais important. Au lieu de faire le tour de l' équipe comme Sarah suit, puis James, parcourez les cartes listes de choses à faire et de terminer. Et pour chaque carte, c'est la personne qui travaille sur cette carte qui parle. Et cela permet de se concentrer sur le travail, et non sur les individus. certains pièges courants, quatre manières dont Évitez certains pièges courants, quatre manières dont les standups tournent mal Évitez d'en faire un rapport de situation. Les gens discutent avec le responsable ou le chef de projet pour énumérer en détail ce qu'ils ont fait sur la défensive. Ce n'est pas le bon public. Le stand up est pour l'équipe, pas pour le boss. Parlez-en à vos pairs. Le deuxième piège, problèmes lors de la réunion. Vous ne résoudrez pas les blocages lors de cette réunion. Si quelqu'un mentionne un bloqueur, nous l'enregistrons pour plus tard. L'équipe commence à réfléchir à des solutions, et 20 minutes plus tard, vous êtes toujours là . Alors ne fais pas ça. Il s'agit de faire ressortir les problèmes, pas de les résoudre. Troisième piège : sauter la réunion lorsque vous êtes occupé. Si nous sommes trop occupés pour prendre la parole aujourd'hui, c'est exactement à ce moment que vous en aurez le plus besoin. Les équipes surchargées le sont donc généralement parce qu'elles ne coordonnent pas assez bien. Sauter le stand up ne fait qu' empirer les choses. C'est comme un cercle vicieux. Ne sautez donc pas ce stand up quotidien. Enfin, Trap Four annule lorsque les gens sont à distance Publions simplement les mises à jour dans Slack maintenant. Je veux dire, c'est bien pour une journée, mais si vous le faites tous les jours de la semaine, l'équipe perdra le sens commun du sprint, et le but de la réunion est la coordination en direct, pas la mise à jour écrite. Donc, si vous le faites en solo, voici quelques adaptations que vous pouvez faire pour des projets solo. Les travailleurs individuels bénéficient toujours d'un enregistrement quotidien. Prenez 5 minutes chaque matin pour ouvrir Trello, regardez votre tableau, demandez-vous ce que j'ai fait hier Que vais-je faire aujourd'hui ? Qu'est-ce qui me bloque ? Écrivez-le quelque part, ne serait-ce que dans une brève entrée de Notion, c'est très bien. Cela peut sembler ridicule de vous parler à vous-même, mais le fait de l'exprimer fait apparaître des problèmes que vous auriez ignorés autrement Alors essayez-le pendant au moins une semaine et vous verrez comment c'est. Ensuite, nous avons visualisation du travail à faire et à faire Le flux à trois colonnes que nous avons configuré dans Trello. Nous y reviendrons plus en détail dans la prochaine vidéo. 26. Visualiser le travail : faire, faire, fait: Bonjour et bon retour. L'idée agile la plus simple et la plus puissante que vous puissiez jamais contrer est la suivante. Rendez l'œuvre visible. Dans cette courte leçon, nous aborderons le flux à trois colonnes qui anime chaque tableau Agile et expliquerons comment bien l'utiliser. Alors pourquoi visualiser ? Voici trois raisons pour lesquelles visualisation est très puissante. Premièrement, tu ne peux pas gérer ce que tu ne peux pas voir. Si le travail réside dans la tête des gens ou dans les fils d'e-mails, il est invisible. Vous ne savez pas où les choses sont bloquées, ce qui est surchargé, qui est surchargé ou quelles sont les deux, cela crée une prise de conscience partagée Toute l'équipe peut voir la même image. Plus rien. Je ne savais pas que tu faisais ça. Je ne savais pas que tu travaillais là-dessus. Tout le monde sait sur quoi chacun travaille. Troisièmement, il résout tous les problèmes de flux. Ainsi, lorsque vous pouvez voir tout le travail en un seul endroit, des schémas apparaissent, des cartes s' accumulent, des cartes bloquées en cours de révision, longs délais entre les listes Chaque schéma indique quelque chose à corriger. Nous avons donc ici les trois listes à faire, à faire et à faire. Sur chaque tableau Agile, ces trois listes font le gros du travail. Il reste du travail à faire pour ce sprint, mais pas encore commencé. Les cartes n'attendent que là-bas. Le haut de la liste est ce que quelqu'un devrait choisir ensuite. Faire, c'est travailler activement en ce moment. C'est là que se concentre l'attention de l' équipe. Et surtout, le travail n'entre en action que lorsque quelqu'un y travaille réellement à ce moment-là. Non, j'y reviendrai plus tard aujourd'hui. Ils le font en ce moment. Le travail terminé est terminé, donc le travail correctement terminé, et non pas terminé à 90 %, sans examen en attente d'examen, est terminé. C'est emballé. Ces trois listes côte à côte vous donnent donc une image en temps réel de la progression du sprint Donc, les limites du travail en cours. Il s'agit d'une astuce puissante que la plupart des débutants risquent de manquer. C'est de limiter le nombre de cartes que vous pouvez jouer en même temps. Maintenant, cela s'appelle une limite de travail en cours ou une limite WIP Pourquoi ? Parce que rien ne tue le progrès comme le fait d'avoir trop de choses à moitié faites. Si cinq personnes ont trois cartes en cours de préparation, vous avez 15 objets en jeu à la fois, et il est presque certain que rien n' est terminé. En règle générale, il ne faut pas plus d'une carte par membre de l'équipe. Certaines équipes utilisent N plus un, donc une équipe de cinq dispose de six emplacements WIP Le nombre exact importe moins lorsque le directeur a terminé les choses avant d'en commencer de nouvelles. Donc, si vous travaillez seul sur votre projet, votre limite de WIP est de un Choisissez une histoire, travaillez dessus, terminez-la, puis choisissez la suivante. Résistez à l'envie de rebondir. Enfin, une fois que vous avez créé un tableau, apprenez à le lire. Il y a donc trois éléments principaux à rechercher au jour le jour. L'un d'eux est le déséquilibre. Une longue liste de choses à faire signifie qu'il y a trop de travail en cours Une liste vide au milieu du sprint signifie que rien n'est terminé Deux sont des cartes qui n'ont pas bougé depuis des jours. Ce sont des cartes bloquées. Découvrez pourquoi ils sont bloqués. Habituellement, il s'agit d'un bloqueur qui n'a pas été levé lors d'une séance debout quotidienne Trois sont vos cartes surprises, des choses qui apparaissent en cours de route et qui ne faisaient pas partie du plan de sprint initial. Ce sont les tueurs silencieux de tout objectif de sprint. Alors faites-leur surface, décidez que nous avons leurs vraies priorités ou s'ils sont réellement des distractions à laisser pour plus tard. Oh, trois colonnes. Une limite d'avancement, une habitude de lire le tableau, et c'est tout. Merci donc de m'avoir rejoint pour cette leçon. Dans le prochain chapitre, nous examinerons gestion des changements en milieu de sprint, ce qui se produit tout le temps. C'est quelque chose que tout chef de projet agile doit être habile à faire. Nous allons donc passer en revue trois questions qui protègent l'objectif, et c'est la prochaine étape. Je vous verrai donc dans la prochaine vidéo. 27. Gérer le changement à mi-sprint: Bonjour, et bon retour. Maintenant, pour être honnête, aucun sprint ne se déroule vraiment comme prévu. Il y a toujours quelque chose qui change. Dans cette leçon, nous allons voir comment vous pouvez effectuer changements en cours de sprint sans paniquer, sans perdre votre concentration et, surtout, sans abandonner votre objectif de sprint initial C'est donc une chose à laquelle il faut s'habituer avec la gestion de projet Agile. Le changement n'est pas un échec. C'est tout à fait normal. À chaque sprint, il se produira quelque chose qui n'était pas prévu. parties prenantes peuvent changer d'avis, un utilisateur peut signaler un bogue critique, peut-être qu'une dépendance échoue, qu'une nouvelle opportunité se présente. Aujourd'hui, le manifeste d'Agi accueille explicitement le changement. Donc, si vous vous souvenez de la quatrième valeur du manifeste, il s'agit de réagir au changement plutôt que de suivre un plan. Cela ne signifie pas que le changement est toujours bon ou toujours acceptable en milieu de sprint. Cela signifie simplement que vous avez un processus pour le gérer au lieu de prétendre que cela ne se produira pas C'est essentiel pour les chefs de projet. Nous allons donc passer en revue un petit cadre décisionnel. Désormais, lorsqu'une demande de modification arrive au milieu du sprint, il s'agit d'un framework simple que vous pouvez utiliser. Nous avons trois questions à poser. La première question est la suivante : est-ce que ce changement nous aide à atteindre l'objectif du sprint ? Si c'est le cas, cela vaut peut-être la peine de le faire. Maintenant, si non, cela va dans le carnet de commandes du produit pour un futur sprint. Deuxième question : cela aide, que devrions-nous laisser tomber pour faire de la place ? La capacité est toujours limitée et vous ne pouvez pas simplement ajouter du travail Vous devez donc faire un compromis. Et la troisième question est l'équipe convient-elle que l'échange en vaut la peine ? Si c'est toute l'équipe qui décide, pas seulement le responsable du produit, en fin de compte, ce sont eux qui font le travail. Si la réponse à ces trois questions est oui, vous pouvez l'échanger. Vous pouvez l'ajouter à la liste des tâches. Si ce n'est pas le cas, vous devez le mettre dans le backlog. Maintenant, la discipline qui consiste à utiliser ce cadre à chaque fois est ce qui vous permettra de protéger votre objectif de sprint. Maintenant, tous les changements ne sont pas égaux. Il existe trois catégories approximatives que nous pourrions utiliser ici : les urgences. Par exemple, le site est en panne, un bogue critique touche utilisateurs ou un problème juridique vient d'arriver, et ils sont vraiment impatients. Alors déposez quelque chose et échangez-le. Mais soyez honnête, les véritables urgences sont assez rares. Si tout est urgent, rien n'est urgent. Ensuite, nous avons ce qui est important , mais pas urgent. Par exemple, une nouvelle idée de fonctionnalité évolution intéressante du marché ou demande d'une partie prenante qui compte mais qui ne change rien. Ils peuvent être ajoutés au backlog des produits, ajouter une fiche et les classer par ordre de priorité pour le prochain sprint. Ne vous inquiétez pas et ne vous laissez pas distraire lorsque quelqu'un a une nouvelle idée, qui semble bonne, mais qui n'est pas vraiment liée à l'objectif du sprint, mettez-la poliment dans le backlog et passez La plupart des demandes de mi-sprint entreront dans cette catégorie. Maintenant, comment dire non, c'est assez difficile en tant que chef de projet. Les gens détestent entendre non, et vous détesterez le dire. Voici donc trois techniques qui vous aideront à ne pas brûler un pont. Il y a donc un « oui » dans le backlog. Ne dites donc pas non à l'idée elle-même, mais dites oui à sa capture . C'est un excellent point. Permettez-moi de l'ajouter au carnet de commandes afin que nous puissions le prioriser correctement. Cela validera l'idée sans vous y engager. Deuxièmement, reportez-vous au cadre dans lequel je veux m'assurer que nous atteignons notre objectif de sprint, à savoir X. Cette nouvelle demande ne soutient pas directement cela. Pouvons-nous donc l'examiner lors de la prochaine réunion du Prints ? L'objectif devient la raison, non votre préférence personnelle, et le troisième est le commerce ouvert. Donc, nous pouvons le faire maintenant, mais cela implique de laisser tomber Y. Ça vous convient ? Tout à coup, le demandeur doit évaluer le coût de sa demande, et pas seulement les avantages Et souvent, ils décideront que cela peut attendre plus tard. Ensuite, il faut documenter la décision. Quelle que soit votre décision, notez-la, ajoutez-la à votre base de données de décisions conceptuelles, inscrivez la date, ce qui a été demandé, ce que nous avons décidé et pourquoi. 2 minutes d'écriture permettront d'économiser des heures sur les raisons pour lesquelles nous ne l'avons pas fait lors de réunions ultérieures. N'oubliez pas que des changements se produiront. Le plus important est de protéger l'objectif du sprint mettre en place un cadre et de documenter la décision. Ensuite, nous examinerons revue du sprint, qui montrera le vrai travail. Ces examens impliquent les parties prenantes. Cela implique du feedback et une certaine honnêteté. Nous allons donc regarder cela dans la prochaine vidéo. 28. L'examen de Sprint : montrer un travail réel aux parties prenantes: Bon retour. Le sprint est donc terminé. C'est maintenant le moment de vérité, qui est de montrer votre travail. Dans cette leçon, nous aborderons la révision du sprint, également appelée démonstration du sprint, et à la fin, vous saurez comment organiser l'une de ces réunions qui informe réellement vos parties prenantes au lieu de simplement performer pour elles. Alors, qu'est-ce qu'une revue Sprint ? La révision du sprint est une réunion qui a lieu à la fin de chaque sprint. C'est extrêmement important car ce sont les réunions au cours desquelles l'équipe montre le travail qu'elle a accompli aux parties prenantes. Les parties prenantes sont les personnes qui s' intéressent au projet mais qui font partie de l'équipe . Il peut donc s'agir du responsable, d'un client , de sponsors internes ou des utilisateurs réels. Il s'agit généralement d'une heure pour un sprint de deux semaines, et ces réunions ont deux objectifs . La première consiste à démontrer ce qui a été construit pour vérifier qu'il répond aux attentes et qu'il fonctionne. deuxième consiste à recueillir des commentaires qui éclaireront le prochain backlog produit et le prochain sprint Maintenant, il ne s'agit pas d'un rapport de situation. Il s'agit d'une conversation sur les résultats concrets produits par votre équipe. Il y a donc trois règles que vous devez suivre quant à ce que vous devez montrer lors de ces réunions. Premièrement, vous affichez un résultat fonctionnel, et non des diapositives sur le résultat fonctionnel. Si vous créez une fonctionnalité, faites une démonstration la fonctionnalité réelle sur un appareil réel ou sur un écran, montrer qu'elle fonctionne. Ne faites pas un jeu de 30 diapositives pour le décrire. Le fait est que cela fonctionne réellement , alors montrez que cela fonctionne. La deuxième consiste à tout relier à l'objectif initial du sprint, à commencer par l'objectif , à expliquer en quoi chaque tâche contribue à cet objectif et à terminer en indiquant si l'objectif a été atteint ou non. Et troisièmement, montrez uniquement ce qui est fait selon votre définition de fait. Non, ce n'est pas réglé à 80 %. Désolé, c'est terminé à 80 %, ou nous avons juste besoin de corriger quelques points. Il doit s'agir d'un véritable travail terminé à 100 %. Si ce n'est pas fait, laissez-le de côté. Vous pouvez le mentionner dans la section sur ce qui n'a pas été terminé, mais ne faites pas de démonstration de ce qui n'est pas terminé. Maintenant, vous devriez avoir un agenda de 60 minutes, que vous pouvez réutiliser pour chaque sprint. minute zéro à cinq est donc bienvenue et récapitulez l'objectif du sprint, à savoir orienter tout le monde dans la salle minutes 5 à 35 seraient votre démonstration pour chaque histoire terminée, cinq à 7 minutes par histoire, montrer qu'elle fonctionne, expliquer le contexte, puis poser des questions. Les minutes 35 à 45, c'est ce qui n'a pas été terminé. Soyez honnête à propos de ce qui est encore en cours et des raisons pour lesquelles cela renforce la confiance et pourquoi le fait de cacher des choses la détruit. Entre 45 et 55 commentaires des parties prenantes , passez la parole aux questions. Qu'en pense le public ? Que voudraient-ils ensuite ? Capturez toutes les données que vous pouvez entendre et ne faire aucune promesse. Ensuite, les 5 dernières minutes seraient consacrées à conclure, à récapituler les principaux commentaires, convenir des mesures à prendre et à y mettre fin à temps Donc, bien gérer les commentaires, c'est là que la plupart des évaluateurs se trompent. Les parties prenantes donnent leur avis. L'équipe se met sur la défensive ou accepte chaque demande comme une promesse. Les deux sont mauvais. Une meilleure approche consiste à écouter d' abord. Ne soyez pas sur la défensive. Ne vous engagez pas, ne l'écoutez pas, ne l' écrivez pas sur un tableau visible dans Notion, ou devant les parties prenantes. Merci, j'ai capturé ça. C'est ce que tu peux dire. Après la réunion avec l'équipe, décidez quoi faire de chaque commentaire. Certains articles deviendront de nouveaux articles en attente. Certains affinent peut-être des histoires existantes. Cela pourrait donc être intéressant mais pas exploitable, ce qui est bien. Ne faites simplement pas de promesses dans la salle. Nous ajouterons que le prochain sprint est un piège à éviter. Vous ne savez pas encore si cela doit être une priorité ou non, alors ne le promettez pas. Capturez la demande et décidez ultérieurement de la planification. Donc, si vous travaillez seul sur ce cours, vous avez toujours besoin d'une partie prenante. Alors trouvez-en un ou soyez un. Cela peut être un ami, un collègue, un partenaire, toute personne qui a de la patience et de curiosité pour vous et votre projet. Planifiez un créneau de 30 minutes, atteignez votre objectif de sprint, faites une démonstration de vos histoires terminées et posez les trois questions. Est-ce que ça a l'air correct ? Qu'est-ce qui t'a surpris ? Et que voudriez-vous ensuite ? Même une personne sans lien de parenté peut surface à des commentaires utiles simplement parce qu'elle a un regard neuf. Prenez donc des notes, il s'agit d'une pratique agile appropriée, mais réduite à un utilisateur solo Ce sont donc des critiques rapides, elles montrent du vrai travail. Ils se réunissent sur ses commentaires. Il ne faut jamais promettre sur-le-champ. Ensuite, nous allons examiner la rétrospective, qui est l' occasion pour l'équipe de se tourner vers l'intérieur et de s' Je vous verrai pour la prochaine vidéo. 29. La rétrospective de Sprint : « Commencez, Arrêtez, Continuez »: Bon retour. La revue du sprint que nous venons d'examiner porte donc sur l'extérieur ce que nous avons construit, tandis que la rétrospective du sprint intérieur et examine la façon dont Dans cette leçon, nous allons donc passer en revue le format de rétrospective le plus simple et le plus populaire , à savoir démarrer, arrêter et continuer Ainsi, à la fin, vous saurez comment organiser l'une de ces réunions qui changera réellement la façon dont votre équipe travaille. Qu'est-ce qu'une rétrospective ? Il s'agit d'une réunion à la fin de chaque sprint, juste après la révision, laquelle l'équipe réfléchit à la manière dont elle travaille ensemble pendant le sprint. Ils ne parlent pas de ce qu'ils ont construit. Ils ont parlé de leur façon de travailler. Cela prend donc généralement 45 à 60 minutes s'il s'agit d'un sprint de deux semaines. Seule l'équipe, sans parties prenantes Il s'agit donc d'un espace sûr où l'équipe peut être honnête quant à ce qui fonctionne et à ce qui ne fonctionne pas. Le principe sous-jacent est tiré du principe 12 du Manifeste Agile, qui stipule qu'à intervalles réguliers, l'équipe réfléchit à la manière de devenir plus efficace, puis adapte son comportement en conséquence. La rétrospective montre comment cela se passe dans la pratique. Le format rétrospectif le plus simple comporte donc trois colonnes sur un mur ou sur un tableau Démarrez, arrêtez et continuez. Alors, commencez. Ce sont des choses que l'équipe devrait commencer à faire et qu'elle ne fait pas actuellement. Commencez peut-être à rédiger les critères d'acceptation avant d'estimer ou commencez un enregistrement de cinq minutes à mi-chemin du sprint. Arrête. sont des choses que l' équipe devrait arrêter de faire, peut-être arrêter d'accepter des modifications après avoir planifié ou arrêter de tenir des stands lorsque le responsable du produit ne peut pas y assister, des choses comme celle-ci, puis continuer ou choses que l'équipe fait bien et devrait continuer à faire. pouvez donc continuer à déjeuner ensemble le mercredi ou continuer à mettre à jour le forum tous les jours, Vous pouvez donc continuer à déjeuner ensemble le mercredi ou continuer à mettre à jour le forum tous les jours, selon ce que l'équipe pense fonctionner et qu'elle fait bien Chaque personne peut donc ajouter des notes autocollantes à chaque colonne, puis l'équipe en discutera. Les groupes peuvent choisir des thèmes similaires, choisir les plus importants sur lesquels agir lors du prochain sprint. Alors, comment organiser ce type de réunion. Voici un programme en cinq points pour une rétrospective de 45 minutes. La première étape consiste à régler la scène sur environ 5 minutes. Rappelez à l'équipe à quoi sert un rétro, établissez l'espace. La règle des Vagas est que ce qui est dit dans le rétro reste dans le rétro Deuxième étape, écriture silencieuse. Ainsi, 10 minutes, chacun écrit ses éléments de début, d' arrêt et de poursuite de manière indépendante. Aucune discussion. Cette séance d'écriture silencieuse fait ressortir des opinions honnêtes sans groupe. La troisième étape consiste à partager et à regrouper. Cela devrait donc prendre environ 10 minutes. Chaque personne lit ses articles. Nous regroupons les articles similaires . N'en débattez pas pour l'instant. Il s'agit d'une partie de la réunion consacrée à la catégorisation. La quatrième étape consiste à discuter des principaux points, prenez environ 15 minutes pour cela. Vous pouvez faire en sorte que chaque personne obtienne trois points, les coller sur les points les plus importants, comme un processus de vote. Et quand tu auras terminé, discute des trois premiers. Cinq, c'est convenir d'une action. Donc, pour chacun des principaux points, convenez d'actions concrètes, qui fera quoi, d'ici à quand. Sinon, le rétro devient une thérapie avec beaucoup de discussions et aucun changement. Alors, mettez-vous d'accord sur ces actions, sur qui, quoi et quand. Une rétrospective n'est donc utile que si les gens sont honnêtes, et ils ne le sont que s'ils se sentent en sécurité Trois choses peuvent donc aider. Premièrement, ce n'est pas de la faute. Selon la directive principale de Kurth, peu importe ce que nous découvrons, nous comprenons et croyons sincèrement que chacun a fait de son mieux, compte tenu de ce qu' il savait à l'époque Lisez-le à haute voix au début de chaque rétrospective, car cela donnera le ton à l'équipe Deuxièmement, il ne devrait y avoir aucun manager dans l'équipe. Si vous avez un supérieur hiérarchique qui ne fait pas partie de l'équipe elle-même, il n'est pas présent parce que les gens ne peuvent pas être honnêtes si c'est le cas. Donc oui, vous ne pouvez pas être honnête quant à la façon dont les gens réagissent avec le manager lorsque les managers sont présents dans la salle. Donc pas de managers. Enfin, il faut se concentrer sur le système, pas sur les personnes. Alors pourquoi est-ce arrivé ? Pourquoi Sarah a-t-elle fait ça ? Ce principe agile est que les bonnes personnes peuvent être piégées dans de mauvais systèmes, alors améliorez le système. Vous avez d'autres formats à essayer. Donc, si votre stop-start vous semble périmé, vous pouvez le mélanger. Nous aborderons donc cette question correctement dans le troisième cours, le plus avancé. Mais voici un avant-goût de trois alternatives. Nous sommes furieux, tristes et contents. Les gens écrivent donc ce qui les a rendus furieux, tristes ou heureux. Ce sprint fait surface en mouvement que le format start, stop, continue peut souvent aplatir Nous avons les quatre points que nous aimons, que nous avons appris, qui nous manquent, que ardemment, qui sont plus réfléchis, en particulier pour les grands sprints Enfin, voilier. L'équipe est un bateau. Quel vent nous a fait avancer ? Quels sont les points d'ancrage qui nous ont freinés ? Quels rochers devons-nous éviter ? C'est assez ludique et visuel , et bon pour les équipes distribuées. Mais nous y reviendrons plus en profondeur dans le cours 3. Alors c'est tout. Rétrospectives, espace court, sûr, axé sur l'action. Les équipes qui s'améliorent le plus sont celles qui font bien les rétrospectives la prochaine séance, nous ferons un exercice d'entraînement dans le cadre duquel vous effectuerez un mini-sprint de cinq jours et vous découvrirez le rythme d'un sprint de bout en bout. Je vous verrai pour la dernière vidéo de la section 5. 30. Exercice pratique : Correr un mini-sprint sur cinq jours: Bon retour. Nous en arrivons donc à l'exercice pratique le plus ambitieux jamais réalisé. Tu vas faire un vrai sprint. Nous allons le réduire à cinq jours, mais c'est réel à tous les autres égards. Alors planifiez, exécutez, révisez et rétrogradez. À la fin, vous aurez vécu un cycle de sprint complet et vous aurez les artefacts pour le prouver. Alors allons-y. Tout d'abord, pourquoi un mini-sprint. Les sprints standard durent généralement deux semaines. Pour cet exercice, nous allons le réduire à cinq jours, du lundi au vendredi. Nous allons le faire parce que le but de l'exercice est de suivre le rythme de la planification d'un sprint, suivre la progression quotidienne, des ajustements à mi-sprint, la révision et du rétro. Cinq jours suffisent pour vivre tout cela sans y consacrer des semaines de votre vie. Gardez donc votre viseur petit, visez deux à trois étages au total. L'objectif est le cycle, pas le volume. Alors, lundi, lundi matin, prévoyez 30 minutes pour la planification du sprint. Utilisez le modèle de la section 4, si possible, écrivez votre objectif de sprint, choisissez deux ou trois articles dans votre carnet de commandes, puis avancez-le Déplacez-les dans votre liste de tâches, appliquez les étiquettes et prenez un instantané de départ. Alors tu devrais commencer le travail. Donc, d'ici la fin du lundi, vous devriez avoir quelque chose à faire dans la colonne des activités, idéalement, quelque chose qui a été fait également. Du mardi au jeudi, c'est à ce rythme quotidien que vous prendrez l'habitude. Nous avons trois jours ouvrables. Donc oui, mardi, mercredi, jeudi. Chaque matin, 5 minutes en solo debout. Qu'est-ce que j'ai fait hier ? Que vais-je faire aujourd'hui ? Qu'est-ce qui me bloque ? Vous pouvez écrire les réponses dans une note de présentation rapide. Assurez-vous de dater chaque entrée. Chaque jour, mettez à jour votre tableau Trello. Les cartes passent de «   à faire » à «   faire », n'accumulent pas de travail en faisant. Quelque chose essaie d'interrompre, utilisez le cadre de changement que nous avons examiné dans la troisième leçon, si cela aide à atteindre l'objectif du sprint, s'il ne le met pas en attente Si c'est le cas, qu'est-ce qui est laissé tomber pour faire de la place ? Essayez de terminer au moins une histoire d'ici mercredi. Si mercredi vous n'avez rien terminé, c'est le signe que vous vous êtes trop engagé Champ d'application réduit maintenant. Et puis le vendredi matin, c'est à ce moment-là que vous aurez la critique. Prenez donc environ 20 minutes pour effectuer votre évaluation du sprint. Trouvez une partie prenante si vous le pouvez, un ami, un partenaire, un ancien collègue, discutez avec GPT, expliquez-leur ce que vous avez construit, montrez-le, mais ne le décrivez pas Si personne n'est disponible, faites-le vous-même. Enregistrez-vous en train de faire la démonstration. Sur une vidéo téléphonique. Il suffit de décrire l'entraînement à voix haute, d'affiner votre réflexion, de capturer les commentaires dans Notion, d'y enregistrer le tout nouvelles idées devraient figurer dans votre carnet de produits sous forme de cartes dans Trello Et puis, le vendredi après-midi, après avoir reçu la critique, vous aurez votre rétrospective, qui dure encore une fois environ 30 minutes. Même si vous le faites vous-même, cela devrait fonctionner. Ouvrez Notion, créez une nouvelle entrée dans votre base de données rétrospectives, utilisez le modèle que vous avez Les colonnes, start, stop et continue. Passez 10 minutes à écrire des articles dans chaque colonne et soyez honnête. Arrêtez de consulter les actualités en cours de tâche, par exemple une autre, commencez à bloquer les sessions de travail de 90 minutes, continuez à fermer les onglets à la fin de la journée, puis choisissez les trois principaux éléments sur lesquels agir pour le sprint suivant et écrivez-les sous forme d'actions concrètes. Qui, quoi et quand ? Marquez votre entrée rétro avec le numéro du sprint. Vous devez les examiner en deux ou trois sprints pour voir si vous avez réellement apporté des modifications Voici donc quelques erreurs courantes à éviter, trois choses à éviter lors de votre tout premier sprint. Les débutants en font beaucoup. Le premier est le surengagement dès le premier jour Il est donc préférable d'en engager moins puis surlivrer plutôt que de surengager et de La seconde consiste à éviter les stand-up lorsque vous êtes en solo. C'est juste moi. Je sais ce que je fais, mais peut-être que vous ne parvenez pas à articuler votre journée avec discipline révèle des choses que vous auriez peut-être oubliées si vous ne les aviez pas expliquées Enfin, il y a l' annulation de la rétrospective. La rétrospective est donc l'essentiel de la méthodologie Agile Si vous ne l'utilisez pas, vous ne vous améliorez pas. N'annulez donc jamais le rétro. Vendredi soir, à la fin de la semaine, vous devriez avoir tout cela. Vous devriez avoir un Trello montrant le parcours avec votre objectif de sprint en haut, les histoires terminées et terminées, histoires terminées et terminées, tout ce qui n'a pas été terminé sera envoyé au backlog Deux ou cinq notes de stand up par jour dans Notion. Troisièmement, vous devriez avoir un document de planification du sprint entièrement rempli pour ce sprint. Quatrièmement, vos notes d' évaluation consignant ce que vous avez montré et les commentaires qui en sont ressortis. Cinq, une rétrospective complète avec trois actions concrètes pour le prochain sprint et six, une capture d'écran de votre tableau Trello terminé à côté de la capture d'écran côté de la Ensemble, il s'agit d'une démonstration digne d'un portfolio démontrant que vous pouvez exécuter un sprint. Donc, c'est ça. Nous avons atteint la fin de la section 5. Je vous verrai pour la section 6. 31. En résumé : les pièges courants des débutants et comment les éviter: Bonjour et bienvenue dans la section 6. C'est la dernière section , bien sûr. Avant de conclure, je voudrais passer peu de temps sur les pièges que les débutants maintes reprises lorsqu'il s'agit gestion de projet agile et principalement de l'exécution de sprints agiles À la fin de cette période, vous saurez à quoi faire attention et vous vous épargnerez probablement des mois d'essais et d' erreurs si vous les suivez Souvenez-vous de ces pièges courants Donc, le premier écueil, c'est de faire de l' Agile sans être Agile. Maintenant, de nouvelles équipes adoptent les cérémonies et organisent des stand-up. Ils ont un tableau. ce qu'on appelle la planification des sprints de réunion, mais en dessous de tout cela, rien n'a réellement changé. Le propriétaire du produit continue de transmettre les exigences, comme le chef de projet. L'équipe attend toujours qu'on lui dise quoi faire. Les modifications sont toujours considérées comme des échecs. La forme est agile, mais le fond est une cascade déguisée Ne tombez pas dans le piège. La solution ne réside pas dans d'autres cérémonies. Tout dépend de l'état d'esprit, de l' état d'esprit qui consiste à faire confiance à votre équipe, accueillir le changement, à créer de la valeur dès le début Donc, si vous suivez les rituels sans appliquer les valeurs, vous ne faites pas vraiment preuve d'agilité. Car le numéro deux, c'est trop planifier le sprint. J'en ai beaucoup parlé dans les vidéos précédentes. La planification du sprint prend donc environ 2 heures. Certaines équipes en font un atelier d'une journée complète, ce qui n'est pas correct. Ils débattent de chaque histoire pendant environ 20 minutes. Ils estiment le demi-point le plus proche. Ils rédigent des paragraphes sur les critères d' acceptation pour des histoires qu'ils n'ont même pas encore commencées. Alors arrête tout ça. La planification est censée être légère en mode Agile, car le but de l' Agile est d' apprendre au fur et à mesure. Donc, des plans détaillés pour des choses que vous n'avez pas encore construites ou que vous n'avez pas encore devinées, déguisés en certitude et leur place dans la gestion de projets en cascade Planifiez donc suffisamment pour commencer, puis peaufinez au fur et à mesure que vous apprenez. Ou le numéro trois est de sauter la rétrospective. Cela arrive souvent . Ne le fais pas. Des équipes sous pression. Ils pourraient d' abord couper le rétro, du genre « Oh, nous n'avons pas le temps ». Nous en ferons une lors du prochain sprint. Deux sprints plus tard ou trois ou six mois plus tard, l'équipe a complètement cessé de s'améliorer Le rétro est donc la réunion la plus importante d' Agile, car c'est grâce à elle que l' équipe s'améliore au fil du temps. Et sans elle, on n'apprend pas. Si vous n'apprenez pas, vous stagnez. Assurez-vous donc de toujours conserver le rétro, même s'il ne dure que 20 minutes, et même s'il ne s'agit que d'un bloc-notes, assurez-vous de ne jamais l'oublier Et Pitfm numéro quatre, laisser le carnet de commandes s' alourdir Chaque idée est ajoutée, et c'est un problème. Rien n'est retiré. Au bout de six mois, vous avez 400 articles. Personne ne trouve quoi que ce soit. Les tâches les plus importantes ne se limitent plus aux tâches les plus importantes C'est ce que vous avez ajouté le plus récemment. Il est donc très important de réduire votre arriéré comme un buisson Une fois par mois, scannez la moitié inférieure. Tout ce qui existe depuis trois mois ou plus et qui n'est la priorité de personne, supprimez-le. Si c'est vraiment important, ça reviendra. Un arriéré propre est donc un carnet de commandes sain. À 45 ans, le problème des héros. C'est donc l'idée qu' une personne de l'équipe fait le gros du travail. Ils sont géniaux. Ce sont eux qui prennent les billets les plus difficiles. Ils travaillent le week-end. Tous les autres comptent sur ces personnes. Cela semble excellent à court terme, mais à long terme, c'est un désastre. Le héros s'épuise donc lorsqu'il quitte l'entreprise ou même s'il part en vacances, l'équipe s'effondre parce que le savoir est coincé dans la tête d'une personne et pire encore, personne d'autre ne peut grandir Répartissez donc les deux joueurs sur des histoires difficiles, laissez-les collaborer, alternez les personnes qui reprendront les plus difficiles, assurez-vous que l'équipe soit résiliente et ne dépende pas d'un seul héros. Le prochain écueil est source de confusion, entre activité et productivité. Le tableau est plein. Des cartes partout. Les gens ont l'air débordés. C'est sûrement ce à quoi ressemble un bon sprint. Pas nécessairement. Une équipe avec 15 cartes en jeu expédie rarement quoi que ce soit. Ils changent de contexte, ils sont à moitié terminés. Peut-être qu'ils sont bloqués et qu'ils sont probablement épuisés. Une équipe avec deux cartes en jeu peut offrir discrètement plus de valeur. Rappelez-vous donc que l'activité n'est pas toujours synonyme de progrès. Regardez la liste des tâches accomplies, pas celle des tâches. La question est de savoir si les gens ne sont pas occupés ? La question devrait être de savoir s'il s'agit d'un flux de valeur ? Pour le numéro sept, c'est ignorer les bloqueurs. C'est très, très important. Si quelqu'un mentionne un bloqueur dans un stand up et que l' équipe hoche simplement la tête, la réunion se poursuit. Trois jours plus tard, le bloc est toujours là. La carte n'a pas bougé et tout le sprint est en difficulté. Les bloqueurs sont donc l'élément le plus urgent de tous les forums. Lorsqu'une carte est levée, nommez-la, notez-la, demandez à quelqu'un de la débloquer ou de s'en occuper vous-même, rendez-la bien visible sur le tableau sous forme d'étiquette ou de carte séparée Un bloqueur que personne ne possède est un bloqueur qui n'est jamais réparé. Souvenez-vous donc de ceci. Donc oui, sept pièges tous évitables. Les équipes qui obtiennent un bon niveau d'agilité sont celles qui évitent toutes ces erreurs, et ce sont elles qui les remarquent le plus rapidement. C'est donc la fin de cette leçon. Dans la leçon suivante, nous verrons où vous en êtes actuellement et nous procéderons à une rapide auto-évaluation pour voir ce que vous avez réellement absorbé dans ce cours. Je vous verrai donc dans la prochaine vidéo. 32. Auto-évaluation : Où en êtes-vous maintenant ?: Bon retour. À ce jour, vous avez passé plusieurs heures à apprendre les bases de la gestion de projet Agile. Dans cette courte leçon, vous allez faire point sur ce que vous savez réellement maintenant. Ainsi, à la fin, vous aurez une idée claire de vos forces, vos lacunes et des points sur lesquels vous concentrer ensuite. Pourquoi même s'auto-évaluer en premier lieu ? Il y a trois raisons principales pour lesquelles c'est important. Premièrement, rendre l'apprentissage réel. Lire et regarder sont des activités purement passives, mais le fait de réfléchir vous oblige à vous mais le fait de réfléchir vous oblige à vous concentrer sur ce que vous savez. Deuxièmement, il vous indique sur quoi vous concentrer ensuite. Donc, sans auto-évaluation honnête, vous pourriez revoir le Bit le plus facile Et évitez les parties les plus difficiles. Maintenant, c'est une mauvaise habitude. Et troisièmement, il vous prépare aux entretiens. Lors des entretiens avec PM et Agile, il est régulièrement demandé me parler de votre expérience avec Scrum Savoir où vous êtes facilite donc ces conversations. Nous avons donc une vérification de dix questions, interrompons la vidéo, et vous pourrez répondre honnêtement, puis revenir. Aucune notation n'est donc nécessaire ici. Remarquez simplement où vous vous sentez en confiance et où vous ne vous sentez pas en confiance. Alors, d'abord, puis-je expliquer Agile en deux phrases sans utiliser de jargon ? Deuxièmement, puis-je citer les quatre valeurs du manifeste Agile ? Troisièmement, puis-je écrire une histoire utilisateur dans un format approprié avec des critères d'acceptation pour un projet sur lequel je ne travaille pas actuellement ? Quatrièmement, est-ce que je comprends la différence entre les backlogs de produits et les backlogs de sprint Cinquièmement, puis-je décrire ce que chacun des trois Scrum Rolls fait et ce qu'il ne fait pas ? Six, puis-je organiser une réunion debout de 15 minutes demain sans préparation ? Septièmement, puis-je expliquer la ville de Moscou et la matrice valeur-effort à un collègue qui n'en a jamais entendu parler auparavant ? Huitièmement, puis-je écrire un objectif de sprint en une phrase pour un projet fictif en une phrase axée sur les résultats ? Neuvièmement, est-ce que je connais la différence entre une évaluation de sprint et une rétrospective et à quoi sert chacune d'elles Et la dixième est la suivante pourrais-je créer un tableau Trello et un espace de travail conceptuel à partir de zéro, prêt à lancer mon propre sprint ? Telles sont donc les dix questions. Répondez-y honnêtement et revenez. Ensuite, que faire de vos résultats ? Donc, trois catégories, soyez honnête quant à celle dans laquelle vous vous trouvez. C'est très important. Donc, la plupart du temps, vous êtes sûr d' avoir huit oui ou plus, ce qui signifie que vous avez très bien assimilé la matière, passez au deuxième cours lorsque vous serez prêt et commencez à vous entraîner sur de vrais projets La plupart du temps, 5 à 7 oui seraient mélangés. Vous avez donc les bases, mais certaines pièces sont encore floues Revoyez les leçons en abordant les questions auxquelles vous avez eu du mal à répondre, puis recommencez l'exercice pratique avec un nouveau projet Plutôt fragile, moins de cinq oui. C'est très bien Cela signifie simplement que le cours nécessite un autre passage ou que vous devez simplement revoir le vocabulaire. Ne vous en faites pas. Agile. C'est beaucoup de choses à assimiler Vous pouvez donc revenir à la première section et y travailler un peu plus lentement Prendre des notes et tenir un glossaire est extrêmement utile dans le domaine de la gestion de projet agile car de nombreux termes, oui, une grande partie du concept de gestion de projet agile se trouvent dans le vocabulaire Alors, enfin, une autre question honnête. Avez-vous réellement fait les exercices d'entraînement ou les avez-vous omis ? Voici donc la vérité. Vous ne pouvez pas vraiment apprendre à courir des sprints simplement en regardant des vidéos Vous apprenez à courir un sprint en exécutant un sprint. Donc, si vous sautez les exercices, votre prochaine étape ne sera pas de vous concentrer davantage sur le contenu, mais de revenir en arrière et de réellement faire ces exercices. Ainsi, même un mini-sprint complet vous permettra d'apprendre plus de 20 heures de vidéos théoriques. Eh bien, c'est votre auto-évaluation terminée. Sois gentil avec toi-même, mais sois honnête. Dans la leçon suivante, nous passerons rapidement en revue le projet afin de voir à quoi devrait ressembler votre sprint terminé Je vous verrai donc dans la prochaine vidéo. 33. Examen du projet : à quoi ressemble votre sprint fini: Bonjour, bienvenue sur l'avant-dernière vidéo de ce cours. présent, si vous avez suivi le cours, planifié et couru un sprint, dans cette leçon, nous allons passer en revue ce à quoi devrait ressembler le sprint terminé, ce à quoi il ressemble, ce dont vous en revue ce à quoi devrait ressembler le sprint terminé , ce à quoi il ressemble, pouvez être fier et comment en parler dans un portfolio ou lors d'un entretien. Donc, l'artefact que vous devriez avoir, vos six artefacts, vous devriez les avoir sur du papier ou dans vos outils Tout d'abord, vous devriez avoir un tableau Trello avec un carnet de produits bien rempli Votre objectif de sprint en haut, un sprint terminé avec des histoires dans Terminé et des captures d'écran du plateau avant et après. Deuxièmement, vous devriez avoir un espace de travail Notion avec quatre sous-pages, la planification des sprints, la rétrospective, décisions et les mises à jour des parties prenantes Troisièmement, vous devez avoir au moins un document de planification du sprint rempli. Quatrièmement, vous devriez avoir une rétrospective complète avec trois actions concrètes Et cinq, vous devriez avoir notes que vous avez prises lors de votre évaluation du sprint, et enfin, six, vous devriez avoir des liens entre Trello et Notion dans les deux sens Si vous avez les six, vous avez construit quelque chose de réel. Toutes nos félicitations. C'est un système Agile qui fonctionne. Il ne s'agit pas simplement d'un exercice. Maintenant, à quoi ressemble le bien ? Voici les cinq principales qualités d'un bon premier sprint. Donc, au-delà des artefacts, comment pouvons-nous faire en sorte que ce premier sprint soit beau ? Cinq qualités à rechercher en premier lieu, c'est que l'objectif du sprint est clair et axé sur les résultats, et que vous pouvez savoir en un coup d'œil si vous êtes capable de l'atteindre ou non. Deuxièmement, les user stories suivent le bon format et comportent des critères d'acceptation testables Ils sont spécifiques. Ils ne sont pas vagues. Troisièmement, le travail que vous avez effectué est directement lié à l'objectif du sprint. Vous n'avez rien de plus et il ne vous manque rien. Quatrièmement, votre rétro identifie les choses réelles à changer, et pas seulement platitudes génériques, comme «   communiquer davantage, c'est mal Déplacez-vous, tenez-vous debout jusqu'à 9 h 30, car 10 h 00. Il vaut mieux entrer en collision avec X. Cinquièmement, la documentation est légère mais utile, juste assez pour être utile, mais pas au point que personne ne la lise. Voici donc les cinq choses. Si vous cochez toutes ces cases et que la réponse est oui, vous savez que votre sprint peut être beau. Maintenant, même si votre premier sprint a été difficile, il y a des vents réels qui méritent d'être reconnus. Maintenant, vous avez appris un nouvel état d'esprit, pas seulement une nouvelle méthodologie L' agilité est une façon de penser le travail. Le fait que vous puissiez désormais reconnaître la pensée en cascade dans vos propres habitudes constitue en soi un grand changement. Vous avez construit quelque chose de tangible. La plupart des personnes qui disent comprendre Agile n'ont jamais réellement couru de sprint, mais vous oui. Vous avez créé un article de portfolio. Ainsi, quel que soit le travail que vous allez entreprendre ensuite, vous pouvez indiquer un sprint terminé avec des objectifs, des histoires, des rétros et des réflexions Vous vous prouvez également que vous pouvez terminer quelque chose Ces cours sont faciles à démarrer, mais difficiles à terminer. Vous avez fait le travail, alors félicitations. Voyons maintenant comment nous pouvons en parler dans les interviews. Si vous êtes à la recherche d'un emploi, le sprint est une médaille d'or pour un entretien si vous le définissez correctement. Ne vous contentez pas de dire que j'ai suivi un cours d'Agile. Cela ne dit pas vraiment l'entretien ou quoi que ce soit d'autre, mais on pourrait dire que je gère un projet Agile pratique dans le cadre duquel j'ai créé un backlog, planifié et exécuté un sprint, organisé une rétrospective et expédié X articles liés à un objectif de sprint spécifique C'est bien plus impressionnant et c'est en fait vrai. Apportez les artefacts, montrez le Trello, parcourez l'espace de travail de Notion La plupart des intervieweurs n' ont jamais vu un candidat démontrer réellement son processus. Ceux qui le feront se démarqueront plus que tout. Soyez donc également honnête à propos de ce que vous avez appris. On pourrait dire que lors de mon premier sprint, je me suis trop engagé. J'ai dû publier deux articles. Rétrospectivement, j'ai découvert que j'avais fait estimation sur la base des meilleurs scénarios. Maintenant, je paie toujours mes estimations. La conscience de soi est donc toujours considérée comme senior et hautement professionnelle. Maintenant, si vous souhaitez l'utiliser comme élément de portfolio, voici ce que vous devez inclure : un court résumé écrit, un court paragraphe de ce que vous avez construit et pourquoi ? Les captures d'écran de votre tableau Trello avant et après, avec l'objectif du sprint visible, sont extrêmement importantes Votre document de planification de sprint exporté depuis Notion. Même la version approximative prouverait que vous avez pensé à la capacité, au risque et à l'engagement. Votre rétro avec les actions que vous avez identifiées. Maintenant, celui-ci est en or parce qu'il montre vous pouvez vous améliorer vous-même, que vous pouvez améliorer une équipe. Et éventuellement, vous pouvez avoir une présentation vidéo du projet de cinq minutes sur un métier à tisser Cela ne dure que 5 minutes, et les gens se souviennent des candidats qui les ont montrés au lieu de les leur dire. Si vous avez votre propre site Web, hébergez-le, téléchargez-le sur un dépôt GitHub public ou partagez-le à l'aide de la fonctionnalité de partage public de Notion Alors, rendez-le connectable et rangez-le. Oh, félicitations. Vous avez atteint la fin du premier cours. Tu as construit quelque chose de réel. Il ne faut jamais sous-estimer ça. Vous avez réalisé quelque chose de concret que vous pouvez ajouter à un portfolio et à l'aide d'entretiens. Cela pourrait vous permettre de faire un pas de plus vers l'obtention de l'emploi de vos rêves. Dans la dernière vidéo de ce cours, nous verrons donc ce qui va suivre, et nous examinerons le lien vers le deuxième cours, qui sera le cours intermédiaire en gestion de projet. Je te verrai donc pour la dernière leçon. 34. Et ensuite ?: Bienvenue pour la dernière fois dans le cours 1. Bravo. Tu es arrivée jusqu'au bout. Dans cette dernière vidéo, nous allons simplement voir où vous allez à partir de là. Nous examinerons le deuxième cours et ce qu'il contient et au-delà. Donc oui, vous saurez exactement quelles sont vos prochaines étapes. Donc, tout d'abord, faisons un bref résumé de ce que vous avez appris Vous avez appris les bases, ce qui est bien plus que ce que peuvent dire la plupart des personnes qui revendiquent une expertise Agile. Nous avons abordé le manifeste d'AgI et l'état d'esprit d'Agi. Nous avons abordé les sprints, les incréments, la boucle empirique. Nous avons couvert les Scrum Rolls. Nous avons abordé les arriérés, les témoignages d'utilisateurs, les critères d'acceptation et la définition du terme « terminé Nous avons examiné comment configurer un espace de travail dans Trello et dans J'ai examiné comment prioriser, estimer et exécuter un sprint. Nous avons examiné comment exécuter un sprint en position debout, en ajustant le sprint en milieu de sprint, ajustant le sprint en milieu de sprint sur des critiques et des rétrospectives Nous avons également examiné les écueils à surveiller. Tout cela constitue donc le fondement. Vous en savez donc plus que la plupart des personnes qui revendiquent une expertise agile. Vous pouvez donc en être fier. Le deuxième cours s'appelle le sprint à grande échelle. C'est donc là que le deuxième cours reprend là où le premier s'est arrêté, et il approfondit les compétences intermédiaires. Vous allez donc apprendre à gérer plusieurs sprints dans une séquence. Vous apprendrez à maintenir votre élan. Vous apprendrez à gérer les changements de sprint au fil des sprints et à gérer la vélocité. Vous aborderez les cérémonies Scrum avancées , puis les sessions de peaufinage du backlog, et vous vous intéresserez à une planification plus sophistiquée grâce à des rétrospectives plus approfondies Vous aborderez également correctement le Kanban, quoi il diffère de Scrum et quand l'utiliser, et vous expliquerez également comment combiner les deux dans une approche hybride Vous apprendrez également à gérer les parties prenantes à grande échelle, à gérer les dirigeants, à gérer les clients et à gérer des priorités concurrentes. Vous explorerez également les outils autres que Trello. Nous examinerons les projets Jira, Linear et Github, et nous verrons également quand ils en valent la peine et quand ils sont premier cours consistait donc à gérer une série de spres tandis que le deuxième portait sur la gestion d'un flux d'entre elles, ce qui est plus proche de la réalité de la gestion de projet agile Maintenant, le cours trois est le plus avancé. C'est ce qu'on appelle diriger et améliorer les équipes. Ce cours s'adresse aux personnes qui souhaitent aller au-delà de la simple organisation de sprints pour réellement mener transformations agiles au sein des entreprises Cela couvre toutes les compétences non techniques telles que le coaching des membres de l'équipe, gestion des conflits d'équipe, le renforcement de la sécurité psychologique. Il couvre également les indicateurs et explique comment mesurer la santé d'une équipe sans devenir la police des indicateurs. Il examine également les aspects organisationnels les plus difficiles, tels que l'adhésion des dirigeants, la gestion de la résistance et l'extension de l'Agile au-delà d' une seule équipe. C'est à ce niveau que l'Agile cesse devenir une méthodologie et devient une compétence de leadership pour vos postes les plus élevés. Quelques autres endroits pour apprendre au-delà de ces trois cours Si vous voulez continuer, nous avons quelques recommandations de livres. Le premier est Scrum de Jeff Sutherland. C'est court, c'est accessible, et Jeff est l'un des inventeurs. Le projet Phoenix est un roman sur le DevOps et l'Agile, qui est étrangement lisible. Enfin, inspiré par Marty Kagan, c'est la Bible du Certifications Vous pouvez jeter un œil au scrum master certifié CSM et au propriétaire de produit Scrum professionnel PSPO sont les plus respectés du secteur Ils sont utiles pour les emplois, même si l'examen proprement dit ne vous apprend pas grand-chose au-delà de ce que vous avez déjà appris. C'est super de l'avoir sur ton CV. Les sous-éditions Communities, Agile et Scrum sont excellentes événements d'alliance agile et les réunions Scrum locales L'un des meilleurs moyens d'apprendre est de parler à d'autres praticiens. Et enfin, ton propre travail. Il est donc formidable d'appliquer ce que vous avez appris à un projet réel, même s'il ne s'agit que d'un projet parallèle. Le prochain sprint que vous courez, qui se déroulera dans le monde réel. Vous en apprendra plus qu' un autre cours. Donc, une dernière chose avant de terminer, Agile n'est en aucun cas une méthodologie parfaite. Elle pose des problèmes, elle fait l'objet d'abus et elle peut devenir de la bureaucratie déguisée Les meilleurs praticiens sont ceux qui l'utilisent de manière pragmatique Ils prennent ce qui fonctionne, ils abandonnent ce qui ne fonctionne pas et ils ne cessent de s'adapter. Votre travail à partir d'ici est donc de faire exactement cela. Lancez des sprints, remarquez ce qui fonctionne, remarquez ce qui ne fonctionne pas, ajustez-le C'est l'ensemble de l'état d'esprit agile appliqué à l'apprentissage de l'Agile lui-même. Merci donc beaucoup de m'avoir rejoint pour le premier cours, qui est le cours pour débutants et d'introduction à la gestion de projet Agile. Bravo d'être arrivé jusqu'au bout. La plupart des gens ne le font pas. J'espère vraiment que cela vous donnera une véritable base de travail que vous pourrez même utiliser lors des entretiens d'embauche et des demandes d'emploi. Encore une fois, merci beaucoup. Bonne chance avec tout ce que tu construiras ensuite, et je te verrai dans le deuxième cours. Au revoir 35. Projet de cours : concevoir votre propre projet Agile: Il est maintenant temps de mettre en pratique tout ce que vous avez appris. Pour votre projet de classe, vous allez créer et gérer votre propre projet agile en utilisant Trello, Notion ou les deux Commencez simplement par choisir l'un des dossiers de projet du cours ou créez votre propre idée de projet si vous préférez Ensuite, vous allez construire votre projet étape par étape. Vous créerez un carnet de produits, rédigerez des témoignages d'utilisateurs, ajouterez des critères d'acceptation, hiérarchiserez votre travail, estimerez les tâches et planifierez votre premier sprint Ensuite, organisez tout dans votre outil de gestion de projet et créez un tableau de sprint indiquant comment le travail va passer d'une tâche à une autre. L'objectif n'est pas de créer un projet parfait. L'objectif est de démontrer que vous comprenez le flux de travail agile et que vous pouvez l' appliquer de manière pratique. Une fois votre projet terminé, téléchargez des captures d'écran de votre tableau Trello, de votre notion, de votre espace de travail, carnet de sprint ou tout autre artefact de projet que vous souhaitez partager Vous pouvez également inclure une brève explication de votre projet et de votre objectif de sprint. Ce projet vous permettra d' acquérir une expérience pratique des mêmes concepts et outils utilisés quotidiennement par les équipes agiles. 36. Félicitations ! Quoi faire ensuite ?: H. Félicitations pour avoir terminé le cours. Vous avez maintenant appris les bases de la gestion de projet agile, en comprenant l'état d'esprit agile et le framework Scrum, en passant comprenant l'état d'esprit agile et le par la création de backlogs, la planification de sprints et la gestion du travail à l'aide d'outils de gestion de projet professionnels Plus important encore, vous avez appliqué ces concepts en élaborant votre propre projet, ce qui correspond exactement à la manière dont les compétences en gestion de projet sont développées dans le monde réel. N'oubliez pas que les bons chefs de projet ne sont pas créés en mémorisant des cadres Ils réussissent en pratiquant continuellement la planification, la communication, la priorisation et l'adaptation Au fur et à mesure que vous poursuivez votre apprentissage, essayez d'appliquer ces techniques à des projets personnels, des initiatives d' équipe ou même à des tâches professionnelles. Plus vous acquerrez d'expérience, plus la gestion de projet agile deviendra naturelle. Si ce n'est pas déjà fait, assurez-vous de télécharger vos projets dans la galerie. J'adorerais voir comment vous avez appliqué les concepts du cours. Et si vous avez apprécié le cours, pensez à nous laisser un commentaire. Cela nous aide à améliorer le cours et permet aux autres étudiants de le découvrir également. Merci de m' avoir rejoint dans ce voyage d'apprentissage, et j'espère vous voir au prochain cours.