Série - Les courbes de croissance d un projet

Fil des billets - Fil des commentaires

Les courbes de croissance d'un projet (1)

Le beurdone montre la décroissance du reste à faire tandis que le burnup montre la croissance de ce qui est fait (et à faire).

Le beurdone introduit par Scrum représente un moyen nouveau et intéressant de montrer l'avancement d'un projet. Cependant il souffre de 2 inconvénients :

  • il ne montre pas l'évolution du périmètre
  • il ne montre pas le débit

Les différentes courbes de croissance que je vais présenter permettent d'offrir ces indicateurs importants.

Dans son aspect le plus simple, un burnup est une courbe de croissance de ce qui a été fait. burnup1.jpg

La courbe montre le cumul de ce qui est fini. Pour visualiser aussi ce qui reste à faire, comme avec le beurdone, il faut ajouter une deuxième courbe qui montre le cumul de ce qui est à faire :

Cette nouvelle courbe permet de voir l'évolution de périmètre. Qui est fréquente, puisque c'est même le principe même des méthodes agiles que de répondre au changement. La zone entre les 2 courbes montre le reste à faire. Avec Scrum, le reste à faire, c'est qui est contenu dans le backlog.

Ce type de graphe peut s'utiliser quelle que soit la technique pour identifier les éléments servant à mesurer : fonctions, use-cases, user stories. Cela pourrait même s'appliquer aux tâches d'une itération.

Dans un billet suivant sur le même sujet, je vais présenter comment en se servant des états des éléments on peut obtenir des indicateurs extrêmement intéressants sur le débit moyen pour finir un élément.

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

Les courbes de croissance d'un projet (3)

Dernier épisode de la série

Le beurdone est simple mais limité en cas de variation de périmètre, le beurneupe montre mieux les changements dans les exigences. Avec une approche Agile, un morceau fonctionnel est complètement développé dans une itération, il n'est pas donc utile de montrer sur une courbe les morceaux qui sont simplement analysés, conçus, codés. Il est cependant intéressant de montrer avec des courbes de croissance multiples les états de ces éléments avant le début de l'itération.

En statuant lors des revues de backlog sur l'état des éléments, on peut obtenir des courbes comme celle-ci :

burnup6.jpg

Et en déduire 2 indicateurs :

  • le TAF est le travail à faire. Travail à faire jugé faisable par l'équipe. Une valeur de TAF trop grande est probablement l'indication de spécifications détaillées prématurées. Une valeur de TAF trop faible montre l'inverse et alerte du risque de goulet d'étranglement : l'équipe n'est pas assez alimentée pour la prochaine itération.
  • le DDD est le délai de développement. Durée moyenne entre le moment où un élément est prêt pour le développement et celui où il est fini. Plus concrètement le délai entre le moment où un client dit ce qu'il veut et le moment où il voit le résultat. Les méthodes Agiles, inspirées par le Lean Development et la théorie des files d'attentes, poussent à avoir ce délai le plus court possible.