J’ai lu « Perplexité, complexité, vélocité » sur le blog d’OCTO. L’article est bien tourné et on sort complètement convaincu. Mon problème c’est que quelques heures après j’ai commencé à avoir des doutes et plus les jours avancent plus mes doutes se transforment en avis contraire. Je vous encourage à lire d’abord le billet d’OCTO, le mien n’aura de sens qu’en réponse.
À quoi sert la vélocité ?
À quoi sert la vélocité ?
1. Estimer ce qui sera réalisé ou non dans le sprint
2. Mesurer la productivité de l’équipe
3. Mesurer le réalisé pour le projet, le produit
Ma divergence avec l’article source vient d’un constat simple : Nous n’utilisons pas cet indicateur dans le même objectif. Lui l’utilise pour mesurer la productivité, moi pour améliorer les estimations.
Améliorer les estimations
Améliorer les estimations c’est faire en sorte de mieux évaluer ce qui sera livré dans chaque sprint et aider à la priorisation. Bref, gérer le projet.
Pour améliorer nos estimations on tente de se baser sur les tâches similaires précédentes et on en réutilise l’estimation sans tenir compte de la productivité de l’équipe. On utilise pour cela une unité virtuelle qui nous détache des jours/hommes : le point. Réaliser une estimation ainsi est de plus en plus simple, rapide et fiable.
Pour prendre en compte les évolutions de productivité (équipe plus efficace ou dette technique grandissante) c’est le nombre de points réalisable dans un sprint qu’on fait varier. Afin de ne pas sortir le dé pour évaluer ce nombre de points, on se base sur ce qui a été réalisé dans les quelques sprints passés et on tente de rester sur une courbe la plus stable possible.
Nos références d’estimation sont stables, nos estimations se fiabilisent avec le temps. Le nombre magique de points qu’on peut mettre dans un sprint, c’est pour moi ce qu’est la vélocité de l’équipe.
En prenant en compte la technique
Si on calcule en points et pas en heures ou en jours, ce n’est pas parce qu’on compte en complexité fonctionne, c’est pour s’autoriser à faire varier la somme totale plutôt que chaque estimation.
Il ne faut pas perdre de vue que notre objectif reste bien d’évaluer une charge de développement. Il faut donc tenir compte dans nos estimations de tout ce qui est nécessaire à évaluer le temps de développement et livrer la fonctionnalité : Ça va des besoins fonctionnels à la complexité technique en passant par les contraintes organisationnelles spécifiques.
Si je ne prends en compte que la complexité fonctionnelle, l’estimation n’aura plus aucun lien avec le temps de développement. Pour savoir ce qui tient ou pas dans le sprint, on en viendra à faire une estimation globale, au jugé, sans références similaires : tout l’inverse de l’objectif.
Outil privé versus indicateur public
À mon humble avis l’erreur de l’article n’est pas seulement de faire de la vélocité une mesure de productivité, c’est en plus de l’avoir communiquée à l’extérieur de l’équipe.
Du coup, forcément, la vélocité devient un enjeu politique. L’équipe, son manager, son coach commencent à avoir intérêt à améliorer l’indicateur au lieu de se concentrer sur ce qui devrait être leur seul objectif : apporter de la valeur au produit.
Que la vélocité augmente, diminue, c’est quelque chose propre à l’équipe. S’il faut un indicateur de productivité et de perturbation, il faut publier la seule chose importante : la progression de la valeur du produit (si ça ressemble au paragraphe précédent, ce n’est pas une coïncidence).
Cette vélocité doit être prise pour ce qu’elle est : un outil d’estimation, de planification et de priorisation. Comme tous les outils, il a vocation à être utilisé en interne, par l’équipe, et nulle part ailleurs.
Et la complexité fonctionnelle ?
Mon second problème est là : Selon moi la complexité fonctionnelle n’indique rien de valable. Ce n’est pas une mesure de ce que coûte la fonctionnalité, ce n’est pas une mesure de ce qu’apporte la fonctionnalité, et incidemment ce n’est pas une mesure de l’implication ou de la productivité de l’équipe.
Tout au plus la complexité fonctionnelle permet de faire une première estimation des histoires utilisateurs qui ne sont pas prévues pour tout de suite ou dont on ne connaît pas la complexité technique.