« Scrum-ban » : différence entre les versions

Traducteur : Fabrice Aimetti<br />  Date : 01/07/2011<br />

Traduction :<br /> <br /> Comme de plus en plus de gens s'intéressent aux idées Lean et à leur application dans la gestion des connaissances et des projets, il est utile de trouver des moyens pour que ce soit plus facile de démarrer ou d'apprendre quelques notions de base qui peuvent mener à une compréhension plus profonde un peu plus tard. Pour ceux qui sont curieux au sujet de Kanban dans un contexte bureau, il n'est pas rare de trouver des gens qui sont soit actuellement en train d'utiliser Scrum, ou qui ont une certaine perception de Scrum en tant que représentant de la pensée Agile. D'une façon ou d'une autre, les utilisateurs de Scrum composent une part importante de l'audience Kanban. Puisque Scrum peut être décrit comme une instance dans la langue que nous utilisons pour décrire les systèmes Kanban, il est également assez facile d'élaborer et de décrire des hybrides Scrum / Kanban. Cela peut être utile pour les équipes Scrum existantes qui cherchent à changer de taille ou améliorer leur capacité. Cela peut également être utile pour des nouveaux utilisateurs plus prudents qui trouvent un réconfort dans une méthode "établie".<br /> <br /> [[Image:ladas-scrumban-001.jpg|ladas-scrumban-001.jpg]]<br />  L'idée d'utiliser un simple tableau de tâches avec des cartes ou des post-its est aussi vieille que l'Agilité elle-même. Une présentation simple est un workflow ''A faire -> En cours -> Fini''. Les cartes représentent des items de travail à traiter dans le périmètre actuel. Des noms peuvent être associés aux cartes pour indiquer qui travaille sur quoi. Les équipes agiles ont eu recours à ce genre de méthode depuis longtemps, et quelques personnes ont remarqué dès le départ que cela avait une certaine ressemblance avec la notion de kanban dans les systèmes lean.<br /> <br />  Bien sûr, divers outils électroniques existent qui remplissent ces fonctions, mais le simple tableau de tâches représente quelques principes Lean que je trouve à forte valeur ajoutée, simple technologiquement' parlant et d'un point de vue contrôle visuel. L'utilité d'une telle méthode simple de gestion de workflow, c'est qu'elle est facile à gérer, et plus important encore, elle est facile à changer. Se blottir autour d'un écran d'ordinateur, même très grand, ne peut en aucune façon remplacer l'interactivité tactile et sociale qui accompagne la manipulation d'un grand tableau de tâches. Peut-être qu'un jour ce sera le cas. Mais pas aujourd'hui. Les outils électroniques sont bons pour gérer des listes de choses, comme les backlogs et les bugs, et produire des rapports. Des outils simples peuvent constituer un concept difficile à expliquer aux fanatiques de technologie, mais c'est ensuite que l'on comprend leur valeur.<br /> <br /> [[Image:ladas-scrumban-002.jpg|ladas-scrumban-002.jpg]]<br />  Un problème avec le tableau de tâches et ses post-its, c'est qu'il n'y a rien pour vous empêcher d'accumuler une grosse pile de travail en cours. Le timeboxing, de par sa nature, établit une limite de TAF sur ce qui peut être traité, mais il peut encore aller plus loin que souhaitable.<br /> <br />  Si un kanban est un objet qui représente une demande de travail, et que notre tableau de tâches échappe à tout contrôle, quel est le véritable problème ? Le problème c'est que le kanban représente davantage qu'une simple demande de travail sur une carte, et mettre des post-its sur un tableau blanc n'est pas suffisant pour mettre en œuvre un système à flux tiré.<br /> <br /> <br /> <br /> <br />