La gestion des itérations d’un projet et la comptabilisation des changements qui permet d’autoriser le client à modifier à tout instant ses demandes, nécessitent une vision un peu plus complète qu’une simple ToDo liste.
Note : j’avais fait remarquer aux journalistes
de plusieurs magazines que dans les précédents articles sur l’Agilité,
les photos illustrant un environnement de travail " Agile ",
représentaient toujours un bureau conventionnel où les acteurs travaillaient sur des portables, visiblement pas en binômes et sans Radiateur d’informations. Cette faille de communication a été corrigée à partir de 2008. Par contre, en guise de Radiateur d’informations, ce ne sont que de simples ToDo listes à trois colonnes qui sont exhibées.
Figure 1 — Planification et monitoring minium
Comme le précisait Einstein, les choses doivent être appréhendées simplement mais pas de manière simpliste.
En l’occurrence il est souvent nécessaire de disposer d’une colonne matérialisant des découpages en tâches techniques et toujours indispensable de conserver un groupe de lignes en bas du tableau pour maintenir visuellement la trace des changements ayant affecté la planification initiale.
C’est d’ailleurs dans cette pratique de métrique formalisée du coût réel du changement que le concept
" adaptatif " trouve sa justification économique et sa réalité organisationnelle.
Figure 2 — Burndown chart (avancement et calcul vélocité)
Rapport d’avancement (Burndown chart)
avec calcul de vélocité par itération :
- Moyenne estimée initiale 72 Points de Récits
- Moyenne réelle observée 92 Points de Récits
La figure 2 représente un suivi basique tout en étant suffisant.
La figue 3 est un exemple très technique, issu d'un projet très important, mais qui reste dans l’esprit du contrôle Agile.
La figure 3 est un exemple de rapport d’avancement
du projet généré automatiquement. Son auteur, Frédéric Tardieu,
commente " En gros ce graphe montre la quantité de problèmes
(statut " open ") sur une échelle de temps. J’ai ensuite amélioré le système en visualisant
les dépendances avec des équipes externes à l’équipe concernée.
J’ai automatisé la génération car nous utilisions un système de gestions de tâches qui stockait tous les informations et évènements (estimation d’effort, codé, testé OK ou non, etc.) en base de données. Il était donc facile d’introspecter cette base pour construire un graphe précis. Une fois le graphe généré, il était envoyé par mail à toutes les personnes impliquées, accompagné de l’état de chaque histoire et tache. Ceci a rendu très visible l’avancement des projets pour le business et l’IT, y compris les externes situés dans d’autres pays. Autre avantage : d’une itérationaux suivantes, j’ai pu observer l’évolution de la coopération, en particulier en pistant les statuts développé et testé OK ou KO, ce qui a montré de manière objective qu’avec le temps, tout le monde a de plus en plus travaillé ensemble, alors qu’auparavant les testeurs et les développeurs travaillaient individuellement. La transparence sur l’avancement des projets a donc été un facteur déterminant pour renforcer le travail en équipe. "
Note : Frédéric Tardieu précise
" Il est vrai que mon approche est un peu orthogonale par rapport à
l’agilité (le fait d’analyser des indicateurs pour voir si réellement le travail
en équipe s’améliore), mais cela permet de rendre vraiment transparent ce qui fonctionne
et ce qui ne fonctionne pas. "
De nombreux produits sur le Web montrent que les logiciels spécialisés, la sophistication et la virtualisation ne sont pas impossibles. Mais je ne pense pas que cet outillage conserve réellement l’esprit Agile basé sur la communication directe en mode plateau.
