Qu'est-ce que le Kanban et en
quoi est-il utile ?

1. Les tra­vailleurs de l’ ​”aval” retirent exacte­ment autant de pièces de l’in­ven­taire que spé­ci­fié sur le kanban
2. Les tra­vailleurs de l’ ​”amont” four­nissent égale­ment des pièces stricte­ment selon les cartes
3. Rien n’est pro­duit ou déplacé sans un kanban
4. Le kan­ban doit tou­jours être attaché aux pièces
5. Les pièces défectueuses né sont pas util­isées dans le système
6. Réduire le nom­bre de cartes kan­ban rend la ges­tion plus sen­si­ble aux change­ments. Mais sans néces­sité extrême, il n’est pas con­seil­lé de chang­er le nom­bre établi de cartes.

1. Flex­i­bil­ité dans la plan­i­fi­ca­tion. L’équipe se con­cen­tre unique­ment sur le tra­vail actuel, la pri­or­ité des tâch­es étant fixée par le manager.
2. Forte impli­ca­tion de l’équipe dans le proces­sus de développe­ment. Grâce à des réu­nions régulières, à la trans­parence des proces­sus et aux oppor­tu­nités d’au­to-organ­i­sa­tion, les employés se rassem­blent et mon­trent un intérêt réel.
3. Durée de cycle plus courte. Si les com­pé­tences néces­saires sont pos­sédées par plusieurs per­son­nes, la durée dimin­ue ; si une seule per­son­ne les pos­sède, un goulet d’é­tran­gle­ment appa­raît. D’où la néces­sité pour les employés de partager leurs con­nais­sances, opti­misant ain­si la durée du cycle. Cela per­met à l’ensem­ble de l’équipe de tra­vailler sur des tâch­es blo­quées et de rétablir un flux fluide.
4. Moins de goulets d’é­tran­gle­ment. Les lim­ites de WIP per­me­t­tent d’i­den­ti­fi­er rapi­de­ment les goulets d’é­tran­gle­ment et les zones prob­lé­ma­tiques résul­tant d’un man­qué de con­cen­tra­tion, de main-d’œu­vre ou de compétences.
5. Vis­i­bil­ité. Lorsque tous les exé­cu­teurs ont accès aux don­nées, il devient plus facile de repér­er les goulets d’é­tran­gle­ment. Les équipes Kan­ban, en plus des cartes elles-mêmes, utilisent générale­ment deux rap­ports courants : des graphiques de con­trôle et un flux cumulatif.

• groupes de sup­port logi­ciel ou help desks.
• Kan­ban fonc­tionne bien dans la ges­tion de star­tups sans plan clair mais où un développe­ment act­if est en cours.

1. le sys­tème fonc­tionne mal avec des équipes de plus de 5 personnes
2. il n’est pas des­tiné à une plan­i­fi­ca­tion à long terme.

Exem­ples d’ap­pli­ca­tion dans l’IT

Dès Microsoft : Le Début de Kan­ban dans le Développe­ment Logiciel

L’u­til­i­sa­tion des principes Kan­ban dans les tech­nolo­gies de l’in­for­ma­tion a com­mencé il y a un peu plus de 10 ans. David Ander­son, l’un des prin­ci­paux pro­mo­teurs de Kan­ban pour les développeurs de logi­ciels, a con­sulté Microsoft en 2005. Ils étaient insat­is­faits des per­for­mances de leur départe­ment — XIT Sus­tained Engi­neer­ing, qui cor­rigeait des bogues dans des appli­ca­tions internes. Au début de l’an­née de rap­port, ce départe­ment était le pire de sa divi­sion. Le back­log dépas­sait cinq fois la taille accept­able, et le temps de traite­ment d’une demande était générale­ment de cinq mois.

Le nou­veau PM, avec les con­sul­ta­tions d’An­der­son, a aug­men­té la pro­duc­tiv­ité du départe­ment en dif­fi­culté de 155 % en neuf mois. Le temps de traite­ment est désor­mais de cinq semaines, le back­log est revenu à une taille nor­male, et l’achève­ment des tâch­es à temps s’est sta­bil­isé à 90 %. Tous ces résul­tats ont été obtenus avec une inté­gra­tion min­i­male de nou­veaux employés ; le per­son­nel con­tin­u­ait à cor­riger les bogues de la même manière — seules les approches d’or­gan­i­sa­tion du tra­vail ont changé.

Dumitriu a ren­con­tré un départe­ment com­posé de trois développeurs et de trois tes­teurs, qui avait 80 deman­des entassées dans le back­log. Le PM lui-même a été tem­po­raire­ment nom­mé puisque les exi­gences du poste inclu­aient une exper­tise en tech­nolo­gie ASP, admin­is­tra­tion de SQL Serv­er et con­nais­sance de MS Project Serv­er. La direc­tion envis­ageait un ​“techie” qui pour­rait coder, pré­par­er des rap­ports et prévoir la charge du back­log dans ce poste. Comme on le croy­ait alors, le prob­lème du départe­ment serait révélé si une grande quan­tité de don­nées était rassem­blée. Dumitriu n’é­tait pas un tel ​“techie”.

Cepen­dant, en com­mençant à analyser les opéra­tions de XIT aux côtés d’An­der­son, il a rapi­de­ment iden­ti­fié des fac­teurs clés affec­tant néga­tive­ment la vitesse du département :

• Prévoir les impli­ca­tions (ROM) de la réal­i­sa­tion d’une demande pre­nait beau­coup de temps. Tant le développeur que le tes­teur devaient pass­er une journée de tra­vail com­plète à réalis­er les cal­culs néces­saires, véri­fi­er le code et com­pléter la doc­u­men­ta­tion. En moyenne, une demande arrivait chaque jour. Selon les cal­culs du PM, 40 % de la pro­duc­tiv­ité du départe­ment étaient con­sacrés au ROM ;
• La pri­or­ité était accordée aux deman­des de plus grande valeur. XIT était financé en fonc­tion de la valeur des com­man­des. La pri­or­i­sa­tion des deman­des était dis­cutée men­su­elle­ment lors des réu­nions des chefs de départe­ment avec les clients — des man­agers d’autres départe­ments. Avec un back­log qui s’élar­gis­sait à la vitesse actuelle, où seules 6 – 7 deman­des étaient traitées par mois, les pri­or­ités d’autres deman­des changeaient con­stam­ment en rai­son du temps qui pas­sait. Beau­coup d’en­tre elles étaient reportées à un ​“plus tard” sig­ni­fi­catif, pas même égal au mois suivant.
• Au stade ROM, la moitié des deman­des étaient fil­trées. Cer­taines étaient trop grandes et étaient requal­i­fiées en pro­jets à trans­fér­er à d’autres départe­ments, d’autres étaient trop coû­teuses et sim­ple­ment annulées. Cer­taines deman­des n’é­taient pas pris­es en développe­ment car leur mise en œuvre prendrait trop de temps. Ain­si, 40 % de la pro­duc­tiv­ité du départe­ment étaient dépen­sés à analyser des deman­des, dont 50 % étaient rejetées. Env­i­ron 15 – 20 % des ressources de tra­vail étaient gaspillées.
• Le tra­vail pré­para­toire sur les deman­des pou­vait dur­er des mois avant que l’im­plé­men­ta­tion né com­mence. Les cal­culs au stade ROM pou­vaient être per­dus ou oubliés durant ce temps. Surtout si l’im­plé­men­ta­tion était gérée par un développeur dif­férent de celui qui avait com­mencé l’analyse.

Solu­tions Kan­ban pour le départe­ment en dif­fi­culté de Microsoft

À la fin de 2005, la pro­duc­tiv­ité du départe­ment a aug­men­té de 155 %. Pour amélior­er davan­tage le tra­vail de XIT, deux employés ont été inté­grés : un développeur et un tes­teur. Le nom­bre de deman­des dans le back­log a dimin­ué à 10, et un développeur a sys­té­ma­tique­ment traité 11 deman­des par trimestre. En moyenne, 56 deman­des étaient com­plétées par trimestre con­tre 11 précédem­ment. Le coût des deman­des est tombé de 7500 $ à 2900 $.

Appli­ca­tion chez Corbis

Après avoir obtenu du suc­cès chez Microsoft, Ander­son en 2006 a com­mencé à s’at­ta­quer à une nou­velle tâche com­plexe. Main­tenant, il tra­vail­lait chez Cor­bis — une autre entre­prise de Bill Gates, qui n’avait pas encore quit­té MS. L’une des activ­ités de Cor­bis était la licence de pho­tos. À cette époque, c’é­tait la deux­ième plus grande bib­lio­thèque de pho­tos de stock au monde avec une base de don­nées d’en­v­i­ron 3500 images.

La tâche d’An­der­son était d’ac­célér­er les prin­ci­pales pub­li­ca­tions de l’en­tre­prise. L’in­ter­valle entre leurs pub­li­ca­tions était de trois mois et pou­vait même s’al­longer. Rien qu’à dis­cuter du plan de pub­li­ca­tion, la direc­tion pre­nait deux semaines. Il fal­lait établir la pub­li­ca­tion de pub­li­ca­tions sec­ondaires ou de mis­es à jour toutes les deux semaines. En même temps, des ressources clés devaient être dirigées vers le pro­jet principal.

Un tableau Kan­ban est apparu dans le bureau de Cor­bis, où Ander­son dis­cu­tait quo­ti­di­en­nement avec l’équipe. L’ob­jec­tif du PM était d’amélior­er le con­trôle visuel sur les proces­sus, d’en­cour­ager l’au­to-organ­i­sa­tion et une plus grande respon­s­abil­ité per­son­nelle par­mi les exé­cu­tants. Le sys­tème Kan­ban visait égale­ment à réduire la sur­veil­lance du man­ag­er et à aug­menter la productivité.

En plus des cartes col­orées et des graphiques, une ​“poubelle” est apparue sur le tableau — dans laque­lle des tâch­es trop grandes étaient envoyées.

Pho­to de la présen­ta­tion officielle

Un sys­tème Kan­ban pour l’ingénierie de main­tien des sys­tèmes logi­ciels par David J Anderson

Le sys­tème Kan­ban a clar­i­fié quand le flux cesse d’être flu­ide et où survi­en­nent des retards, le soi-dis­ant goulet d’é­tran­gle­ment. Des dis­cus­sions rapi­des avec l’équipe ont aidé à iden­ti­fi­er les prob­lèmes actuels. Par exem­ple, les tests pre­naient 3 jours, ce qui impactait néga­tive­ment le cal­en­dri­er de pub­li­ca­tion. Trois employés se sont réu­nis et ont trou­vé un moyen de réduire le temps à un jour.

Un goulet d’é­tran­gle­ment est une sec­tion du sché­ma ou de l’al­go­rithme des opéra­tions de l’en­tre­prise, où des lim­i­ta­tions de pro­duc­tiv­ité des ressources ou humaines réduisent abrupte­ment le débit du flux de tâch­es. Un man­qué de main-d’œu­vre, une mau­vaise con­nex­ion Inter­net ou un directeur en vacances blo­quent ou ralen­tis­sent l’exé­cu­tion des tâches.

Les lim­ites pour les cartes Kan­ban ont été définies de manière empirique deux fois. Dans la colonne ​“prête pour le développe­ment”, les lim­ites ont été aug­men­tées. Une nou­velle colonne — ​“prête pour les tests” — est égale­ment apparue. De nom­breuses deman­des pour l’a­mont étaient mal for­mulées, entraî­nant des dépens­es de temps inutiles. Par con­séquent, le PM a exam­iné les opéra­tions du flux supérieur et a trou­vé des erreurs.

La procé­dure d’ex­a­m­en des deman­des pou­vait pren­dre 100 jours, mais les pub­li­ca­tions com­mençaient tou­jours à sor­tir toutes les deux semaines comme prévu. Les déci­sions con­cer­nant le con­tenu des pub­li­ca­tions étaient pris­es 5 jours avant la pub­li­ca­tion. La pra­tique du décompte, comme dans le cas du départe­ment XIT chez Microsoft, a été aban­don­née au prof­it de la pro­duc­tiv­ité. Les pri­or­ités des tâch­es étaient fixées en fonc­tion des ​“coûts des retards” ou de la disponi­bil­ité des ressources.

Le sys­tème Kan­ban a non seule­ment aidé Ander­son à attein­dre l’ob­jec­tif fixé, mais a égale­ment amélioré le moral au sein de l’équipe. Grâce aux dis­cus­sions col­lec­tives et à la vis­i­bil­ité des proces­sus, les employés ont établi une con­fi­ance mutuelle. Le per­son­nel a égale­ment adop­té le Kaizen, c’est-à-dire la pra­tique de l’amélio­ra­tion continue.

Pro­grammes et appli­ca­tions pour KANBAN

Trel­lo

Sys­tème de Kan­ban pop­u­laire pour la ges­tion des tâch­es. Il est recon­nu pour son attrait visuel et son inter­face con­viviale. Les util­isa­teurs soulig­nent sa super flexibilité.

Kan­ban­tool

Tableau gra­tu­it pour deux util­isa­teurs. Sup­port API et inter­faces tactiles.

Lean Kit Kanban

Tableau gra­tu­it pour cinq util­isa­teurs avec de bonnes car­ac­téris­tiques de col­lab­o­ra­tion. Sup­port API et fonc­tion­nal­ités d’import/​export, sta­tis­tiques étendues.

Kan­ban­ize

Ser­vice com­plète­ment gra­tu­it avec une fonc­tion­nal­ité décente. Ses pro­prié­taires garan­tis­sent une aug­men­ta­tion de 300 % de la pro­duc­tiv­ité lors de l’u­til­i­sa­tion de leur produit.

Work­sec­tion

SaaS ukrainien —  appli­ca­tion pour le suivi et la ges­tion rapi­de des pro­jets. Actuelle­ment, en plus de la compt­abil­ité des finances et des délais, il y a un dia­gramme de Gantt. Dans les mois à venir, les développeurs ajouteront un tableau Kan­ban avec des options de per­son­nal­i­sa­tion, ren­dant le ser­vice encore plus adap­té au Kanban.

---

Verdict

Kan­ban est une pra­tique qui aide à attein­dre le suc­cès, tan­dis que l’u­til­i­sa­tion unique­ment de méth­odes agiles n’est pas oblig­a­toire. Des change­ments sig­ni­fi­cat­ifs sont obtenus en élim­i­nant le temps per­du, en gérant les goulets d’é­tran­gle­ment et en réduisant la variabilité.

Cepen­dant, les change­ments réus­sis néces­si­tent du temps. Ils se pro­duisent pro­gres­sive­ment, tan­dis que la résis­tance de l’équipe aux inno­va­tions est min­i­male. Le sys­tème Kan­ban motive le per­son­nel à s’amélior­er sans change­ments dans les méth­odes d’ingénierie.

Les livres pour l’ar­ti­cle sont four­nis par kni​ga​.biz​.ua