Dès 2006, j’avais choisi de ne pas traduire release pour l’utilisation dans plan de release, comme on peut le lire dans ce billet Sprints, releases et produit ou celui-ci Release et moi.
Pour éviter la confusion possible, que j’évoquais déjà, entre ce qui est produit et la période de temps nécessaire pour le produire, j’emploie version pour le premier sens.
Dans le glossaire que j’ajoute à l’édition quatre, voilà l’entrée pour release :
Après avoir unifié en une seule vue le backlog (et ses bacs) avec le plan de release, ajoutons-y les incertitudes.
Nous sommes dans le cadre d’une release dont la date de fin est fixée. Par exemple : elle se termine après 8 sprints, chacun de deux semaines. Nous sommes à la fin du 3ème sprint. On nous demande des prévisions sur ce qui sera fini pour cette release.
On pourrait faire des estimations et mesurer la vélocité.
Le plan de release peut être montré avec des incertitudes et des vagues. Les éléments qu’on y fait figurer sont tirés du backlog, on les trouve donc aussi dans les bacs.
Dans le cadre du management visuel, ces deux représentations sont utiles. Cependant il faut passer d’une l’une à l’autre, ne pourrait-on pas tout mettre dans une seule vue ?
Cela éviterait d’avoir à dupliquer les post-it…
On peut noter que le temps y est représenté différemment :
Le schéma est facile est 3 colonnes. L’incertitude cumulée sur 6-7 sprints (ex. release de 3 mois avec des sprints de 2 semaines) risque d’être très forte.
Pour éviter qu'une prévision soit prise pour un engagement, il vaut mieux montrer qu'il y a des incertitudes dans le plan
Un plan de release est souvent présenté en colonnes, comme on peut le voir dans ce schéma.
Le problème avec cette représentation, c’est qu’on ne voit pas l’incertitude. Et il y en a forcément. Qu’on ait fait des estimations ou pas, la prévision comporte une marge d’incertitude.
Une solution pour la montrer pourrait être de publier 2 plans : un optimiste et un pessimiste. Pas terrible : il faut regarder à deux endroits pour comprendre.
