Les tâches en couleurs

Il n'est pas question de lessive (on est mardi), mais de management visuel.

Un utilisateur d'IceScrum a déposé une demande d'évolution dans le bac à sable en ligne. Il nous dit :

Dans un environnement de production, vous avez souvent différents groupes de personnes qui sont responsables d'accomplir des tâches spécifiques. Par exemple, vous pourriez avoir des artistes, des designers, des programmeurs sur différents domaines, des testeurs..., tous ayant des compétences différentes. Il nous serait utile de les suivre séparément en termes de tâches et de ressources.

Voilà ce qu'il propose :

  • Pour rester dans le management visuel, une discipline aurait un code couleur.
  • On pourrait alors associer une tâche individuelle à une discipline spécifique, ce qui la colorierait automatiquement et permettrait de voir facilement quelles tâches sont relatives à une discipline.

Il fournit même la story correspondante :

En tant que Scrum Master, je peux assigner les tâches à une discipline afin de mieux organiser l'ensemble des compétences de l'équipe en relation avec la gestion des tâches.

Notre utilisateur va encore plus loin en suggérant de définir les ressources disponibles par discipline pour un sprint et de produire des burndowns par discipline aussi.

Bien sûr, on pourrait lui faire remarquer que cela va à l'encontre d'une équipe pluridisciplinaire et que cela peut pousser à renforcer les spécialités alors que l'agilité promeut les généralistes dans une équipe. Mais on peut aussi penser que cela peut aider à éviter les goulets d'étranglement, cibles de la théorie des contraintes.

J'avais déjà posté un billet sur le type de tâches dans lequel les couleurs étaient utilisées pour reconnaitre les tâches de test. J'ai revu la carte heuristique en mettant en évidence cette notion de discipline, que j'ai préféré appeler activité :

Types de tâches

Dans un tableau des tâches, l'état est (généralement) montré par la position dans les colonnes et l'association à une story (ou pas) se voit avec la place de la tâche dans les lignes.

Les couleurs peuvent permettre l'identification rapide des 2 autres caractéristiques d'une tâche. Certains les utilisent pour savoir quel membre de l'équipe a pris quelle tâche. L'utilisation pour des activités, comme c'est suggéré par le soumissionnaire de cette demande d'évolution, est possible dès la réunion de planification du sprint. Plus pérenne, elle me semble plus pertinente, notamment pour les équipes avec des compétences bien différenciées avant la transition à l'agilité, comme dans les jeux vidéo.

Commentaires

1. Le mardi 18 janvier 2011, 21:59 par Oaz

On peut surement trouver de nombreuses utilités aux taches en couleurs. Chez nous, où les taches sont matérialisées par des post-it colorés, chaque couleur correspond à une zone du logiciel (la logique métier, l'interface utilisateur, l'accès aux données, le packaging, ...) Lors du découpage en taches, ça donne un support pour discuter des diverses parties de l'application impactées par un besoin.

Packaging, c'est une zone ? Enfin l'essentiel, c'est que chaque équipe définisse l'usage qui lui va bien.

Mais pour en revenir aux taches par discipline, c'est surtout la formulation de la story que je trouve un peu limite : "En tant que Scrum Master, je peux assigner les tâches"...

Ah oui, mais il y a bien pire dans la formulation des demandes par les utilisateurs. Là il ne s'agit que d'assigner (associer) les tâches à des activités. Bien sûr si on l'ajoute dans IceScrum, ce ne sera pas réservé au ScrumMaster. Aujourd'hui (et ce n'est pas la première fois) il y a eu une demande pour que le ScrumMaster puisse assigner les tâches aux membres de l'équipe. En tant que PO d'IceScrum, j'ai toujours refusé.
2. Le samedi 26 février 2011, 18:10 par Timothée

L'utilisation de fiches pour les tâches nous a amenés à pré-imprimer des zones d'informations (décrites ci-dessous) que nous avions pris l'habitude de noter en plus de la description de la tâche :
- sprint (numéro du sprint)
- user story (référence du scénario, pratique quand la tâche s'est décrochée du tableau)
- type de tâche (Modèle, controleur, vue, test, R7, conception, jeux de données ...)
- Tracking (permet de saisir le numéro de commit Subversion)
- zone libre pour y mettre une date, ou tout autre info utile à l'équipe

Les fiches sont imprimées sur du papier de 4 couleurs différentes :
- blanc : il s'agit des tâches classiques, identifiées lors de la planification
- vert : il s'agit des spikes ou tâches nécessitant de la R&D. L'idée est de souligner que l'équipe ne maîtrise pas ce sujet
- jaune : il s'agit de faire apparaître sur le tableau les tâches que nous n'avions pas identifiées à la planification. A la mêlée, il est courant de se rendre compte que l'on a travaillé sur une tâche qui ne figure pas au tableau !
- orange (ou rouge) = bug

En fin de Sprint, on compte les tâches de chaque couleur.
On a donc un compteur de tâches en plus des autres indicateurs : vélocité, work capacity, effort de concentration, etc. C'est très enrichissant pour la rétrospective, notamment quand il y a explosion des tâches non-plannifiées.