Commentaires sur : Métrique pour Scrum

Par : Fabrice Aimetti

Fabrice Aimetti — Mon, 29 Jun 2009 19:04:32 +0000

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 !

Par : Claude Aubry

Claude Aubry — Mon, 29 Jun 2009 17:35:52 +0000

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.

Alexandre : « Torchons et Serviettes » pas vraiment, puisque le nombre de points TERMINE dépend de la capacité de production exprimée en jours … comme les urgences.
Pour le reste, chacun est libre de ses choix

Par : Fabrice AIMETTI

Fabrice AIMETTI — Mon, 29 Jun 2009 12:40:41 +0000

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).

Alexandre : A quoi servent les 5 types de demandes ? A prendre des décisions pour mieux gérer l’activité de maintenance ? Ou alors plutôt à gérer la relation contractuelle entre client et fournisseur ? Mais donc sans réel objectif d’amélioration des processus !
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.