Les courbes de croissance d'un projet (2)

La deuxième partie sur les mesures d'avancement d'un projet.

Le beurdone, c'est bien. Le beurneupe à 2 courbes, c'est encore mieux comme l'a bien montré Matthieu dans son commentaire. Les 2 sont le reflet des mesures faites sur des petits éléments qui apportent de la valeur[1]. Le beurneupe est basé sur 2 états de cet élément : identifié pour la courbe du haut, fini pour la courbe du bas.

Et si on ajoutait d'autres états ? Traditionnellement, l'état d'une fonctionnalité (exigence fonctionnelle, cas d'utilisation...) est fonction de la phase dans laquelle on se trouve : analysée, conçue, codée, testée...

Dans un développement Agile, tous ces états sont franchis dans une seule itération, il n'y a donc aucun intérêt à les utiliser pour des mesures. On peut montrer ce qui est en cours, ce qui a un tout petit peu plus d'intérêt :

burnup3.jpg

En principe, ce qui était en cours au début de l'itération n est fini à la fin de l'itération n. Le graphe peut être utile quand ce n'est pas toujours le cas.

Par contre l'élément a quand même une vie intéressante dans un développement Agile, avant l'itération. Après avoir été identifié, un élément peut être estimé. Pour être mis dans une itération, l'élément doit, en plus d'être identifié et estimé, répondre à des critères permettant de le mettre dans une itération : par exemple qu'il soit suffisamment petit pour être fini dans l'itération, ou qu'il soit suffisamment compris par l'équipe. Cela m'amène à représenter le cycle de vie d'un élément avec les états suivants, utile dans le cadre d'un développement Agile :

VieEltBacklog.jpg

La mesure des éléments en fonction de ces états permet d'obtenir de nouvelles courbes de croissance :

A noter que si on prend en compte l'état identifié, on ne peut pas utiliser les points puisqu'on ne les a pas encore estimés. La mesure s'effectue simplement sur le nombre d'éléments dans chaque état.

Nous verrons dans un prochain billet comment utiliser ces courbes pour identifier les goulets d'étranglement et les variations de débit, dans un esprit Lean.

Notes

[1] éléments du backlog dans le cas de Scrum, en général des histoires d'utilisateur