La fin d'une release

Une release est une séquence de sprints, mais quand finit-elle ?

Pour décider de l’arrêt des sprints et de la fin d'une release, on a plusieurs solutions :

Finir quand le backlog est vide

Ceux qui sont habitués à développer à partir d’une spécification contenant tout ce qu’il y a à faire seront tentés de dire que la release s’arrêtera quand le backog de produit sera vide. Mais le backlog est vivant et, finalement, il se rapproche d’un flot continu toujours alimenté. Ce n’est donc pas une bonne idée que de vouloir vider le backlog.

J’ai connu une équipe qui a essayé pendant 18 sprints, sans succès !

Une variante est de sélectionner un sous-ensemble du backlog pour la release. Comme les éléments sont rangés par priorité, il suffit de fixer une limite en disant : « on s’arrêtera là pour la release courante, les stories suivantes seront faires dans la release suivante ». C'est ce qu'on appelle une release à périmètre fixé. La planification de la release a pour objectif d'estimer la date de fin.

Attention : même restreint de cette façon, le périmètre peut toujours évoluer, il serait stupide de figer le backlog en refusant un changement qui apporte de la valeur.

Fixer la date à l’avance

Une meilleure façon de procéder est de définir une date de fin de release et de s’y tenir absolument, en reprenant l’idée de la timebox. La planification d’une release à date fixée a pour objectif d’estimer quel contenu sera fourni à la date prévue. La release à date fixée présente de nombreux avantages :

  • elle donne un objectif pas trop lointain, ce qui motive plus l'équipe,
  • elle demande obligatoirement une réflexion poussée sur les priorités des éléments du backlog par le Product Owner,
  • des éléments du backlog apportant le moins de valeur ne seront pas développés,
  • on passe généralement moins de temps à estimer et planifier, puisque la date de livraison est connue.

Un autre avantage est le rythme donné par des releases régulières : une organisation avec des releases régulières s’habituera à cette fréquence, qui cadence le travail de l’équipe mais aussi celui des utilisateurs et de leurs représentants.

La release à date fixée et à durée uniforme, par exemple une release tous les 3 mois, est la formule la plus facile à mettre en œuvre.

Variantes

  • Attendre quelques sprints pour décider. Une fois la décision prise, on se retrouve dans une des deux situations précédentes.
  • Arrêter la release quand le produit partiel a suffisamment de valeur.
  • Arrêter la release quand un certain nombre de points, fixé à l’avance, a été réalisé. C'est la release à points.

Commentaires

1. Le lundi 07 septembre 2009, 17:51 par Fabrice Aimetti

Cette question me rappelle un billet de Guillaume Bodet (Xebia) introduisant la notion économique d'utilité marginale décroissante : "Pourquoi les projets agiles ne peuvent pas (vraiment) être menés au forfait". Cf. http://blog.xebia.fr/2009/02/04/pou...