Dans le cadre des projets Agile, il est souvent fait usage de bons gros graphiques, fixés sur un mur de la salle de travail, qui permettent de visualiser et de partager l'état actuel du projet. On trouve aussi ce genre de procédés dans le cadre des systèmes Lean. Le terme KanBan, que l'on pourrait traduire du japonais par "fiche" ou "étiquette" désigne, dans un système de production Lean, une méthode de marquage par étiquette des taches, ou lots de taches. Une nouvelle fiche est ajoutée au système seulement lorsque le travail représenté par une fiche "en cours" est achevé.
Dans cet article, j'explore les méthodes de visualisation modernes des projets Agile. Je propose ensuite, par le biais des tableaux Kanban, une organisation selon 3 perspectives (Time, Task et Team) qui permet à toute une équipe de comprendre l' état courant d'un projet et de travailler de manière autonome, motivante, et collaborative. Pour finir, je présente un outil logiciel, TRICHORD, qui implémente la méthode des tableaux Kanban pour réaliser une représentation visuelle de ces 3 perspectives.
Les supports visuels dans les projets Agile.
L'extreme programming (XP) propose un concept d' "espace de travail informatif", qui permet de voir l'état du projet en un coup d'œil [Beck05]. Il suffit pour cela d'afficher des "Story cards" et des "Task cards" au mur. On affiche parfois des graphiques ou des diagrammes nommés "Information Radiators" (diffuseurs d'information)[Cockburn01] ou "Visible Big Charts" [Jeffries04], très courants de nos jours dans les salles de projets agiles. Ci-dessous, quelques exemples d'outils graphiques que l'on peut trouver dans les équipes Agile japonaises.
Le premier exemple, en figure 1, est un Task Board Kanban, nommé ainsi d'après la méthode d'organisation et de gestion de production "Juste-à-temps" (JAT) de TPS(Toyota Production System)[Poppendieck03, 07].
Figure 1: Task Board Kanban
Un Kanban est une étiquette décrivant une tâche à effectuer. Chez TPS, on l'utilise pour superviser une production Juste-à-temps à flux "tiré". Sur l'image 1, on peut voir un tableau Kanban qui nous renseigne sur l'ensemble des tâches à faire sur cette itération. À chaque tâche correspond une étiquette (un simple post-it), dont le statut est représenté par sa position sur le tableau, que l'on a séparé en 3 zones: ToDo, Doing et Done (à faire, en cours et effectué). Ce tableau Kanban permet à l'équipe de voir ce qui se passe bien, ce qui reste à faire, et d'être autonome.
La figure 2 représente un autre type de tableau Kanban, qu'on appelle Feature Kanban Board. (Hightsmith le qualifie simplement de "Feature Card Whiteboard Layout" - Tableau blanc pour Feature Cards, mais je suis catégorique sur l'idée que c'est bien d'un tableau Kanban qu'il s'agit)[Highsmith04]
Figure 2: Feature Kanban Board
Sur ce tableau, l'axe horizontal représente le temps. Les zones verticales ,elles, représentent les versions, dont chaque étiquette est une nouvelle fonctionnalité à implémenter. Contrairement au premier tableau, qui est généralement utilisé par les équipes de développement, ce tableau fournit une vue d'ensemble de haut niveau sur l'évolution du produit. Elle devrait donc être partagée par l'ensemble de l'équipe "élargie", c'est à dire en incluant les clients ainsi que les pôles marketing et management.
De même, le Parking Lot Chart de la figure 3 est utilisé pour fournir un résumé très haut niveau et digeste du statut du projet (à ne pas confondre avec un "Parking Lot List", un outil utilisé pour répertorier les problèmes non résolus). Le "Parking Lot Chart" a d'abord été décrit dans le "Feature Driven Developpement" (FDD)[Palmer02], et est maintenant utilisé dans la plupart des projets Agile. On l'appelle parfois "Project Dashboard".
Figure 3: Parking Lot Chart
L'image quatre nous montre un autre outil de visualisation nommé Burndown Chart.
Figure 4: Burndown Chart
Il a d'abord été conçu pour la méthodologie Scrum[Schwaber01], pour afficher le backlog restant, avant d'être étendu à la plupart des méthodologies Agile [Cockburn04], [Cohn05]. Il affiche le statut courant ainsi que le taux d'avancement des tâches restantes.
Le dernier graphique intéressant, figure 5, s'appelle le Niko-niko Calendar (ou Smiley Calendar). C'est une création japonaise, qui représente, pour chaque membre de l'équipe, l'humeur du jour. Chaque membre dépose un smiley sur son propre calendrier à la fin de la journée, avant de quitter la salle de travail [Sakata06]. C'est un regard sur le bien-être et la motivation de chaque membre du projet.
Figure 5: Niko-niko Calendar (ou Smiley Calendar)
Les tableaux Kanban en tant que principaux diffuseurs d'information
Pour résumer, les outils de représentations évoqués sont:
Le Kaban Board. Chaque étiquette va représenter une tâche, une story, une fonctionnalité... et sera fixé sur une ligne temporelle (un tableau). Il y a différents niveaux de granularité possibles.
Le Burndown Chart. Fait le décompte du nombre de Kanbans (tâches restantes) et l'affiche sur une ligne temporelle montrant la tendance globale du travail accompli. Ici aussi, on peut trouver plusieurs niveaux de granularité.
Les Parking lot Charts. Résumés très haut niveau de l'état du projet
Les Calendards. En plus des Niko-niko calendars, il existe une multitude de variations de calendriers décrivant l'état courant ou prévisionnel d'un projet.
Notez qu'entre tableau Kanban, Burndown Chart et Parking Lot Carts, ce sont les tableaux Kanban qui offrent les informations les plus détaillées. Le traçage des Burndown Charts et des Parking Lot Charts peut être basé sur les informations que fournissent les mises à jour quotidiennes du tableau Kanban. C'est pourquoi je poursuivrai en considérant les tableaux Kanban comme principaux supports d'information, et les Burdown Charts / Parking lot Charts comme outils secondaires, résumés visuels des tableaux Kanbans.
L'organisation en Kanban des trois perspectives
En regardant attentivement les tableaux Kanban, vous pouvez constater qu'ils couvrent 3 aspects: le Temps, les Taches et l'Équipe. Je vais ici tenter d'organiser les Kanbans selon ces 3 points de vue.
Figure 6: Découpage du Temps et des Tâches
1.Temps:
Dans les projets agiles, le temps est découpé en Releases (ou Versions), elles mêmes découpées en Itérations, elles mêmes découpées en Jours.
- Une Release dure habituellement entre 1 et 6 mois et représente la granularité temporelle la plus grossière. Il s'agit d'un point de synchronisation partagé par toute l'équipe, toute l'équipe se doit d'y assister.
- Une Itération représente le deuxième niveau granulaire. Elle dure habituellement de 1 à 4 semaines et sera pour les développeurs un cycle de travail, d'analyses et d'améliorations.
- Une Journée est le plus fin niveau de granularité, l'équipe se rencontre chaque jour pour un stand-up afin de partager l'avancement du projet et les problèmes rencontrés.
2.Tâches:
Pour les tâches aussi, il existe 3 niveaux de granularité. Je nomme le plus haut niveau "Features", chaque Feature est divisée en Stories et chaque Story en Tâches.
- Une Feature est une fonction utile et significative pour l'utilisateur.
- Une Story est une partie testable d'une Feature, on la décrit aussi d'un point de vue utilisateur.
- Enfin, une Tâche est un constituant de Story, qui sera décrite en termes techniques par les développeurs.
3.Equipe:
Pour un projet, une équipe est un groupe de personnes travaillant sur un but commun. On trouve habituellement dans les membres la constituant un manager, des développeurs, des analystes d'entreprise, des utilisateurs, des testeurs et d'autres parties prenantes. Toute l'équipe se doit de partager les informations sur le Temps et les Tâches décrites plus haut pour parvenir à ce but commun.
Les tableaux Kanban associant Temps et Tâches de l'équipe
J'aimerai concevoir un tableau Kanban associant les Tâches et le Temps. Souvenez-vous que Temps et Tâches partagent tous deux une structure à 3 niveaux, et plus le niveau est élevé, plus le management associé doit être conséquent. Il est donc raisonnable de concevoir le Kanban en associant les concepts Release/Feature, Iteration/Story, et Jour/Tâche comme montré sur le tableau 1. Cela dit, d'autres associations Temps/Tâches sont tout à fait envisageables.
Tableau 1: Combinaison des Kanban Tâche et Temps
Une Feature Kanban permet de donner à toute l'équipe une vision haut niveau du projet. On peut s'appuyer sur un Parking Lot Charts pour montrer l'état d'avancement à haut niveau.
À moyen niveau, on retrouve une Story Kanban, sans doute la plus respectée et suivie pour par l'équipe. On peut l'associer à un Burndown Chart valable pour toute l'Itération.
À bas niveau, le Task Kanban permet de représenter les évolutions au jour le jour, il peut s'appuyer sur un Burndown Chart quotidien.
Figure 7: Vue d'ensemble - les 3 facettes et les Kanbans associant Tâche et Temps
TRICHORD
Nous avons développé un utilitaire de management de projets Agiles, TRICHORD: TRI pour les trois points de vue (Temps, Tâche et Équipe) et CHORD pour harmonie.
Il fonctionne comme un lieu de travail virtuel pour partager l'avancement du projet avec toute l'équipe, en fournissant les 3 niveaux de tableaux Kanban: Feature Kanban, Story Kanban et Task Kanabn, comme le montre la table 1. Une Feature Kanban est illustrée par un Parking Lot Chard, Story et Tâches sont illustrées par des Burndown Charts.
Figure 8: TRICHORD (Tableau Kanban, Burndown Chart et Parking Lots)
De plus, TRICHORD possède un service de calendrier Niko-niko pour partager l'humeur de l'équipe. Il fonctionne comme un simple Twitter-Like, comme un réseau social dans le projet.
Figure 9: Niko-niko Calendar TRICHORD
TRICHORD est implémenté sur Eclipse RCP (Rich Client Platform), et peut fonctionner avec Trac (gestionnaire de demandes).
Remerciements
Mille mercis à Mary Poppendieck, qui a relu ce papier avec attention et qui a fourni nombre de conseils et de suggestions.
Références
- [Sakata06] Akira Sakata, “Niko-niko calendar”, 2008
http://www.geocities.jp/nikonikocalendar/index_en.html - [Beck05] Kent Beck, “Extreme Programming Explained 2nd “, 2005 Addison-Wesley
Le concept d'"espace de travail informatif" (“Informative workspace”) provient de l'XP. - [Cockburn01] Alistair Cockburn, “Agile Software Development”, 2001 Addison-Wesley
Le terme “diffuseur d'information” ("information radiator") est plus courant. - [Cockburn04] Alistair Cockburn, “Crystal Clear”, 2004 Addison-Wesley
Ou l'on discute de l'intérêt du “Burndown/up chart”. - [Cohn05] Mike Cohn, “Agile Estimating and Planning”, 2005 Prentice Hall
Ou l'on approfondie la discussion sur l'intérêt du “Burndown chart”. - [Jeffries04] Ron Jeffries, "Big Visible Chart", 2004
http://www.xprogramming.com/xpmag/BigVisibleCharts.htm - [Poppendieck03] Mary and Tom Poppendieck, “Lean Software Development”, 2003 Addison-Wesley
- [Poppendieck07] Mary and Tom Poppendieck, “Implementing Lean Software Development”, 2006 Addison-Wesley
Donnes des explications sur Kanban et son fonctionnement en tant que pull process mechanism. - [Schwaber01] Ken Schwaber, et al. “Agile Software Development with SCRUM”, 2001 Prentice Hall
- [Highsmith04] Jim Highsmith, “Agile Project Management”, 2004 Addison-Wesley
Dans cet ouvrage, le Feature Kanban est désigné sous les termes "Feature breakdown structure" et "Feature planning on whiteboard" (littéralement, "planning de features sur tableau blanc"). - [Palmer02] Stephen R. Palmer et al., Practical Guide to Feature-Driven Development, 2002, Prentice Hall
Première évocation des Parking Lot Chart
L'auteur
Kenji Hiranable est le directeur général de Change Vision, Inc. Il est le créateur de JUDE, un éditeur logiciel d'UML et de MindMap.Il est aussi le responsable de la traduction japonaise de Lean Software Development, XP Installed, Agile Project Management, et d'autres livres XP/Agile. Kenji voit le développement logiciel comme une forme de jeu de communication, il cherche toujours à explorer de nouvelles voies pour le rendre plus productif, collaboratif et amusant. De plus amples informations sur TRICHORD sont disponibles sur trichord.change-vision.com.