Indicateurs quantitatifs

Considérons quelques indicateurs (parmi tant d’autres) visant à quantifier le fonctionnement d’un projet agile

• nombre de story points (de user story) réalisés dans une période (une itération, une release) par jour.homme, pour intégrer les variations de capacité de production (vacances, disponibilités partielles). Moyenne plus ou moins glissante. Instructif quand il s’agit de planifier la suite. Voici le backlog, voici la colonne story points, voici le total, je divise par tel ratio, voici le nombre d’itérations, voici la date d’atterrissage, vous pouvez décaler la release de x mois si on ne change rien.
• nombre d’heures idéales (de tâches) réalisées dans une période (une journée, une itération) par jour.homme. Moyenne plus ou moins glissante. Instructif quand il s’agit de planifier la suite. Pas évident d’expliquer qu’en une journée on fait 5,8 h idéales et pas 7 ou 8, si ce n’est en le montrant
• % des story points prévus qui ont été effectivement livrés dans l’itération. Pour éviter de trop s’engager à chaque fois et conserver la confiance.
• % des story points prévus et livrés qui ont été finalement inclus dans la release finale, pour évaluer la quantité de changement du périmètre et la rationalité de la priorisation sur laquelle s’est appuyée la planification.
• % des story points des user stories qui ont été ajoutés en cours de release, pour évaluer la stabilité du périmètre. Ok pour accepter le changement, mais ca prend du temps.
• Somme de l’estimation en heures de correction idéales de bugs injectés par itération, pour évaluer la qualité du processus de devt, la surchauffe.
• Etc… (Je n’aborde pas ici l’efficacité directe des rituels, comme la durée du standup ou le temps entre le moment où une idée est évoquée en rétrospective et le moment où elle est prise en compte (ou abandonnée))

L’essence de ces indicateurs est toujours la même. On confronte le projet au réel (demandes du métier, développement et corrections de defects) pour en déduire a posteriori des indicateurs sur le fonctionnement du projet permettant, en s’appuyant sur cet historique des projections sur l’avenir (toutes proportions gardées, le cône d’incertitude se réduisant au fur et à mesure de l’avancement du projet) ou pour identifier des plans d’action (resensibiliser le product owner, améliorer la qualité, …).

Ne pas mesurer le temps passé par les uns et les autres mais bien les progrès effectués par l’équipe.

Inclure des correctifs de la capacité de production quand une personne est absente ou ne l’est pas.

Rester prudent en exploitant ces résultats, les indicateurs ne se stabilisent pas forcément dans le temps. Il faut les assortir d’hypothèses, et assortir les conclusions que l’on en tire de ces mêmes hypothèses.

Le but ultime : annoncer les mauvaises nouvelles dès qu’on les connait pour prendre les mesures qui s’imposent (réduire le périmètre, augmenter l’équipe (à utiliser avec modération), arrêter le projet). Ne pas faire l’économie de l’effort de communication, de préparation du discours (s’appuyer sur des faits et non des impressions). S’attendre à une résistance, un frein à l’action. Personne n’aime annoncer des mauvaises nouvelles ou demander une rallonge.