{"id":72,"date":"2014-11-05T15:06:00","date_gmt":"2014-11-05T14:06:00","guid":{"rendered":""},"modified":"2023-05-13T23:20:03","modified_gmt":"2023-05-13T21:20:03","slug":"concevoir-un-kanban-utile-utilisable-utilise","status":"publish","type":"post","link":"https:\/\/opatou.com\/index.php\/2014\/11\/05\/concevoir-un-kanban-utile-utilisable-utilise\/","title":{"rendered":"Concevoir un Kanban Utile, Utilisable, Utilis\u00e9"},"content":{"rendered":"
\nConcevoir un tableau kanban n’est pas toujours facile!<\/span><\/div>\n
\n
<\/span><\/div>\n
\nIl s’agit d’abord de comprendre le processus de fabrication et de le rendre visible. <\/span><\/div>\n
\n
<\/span><\/div>\n
\nLes “\u00e9l\u00e9ments du flux” (les “choses \u00e0 fabriquer”) peuvent \u00eatre diff\u00e9rents : la granularit\u00e9 peut varier fil du processus avec des \u00e9clatement d’un \u00e9l\u00e9ment en plusieurs, et diff\u00e9rents types peuvent coexister. <\/span><\/div>\n
\n
<\/span><\/div>\n
\nIl n’y a pas non plus une seule bonne solution, mais plusieurs options qu’il s’agit d’explorer pour que le processus soit juste, pour que l’\u00e9quipe le comprenne, et enfin et surtout pour que l’\u00e9quipe l’utilise et en tire profit. <\/span><\/div>\n
\n
<\/span><\/div>\n
\nC’est bien cette derni\u00e8re \u00e9tape qui est la plus cruciale et sur laquelle nous butons encore sur un de nos syst\u00e8mes Kanban. <\/span><\/div>\n
\n
<\/span><\/div>\n
\nContexte de l’\u00e9quipe: <\/u><\/b><\/span><\/div>\n
\n
<\/span><\/div>\n
\nNotre \u00e9quipe de “Support Technique” aux \u00e9quipes de d\u00e9veloppement est distribu\u00e9e sur 4 sites. Deux personnes se trouvent seules chacune sur un site diff\u00e9rent (Montreuil et Arras), quatre autres sont \u00e0 Nantes, deux ressources sont en centre de service \u00e0 Bordeaux et les reste de l’\u00e9quipe est \u00e9galement \u00e0 Bordeaux, dans les locaux de la DSI. En tout nous sommes une \u00e9quipe de 18 personnes. <\/span><\/div>\n
\n
<\/span><\/div>\n
\nUne autre caract\u00e9ristique est que les \u00e9quipes a qui nous apportons notre support ne sont pas homog\u00e8nes dans leurs activit\u00e9s, leurs processus. Certaines \u00e9quipes travaillent essentiellement avec des progiciels qui n\u00e9cessitent parfois des d\u00e9veloppements sp\u00e9cifiques, d’autres d\u00e9veloppent des application en mode cycle en V tandis que le plus gros client est plut\u00f4t agile avec une organisation comprenant des Chefs de Projet, des Product Owner et plusieurs \u00e9quipes Scrum.<\/span><\/div>\n
\n
<\/span><\/div>\n
\nDans ce cadre il est difficile d’avoir une animation d’\u00e9quipe homog\u00e8ne, avec des \u00e9changes r\u00e9guliers et fluides. Notre difficult\u00e9 principale est le manque de communication entre tous les membres de l’\u00e9quipe, surtout lorsque des activit\u00e9s passent par des acteurs situ\u00e9s sur les diff\u00e9rents sites.<\/span><\/div>\n
\n
<\/span><\/div>\n
\nD\u00e9marche de changement :<\/u><\/b><\/span><\/div>\n
\n
<\/span><\/div>\n
\nDans notre d\u00e9marche agile, nous avons (cf. posts pr\u00e9c\u00e9dents) mis en place plusieurs tableaux Kanban pour r\u00e9pondre initialement \u00e0 deux types de demandes diff\u00e9rents :<\/span><\/div>\n
\n<\/div>\n