« Appliquer Kanban aux processus informatiques (2) » : différence entre les versions

Auteur : Eli Weinstock-Herman<br/>

Date : 08/12/2009<br/>

----

Traduction :<br/>

<br/>

<br/>

Dans cette deuxième partie de cette série "Appliquer Kanban aux processus informatiques", nous explorons un helpdesk et la manière dont Kanban peut aider à améliorer son image, ses métriques, son moral, sa réactivité et ses délais d’exécution. Les exemples de tableaux et de processus donnés dans cet article ne sont pas destinés à être pris tel quel dans vos processus d’entreprise, mais plutôt pour créer un système basé sur Kanban et l’appliquer dans un cadre fictif. Kanban est une philosophie et non pas un ensemble figé de processus, donc s’il vous plaît rappelez-vous que ce n’est qu’un exemple de la façon dont il pourrait être appliqué dans les cas fictifs décrits.<br/>

Dans l’esprit de garder les choses simples, nous avons bâti ensemble notre premier tableau Kanban en utilisant un tableau blanc, un peu de ruban et quelques post-its.<br/>

<br/>

<br/>

Premier tableau visuel de l’entreprise ABC complété avec les post-its des tâches actuelles<br/>

Après avoir parlé à l’équipe et examiné les post-its sur notre tableau actuel, l’équipe a décidé de modifier le tableau en ajoutant un endroit pour les « Tâches escaladées ». Cette modification a été une idée de l’un des membres de l’équipe pour nous aider à mieux suivre les tâches qui ont été escaladées aux Administrateurs systèmes et au Développement afin qu’ils ne prennent pas de place dans la colonne "Travail en cours", nous ne voulions pas les perdre en les sortant complètement du tableau. Pour l’équipe de l’entreprise ABC, cette demande avait du sens, nous l’avons donc ajouter au tableau.<br/>

<br/>

<br/>

"Tableau visuel de l’entreprise ABC avec une nouvelle étape d’escalade des tâches"<br/>

Nous allons également attribuer à chaque membre une colonne « principale » où ils ont l’habitude de travailler. Puisque les limites de Kanban imposent un nombre maximal de tâches autorisées dans chaque étape du processus, il y aura des moments où des pans entiers du tableau seront bloqués. Par exemple, si la personne responsable de la colonne "En attente retour client" est surchargée ou en congé maladie, l’ensemble du département sera bloqué parce que la colonne « En attente retour client » est pleine. Lorsque cela arrive, les gens quitteront leur colonne "principale" pour aider à éliminer les goulots d’étranglement.<br/>

<br/>

<br/>

Tableau visuel de l’entreprise ABC avec des limites définies<br/>

Le dernier changement sur notre processus concernera la manière de répartir les tâches et la manière dont elles se déplacent à travers le tableau. Jusqu’à présent, nous n’avons pas contraint la manière ou le moment auquel les gens choisiront de travailler sur certaines tâches plutôt que d’autres, ou comment prioriser les nouvelles tâches. Un des concepts importants de Kanban est de tirer les tâches à travers le processus au lieu de les pousser. A chaque étape, les membres de l’équipe choisissent une tâche de l’étape précédente pour travailler dessus et ceci dans les limites imposées par la colonne concernée. Pour permettre d’identifier les tâches qui sont prêtes à être sélectionnées, nous avons ajouté une sous-colonne ombrée à chaque colonne. Pour la colonne "Travail en attente", la sous-colonne ombrée contient les prochaines tâches prioritaires, et pour les autres colonnes il s’agit plutôt d’une sous-colonne "Terminé".<br/>

<br/>

<br/>

'''Analyse finale'''<br/>

Initialement, les personnes travaillaient sur plusieurs tâches à la fois, diluant leur concentration et perdant à chaque fois du temps quand ils passaient d’une tâche à l’autre. En l’absence de priorisation, il n’y avait aucune garantie sur l’instant où une tâche serait sélectionnée par un membre de l’équipe, les tâches pouvaient même être égarées ou complètement oubliées. La communication à l’utilisateur final était incohérente et les tâches escaladées étaient rarement communiquées ou suivies, les solutions complexes mises en œuvre n’étaient généralement pas expliquées et généraient des tâches supplémentaires à traiter.<br/>

<br/>

<br/>

Progression dans le temps du tableau visuel de l’entreprise ABC<br/>

Les avantages décrits ci-dessus sont directement liés à l’application de Kanban dans un environnement général. Dans le cas de l’entreprise ABC, nous pourrions probablement ajouter d’autres gains plus spécifiques à leur environnement, si ce n’était pas une société fictive. Peut-être le plus gros gain est-il que le département fonctionne maintenant à partir d’un tableau blanc. Quelqu’un a récemment déclaré que les tableaux blancs, de par leur nature, invitaient les gens à écrire dessus ou à modifier leur contenu, tandis qu’un papier imprimé invite plutôt à la lecture seule. En quoi est-ce pertinent ? Aucun processus n’est parfait et un processus figé dans la marbre est un processus qui ne se développe pas pour répondre au mieux aux besoins de leur entreprise. En engageant les membres de l’équipe, en expérimentant et en définissant le processus sur un support modifiable, on encourage l’équipe à continuer de faire des suggestions et à continuer à essayer d’améliorer le processus et le département.<br/>

<br/>

<br/>

'''A propos de l’auteur'''<br/>

<br/>

Eli Weinstock-Herman : Eli a plus d’une dizaine d’années d’expérience dans les architectures logicielle et système, le développement web, la programmation sur bases de données, l’administration de bases de données, l’architecture et l’intégration de systèmes industriels, l’administration de systèmes, … dans plusieurs secteurs industriels, en passant par l’éducation et l’industrie pour aller jusqu’au consulting et le développement SaaS. Ses billets reflètent cette diversité, en visitant une variété de sujets, notamment l’amélioration des processus, le codage, la qualité, l’administration de systèmes, les pratiques de développement et l’architecture logicielle.