Planning de release

Un plan de release permet d'avoir la connaissance actualisée de ce qui va être fourni au long des sprints de la release. C'est une projection du backlog sur les sprints qui constituent la release.

Je viens de mener, cette semaine et la semaine dernière, 2 sessions de planification de release, pour 2 projets différents. La planification de release faite la semaine dernière a été effectuée alors que l'équipe avait déjà déroulé 5 sprints. Celle de cette semaine s'est faite pendant le sprint 0. Dans les 2 cas nous y avons consacré environ 2 jours avec des ateliers intensifs.

Ce n'est pas le travail de planification proprement dit qui est long, c'est la collecte de tous les éléments nécessaires.

En effet, il faut disposer des ingrédients suivants:

  • L'objectif de la release et sa date de fin.
  • Le backlog contenant la liste de tout ce qu'il y a à faire pour cette release. Cela donne entre 50 et 100 éléments dans le backlog et c'est un gros travail pour y arriver. La subtilité est que tout n'est pas décomposé au même niveau : on a besoin d'avoir une décomposition très fine, en petites user stories, uniquement pour ce qui sera fait dans les prochains sprints. Pour le reste la décomposition s'arrête lorsque l'estimation de l'élément est possible. Cela donne un backlog avec les petites histoires devant et les grandes qui attendent leur tour dans le fond.
  • L'estimation (en points) de chaque élément du backlog.
  • La durée des sprints (constante).
  • La capacité obtenue à partir de la vélocité mesurée si l'équipe a déjà fait quelques sprints, estimée si l'équipe n'a pas d'expérience de travail en commun.

Généralement, l'atelier de collecte des stories est suivi d'un atelier pour définir les priorités puis d'une séance de planning poker pour estimer.
Cette semaine, nous avons estimé chaque story dès qu'elle était identifiée. Nous avions fait une ébauche des priorités au début sur les thèmes fonctionnels et nous sommes revenus dessus en détail (pour les 3 prochains sprints) à la fin.

Planifier une release pour la première fois, c'est beaucoup d'efforts, mais c'est essentiel pour partir sur de bonnes bases dans un développement agile.

Commentaires

1. Le jeudi 10 juillet 2008, 20:31 par Olivier

Billet synthétique comme j'aime.

Petite question d'un béotien mais qui en veut : un sprint correspond-t-il à une fourniture d'une version mise en exploitation (et donc accessible par des utilisateurs) ?

Merci !

2. Le samedi 12 juillet 2008, 15:03 par claude aubry

Merci Olivier. J'ai fait un billet sur l'utilisation de la version de fin de sprint, c'était il y a déjà longtemps : voilà, c'est là.

Je pense que ça répond à ta question.