<\/p>\n
Comment \u00e7a \n“Scrum c’est super bien, mais entre la r\u00e9union de planification du Sprint et les changement incessants de priorit\u00e9s d\u00fb \u00e0 des demandes urgentes de support de la part des projets, on ne peut pas garantir plus de 20% du respect de l’engagement initial….”<\/i><\/span><\/p><\/blockquote>\n ou<\/p>\n \n“Je voudrais bien que l’on se mette \u00e0 Kanban pour favoriser l’interaction des \u00e9quipiers, et g\u00e9rer nos priorit\u00e9s au jour le jour\/\u00e0 la demande, mais entre les diff\u00e9rents domaines d’expertise sur lesquels nous sommes sollicit\u00e9s, il est impossible de d\u00e9finir un processus commun \u00e0 toute l’\u00e9quipe, quelque soit la demande.”<\/i><\/span><\/p><\/blockquote>\n Je vous propose ci-dessous une vulgarisation des principes de Scrumban pour une mise en oeuvre dans ce type de contexte.<\/span><\/p>\n
\nmarche :<\/b><\/span><\/p>\n\n
\nde <\/span>lancement pour un Sprint<\/u> dans lequel chaque item compte pour 1<\/span><\/li>\n<\/ul>\n\n
\ninjection d\u2019\u00e9l\u00e9ments <\/span>\u00e0 la demande<\/u> dans la colonne \u00ab A faire \u00bb. Le backlog
\nsur le tableau devient donc une ent\u00e9e permettant de prioriser dans la colonne
\n\u00ab Pr\u00eat \u00bb les \u00e9l\u00e9ments \u00e0 prendre en priorit\u00e9 (cf pt
\n1)<\/span><\/li>\n<\/ul>\n\n
\ntous debout devant le tableau.<\/span><\/li>\n<\/ul>\n\n
\nchangements de priorit\u00e9 du jour et les nouveaux \u00e9l\u00e9ments sont ajout\u00e9s au
\ntableau<\/span><\/li>\n<\/ul>\n\n
\nrencontr\u00e9s, fait le point sur son avancement au regard des items, et expose ce
\nqu\u2019il fera dans la journ\u00e9e.<\/span><\/li>\n<\/ul>\n
<\/span><\/div>\n
<\/span><\/div>\n
\npeuvent motiver la mise en \u0153uvre de Scrumban plutot que Scrum, Kanban ou encore XP : <\/span><\/div>\n
<\/b><\/span><\/div>\n
\nt\u00e2ches :<\/u>
\nScrum avec les colonnes A faire -> En
\ncours -> Termin\u00e9<\/i>.
\nsuppl\u00e9mentaire \u00ab Pr\u00eat \u00bb qui permet de prioriser les demandes entre la backlog (A
\nfaire) et le travail en cours.
\nA faire -> Pr\u00eat -> En cours ->
\nTermin\u00e9<\/i>
\nlimites : <\/u>
\nn\u2019obtient pas un syst\u00e8me Kanban, et on risque de commencer plein d\u2019activit\u00e9s
\nsans en terminer aucune. On ne travaillera donc pas en
\nflux.
\ntravail en cours est : nb personnes dans l\u2019\u00e9quipe *
\n2.
\nblocages : je suis bloqu\u00e9, donc je passe \u00e0 la t\u00e2che suivante en attendant de
\nd\u00e9bloquer la pr\u00e9c\u00e9dente.
\n\u00e9l\u00e9ments<\/u>
\non alimente une Backlog avec une liste de choses \u00e0 faire. Cette Backlog est
\ndiscut\u00e9e avec le Product Owner puis estim\u00e9e en complexit\u00e9 (la \u00ab taille \u00bb de
\n
\nv\u00e9locit\u00e9 de l\u2019\u00e9quipe est un indicateur qui permet de limiter pour un Sprint
\n(\u00ab TimeBoxing \u00bb) la quantit\u00e9 de travail \u00e0 r\u00e9aliser.
\nla taille n\u2019importe pas. Ce qui compte c\u2019est le nombre d\u2019\u00e9l\u00e9ments en cours que l’on limite de mani\u00e8re explicite par un nombre d’\u00e9l\u00e9ments (t\u00e2ches\/story) sur chaque colonne du
\nsyst\u00e8me.
\nScrumBan, une \u00e9quipe peut choisir le meilleur des deux par rapport \u00e0 sa probl\u00e9matique :<\/span>
\nune r\u00e9union de lancement pour un Sprint dans lequel chaque item compte pour 1<\/span><\/div>\n
\nune injection d\u2019\u00e9l\u00e9ments \u00e0 la demande dans la colonne \u00ab A faire \u00bb. Le backlog sur le tableau devient donc une ent\u00e9e permettant de prioriser dans la colonne \u00ab Pr\u00eat \u00bb les \u00e9l\u00e9ments \u00e0 prendre en priorit\u00e9 (cf pt 1)<\/span><\/div>\n
\n<\/u>
\napplication, le rythme de livraison devra \u00eatre d\u00e9termin\u00e9 en fonction des besoins
\net des capacit\u00e9s des \u00e9quipes de d\u00e9ploiement etc\u2026. Si l\u2019on veut, on peut se caler
\nsur la notion de Sprint (it\u00e9ration de dur\u00e9e fixe) pour obliger l\u2019\u00e9quipe \u00e0
\npr\u00e9parer une version \u00ab propre \u00bb.<\/span>
\nDans le contexte des \u00e9quipes de support transverse, il n’y a pas besoin de livrer un produit fini \u00e0 rythme d\u00e9termin\u00e9, puisque l’on a plut\u00f4t une livraison au fil de l’eau \u00e0 d’autres \u00e9quipes.
\nR\u00e9trospectives<\/u>
\nn\u00e9cessaire et primordial si l\u2019on veut tirer un r\u00e9el b\u00e9n\u00e9fice de toutes ces
\nm\u00e9thodes, c\u2019est de faire une r\u00e9trospective au minimum une fois par mois avec
\nl\u2019ensemble des \u00e9quipiers. <\/span>
\nIl est important de rythmer avec une p\u00e9riode fixe ces
\npoints d\u2019am\u00e9lioration continue. A l\u2019image du c\u0153ur qui rythme nos vies, c\u2019est ce
\nrendez-vous qui permet de s\u2019adapter au contexte de l\u2019organisation et lever les
\nobstacles qui encombrent la route.<\/span><\/div>\n\n
\nfonctionn\u00e9, quels probl\u00e8mes on a rencontr\u00e9, comment on les a r\u00e9solus et quels
\nsont les probl\u00e8mes que nous avons encore.<\/span><\/li>\n
\n\u00e9volution du syst\u00e8me sera mise en oeuvre pour la p\u00e9riode
\nsuivante<\/span><\/li>\n
\nManager\/Scrum Master et l\u2019\u00e9quipe se chargeront de r\u00e9soudre pendant la p\u00e9riode
\nsuivante.<\/span><\/li>\n<\/ul>\n<\/div>\n
\nd\u2019ajouter de nouvelles colonnes au tableau afin coller un peu plus aux
\nsp\u00e9cialit\u00e9s des collaborateurs et au processus de
\ntravail.
\n<\/u>\n
\nvu au point 3<\/span><\/li>\n
\nfa\u00e7on Scrum <\/span><\/li>\n<\/ul>\n<\/div>\n\n