La tyrannie du « OU » 3/4 : peut-on y échapper?

Il semblerait qu’il faille regarder du côté de l’agilité pour trouver une option pour s’en sortir. Mais attention, ce n’est pas un viatique ou une solution miracle « poudre de perlinpimpin ». Il va falloir travailler…

Dans les précédents épisodes :

La tyrannie du « OU » 1/4 : projets ou opérations ?

La tyrannie du « OU » 2/4 : C*(Q+F)*D = Le triangle de fer

Une approche agile permet de se rapprocher d’un résultat mesurable et surtout atteignable. Contactez-nous pour en savoir plus

Le CQFD de l’Agilité

Dans le cas de l’Agilité, les invariants de l’équation C * (Q+F) * D sont :

• Les coûts : ils ne sont pas fixes mais ils sont prédictibles comme dans un engagement de moyens
• La durée : c’est le principe de faire des livraisons régulières, des sprints

Restent donc les variables (Q + F) représentant le périmètre comme variable d’ajustement.

Mais dans ce cas, c’est quoi la différence avec un engagement de moyens ?

L’objectif de l’Agilité c’est de responsabiliser l’équipe et d’avoir une boucle de rétroaction / feedback avec les utilisateurs ou clients le plus rapidement possible (le résultat de chaque sprint est un livrable).

C’est aussi l’idée qu’il vaut mieux faire des points de situation réguliers pour savoir si l’on s’éloigne de l’objectif (sprints reviews / sprints retros) et réévaluer la « destination du voyage » régulièrement (backlog grooming).

Un des outils les moins bien compris (et utilisé) est le « burn-up chart ». Il permet de mesurer l’atteinte du périmètre en fonction de l’avancement de l’équipe et donc de ne pas laisser « un chèque en blanc » à l’équipe :

Un outil de pilotage (peu ou mal) utilisé : le « Burn up chart »

Le burn-up chart permet d’avoir une vision de l’avancement de l’équipe :

• Objectif attendu (« expected » en bleu)
• Le Réalisé (« Actual » en rouge)
• Une projection en fonction du réalisé (« Estimate »)

Cela peut sembler hyper-simple mais je vous promets que nombre d’équipes passent à côté de cet outil et celles qui pourraient le faire ne l’utilisent pas. Alors que cet outil permet de prédire :

• Ce qui sera atteint en termes de périmètre de manière plus réaliste : dans l’exemple ci-dessus, à la fin du sprint 14, qui est la date de fin de release cible, l’équipe aura atteint : 120 / 140 = 85,7 % du périmètre
• Ce qui semble nécessaire de rajouter pour finir 100% du périmètre (ici 2 « extra sprints »)

Donc dans le cas d’une approche plus agile, on sort de l’approche moyens uniquement et on se rapproche d’un résultat mesurable et surtout atteignable.

Pourquoi le périmètre est-il mesuré en story points et pas en jour-homme ?

Par principe, chaque équipe définit ce qu’elle mesure : un story point est une définition propre à l’équipe ou au projet. L’équipe se choisit son propre référentiel.

Dans «Scrum by the book », il est conseillé d’avoir une Story de référence sur laquelle toute l’équipe s’accorde pour définir sa valeur en points et les autres Story sont évalués en plus ou en moins par rapport à celle-ci. Ensuite, on applique une suite de Fibonnacci et le tour est joué. Cela peut sembler abscons mais l’idée, c’est que, de toute façon, au début en tout cas, chacun a sa manière de chiffrer et il faut bien commencer par quelque chose. D’ailleurs, il n’y a pas de « vraie science » du chiffrage et cela peut sembler s’apparenter aux arts divinatoires (surtout que certains développeurs s’acharnent souvent à le rendre compliqué : on a alors l’impression de s’adresser à la Pythie de Delphes lorsqu’on demande un chiffrage. Il faut dire aussi que souvent, le chiffrage est vu comme un engagement à partir duquel est établi le budget de manière quasi-contractuelle…).

Pour ceux que cela intéresse, il existe quand même des méthodes de chiffrage rationnelles (même s’il reste une part d’art divinatoire, c’est moins fumeux qu’un chiffre ou une taille de T-Shirt) via la méthode des Use Case Points :

https://developer.ibm.com/devpractices/devops/ ou https://en.wikipedia.org/wiki/Use_Case_Points

Rien ne vous empêche par la suite de faire des transpositions entre jour-homme et story points. On peut également convenir qu’un jour/homme = 1 story point. Attention, cependant, à ne pas tomber dans une dérive classique :

Estimer en jour/homme ancre la tyrannie du « OU » : QUALITE ou PRIX

Lisez aussi :

Le Sprint 0, élément essentiel du démarrage d’un projet Agile