Table
On peut considérer le développement agile d’un produit comme un système asservi par le retour d’information (feedback). Le Backlog de Produit est ainsi la résultante de la vision initiale du Produit et son ajustement par le feedback apporté tout au long du projet.
L’importance du feedback
Le développement agile d’un produit commence par l’expression d’une vision et sa traduction en besoins fonctionnels : le Backlog de Produit.
A la fin de chaque développement, l’incrément de produit généré est présenté aux parties prenantes, c’est-à-dire tous ceux qui ont des attentes vis-à-vis de ce développement. On attend d’eux qu’ils réagissent en formulant des retours d’information.
C’est ce retour d’information (feedback) qui sert à réajuster le Backlog de Produit comme montré sur le dessin ci-dessous.
Product Backlog feedback loop
Ainsi, après plusieurs itérations, le Backlog de Produit a bien changé. Le contenu fonctionnel a été revu. Et le Backlog de Produit contient aussi tous les défauts (bugs) découverts. Qu’il s’agisse du réajustement du contenu fonctionnel ou bien de la découverte de défauts, ces informations proviennent le plus souvent du feedback donné en démonstration de l’incrément de produit.
Quelle durée pour cette boucle de retour ?
Plus la boucle de rétroaction est courte, plus le système peut être adapté facilement. Lorsque cette boucle est longue ou qu’elle n’existe pas, on parle d’effet tunnel.
On va donc chercher à réduire au maximum ce temps de boucle.
D’un autre côté, les développeurs ont besoin de temps pour construire la solution qu’ils vont proposer. Une tendance à la perfection les pousse même à continuer jusqu’à ce qu’ils aient donné le dernier coup de lustre à leur produit.
Ainsi, la durée de l’itération agile doit rester le compromis entre le besoin d’un retour d’information rapide et le temps nécessaire à l’équipe de développement pour produire un résultat tangible.
Le vocabulaire du mode flux se prête encore mieux à cette notion. On cherche de la même façon à réduire le temps de cycle par analogie avec la durée de l’itération. La démonstration de tout incrément provoque le retour d’information qui va à son tour alimenter l’expression des exigences.
L’expérimenter à pas cher
Le jeu du bâton d’hélium fourni un excellent moyen de comprendre ce besoin de retour d’information. C’est en comprenant qu’il manque le retour d’information qu’on trouve la solution de ce petit jeu.
Le Moto à retenir
A l’inverse, tant qu’il n’y a pas de retours d’information, il n’y a pas de raison de changer. Cela amène à définir ce moto :
No Feedback, no changes!
Source
Cet article est fortement inspiré par les schémas de Gunter Verheyden dans son article sur la cadence des sprints à l’échelle.