Avantages d'une release à date fixée
05 lundi mars 2007 07:38
La technique des blocs de temps a du bon
Pour décider de la livraison d'une release, on a en gros 2 solutions :
- dire que la release sera terminée quand le backlog sera vide. C'est ce qu'on appelle une release à périmètre fixé. La planification de la release permet d'estimer la date de fin.
- définir une date de livraison et s'y tenir absolument. C'est une release à date fixée. Avec une planification de release, on peut estimer quels éléments du backlog devraient être finis à cette date.
On peut aussi décider de prendre une position intermédiaire avec la technique MoSCoW[1] préconisée par DSDM.
La release à date fixée présente de nombreux avantages :
- elle donne un objectif à court terme, ce qui motive plus l'équipe. Une release à périmètre fixé peut durer longtemps : je connais un projet qui en est à sa 18ème itération et le backlog n'est pas encore vide...
- elle demande obligatoirement une réflexion poussée sur les priorités des éléments du backlog par le directeur de produit
- des éléments du backlog apportant peu de valeur ne seront pas développés
- on peut détailler et décomposer les éléments du backlog au dernier moment possible, c'est à dire juste pour l'itération courante
- on passe généralement moins de temps à estimer et planifier, puisque la date de livraison est connue
Notes
[1] Must have, Should have, Could have, Won't Have

Commentaires
Si on attend que le backlog soit vide, cela suppose qu'il n'y a qu'une release donc?
Je pense que Claude parle du backlog de release, qui en fait n'est qu'un sous-ensemble du backlog de produit
En revanche j'ai un peu de mal à voir à quoi correspond le concept de release.
Si chaque sprint est censé produire une version utilisable du produit, qu'est-ce que le sprint qui termine une release a de spécial ?
Est-ce qu'on ne donne le produit aux utilisateurs finaux que lorsqu'on a terminé une release ?
pour moi, une release est en effet une version "livrable" c'est à dire que toutes les fonctionnalitées sont complètes, à l'inverse des version inter itérations.
Dans ce cas, j'ai du mal à concevoir une release à date fixe, car on ne peut pas être sur que tout soit fonctionnel...
Ou alors je me trompe sur la définition d'une release?
Quand on a des impératifs de fonctions à rendre disponible dans une version donnée, la release devra attendre que les fonctions souhaitées soient terminées pour être finalisée non?