haber

Ucuz Uçak Biletleri

Écrit par Vincent MARTIN

Elément central de la communication de l’équipe Scrum, le scrum board, ou tableau des tâches, est le lieu où viennent atterrir les post-it attribués aux tâches du sprint en cours. Simplissime par son fonctionnement, emblématique de Scrum et des méthodes Agiles, c’est aussi un puissant outil de visualisation de l’avancement du sprint, tout autant qu’un prétexte sympa à la communication entre membres de l’équipe projet.

Introduction : le tableau « de base »

A la base, le tableau des tâches est constitué de trois colonnes : « à faire », « en cours » et « terminé » ; chaque tâche à réaliser pendant le sprint (ou itération d’un projet Scrum) est matérialisée par un post-it, d’abord dans la colonne « à faire », puis, au fur et à mesure de son traitement, dans les colonnes suivantes.

source : http://leansoftwareengineering.com/ksse/scrum-ban/

Les colonnes du tableau matérialisent le cycle de vie des tâches du projet ; l’utilisation des post-it et leur positionnement sur le tableau permettent de communiquer rapidement et visuellement sur l’avancement de chaque tâche (sans avoir à consulter un compte-rendu de réunion, un outil de suivi de projet ou autre).

Le tableau des tâches est un élément à part entière du « radiateur d’informations » des projets Agiles, irremplaçable pour fournir un partage instantané des informations importantes sur le projet.

C’est aussi devant le tableau qu’ont lieu les mêlées quotidiennes. Chaque équipier peut ainsi mettre à jour le tableau en fonction des tâches qu’il traite ou qu’il a terminées.

Les règles de fonctionnement du tableau scrum :

ne peuvent être placées dans la colonne « terminé » que les tâches effectivement et réellement terminées, c'est-à-dire celles qui remplissent les conditions fixées par la notion de « terminé » du projet ;

si, par exemple, la notion de « terminé » spécifie : le code (avec des critères qualitatifs : passage par un outil de revue de code, taux de commentaires, etc.), la documentation et les tests (passage des scénarii d’acceptation), toute tâche ne respectant pas ces critères ne pourra pas être considérée comme « terminée » et ne pourra donc pas être placée dans la colonne éponyme dans le tableau ;

les tâches qui ne sont pas dans la colonne « terminé » à la fin du sprint sont replacées dans la liste de ce qu’il reste à faire (backlog du projet) ; le plus souvent, elles seront traitées dans le sprint qui suit, surtout si elles ont été commencées ;
on indique en général sur le post-it l’effort de réalisation estimé en début de sprint pour la tâche ; à la fin du sprint, il suffit d’additionner les efforts des tâches qui sont dans la colonne « terminé » pour avoir la vélocité du sprint ;
on peut utiliser des post-it de couleurs différentes en fonction de la nature de la tâche ou de celui qui a la responsabilité de son traitement ; le tableau permet ainsi de visualiser la répartition des tâches par catégorie ou par équipier ;
le tableau est réinitialisé à chaque nouveau sprint.

Un scrum board plus élaboré

Comme indiqué plus haut, les colonnes du scrum board ne sont jamais que la matérialisation du cycle de vie des tâches en cours, lesquelles doivent respecter les critères de la notion de « terminé » pour prétendre au statut du même nom.

On peut donc utiliser le tableau des tâches pour matérialiser cette notion de « terminé » en attribuant une colonne du tableau à chaque critère de la notion. Pour reprendre l’exemple ci-dessus, on aura dans notre tableau les colonnes : « à faire », « codage », « revue de code », « documentation », « tests » et « terminé ».

Le suivi de la progression des tâches dans leurs différentes colonnes peut ainsi servir à calculer des ratios entre tests et développement, documentation et développement, etc. toutes informations pouvant s’avérer utiles pour affiner le processus d’estimation lors des sprints suivants.

Aujourd’hui, le modèle de tableau des tâches le plus utilisé est le modèle à cinq colonnes proposé par Mike Cohn :

source : http://www.mountaingoatsoftware.com/scrum/task-boards

La première colonne, « Story », permet de faire le lien entre l’exigence à traiter et les tâches qui permettent de la réaliser. Lorsque toutes les tâches sont terminées, la story elle-même peut être placée dans la colonne « terminé ».

Un fonctionnement plus élaboré :

une règle issue de Kanban : limiter, en nombre de post-it ou de points d’efforts, la quantité de travail dans une colonne pour un membre de l’équipe ; cette règle devient plus pertinente avec des tableaux à plus de trois colonnes ;
optimiser la règle précédente en faisant qu’à tout moment le nombre de points d’effort dans une colonne soit proche du maximum ; on se rapproche ainsi d’un fonctionnement limitant les périodes d’inactivité.

Le meilleur scrum board

Aucun projet ne ressemble à aucun autre, c’est vrai aussi pour les projets Agiles. Partant de ce point, ce serait un non sens que de suggérer un modèle de tableau plutôt qu’un autre.

Le meilleur tableau est celui qui convient le mieux au projet et à ses acteurs ; c’est celui qui apporte le meilleur compromis entre le niveau d’information, la qualité de la visualisation et la facilité de la gestion.

On peut aborder la composition et la gestion du tableau des tâches lors des rétrospectives de sprint. Le mieux est de partir du modèle « basique » standard (les trois colonnes) et de l’améliorer sprint après sprint, en composition comme en règles d’utilisation, en fonction des points d’amélioration identifiés en rétrospective.

Les tableaux virtuels

Je suis plutôt réticent à l’utilisation d’outils (plus ou moins) sophistiqués lorsqu’il existe des moyens simples et peu onéreux. Cette réserve est d’autant plus importante que le tableau scrum est pour moi plus qu’un support de visualisation : c’est un lieu d’échange et de rencontre entre les membres de l’équipe projet, et c’est aussi pour eux un fournisseur de satisfaction : pour l’avoir expérimenté personnellement comme observé sur les projets que j’ai accompagnés, le plaisir de placer physiquement un post-it dans cette sacrée colonne « terminé » n’a que peu de choses à voir avec une coche ou un changement d’état dans un tableur Excel (et ne je parle pas d’une saisie d’activité dans MS-Project !)

Cela dit, un tableau virtuel peut s’avérer utile dans le cas de projets dont les membres n’ont pas la possibilité de se rencontrer physiquement.

Dans ce type de cas, il existe Trello, un outil 100 % web qui permet visuellement d’organiser dans un tableau en colonnes des éléments, quels qu’ils soient (donc par exemple des tâches). Un billet sur Trello existe sur ce site : http://www.computure.net/fr/test-logiciel/137-trello-un-gestionnaire-de-listes-pour-les-projets-collaboratifs

Le nombre comme les titres des colonnes sont configurables.

L’outil a une qualité : les tableaux virtuels ressemblent à de vrais tableaux scrum, et les items peuvent être déplacés par drag and drop ; du coup, le plaisir de la manipulation physique et la satisfaction du travail « terminé » sont (presque) intacts.

Conclusion

Le tableau des tâches, la manipulation des post-it sont des pratiques emblématiques de l'Agilité et de la méthode Scrum. Il n'en est pas moins possible de les mettre en oeuvre dans un autre cadre, même non Agile.

Elles apporteront à tous les participants la communication visuelle, permanente, rapide, de la répartition et de l'avancement du travail de chacun, ainsi que l'occasion d'échanger chaque jour sur les tâches en cours et les objectifs à court terme que chacun peut se fixer. Une première étape vers l'auto-organisation et surtout la motivation de tous.

Computurellement vôtre.

Retrouvez tous nos articles sur www.computure.net.

Pour tout savoir de Scrum :

L’essentiel de SCRUM. SCRUM est aujourd’hui la méthode agile la plus utilisée et la plus riche en termes de retour sur investissement. Voici, en quelques billets, l’essentiel de la méthode. lire la suite…
L’essentiel de SCRUM (suite). Un deuxième billet sur l’essentiel de la méthode, plus orienté cette fois sur les « cérémonies » (les réunions). lire la suite…
Tutorial Scrum : l'agilité et la priorisation par la valeur. Comme dans le tutorial sur les niveaux de maturité de CMMI, une petite analogie pour aborder quelques-uns des principes de l’agilité et de la méthode Scrum. lire la suite...
Le mineur, le missile et le marin, ou l'agilité par l'exemple. Derrière ce titre aux allures de fable, trois exemples parmi ceux que j’utilise parfois à propos de l’agilité et de ses principes. lire la suite...
Computure lance le projet DSA : Les dictionnaires sont à la mode. Les éditions Plon confient depuis quelques années un « Dictionnaire amoureux de ... » à des pointures du monde de la culture. A l'exception du format, évidemment imposé (le lexique classé alphabétiquement), le procédé laisse à son auteur toute liberté quant au choix de ses entrées et de ses textes. lire la suite...
Idée reçue n° 1 : il n'y a plus de documentation : premier billet d'une série consacrée aux idées reçues sur l'Agilité. lire la suite...
Idée reçue n° 2 : l'Agilité, c'est pour les petits projets : les « petits » projets sont-ils vraiment exclus de l'application des méthodes Agiles ? Les petits projets sont-ils vraiment les plus appropriés pour une démarche Agile ? lire la suite..
Un peu de Kanban : dans le monde des méthodes Agiles, Kanban commence à occuper une place de plus en plus importante. Conçue au départ pour optimiser les chaînes de production, la méthode est, par sa capacité à améliorer la prise en compte des événements "au fil de l'eau", très adaptée au monde de la maintenance. lire la suite...
Le coup du parachute : de la ressemblance entre le pliage d'un parachute et la notion de « terminé ». lire la suite...
Apprendre par le jeu : le jeu de LEGO pour comprendre les principes de Scrum et de l'Agilité. lire la suite...

Et dans la catégorie « Méthodes », retrouvez également les articles suivants :

Aider le client à prioriser ses exigences. Comment prioriser son besoin à l'aide du modèle de Kano. lire la suite...
Les exigences : définition et classification. La gestion des exigences est aujourd’hui une activité majeure de l’ingénierie du logiciel. Elle est couverte dans CMMI par deux domaines de processus : REQM (Requirements Management : niveau 2) et RD (Requirements Development : niveau 3). Voici le premier de quelques billets consacrés à l’essentiel de l’ingénierie des exigences… lire la suite…
Tutorial : les niveaux de maturité de CMMI. Tout le monde le sait : rien ne vaut une analogie pour comprendre un concept un peu abstrait. Lorsque j’explique les niveaux de maturité du CMMI (Capability Maturity Model Integration), j’utilise souvent une analogie, disons... domestique. lire la suite...
sans oublier le très populaire Petit lexique du chef de projet informatique.