Nous souhaitons tous, et surtout nos managers, savoir ce que l’on a fait car cette information nous permet de prendre des décisions futures avec plus de sérénité car nous avons une meilleure confiance sur notre capacité à faire.
Je ne parlerais pas dans cet article de la gestion de projet agile (Burndown chart, Dashboard …) mais de la gestion de produit agile et en particulier d’une métrique que je recommande de rendre visible pour connaître ce que l’équipe a fait lors des itérations précédentes.
La plupart des produits sont à la fois en phase de maintenance (des versions précédentes) et de développement (la version à venir), et il est toujours intéressant de connaître le temps passé par l’équipe dans les 2 activités.
Dans les approches traditionnelles, l’équipe est supposée remplir des feuilles de temps détaillées qui indique les heures passées en maintenance et celles passées en développement. La saisie de ces informations est fastidieuse, mal perçues par l’équipe et de plus, certaines activités comme la validation finale ou le refactoring ont du mal à être classé dans l’une ou l’autre des catégories.
Au bilan les informations recueillies sont erronnées et ne peuvent/doivent être utilisées pour prendre des décisions.
Mais que faire ?
Scrum nous propose une solution toute simple grâce à la mise en place d’estimation des fonctionnalités en « points d’utilisateurs ». Il suffit de catégoriser les « user stories » dans le product backlog et, à l’issue de chaque itération, de rendre visible ce qui a été produit sous forme de ratios.
Les 4 catégories que je préconise sont :
- Fonctionnelle : La User Story apporte une valeur ajoutée directe à l’utilisateur final
- Non Fonctionnelle : La User Story est en général à l’initiative de l’équipe technique et à pour but d’améliorer le processus de développement
- Bug : La correction d’un défaut connu a été planifié lors de l’itération
- Urgence : L’équipe est intervenue pour résoudre un problème (généralement en clientèle ou sur les plateformes de production)
Pour la catégorie « urgence », il est nécessaire de mesurer le temps passé (par exemple lors de chaque Stand Up) sur chacune des urgences. Le ratio des urgences se calcule donc par rapport à la capacité de production initiale de l’équipe et non sur la complexité (pas de « points d’utilisateurs » dans ce cas).
Comment utiliser cette métrique ?
De beaucoup de façons différentes, entre autres :
- Pour le Product Owner à évaluer la quantité réelle de nouvelles fonctionnalités que l’équipe est capable de produire par itération
- Pour l’équipe à argumenter la nécessité d’implémenter des tâches non fonctionnelles (voir même définir un seuil minimum)
- Pour l’équipe complète de mesurer l’efficacité de la mise en place de pratiques d’ingénierie spécifiques (TDD, Pair Programming, IC …) sur la qualité des livrables (moins de bugs, moins d’urgence …)
- Pour le Manager … de lui donner de la visibilité sans effort … même si cette métrique ne lui est pas d’une grande utilité 🙂
La mise à disposition de cette information nécessite l’ajout d’une colonne dans le backlog puis de comptabiliser en fin d’itération les User Story « DONE » dans chaque catégorie … et le résultat est disponible en moins de 5 minutes … plus 1 minute pour l’imprimer et l’afficher.
Simple non ?
Une équipe de maintenance traditionnelle gère théoriquement chaque demande de changement unitairement et en la typant 1° soutien, 2° étude, 3° correctif (urgent o/n, bloquant o/n), 4° évolutif (mineur, majeur), 5° préventif/adaptatif. Dans le cas d’une maintenance externalisée, les modalités d’engagements de service (plage horaire, délai de prise en compte, …) et de facturation sont au cas par cas. A mon sens, l’une des innovations de l’Agile (je me perd un peu dans la paternité Scrum/XP) est l’intégrité fonctionnelle de la user story qui peut embarquer à la fois du correctif, préventif et de l’évolutif par exemple… Par ailleurs et à titre d’information, l’utilisation de Scrum, qui fixe des itérations de longueur fixe, peut être difficile dans le cadre du maintien en condition opérationnelle nécessitant une réactivité parfois très forte. Dans ce cas, je renvoie tout le monde à l’article de Henrik Kniberg que j’ai traduit en français « Kanban vs Scrum » (le « versus » qui a fait coulé beaucoup d’encre se veut à titre de comparaison et non pas d’opssition).
Quand à Scrum, les itérations de durée fixe ne sont pas un obstacle à la gestion des urgences et à une réactivité immédiate, je le confirme tous les jours avec les équipes que je coache … mais par contre il faut absolument mesurer le temps passé sur ces activités pour mieux anticiper le futur.
Mesurer le temps passé sur les urgences (en fait sur autre chose que du backlog) est essentiel. Maintenant je trouve que ton graphe mélange les torchons et les serviettes : si j’ai bien compris le ratio entre les 3 premières catégories se fait sur les points et pour les urgences, c’est le temps passé.
D’autre part je pense que non fonctionnel, c’est une appellation trompeuse. Il y a des exigences non fonctionnelles (utilisabilité, …) et les mettre dans la même catégorie que des activités techniques est à mon avis discutable. Je préfère séparer en user stories et stories techniques.
Enfin ça ne m’a pas l’air si facile que ça à interpréter.
Pour le reste, chacun est libre de ses choix 🙂
Les types de demandes de changement gérés correspondent à des workflows de traitement différents, à des équipes différentes (ex: support par le client, évolutif externalisé), à des équipes géographiquement dispersées (ex: support à l’exploitation & correctif urgent sur place chez le client, évolutif mineur en Inde), à une mixité junior/senior différente des équipes, à des unités d’œuvre différentes, et oui… à une facturation dédiée pour chaque type de demande de changement. Et effectivement, c’est loin d’être simple en fin de mois, surtout lorsqu’il faut croiser avec les indicateurs/objectifs de la convention de service et calculer les pénalités ou les bonus lorsque c’est prévu. Mais des outils de saisie, d’affectation et de suivi des demandes (Mantis, Jira, …), partagés entre le client et le(s) équipe(s) de maintenance permettent a priori de gérer/industrialiser une partie de la chaîne.
Théoriquement, l’engagement porte sur une amélioration des workflows, des gains de productivité, une augmentation de la qualité perçue par le client et oui… à une réduction des coûts pour ce client. Mais je n’essaye pas de vous convertir à un business model qui a déjà vécu et je suis convaincu qu’il faut expérimenter Scrum. Donc, en conclusion, bravo pour votre rôle de coaching au sein de ces équipes !