![\"Chalkboard-style](\"https:\/\/www.diagrams-ai.com\/wp-content\/uploads\/2026\/03\/agile-sprint-failure-recovery-case-study-infographic-chalkboard.jpg\"\/)
<\/figure>\n<\/div>\nContexte : L’\u00e9quipe et l’environnement \ud83c\udfe2<\/h2>\n
Pour comprendre l’\u00e9chec, nous devons d’abord comprendre la structure. L’organisation fonctionne selon un mod\u00e8le d’\u00e9quipe pluridisciplinaire. Le groupe se compose de cinq d\u00e9veloppeurs, d’un product owner et d’un testeur d\u00e9di\u00e9. Le travail est organis\u00e9 en cycles de deux semaines.<\/p>\n
L’\u00e9quipe utilisait un tableau de suivi physique et num\u00e9rique pour g\u00e9rer le flux. Les histoires \u00e9taient d\u00e9plac\u00e9es de Backlog<\/strong> \u00e0 En cours<\/strong> puis enfin \u00e0 Termin\u00e9<\/strong>. L’objectif \u00e9tait une livraison constante de valeur sans compromettre la qualit\u00e9 du code.<\/p>\n Le sprint 42 a commenc\u00e9 avec une forte impulsion. L’\u00e9quipe a tir\u00e9 30 points d’histoire depuis le backlog. Au troisi\u00e8me jour, le rythme semblait stable. Au cinqui\u00e8me jour, des frictions sont apparues. Au dixi\u00e8me jour, l’\u00e9quipe a compris qu’elle ne terminerait pas le travail engag\u00e9.<\/p>\n L’\u00e9chec n’\u00e9tait pas d\u00fb \u00e0 un seul \u00e9v\u00e9nement catastrophique. Il s’agissait d’une s\u00e9rie cumul\u00e9e de probl\u00e8mes qui ont \u00e9rod\u00e9 la capacit\u00e9.<\/p>\n Les chiffres racontent une histoire plus claire que les sentiments. Le tableau suivant illustre l’\u00e9cart entre l’effort pr\u00e9vu et la livraison r\u00e9elle.<\/p>\n Ces donn\u00e9es r\u00e9v\u00e8lent une d\u00e9viation importante des ressources. Ce qui a commenc\u00e9 comme du travail de d\u00e9veloppement s’est transform\u00e9 en maintenance et gestion de crise.<\/p>\n Bl\u00e2mer les individus ne r\u00e9sout pas les probl\u00e8mes syst\u00e9miques. L’\u00e9quipe a men\u00e9 une analyse des causes profondes sans bl\u00e2me afin d’identifier les probl\u00e8mes fondamentaux.<\/p>\n Pour aller plus loin, l’\u00e9quipe a appliqu\u00e9 la 5 pourquoi<\/strong> m\u00e9thode au probl\u00e8me des d\u00e9lais manqu\u00e9s.<\/p>\n Le probl\u00e8me fondamental n’\u00e9tait pas la pr\u00e9cision de la planification ; c’\u00e9tait la mise en \u0153uvre de pratiques d’ing\u00e9nierie durables.<\/p>\n Une r\u00e9trospective est le moteur de l’am\u00e9lioration agile. Toutefois, un sprint \u00e9chou\u00e9 exige un type particulier de r\u00e9trospective. Les formats standards semblent souvent \u00eatre une simple v\u00e9rification de cases. Cette session a exig\u00e9 un sentiment de s\u00e9curit\u00e9 psychologique et une enqu\u00eate approfondie.<\/p>\n Avant la r\u00e9union, le propri\u00e9taire produit a collect\u00e9 des donn\u00e9es. L’\u00e9quipe a \u00e9t\u00e9 invit\u00e9e \u00e0 r\u00e9fl\u00e9chir individuellement \u00e0 ce qui s’\u00e9tait bien pass\u00e9 et \u00e0 ce qui n’avait pas fonctionn\u00e9. Cela a assur\u00e9 que les membres discrets aient le temps de formuler leurs id\u00e9es.<\/p>\n L’\u00e9quipe a discut\u00e9 du concept de l’analyse de capacit\u00e9<\/strong>. Ils ont r\u00e9alis\u00e9 qu’ils avaient engag\u00e9 100 % de leur temps sur de nouvelles fonctionnalit\u00e9s. Il n’y avait aucune marge de man\u0153uvre pour les interruptions in\u00e9vitables qui surviennent dans les environnements en production.<\/p>\n Ils ont \u00e9galement abord\u00e9 le D\u00e9finition de \u00ab fait \u00bb<\/strong>. Actuellement, \u00ab fait \u00bb signifiait \u00ab Code \u00e9crit \u00bb. Il ne comprenait pas \u00ab Code revu \u00bb ou \u00ab Tests \u00e9crits \u00bb. Cette divergence a cr\u00e9\u00e9 un goulot d’\u00e9tranglement \u00e0 la fin de la sprint.<\/p>\n Conna\u00eetre le probl\u00e8me n’est que la moiti\u00e9 de la bataille. La strat\u00e9gie de r\u00e9cup\u00e9ration n\u00e9cessitait des changements dans le flux de travail, les attentes et les normes techniques.<\/p>\n L’\u00e9quipe a cess\u00e9 de s’engager \u00e0 100 % de ses heures disponibles. Ils ont adopt\u00e9 une strat\u00e9gie de buffer<\/strong>.<\/p>\n Ce changement a r\u00e9duit la pression pour livrer des chiffres parfaits et a permis une gestion r\u00e9aliste des interruptions.<\/p>\n L’\u00e9quipe a mis \u00e0 jour leur liste de v\u00e9rification DoD<\/strong>. Une histoire ne pouvait pas passer \u00e0 Termin\u00e9<\/strong> sans remplir ces crit\u00e8res :<\/p>\n Cela a emp\u00each\u00e9 la dette technique de s’accumuler silencieusement. Cela a assur\u00e9 que ce qui \u00e9tait livr\u00e9 \u00e9tait v\u00e9ritablement utilisable.<\/p>\n Les canaux de communication avec les fournisseurs externes ont \u00e9t\u00e9 formalis\u00e9s. L’\u00e9quipe exige d\u00e9sormais :<\/p>\n L’\u00e9quipe s’est accord\u00e9e \u00e0 consacrer un sprint par trimestre sp\u00e9cifiquement \u00e0 la r\u00e9duction de la dette technique. Cela emp\u00eache l’effet d’int\u00e9r\u00eat compos\u00e9 du code de mauvaise qualit\u00e9. Cela signale aux parties prenantes que la stabilit\u00e9 est une fonctionnalit\u00e9, et non une r\u00e9flexion tardive.<\/p>\n Les changements ont \u00e9t\u00e9 mis en \u0153uvre imm\u00e9diatement lors du sprint 43. La r\u00e9cup\u00e9ration n\u2019a pas \u00e9t\u00e9 instantan\u00e9e, mais la trajectoire s\u2019est modifi\u00e9e.<\/p>\n L’\u00e9quipe n’a pas cherch\u00e9 \u00e0 revenir \u00e0 l’ancienne vitesse de 30 points. Elle visait plut\u00f4t pr\u00e9visibilit\u00e9<\/strong>. Il vaut mieux s’engager sur moins et livrer de fa\u00e7on coh\u00e9rente que de s’engager trop et \u00e9chouer.<\/p>\n Pour assurer que la reprise soit effective, l’\u00e9quipe a suivi des indicateurs pr\u00e9cis au cours des trois prochains mois.<\/p>\n Les donn\u00e9es montrent une corr\u00e9lation claire entre les changements de processus et la sant\u00e9 de l’\u00e9quipe. Moins de bogues ont entra\u00een\u00e9 moins de stress, ce qui a am\u00e9lior\u00e9 le moral.<\/p>\n L’\u00e9chec est un professeur. Voici les le\u00e7ons tir\u00e9es de cette \u00e9tude de cas qui s’appliquent \u00e0 tout environnement agile.<\/p>\n La vitesse sans stabilit\u00e9 est une illusion. Les \u00e9quipes doivent privil\u00e9gier la livraison r\u00e9guli\u00e8re plut\u00f4t que la production brute. Les parties prenantes font confiance aux \u00e9quipes qui tiennent leurs promesses, m\u00eame si celles-ci sont plus modestes.<\/p>\n Pr\u00e9voyez toujours l’impr\u00e9vu. Si vous disposez de 100 heures disponibles, pr\u00e9voyez 70 heures de travail. Le temps restant absorbe les frottements in\u00e9vitables du d\u00e9veloppement logiciel.<\/p>\n La DoD n’est pas une suggestion. C’est un contrat entre l’\u00e9quipe et le propri\u00e9taire produit. Si une histoire ne r\u00e9pond pas \u00e0 la DoD, elle n’est pas pr\u00eate \u00e0 \u00eatre livr\u00e9e.<\/p>\n Quand les choses tournent mal, l’\u00e9quipe doit se sentir en s\u00e9curit\u00e9 pour parler. Si les membres craignent des sanctions, ils cacheront les probl\u00e8mes jusqu’\u00e0 ce qu’ils deviennent des crises.<\/p>\n Le logiciel n’existe pas dans un vide. Les d\u00e9pendances vis-\u00e0-vis des services tiers doivent \u00eatre g\u00e9r\u00e9es avec la m\u00eame rigueur que le code interne.<\/p>\n Beaucoup d’\u00e9quipes tentent de corriger les \u00e9checs en travaillant plus dur. C’est une erreur courante. Les actions suivantes doivent \u00eatre \u00e9vit\u00e9es pendant une p\u00e9riode de r\u00e9cup\u00e9ration.<\/p>\n L’objectif de l’agilit\u00e9 n’est pas seulement de livrer du code, mais de construire un syst\u00e8me capable de livrer du code ind\u00e9finiment. Le rythme durable est la fondation de ce syst\u00e8me.<\/p>\n Apr\u00e8s la r\u00e9cup\u00e9ration, l’\u00e9quipe a \u00e9tabli un rythme d’am\u00e9lioration continue<\/strong>. Toutes les deux semaines, ils examinent non seulement le sprint, mais aussi l’\u00e9tat du flux de travail. Ils se posent des questions comme :<\/p>\n Cette surveillance continue emp\u00eache les petits probl\u00e8mes de devenir \u00e0 nouveau de grandes erreurs.<\/p>\n La transparence vis-\u00e0-vis des parties prenantes est cruciale. Lorsqu’un sprint \u00e9choue, communiquez t\u00f4t. Expliquez l’impact, la cause et le plan. Cela renforce la confiance.<\/p>\n Les parties prenantes consid\u00e8rent souvent un sprint \u00e9chou\u00e9 comme une preuve d’incomp\u00e9tence. Lorsqu’il est expliqu\u00e9 comme un point de donn\u00e9es pour l’am\u00e9lioration, cela devient une preuve de maturit\u00e9 professionnelle. Elles pr\u00e9f\u00e8rent une \u00e9quipe qui reconna\u00eet un probl\u00e8me et le corrige \u00e0 une \u00e9quipe qui le cache.<\/p>\n Les \u00e9checs sont normaux. Un taux d’\u00e9chec de 10 % est souvent acceptable selon le domaine. Des taux \u00e9lev\u00e9s constants indiquent un probl\u00e8me syst\u00e9mique de planification.<\/p>\n G\u00e9n\u00e9ralement, non. Arr\u00eater un sprint perd le temps d\u00e9j\u00e0 investi. Il est pr\u00e9f\u00e9rable de terminer ce qui peut l’\u00eatre et de recommencer pour le cycle suivant.<\/p>\n Oui, si votre vitesse est artificiellement gonfl\u00e9e par un engagement excessif. La r\u00e9duire pour correspondre \u00e0 la r\u00e9alit\u00e9 am\u00e9liore la pr\u00e9cision et la pr\u00e9visibilit\u00e9.<\/p>\n Des solutions temporaires sont possibles, mais une r\u00e9cup\u00e9ration \u00e0 long terme n\u00e9cessite un changement de processus. Autrement, l’\u00e9chec se reproduira.<\/p>\n L’Agile est un parcours d’adaptation. Un sprint \u00e9chou\u00e9 n’est pas la fin de la route ; c’est un panneau indiquant la voie vers de meilleures pratiques. En analysant profond\u00e9ment l’\u00e9chec et en mettant en \u0153uvre des changements structurels, les \u00e9quipes peuvent ressortir plus fortes et plus r\u00e9silientes.<\/p>\n","protected":false},"excerpt":{"rendered":" La m\u00e9thodologie Agile promet de la flexibilit\u00e9, de la r\u00e9activit\u00e9 et une am\u00e9lioration continue. Toutefois, la r\u00e9alit\u00e9 comporte souvent des revers. Un sprint \u00e9chou\u00e9 n’est pas une anomalie ; c’est un indicateur. Comprendre comment une \u00e9quipe g\u00e8re l’\u00e9chec d\u00e9termine davantage la r\u00e9ussite \u00e0 long terme que la c\u00e9l\u00e9bration de cycles parfaits. Cet article examine un sc\u00e9nario pr\u00e9cis o\u00f9 une \u00e9quipe de d\u00e9veloppement a compl\u00e8tement manqu\u00e9 ses objectifs de sprint. Nous explorerons les facteurs techniques et humains impliqu\u00e9s, le processus de r\u00e9trospective utilis\u00e9 pour diagnostiquer le probl\u00e8me, ainsi que les mesures concr\u00e8tes prises pour restaurer la vitesse et la qualit\u00e9. Contexte : L’\u00e9quipe et l’environnement \ud83c\udfe2 Pour comprendre l’\u00e9chec, nous devons d’abord comprendre la structure. L’organisation fonctionne selon un mod\u00e8le d’\u00e9quipe pluridisciplinaire. Le groupe se compose de cinq d\u00e9veloppeurs, d’un product owner et d’un testeur d\u00e9di\u00e9. Le travail est organis\u00e9 en cycles de deux semaines. L’\u00e9quipe utilisait un tableau de suivi physique et num\u00e9rique pour g\u00e9rer le flux. Les histoires \u00e9taient d\u00e9plac\u00e9es de Backlog \u00e0 En cours puis enfin \u00e0 Termin\u00e9. L’objectif \u00e9tait une livraison constante de valeur sans compromettre la qualit\u00e9 du code. Caract\u00e9ristiques cl\u00e9s Taille de l’\u00e9quipe : 7 membres (y compris le personnel de soutien). Dur\u00e9e du cycle : 14 jours. Objectif : Am\u00e9liorations de fonctionnalit\u00e9s visibles aux clients. Performance ant\u00e9rieure : A atteint de mani\u00e8re constante entre 80 % et 90 % des points d’histoire engag\u00e9s pendant six mois pr\u00e9c\u00e9dents. L’incident : D\u00e9faillance du sprint 42 \ud83d\udcc9 Le sprint 42 a commenc\u00e9 avec une forte impulsion. L’\u00e9quipe a tir\u00e9 30 points d’histoire depuis le backlog. Au troisi\u00e8me jour, le rythme semblait stable. Au cinqui\u00e8me jour, des frictions sont apparues. Au dixi\u00e8me jour, l’\u00e9quipe a compris qu’elle ne terminerait pas le travail engag\u00e9. L’\u00e9chec n’\u00e9tait pas d\u00fb \u00e0 un seul \u00e9v\u00e9nement catastrophique. Il s’agissait d’une s\u00e9rie cumul\u00e9e de probl\u00e8mes qui ont \u00e9rod\u00e9 la capacit\u00e9. Chronologie des \u00e9v\u00e9nements Jour 1 : Planification du sprint termin\u00e9e. 30 points engag\u00e9s. Jour 3 : Un bug critique est apparu dans la version pr\u00e9c\u00e9dente, consommant 2 jours de travail pour les d\u00e9veloppeurs. Jour 5 : L’API de d\u00e9pendance externe a chang\u00e9 de mani\u00e8re inattendue sans avis pr\u00e9alable. Jour 7 : Le moral de l’\u00e9quipe a baiss\u00e9 en raison d’un manque per\u00e7u de clart\u00e9 sur les exigences. Jour 10 : La dette technique des sprints pr\u00e9c\u00e9dents a commenc\u00e9 \u00e0 bloquer le d\u00e9veloppement nouveau. Jour 14 : Seulement 12 points ont \u00e9t\u00e9 accomplis. 60 % du sprint ont \u00e9t\u00e9 manqu\u00e9s. Quantifier l’\u00e9chec \ud83d\udcca Les chiffres racontent une histoire plus claire que les sentiments. Le tableau suivant illustre l’\u00e9cart entre l’effort pr\u00e9vu et la livraison r\u00e9elle. Cat\u00e9gorie Pr\u00e9vu R\u00e9el \u00c9cart Points d’histoire accomplis 30 12 -18 Bugs trouv\u00e9s (pendant le sprint) 2 14 +12 Tickets de support trait\u00e9s 0 3 +3 Changements de d\u00e9pendances externes 0 1 +1 Ces donn\u00e9es r\u00e9v\u00e8lent une d\u00e9viation importante des ressources. Ce qui a commenc\u00e9 comme du travail de d\u00e9veloppement s’est transform\u00e9 en maintenance et gestion de crise. Analyse des causes profondes \ud83d\udd0d Bl\u00e2mer les individus ne r\u00e9sout pas les probl\u00e8mes syst\u00e9miques. L’\u00e9quipe a men\u00e9 une analyse des causes profondes sans bl\u00e2me afin d’identifier les probl\u00e8mes fondamentaux. Facteurs principaux identifi\u00e9s Influx de travail impr\u00e9vu : Aucun m\u00e9canisme n’existait pour amortir le sprint face aux bogues impr\u00e9vus ou aux tickets de support. Ambigu\u00eft\u00e9 de la d\u00e9finition de \u00ab fait \u00bb (DoD) : Les crit\u00e8res d’acceptation \u00e9taient flous, entra\u00eenant des reprises de travail. Dette technique : Des d\u00e9cisions ant\u00e9rieures ont \u00e9t\u00e9 prises pour aller vite, ce qui a cr\u00e9\u00e9 des frictions dans le d\u00e9veloppement actuel. Failles de communication externe : L’\u00e9quipe n’a pas \u00e9t\u00e9 inform\u00e9e des modifications de l’API par le fournisseur jusqu’\u00e0 ce que l’int\u00e9gration \u00e9choue. La technique des 5 pourquoi Pour aller plus loin, l’\u00e9quipe a appliqu\u00e9 la 5 pourquoi m\u00e9thode au probl\u00e8me des d\u00e9lais manqu\u00e9s. Pourquoi avons-nous manqu\u00e9 l’objectif du sprint ? Parce que nous avons termin\u00e9 moins d’histoires que pr\u00e9vu. Pourquoi moins d’histoires ont-elles \u00e9t\u00e9 termin\u00e9es ? Parce que les d\u00e9veloppeurs \u00e9taient bloqu\u00e9s par des bogues et des changements externes. Pourquoi \u00e9taient-ils bloqu\u00e9s ? Parce que la correction du bogue a pris plus de temps que pr\u00e9vu, et que le changement d’API a exig\u00e9 une refonte. Pourquoi le bogue a-t-il pris plus de temps ? Parce que la base de code pr\u00e9sentait une haute complexit\u00e9 et une faible couverture de tests. Pourquoi la couverture de tests \u00e9tait-elle faible ? Parce que les sprints pass\u00e9s ont privil\u00e9gi\u00e9 la vitesse des fonctionnalit\u00e9s par rapport \u00e0 la stabilit\u00e9. Le probl\u00e8me fondamental n’\u00e9tait pas la pr\u00e9cision de la planification ; c’\u00e9tait la mise en \u0153uvre de pratiques d’ing\u00e9nierie durables. Le processus de r\u00e9trospective \ud83d\udde3\ufe0f Une r\u00e9trospective est le moteur de l’am\u00e9lioration agile. Toutefois, un sprint \u00e9chou\u00e9 exige un type particulier de r\u00e9trospective. Les formats standards semblent souvent \u00eatre une simple v\u00e9rification de cases. Cette session a exig\u00e9 un sentiment de s\u00e9curit\u00e9 psychologique et une enqu\u00eate approfondie. Pr\u00e9paration Avant la r\u00e9union, le propri\u00e9taire produit a collect\u00e9 des donn\u00e9es. L’\u00e9quipe a \u00e9t\u00e9 invit\u00e9e \u00e0 r\u00e9fl\u00e9chir individuellement \u00e0 ce qui s’\u00e9tait bien pass\u00e9 et \u00e0 ce qui n’avait pas fonctionn\u00e9. Cela a assur\u00e9 que les membres discrets aient le temps de formuler leurs id\u00e9es. R\u00e8gles de facilitation Pas d’attaques personnelles : Concentrez-vous sur le processus, pas sur les personnes. Une seule conversation : Une seule personne parle \u00e0 la fois. R\u00e9sultats exploitables : Chaque probl\u00e8me identifi\u00e9 doit mener \u00e0 une exp\u00e9rience sp\u00e9cifique. Discussions cl\u00e9s L’\u00e9quipe a discut\u00e9 du concept de l’analyse de capacit\u00e9. Ils ont r\u00e9alis\u00e9 qu’ils avaient engag\u00e9 100 % de leur temps sur de nouvelles fonctionnalit\u00e9s. Il n’y avait aucune marge de man\u0153uvre pour les interruptions in\u00e9vitables qui surviennent dans les environnements en production. Ils ont \u00e9galement abord\u00e9 le D\u00e9finition de \u00ab fait \u00bb. Actuellement, \u00ab fait \u00bb signifiait \u00ab Code \u00e9crit \u00bb. Il ne comprenait pas \u00ab Code revu \u00bb ou \u00ab Tests \u00e9crits \u00bb. Cette divergence a cr\u00e9\u00e9 un goulot d’\u00e9tranglement \u00e0 la fin de la sprint. Strat\u00e9gie de r\u00e9cup\u00e9ration : Le plan \u2699\ufe0f Conna\u00eetre le probl\u00e8me n’est que la moiti\u00e9 de la bataille. La strat\u00e9gie de r\u00e9cup\u00e9ration n\u00e9cessitait des changements<\/p>\n","protected":false},"author":1,"featured_media":4171,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_yoast_wpseo_title":"R\u00e9cup\u00e9ration apr\u00e8s un sprint \u00e9chou\u00e9 Agile : \u00e9tude de cas et \u00e9tapes \ud83d\ude80","_yoast_wpseo_metadesc":"D\u00e9couvrez comment une \u00e9quipe s'est remise d'un sprint \u00e9chou\u00e9. \u00c9tude de cas d\u00e9taill\u00e9e sur l'analyse des causes profondes, les r\u00e9trospectives et les strat\u00e9gies de r\u00e9cup\u00e9ration Agile.","fifu_image_url":"","fifu_image_alt":"","footnotes":""},"categories":[84],"tags":[77,83],"class_list":["post-4170","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agile","tag-academic","tag-agile"],"yoast_head":"\nCaract\u00e9ristiques cl\u00e9s<\/h3>\n
\n
L’incident : D\u00e9faillance du sprint 42 \ud83d\udcc9<\/h2>\n
Chronologie des \u00e9v\u00e9nements<\/h3>\n
\n
Quantifier l’\u00e9chec \ud83d\udcca<\/h2>\n
\n\n
\n \nCat\u00e9gorie<\/th>\n Pr\u00e9vu<\/th>\n R\u00e9el<\/th>\n \u00c9cart<\/th>\n<\/tr>\n<\/thead>\n \n Points d’histoire accomplis<\/td>\n 30<\/td>\n 12<\/td>\n -18<\/td>\n<\/tr>\n \n Bugs trouv\u00e9s (pendant le sprint)<\/td>\n 2<\/td>\n 14<\/td>\n +12<\/td>\n<\/tr>\n \n Tickets de support trait\u00e9s<\/td>\n 0<\/td>\n 3<\/td>\n +3<\/td>\n<\/tr>\n \n Changements de d\u00e9pendances externes<\/td>\n 0<\/td>\n 1<\/td>\n +1<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Analyse des causes profondes \ud83d\udd0d<\/h2>\n
Facteurs principaux identifi\u00e9s<\/h3>\n
\n
La technique des 5 pourquoi<\/h3>\n
\n
Le processus de r\u00e9trospective \ud83d\udde3\ufe0f<\/h2>\n
Pr\u00e9paration<\/h3>\n
R\u00e8gles de facilitation<\/h3>\n
\n
Discussions cl\u00e9s<\/h3>\n
Strat\u00e9gie de r\u00e9cup\u00e9ration : Le plan \u2699\ufe0f<\/h2>\n
1. Ajuster la planification de capacit\u00e9<\/h3>\n
\n
2. Renforcer la D\u00e9finition de \u00ab fait \u00bb<\/h3>\n
\n
3. Gestion des d\u00e9pendances externes<\/h3>\n
\n
4. Sprints de r\u00e9duction de la dette technique<\/h3>\n
Mise en \u0153uvre et suivi \ud83d\udcc8<\/h2>\n
R\u00e9sultats du sprint 43<\/h3>\n
\n
Indicateurs de suivi<\/h3>\n
\n\n
\n \nSemaine<\/th>\n Objectif de sprint atteint<\/th>\n Nombre de bogues<\/th>\n Moral d’\u00e9quipe (1-5)<\/th>\n<\/tr>\n<\/thead>\n \n Mois 1<\/td>\n Oui<\/td>\n 12<\/td>\n 3<\/td>\n<\/tr>\n \n Mois 2<\/td>\n Oui<\/td>\n 8<\/td>\n 4<\/td>\n<\/tr>\n \n Mois 3<\/td>\n Oui<\/td>\n 5<\/td>\n 5<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Points cl\u00e9s pour les \u00e9quipes agiles \ud83d\udcdd<\/h2>\n
1. Pr\u00e9visibilit\u00e9 avant vitesse<\/h3>\n
2. La capacit\u00e9 inclut une marge de s\u00e9curit\u00e9<\/h3>\n
3. La d\u00e9finition de termin\u00e9 est un contrat<\/h3>\n
4. La s\u00e9curit\u00e9 psychologique est essentielle<\/h3>\n
5. Les d\u00e9pendances externes doivent \u00eatre g\u00e9r\u00e9es<\/h3>\n
P\u00e9ch\u00e9s courants dans la r\u00e9cup\u00e9ration \ud83d\udeab<\/h2>\n
\n
Durabilit\u00e9 \u00e0 long terme \ud83c\udf31<\/h2>\n
\n
Conclusion destin\u00e9e aux parties prenantes \ud83e\udd1d<\/h2>\n
Questions fr\u00e9quemment pos\u00e9es \u2753<\/h2>\n
Avec quelle fr\u00e9quence une \u00e9quipe devrait-elle s’attendre \u00e0 \u00e9chouer ?<\/h3>\n
Devrions-nous arr\u00eater le sprint apr\u00e8s un \u00e9chec ?<\/h3>\n
Cela signifie-t-il que nous devrions r\u00e9duire notre vitesse ?<\/h3>\n
Pouvons-nous nous r\u00e9tablir sans changer le processus ?<\/h3>\n