La 4ème colonne

Voire la 5ème colonne, si on compte la colonne Story.

Dans le tableau des tâches qui représente le plan du sprint en cours, on trouve, avec la disposition la plus classique :

  • la colonne de gauche dans laquelle sont placées les stories du sprint,
  • 3 colonnes pour visualiser l'état des tâches : à faire, en cours ou fini.

Les 3 colonnes pour les tâches

Certaines équipes utilisent une 4ème colonne, placée entre la colonne en cours et celle fini. Ils la nomment généralement "à tester".

Cette 4ème colonne était bien présente sur le grand tableau mural que j'ai vu hier chez MaxSea à Bidart.

Il n'y a que les 3 colonnes habituelles dans iceScrum, mais des utilisateurs réclament de temps en temps une 4ème colonne, comme aujourd'hui sur le forum communautaire.

On la voit sur des photos de tableaux Scrum publiées en ligne. Je me souviens que c'est après avoir vu une photo sur le site de Mike Cohn il y a 5 ans que j'avais essayé cette colonne supplémentaire.

J'ai abandonné bien vite et maintenant je déconseille cette pratique, pour les raisons suivantes :

  • la confusion entre story et tâche. Je constate que pour quelques équipes ces 2 notions sont mal maîtrisées, alors cette colonne "à tester" qui concerne la story coincée entre 2 colonnes qui portent sur des tâches ne contribue pas à clarifier les choses.
  • c'est bien la story qu'on teste, ce ne sont pas les tâches. Tester, ou vérifier les tâches je ne vois pas l'intérêt. Ce qui compte c'est de finir la story.
  • une colonne en plus, c'est plus compliqué à comprendre (et à gérer aussi). On pourrait me rétorquer que les tableaux kanban possèdent en général plus de colonnes, mais d'une part on n'utilise pas Kanban que pour un processus agile et d'autre part, la 5ème pratique fondamentale de Kanban pousse à réduire le nombre de colonnes.
  • le côté visuel de la colonne supplémentaire est destiné à faire apparaître au Product Owner ou aux testeurs qu'une story est prête à être testée. Finalement pour donner de l'importance au test d'une story je trouve plus efficace de définir les activités de test comme des tâches explicites, avec éventuellement des couleurs pour les reconnaître.

Donc ajouter une 4ème colonne reste dans ma liste "en faire moins".

Commentaires

1. Le mercredi 13 juillet 2011, 00:05 par Remy

C'est délicat lorsqu'on a des qualifieurs fonctionnels et qu'on veut permettre aux devs d'indiquer qu'ils ont fini leur partie.
Mais du coté du principe, je suis assez d'accord d'afficher le test comme une tache.
D'autant que si on a bien le "how to demo" à l'entrée du sprint, l'automatisation du test pourrait être faite en parallèle des devs (pas toujours, mais ça peut arriver quand même).
A mon avis c'est très lié à la maturité de l'équipe vis à vis de l'agilité.

2. Le mercredi 13 juillet 2011, 00:16 par David

Tout a fait en phase , merci pour cette analyse Claude !

3. Le mercredi 13 juillet 2011, 08:57 par Laurent Carbonnaux

En phase aussi, Claude.
J'utilise une colonne de plus pour les tâches "bloquées", souvent en bas à droite de la colonne "fini". ça les rend plus visibles lors du scrum meeting.

4. Le mercredi 13 juillet 2011, 10:01 par Thomas Clavier

+1 ... je pousse exactement la même chose chez mes clients, 1 ou des taches de test et pas une colonne de plus. Ça pousse aussi l'équipe à être plus soudé, pas une équipe qui test après l'équipe de dev. Idem pour la colonne "Déploiement en prod" il est préférable de regrouper les gens dans une équipe qui communique :-) Et puis l'avantage c'est d'avoir une équipe qui monte en compétences.

Chez nous, Fini == testé et en prod ! et chacun est capable de tout faire ... plus ou moins vite, plus ou moins bien.

5. Le mercredi 13 juillet 2011, 10:14 par Nicolas

Moi je trouve de l'intérêt à la colonne "à tester" (ou plutôt "à valider") pour le PO, quand il n'est pas tout le temps sur site.
Ça lui permet de voir le boulot qu'il a à faire en arrivant, sans devoir demander à l'ensemble de l'équipe.

6. Le dimanche 24 juillet 2011, 12:24 par Couthaïer FARFRA

Je ne partage pas cet avis de supprimer la colonne "A tester" dans le tableau de suivi. Sur les projets ou je suis intervenu comme ScrumMaster, cette 4ième colonne nous a permis de toujours distinguer les story "fini" au sens de la définition de "Done" et celles dont toutes les tâches sont terminées (avec leurs TDD) et restant soumises au passage des ATDD. Je suis d'accord sur le fait que ce ne sont pas les tâches que l'on test dans cette colonne, mais bien la story et c'est ce qui doit être défini dès la réunion de planification du sprint. J'interviens actuellement sur un projet ou nous n'avons pas automatiser les ATDD. Cette colonne "A tester" me permet de savoir sur quelle Story je peut lancer les ATDD manuels, lorsque toutes les tâches sont terminées et apporte une indication au PO sur celles dont les tests sont validés pour la revue de sprint.