![\"Kawaii-style](\"https:\/\/www.diagrams-ai.com\/wp-content\/uploads\/2026\/03\/agile-scrum-first-week-roadmap-kawaii-infographic.jpg\"\/)
<\/figure>\n<\/div>\nPourquoi ce plan d’action est-il important \ud83d\udccb<\/h2>\n
Entrer dans un nouvel environnement de d\u00e9veloppement exige une clart\u00e9. Sans une compr\u00e9hension claire de la mani\u00e8re dont votre \u00e9quipe fonctionne, les progr\u00e8s peuvent stagner. Les m\u00e9thodologies Agile privil\u00e9gient les individus et les interactions plut\u00f4t que les processus et les outils. Toutefois, pour avoir des interactions significatives, vous avez besoin d\u2019un langage commun. Ce plan d’action vous assure d\u2019apprendre ce langage. Vous passerez d\u2019une observation passive \u00e0 une contribution active. L\u2019objectif est de devenir un membre fonctionnel d\u2019une \u00e9quipe Scrum qui comprend le \u00ab pourquoi \u00bb derri\u00e8re chaque c\u00e9r\u00e9monie et chaque artefact.pourquoi<\/em>derri\u00e8re chaque c\u00e9r\u00e9monie et chaque artefact.<\/p>\n Durant cette semaine, nous nous concentrerons sur :<\/p>\n Le premier jour consiste \u00e0 poser les bases. Vous n\u2019avez pas besoin d\u2019\u00e9crire du code imm\u00e9diatement. Concentrez-vous plut\u00f4t sur la compr\u00e9hension de l\u2019environnement et des r\u00e8gles d\u2019engagement. Votre t\u00e2che principale est d\u2019absorber le contexte dans lequel vous allez travailler.<\/p>\n Le d\u00e9veloppement en mode Agile est guid\u00e9 par la valeur. Nous ne d\u00e9veloppons pas des fonctionnalit\u00e9s pour le simple fait de les d\u00e9velopper ; nous les d\u00e9veloppons pour r\u00e9soudre des probl\u00e8mes pour les utilisateurs. Cela est capt\u00e9 dans les User Stories. Comprendre comment les lire et les r\u00e9diger est essentiel.<\/p>\n Une User Story standard suit une structure sp\u00e9cifique :<\/p>\n En tant que [r\u00f4le], je veux [fonctionnalit\u00e9], afin que [avantage].<\/p>\n<\/blockquote>\n Ce format vous oblige \u00e0 r\u00e9fl\u00e9chir au qui<\/strong>, au quoi<\/strong>, et au pourquoi<\/strong>. Lorsque vous recevez une story, votre premi\u00e8re t\u00e2che est de poser des questions. Si l’avantage est flou, la story est probablement incompl\u00e8te.<\/p>\n Chaque User Story doit avoir des crit\u00e8res d’acceptation. Ce sont les conditions qui doivent \u00eatre remplies pour que la story soit accept\u00e9e par le Product Owner. Elles agissent comme un contrat entre le d\u00e9veloppeur et le partie prenante. Recherchez les stories qui manquent de ces crit\u00e8res ; c’est un signe courant qu’un backlog n\u00e9cessite un nettoyage.<\/p>\n La r\u00e9union de planification du Sprint est l’occasion o\u00f9 l’\u00e9quipe d\u00e9cide du travail qu’elle abordera pour le cycle \u00e0 venir. Il s’agit d’un \u00e9v\u00e9nement collaboratif, et non d’une affectation hi\u00e9rarchique. Votre participation ici fixe le ton du Sprint.<\/p>\n La r\u00e9union est g\u00e9n\u00e9ralement divis\u00e9e en deux parties :<\/p>\n Les \u00e9quipes Agile utilisent rarement des heures pour l’estimation. \u00c0 la place, elles utilisent une estimation relative. Cela tient compte de la complexit\u00e9 et de l’effort par rapport aux autres stories. Les m\u00e9thodes courantes incluent :<\/p>\n Important :<\/strong> L’estimation est une estimation, pas une promesse. C’est un outil de planification, pas une cible de gestion des performances. \u00c9vitez de vous engager sur des d\u00e9lais pr\u00e9cis ; engagez-vous sur la port\u00e9e que vous croyez pouvoir g\u00e9rer dans le cadre du timebox.<\/p>\n D\u00e8s le d\u00e9but du Sprint, l’attention se concentre sur l’ex\u00e9cution. La r\u00e9union quotidienne (ou Daily Scrum) est le c\u0153ur battant du Sprint. Il s’agit d’une r\u00e9union br\u00e8ve, g\u00e9n\u00e9ralement de 15 minutes, o\u00f9 l’\u00e9quipe se synchronise.<\/p>\n Vous ne devez pas consid\u00e9rer cela comme un rapport d’\u00e9tat destin\u00e9 au manager. Il s’agit d’un plan pour les 24 prochaines heures. Lorsque c’est votre tour de parler, abordez trois points :<\/p>\n La fin du Sprint n’est pas la fin du travail ; c’est la fin d’un cycle. Deux \u00e9v\u00e9nements majeurs ont lieu pour boucler la boucle.<\/p>\n Il s’agit d’une d\u00e9monstration du travail accompli. L’\u00e9quipe montre l’incr\u00e9ment aux parties prenantes. Ce n’est pas une pr\u00e9sentation formelle avec diapositives. C’est une d\u00e9monstration pratique.<\/p>\n Cette r\u00e9union est r\u00e9serv\u00e9e uniquement \u00e0 l’\u00e9quipe. C’est un espace s\u00e9curis\u00e9 pour discuter de la mani\u00e8re dont le sprint s’est d\u00e9roul\u00e9. L’objectif est l’am\u00e9lioration continue.<\/p>\n Pour mieux visualiser le d\u00e9roulement de votre premi\u00e8re semaine, reportez-vous au tableau ci-dessous.<\/p>\n M\u00eame les d\u00e9veloppeurs exp\u00e9riment\u00e9s peuvent faire des erreurs lorsqu\u2019ils sont nouveaux dans Agile. Voici des pi\u00e8ges courants \u00e0 surveiller.<\/p>\n Agile exige la collaboration. Si vous attendez qu\u2019un ticket soit attribu\u00e9 avant de commencer \u00e0 y r\u00e9fl\u00e9chir, vous travaillez en silo. Communiquez t\u00f4t. Posez des questions. Partagez vos connaissances.<\/p>\n Terminer le code ne suffit pas. La d\u00e9finition de \u00ab fait \u00bb inclut g\u00e9n\u00e9ralement les tests, la documentation et la revue. Si vous sautez ces \u00e9tapes, vous cr\u00e9ez une dette technique qui ralentira l\u2019\u00e9quipe plus tard.<\/p>\n Il est tentant de dire oui \u00e0 tout. Si vous sur-engagez, vous manquerez l\u2019objectif du Sprint. Il vaut mieux s\u2019engager sur moins et livrer de fa\u00e7on coh\u00e9rente. La transparence est pr\u00e9f\u00e9rable aux promesses fallacieuses.<\/p>\n La r\u00e9trospective est souvent la r\u00e9union la plus pr\u00e9cieuse. Si vous la sautez, vous manquez la chance d\u2019am\u00e9liorer votre flux de travail. Traitez-la avec respect. Parlez des obstacles qui freinent votre productivit\u00e9.<\/p>\n Pour \u00eatre pr\u00eat Scrum, vous devez comprendre les trois artefacts fondamentaux qui assurent la transparence et l\u2019inspection.<\/p>\n Il s\u2019agit d\u2019une liste ordonn\u00e9e de tout ce qui est connu comme n\u00e9cessaire pour le produit. C\u2019est la source unique des exigences. Elle n\u2019est jamais compl\u00e8te. Elle est dynamique et \u00e9volue avec le produit et l\u2019environnement. En tant que d\u00e9veloppeur, vous pouvez ajouter des \u00e9l\u00e9ments \u00e0 cette liste, tels que des t\u00e2ches techniques n\u00e9cessaires pour soutenir des fonctionnalit\u00e9s.<\/p>\n Il s\u2019agit de l\u2019ensemble des \u00e9l\u00e9ments du Product Backlog s\u00e9lectionn\u00e9s pour le Sprint, accompagn\u00e9s d\u2019un plan pour livrer l\u2019Increment du produit. Il s\u2019agit d\u2019un plan \u00e9tabli par les D\u00e9veloppeurs. Il est visible de tous. Il \u00e9volue pendant le Sprint au fur et \u00e0 mesure que l\u2019\u00e9quipe en apprend davantage sur le travail.<\/p>\n Un Increment est une \u00e9tape concr\u00e8te vers l\u2019objectif du produit. Il s\u2019agit de la somme de tous les \u00e9l\u00e9ments du Product Backlog termin\u00e9s pendant un Sprint ainsi que de la valeur des increments de tous les Sprints pr\u00e9c\u00e9dents. Vous devez vous assurer que chaque Increment est en \u00e9tat utilisable, quels que soient les choix du Product Owner concernant sa mise en production.<\/p>\n Les comp\u00e9tences techniques sont essentielles, mais la communication est ce qui fait fonctionner une \u00e9quipe. Dans un environnement Agile, la communication est explicite et fr\u00e9quente.<\/p>\n Utilisez le tableau. D\u00e9placez les tickets au fur et \u00e0 mesure que vous travaillez. Si un ticket est bloqu\u00e9, d\u00e9placez-le dans la colonne \u00ab Bloqu\u00e9 \u00bb. Ce rep\u00e8re visuel signale \u00e0 l\u2019\u00e9quipe qu\u2019un aide est n\u00e9cessaire sans que vous ayez \u00e0 interrompre quelqu\u2019un constamment.<\/p>\n Tout n\u2019a pas besoin d\u2019une r\u00e9union. Utilisez des outils de messagerie pour partager des liens, poser des questions rapides ou annoncer la fin d\u2019une t\u00e2che. Cela r\u00e9duit la fatigue li\u00e9e aux r\u00e9unions et permet un travail en profondeur.<\/p>\n Demandez des retours t\u00f4t. Montrez votre code \u00e0 un coll\u00e8gue avant de le consid\u00e9rer comme termin\u00e9. Demandez au Product Owner si vous \u00eates sur la bonne voie avant de construire toute la fonctionnalit\u00e9. Cela \u00e9vite les efforts perdus.<\/p>\n La vitesse est importante, mais la qualit\u00e9 est incontournable. Agile ne signifie pas faire des raccourcis.<\/p>\n La dette technique survient lorsque vous choisissez une solution facile maintenant au lieu d’une approche meilleure qui prendrait plus de temps. Parfois, cela est n\u00e9cessaire pour gagner du temps, mais cela doit \u00eatre reconnu. Si vous prenez de la dette, vous devez cr\u00e9er une t\u00e2che pour la rembourser. Ne laissez pas la dette s’accumuler ind\u00e9finiment.<\/p>\n Pour avancer rapidement sans tout casser, vous avez besoin de confiance. Les tests automatis\u00e9s fournissent cette confiance. Les tests unitaires, les tests d’int\u00e9gration et les tests bout en bout doivent faire partie de votre D\u00e9finition de Fait. Si un test \u00e9choue, le travail n’est pas termin\u00e9.<\/p>\n L’Agile n’est pas une destination ; c’est un voyage continu. Votre premi\u00e8re semaine n’est que le d\u00e9but. Vous rencontrerez des changements de besoins, des priorit\u00e9s qui \u00e9voluent et de nouveaux d\u00e9fis. Le cadre fournit la structure pour g\u00e9rer ces changements avec \u00e9l\u00e9gance.<\/p>\n Souvenez-vous que le guide Scrum est la fondation. C’est la source de v\u00e9rit\u00e9 pour les r\u00f4les et les \u00e9v\u00e9nements. Si vous trouvez un processus qui ne correspond pas aux valeurs de l’Agile, en discutez lors de la r\u00e9trospective. L’objectif est de trouver ce qui fonctionne le mieux pour votre contexte d’\u00e9quipe sp\u00e9cifique tout en maintenant les principes fondamentaux.<\/p>\n En suivant cette feuille de route, vous construisez une base solide pour votre carri\u00e8re en d\u00e9veloppement Agile. Vous apprenez \u00e0 livrer de la valeur de fa\u00e7on coh\u00e9rente, \u00e0 collaborer efficacement et \u00e0 progresser continuellement. Bienvenue dans l’\u00e9quipe. Cr\u00e9ons quelque chose de formidable. \ud83c\udfd7\ufe0f<\/p>\n","protected":false},"excerpt":{"rendered":" Bienvenue au d\u00e9but de votre parcours vers le d\u00e9veloppement Agile. Le passage des m\u00e9thodes traditionnelles \u00e0 un cadre comme Scrum peut sembler accablant. Ce n\u2019est pas seulement une question de changement d\u2019outils ; il s\u2019agit de modifier votre mentalit\u00e9 vers la collaboration, l\u2019adaptabilit\u00e9 et l\u2019am\u00e9lioration continue. Ce guide est con\u00e7u pour vous offrir une voie structur\u00e9e durant vos premiers sept jours. \u00c0 la fin de cette semaine, vous comprendrez les m\u00e9canismes fondamentaux du cadre Scrum et sa mani\u00e8re d\u2019\u00eatre int\u00e9gr\u00e9 efficacement dans votre workflow quotidien. \ud83d\udee0\ufe0f Pourquoi ce plan d’action est-il important \ud83d\udccb Entrer dans un nouvel environnement de d\u00e9veloppement exige une clart\u00e9. Sans une compr\u00e9hension claire de la mani\u00e8re dont votre \u00e9quipe fonctionne, les progr\u00e8s peuvent stagner. Les m\u00e9thodologies Agile privil\u00e9gient les individus et les interactions plut\u00f4t que les processus et les outils. Toutefois, pour avoir des interactions significatives, vous avez besoin d\u2019un langage commun. Ce plan d’action vous assure d\u2019apprendre ce langage. Vous passerez d\u2019une observation passive \u00e0 une contribution active. L\u2019objectif est de devenir un membre fonctionnel d\u2019une \u00e9quipe Scrum qui comprend le \u00ab pourquoi \u00bb derri\u00e8re chaque c\u00e9r\u00e9monie et chaque artefact.pourquoiderri\u00e8re chaque c\u00e9r\u00e9monie et chaque artefact. Durant cette semaine, nous nous concentrerons sur : Comprendre le cadre : Comprendre les r\u00f4les fondamentaux, les \u00e9v\u00e9nements et les artefacts. Collaboration : Apprendre \u00e0 communiquer efficacement au sein d\u2019une \u00e9quipe. Ex\u00e9cution : Participer au cycle de sprint, de la planification \u00e0 la revue. R\u00e9flexion : Identifier les domaines de croissance personnelle et d\u2019\u00e9quipe. Jour 1 : Orientation et concepts fondamentaux \ud83e\udded Le premier jour consiste \u00e0 poser les bases. Vous n\u2019avez pas besoin d\u2019\u00e9crire du code imm\u00e9diatement. Concentrez-vous plut\u00f4t sur la compr\u00e9hension de l\u2019environnement et des r\u00e8gles d\u2019engagement. Votre t\u00e2che principale est d\u2019absorber le contexte dans lequel vous allez travailler. Activit\u00e9s cl\u00e9s pour le jour 1 Rencontrez l\u2019\u00e9quipe : Pr\u00e9sentez-vous au Product Owner, au Scrum Master et aux autres d\u00e9veloppeurs. Comprenez leurs r\u00f4les et responsabilit\u00e9s. Revoyez la D\u00e9finition de \u00ab Termin\u00e9 \u00bb : Il s\u2019agit d\u2019un accord fondamental au sein de l\u2019\u00e9quipe. Il d\u00e9finit les crit\u00e8res \u00e0 remplir pour qu\u2019un \u00e9l\u00e9ment de travail soit consid\u00e9r\u00e9 comme termin\u00e9. Si vous ne comprenez pas cela, vous ne pouvez pas livrer de valeur. Acc\u00e9dez au tableau : Obtenez l\u2019acc\u00e8s au tableau num\u00e9rique ou physique o\u00f9 le travail est suivi. Ne vous inqui\u00e9tez pas encore du logiciel sp\u00e9cifique. Comprenez les colonnes : \u00c0 faire, En cours, Termin\u00e9. Lisez le Product Backlog : Examine la liste existante d\u2019\u00e9l\u00e9ments. Ne cherchez pas \u00e0 les m\u00e9moriser, mais comprenez les types de travail r\u00e9alis\u00e9s (fonctionnalit\u00e9s, bogues, dette technique). Ce qu\u2019il faut \u00e9viter Ne supposez pas que vous savez comment fonctionne l\u2019\u00e9quipe en vous basant sur votre exp\u00e9rience pass\u00e9e. Chaque \u00e9quipe est unique. \u00c9vitez de demander des validations de code ou des demandes de fusion avant de comprendre la strat\u00e9gie de branche. Jour 2 : L\u2019art des user stories \ud83d\udcdd Le d\u00e9veloppement en mode Agile est guid\u00e9 par la valeur. Nous ne d\u00e9veloppons pas des fonctionnalit\u00e9s pour le simple fait de les d\u00e9velopper ; nous les d\u00e9veloppons pour r\u00e9soudre des probl\u00e8mes pour les utilisateurs. Cela est capt\u00e9 dans les User Stories. Comprendre comment les lire et les r\u00e9diger est essentiel. Comprendre le format Une User Story standard suit une structure sp\u00e9cifique : En tant que [r\u00f4le], je veux [fonctionnalit\u00e9], afin que [avantage]. Ce format vous oblige \u00e0 r\u00e9fl\u00e9chir au qui, au quoi, et au pourquoi. Lorsque vous recevez une story, votre premi\u00e8re t\u00e2che est de poser des questions. Si l’avantage est flou, la story est probablement incompl\u00e8te. Crit\u00e8res d’acceptation Chaque User Story doit avoir des crit\u00e8res d’acceptation. Ce sont les conditions qui doivent \u00eatre remplies pour que la story soit accept\u00e9e par le Product Owner. Elles agissent comme un contrat entre le d\u00e9veloppeur et le partie prenante. Recherchez les stories qui manquent de ces crit\u00e8res ; c’est un signe courant qu’un backlog n\u00e9cessite un nettoyage. Checklist du jour 2 Identifiez trois User Stories dans le backlog actuel. Analysez les crit\u00e8res d’acceptation de chacune. Identifiez toute lacune ou ambigu\u00eft\u00e9 dans la description. Assistez \u00e0 la session de nettoyage du backlog si elle est pr\u00e9vue, ou r\u00e9visez les notes. Jour 3 : Planification du Sprint et estimation \ud83d\uddd3\ufe0f La r\u00e9union de planification du Sprint est l’occasion o\u00f9 l’\u00e9quipe d\u00e9cide du travail qu’elle abordera pour le cycle \u00e0 venir. Il s’agit d’un \u00e9v\u00e9nement collaboratif, et non d’une affectation hi\u00e9rarchique. Votre participation ici fixe le ton du Sprint. Les deux parties de la planification La r\u00e9union est g\u00e9n\u00e9ralement divis\u00e9e en deux parties : Partie 1 : Qu’est-ce qui peut \u00eatre livr\u00e9 ? Le Product Owner pr\u00e9sente les \u00e9l\u00e9ments de plus haute priorit\u00e9. L’\u00e9quipe les discute et choisit une cible en fonction de sa capacit\u00e9. Partie 2 : Comment le travail sera-t-il accompli ? L’\u00e9quipe d\u00e9compose les \u00e9l\u00e9ments s\u00e9lectionn\u00e9s en t\u00e2ches techniques. C’est ici que vous d\u00e9finissez les \u00e9tapes n\u00e9cessaires pour construire la solution. Techniques d’estimation Les \u00e9quipes Agile utilisent rarement des heures pour l’estimation. \u00c0 la place, elles utilisent une estimation relative. Cela tient compte de la complexit\u00e9 et de l’effort par rapport aux autres stories. Les m\u00e9thodes courantes incluent : Points de story : Une unit\u00e9 de mesure repr\u00e9sentant la complexit\u00e9, l’effort et le risque. Tailles T-shirt : S, M, L, XL, XXL. Poker d’estimation : Une technique o\u00f9 tout le monde vote simultan\u00e9ment sur la taille d’une histoire afin d’\u00e9viter les biais. Important : L’estimation est une estimation, pas une promesse. C’est un outil de planification, pas une cible de gestion des performances. \u00c9vitez de vous engager sur des d\u00e9lais pr\u00e9cis ; engagez-vous sur la port\u00e9e que vous croyez pouvoir g\u00e9rer dans le cadre du timebox. Jour 4 : Ex\u00e9cution et r\u00e9unions quotidiennes \ud83c\udfc3 D\u00e8s le d\u00e9but du Sprint, l’attention se concentre sur l’ex\u00e9cution. La r\u00e9union quotidienne (ou Daily Scrum) est le c\u0153ur battant du Sprint. Il s’agit d’une r\u00e9union br\u00e8ve, g\u00e9n\u00e9ralement de 15 minutes, o\u00f9 l’\u00e9quipe se synchronise. Comment participer Vous ne devez pas consid\u00e9rer cela comme un rapport d’\u00e9tat destin\u00e9 au manager. Il s’agit d’un plan pour les 24 prochaines heures. Lorsque c’est votre tour de parler,<\/p>\n","protected":false},"author":1,"featured_media":4061,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_yoast_wpseo_title":"D\u00e9marrage rapide Agile : Feuille de route Scrum de la semaine 1","_yoast_wpseo_metadesc":"Apprenez \u00e0 devenir un d\u00e9veloppeur pr\u00eat \u00e0 utiliser Scrum durant votre premi\u00e8re semaine. Une feuille de route Agile d\u00e9taill\u00e9e couvrant les sprints, les stand-ups et les user stories.","fifu_image_url":"","fifu_image_alt":"","footnotes":""},"categories":[84],"tags":[77,83],"class_list":["post-4060","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agile","tag-academic","tag-agile"],"yoast_head":"\n\n
Jour 1 : Orientation et concepts fondamentaux \ud83e\udded<\/h2>\n
Activit\u00e9s cl\u00e9s pour le jour 1<\/h3>\n
\n
Ce qu\u2019il faut \u00e9viter<\/h3>\n
\n
Jour 2 : L\u2019art des user stories \ud83d\udcdd<\/h2>\n
Comprendre le format<\/h3>\n
\n
Crit\u00e8res d’acceptation<\/h3>\n
Checklist du jour 2<\/h3>\n
\n
Jour 3 : Planification du Sprint et estimation \ud83d\uddd3\ufe0f<\/h2>\n
Les deux parties de la planification<\/h3>\n
\n
Techniques d’estimation<\/h3>\n
\n
Jour 4 : Ex\u00e9cution et r\u00e9unions quotidiennes \ud83c\udfc3<\/h2>\n
Comment participer<\/h3>\n
\n
Travailler pendant le Sprint<\/h3>\n
\n
Jour 5 : Revue du Sprint et r\u00e9trospective \ud83d\udd04<\/h2>\n
Revue du Sprint<\/h3>\n
\n
R\u00e9trospective de sprint<\/h3>\n
\n
Aper\u00e7u du planning hebdomadaire \ud83d\udcc5<\/h2>\n
\n\n
\n \nJour<\/th>\n Domaine d’attention<\/th>\n \u00c9v\u00e9nement cl\u00e9<\/th>\n R\u00e9sultat<\/th>\n<\/tr>\n<\/thead>\n \n 1<\/td>\n Orientation<\/td>\n Pr\u00e9sentation de l’\u00e9quipe et revue du backlog<\/td>\n Comprendre les r\u00f4les et la d\u00e9finition de \u00ab fait \u00bb<\/td>\n<\/tr>\n \n 2<\/td>\n Exigences<\/td>\n Affinage du backlog<\/td>\n Apprenez \u00e0 r\u00e9diger\/lire des User Stories<\/td>\n<\/tr>\n \n 3<\/td>\n Planification<\/td>\n Planification du sprint<\/td>\n Engagement sur l’objectif du sprint et les t\u00e2ches<\/td>\n<\/tr>\n \n 4<\/td>\n Ex\u00e9cution<\/td>\n R\u00e9union quotidienne<\/td>\n Commencez \u00e0 coder et \u00e9liminez les obstacles<\/td>\n<\/tr>\n \n 5<\/td>\n Revue et r\u00e9flexion<\/td>\n Revue et r\u00e9trospective<\/td>\n D\u00e9montrer le travail accompli et planifier les am\u00e9liorations<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n P\u00e9ch\u00e9s courants \u00e0 \u00e9viter \u26a0\ufe0f<\/h2>\n
1. Travailler en silos<\/h3>\n
2. Ignorer la d\u00e9finition de \u00ab fait \u00bb<\/h3>\n
3. Sur-engager<\/h3>\n
4. Sauter la r\u00e9trospective<\/h3>\n
Approfondissement : les artefacts Scrum \ud83d\udce6<\/h2>\n
1. Product Backlog<\/h3>\n
2. Sprint Backlog<\/h3>\n
3. Increment<\/h3>\n
Strat\u00e9gies de communication \ud83d\udcac<\/h2>\n
1. Gestion visuelle<\/h3>\n
2. Mises \u00e0 jour asynchrones<\/h3>\n
3. Boucles de retour<\/h3>\n
La dette technique et la qualit\u00e9 \ud83d\udee1\ufe0f<\/h2>\n
G\u00e9rer la dette technique<\/h3>\n
Tests automatis\u00e9s<\/h3>\n
Derni\u00e8res r\u00e9flexions sur l’adaptabilit\u00e9 \ud83c\udf31<\/h2>\n