Comme Scrum, les séries télé sont devenues extrêmement populaires. Les créateurs d’une série, après avoir testé l’intérêt de leur idée dans un pilote, préparent une première saison avec quelques épisodes. Si la saison est bien reçue, il y en aura d’autres, puis d’autres encore tant que l’intérêt du public se maintient.
Cette analogie d’un sprint avec un épisode m’a frappé, c’est pourquoi je vais reprendre le terme saison pour nommer une séquence de quelques sprints.
Dans le glossaire de mon livre Scrum, édition 4, je définissais une release ainsi :
Release : période de temps constituée d’une série de sprints aboutissant généralement à déployer une version du produit.
Depuis l’édition 5 de Scrum, j’ai substitué l’emploi de release par celui de saison. La suite de cet article a été modifiée dans ce sens.
Pourquoi prévoir à un horizon plus lointain que le sprint ?
Dans l’édition 4 de mon livre Scrum, la présentation de la planification de release a été repoussée. Planifier la release constitue maintenant le chapitre 16. Dans les éditions précédentes, elle était présentée avant la planification de sprint. Cette décision de déplacer ce sujet m’a demandé beaucoup d’efforts, d’autant plus que j’en ai profité pour revoir une grande partie du contenu de l’édition 3, en intégrant des notions nouvelles inspirées du courant #noEstimates.
Ça va être plus roll que rock, le rolling wave planning
Suite à mon billet d’hier sur Plan de release et incertitudes, j’ai reçu un commentaire qui m’amène plusieurs réflexions.
Mon lecteur commence à parler du schéma :
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.
Dans une situation où il est nécessaire d’avoir un plan à moyen terme voilà comment se servir du bac d’affinage. Ce plan que j’appelais plan de release (release plan) je le nomme maintenant plan de saison.
Dans la série Suppléments en ligne, voici ceux du chapitre La planification de release
C’est dans ce chapitre qu’est abordé le sujet toujours délicat de l’estimation des stories en points. C’est aussi là que je présente la notion de vélocité et qu’on voit pour la première fois un burndown chart.
La planification de release est optionnelle dans Scrum. On n’en a pas toujours besoin. Cependant la plupart des équipes que je connais souhaitent en disposer, ce qui demande des efforts.
Pour arriver au plus petit ensemble ayant de la valeur pour un client
Quand on démarre le développement d’un nouveau produit, une étape significative est d’élaborer une liste de features, de les prioriser puis d’identifier les stories des features les plus prioritaires.
Ensuite le développement se planifie sur les sprints et les releases. Dans le billet Features et stories, avec un schéma carré, j’expliquais : “Une story est planifiée dans un sprint et une feature dans une release.”
J’y montrais aussi le cycle de vie d’une feature, qui est finie une fois qu’elle est livrée.
La nouvelle édition du guide Scrum présente la planification de release comme une pratique en dehors de Scrum :
La planification de release est intéressante lorsqu’on pratique Scrum, mais n’est pas exigée par Scrum lui-même.
C’est une évolution car dans la version précédente, même si ce n’était pas toujours bien cohérent, la planification de release était présentée comme une pratique Scrum.
Faire un plan de release, c’est effectivement souvent utile, notamment quand on a besoin de se synchroniser avec d’autres équipes ou d’autres services de l’organisation.
En tant que consultant, j’ai la chance de travailler dans des domaines variés. Après avoir accompagné Sarenza.com dans sa transition radicale et à grande échelle à Scrum[1], j’interviens sur le projet Sirius du CNES avec Thalès.
Il s’agit de développer le patrimoine de base de la dynamique du vol, sur lequel viendront se construire les futurs outils opérationnels pour les mises à poste et maintien à poste de satellites. Sirius consiste en des bibliothèques Java sur la base de OREKIT et Commons Math.
IBM Toulouse organise le 10 Novembre prochain, sur le site de la Plaine, un séminaire sur l’agilité au-delà du projet, pour des produits qui évoluent longtemps, font partie de programmes ou d’une famille de produits ou sont inclus dans un portefeuille de produits
J’aurai le plaisir de faire la présentation sur ce sujet et je dispose d’une bonne partie de la matinée.
Les premiers inscrits recevront un exemplaire de mon livre « SCRUM : le guide pratique de la méthode agile la plus populaire » publié aux Éditions DUNOD, qui leur sera remis le jour du séminaire.
Ce chapitre deux parle de cycle de vie pour développer un produit
Mon éditeur (Dunod) m’a demandé de commencer à réfléchir à une deuxième édition de Scrum, le guide pratique de la méthode agile la plus populaire. Oh, on a le temps, c’est pour une publication au printemps en automne 2011.
Une 2ème édition peut inclure un éventuel nouveau chapitre, mais le plus usuel est d’améliorer et d’ajouter des paragraphes à ceux existant.
J’allais oublier de publier les résultats du dernier sondage, sur la fin de release, qui a récolté plus de 100 réponses.
La question était :
Quand finissez-vous la release ?
La release à date fixée arrive en tête, c’est aussi la pratique la plus facile à appliquer. La fin de release définie sur la valeur obtient un bon quart, je serais curieux de savoir comment le “assez de valeur” (c’était avant que je dise utilité) est évalué.
La vie d’un produit développé en appliquant Scrum est faite d’une séquence de releases. En général, une release dure quelques mois (entre 2 et 8 mois). Quand on a fini une release, on passe à la suivante, jusqu’à la fin de vie du produit. Normalement, les releases se suivent, mais ne chevauchent pas.
Une release est constituée d’une séquence de sprints. Un sprint dure entre une semaine et 4 semaines. Quand un sprint est fini, le suivant commence. En principe, il n’y a pas de trou entre 2 sprints et les sprints ne se chevauchent pas.
Un plan de release présente les itérations à venir et le contenu prévu de ces itérations. Ce contenu consiste en des éléments du backlog de produit.
Présenté sous forme de tableau, un plan de release est facile à comprendre. Il constitue un outil de communication important avec tous les intervenants du projet.
Voici un exemple du plan de release du projet IceScrum.
C'est le sujet de ma présentation de vendredi au SigmaT8
Ceux qui ne connaissent pas trop l’agilité pensent parfois, à tort, qu’on ne peut pas planifier sur les projets agiles, parce que ça change tout le temps. Ils ont bien compris que le client pouvait faire des changements. Ils doivent en déduire :
À quoi ça sert de faire des plans s’ils sont remis en question ?
L'agilité favorise l'adaptation mais n'interdit pas un peu d'anticipation
Les méthodes agiles facilitent l’adaptation au changement. Dans les présentations, on oppose souvent ce côté adaptatif de l’agilité à celui, associé aux méthodes traditionnelles basées sur un cycle en V, de faire en sorte de tout prévoir à l’avance. Le prédictif contre l’adaptatif.
Cette vision est trop simpliste. Qu’on utilise une méthode agile ou pas, on a toujours besoin de prévoir. Pour anticiper.
Par rapport à un plan monolithique, les méthodes agiles sont basées sur plusieurs plans à différents niveaux, correspondant aux cycles de vie. La vie d’un produit est constituée de releases successives, chaque release est une suite d’itérations ou sprints.
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.
