Des sprints pour une release

Chapitre 2

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.

Je commence par le chapitre 2 : Des sprints pour une release. Je viens de le relire, c'est d'ailleurs la première fois que je me relis depuis octobre de l'année dernière, pour le bon à tirer. Parmi les retours que j'ai reçus de mes lecteurs, je ne crois pas en avoir qui portent en particulier sur ce chapitre.

Voici le plan de ce chapitre :

L’APPROCHE ITÉRATIVE ET INCRÉMENTALE

  • Incrément et itération
  • Bloc de temps
  • Durée du sprint

CYCLE DE DÉVELOPPEMENT SCRUM

  • L’aspect temporel
  • Activités et cycle de développement
  • Le résultat d’un sprint
  • Le résultat d'une release

GUIDES POUR LES SPRINTS ET RELEASES

  • Démarrer le premier sprint au bon moment
  • Produire des micro-incréments
  • Enchaîner les sprints
  • Utiliser le produit partiel
  • Savoir finir la release

Ce chapitre parle donc de cycle de vie pour développer un produit. Voici les quelques idées que j'ai pour l'améliorer dans la seconde édition.

Je pourrais montrer un niveau supplémentaire dans la vie du produit. Je dis qu'une release est constituée de sprints; je pourrais aborder l'enchaînement de releases, ce qu'on voit généralement dans une roadmap de produit.

Dans l'autre sens, montrer davantage l'intérieur d'un sprint, éventuellement aborder le pomodoro.

Ce chapitre, orienté processus, montre la différence entre un processus basé sur des activités de développement séquentielles et une approche agile. Je pourrais montrer comment les 2 se combinent, mais à la réflexion, cela serait prématuré au début du livre, je réserve cela pour le chapitre 18, Transition à Scrum.

Comme le Kanban est une pratique qui prend de l'importance, je pourrais l'évoquer dans ce chapitre. Cela permettrait de mettre en évidence la possibilité d'avoir des rythmes différents pour la planification, la livraison (et le déploiement) et l'amélioration de processus. Bien que Scrum soit orienté développement de produit, je pourrais aborder son usage pour des services, à travers la notion de flux continu.

La notion de timebox pourrait être approfondie avec des guides pour donner des pistes dans des situations rencontrées sur le terrain : équipes à effectif non stable, période de vacances...

Je parle souvent de la période de temps au début de la release avant de commencer le premier sprint. Je me refuse à l'appeler sprint zéro, mais il serait tout de même plus clair de lui donner un nom.

Évidemment j'en profiterai pour remettre à jour le paragraphe sur la durée des sprints avec mon sondage 2010.

Si vous avez d'autres idées, votre feedback est le bienvenu.

Billets en rapport :

Commentaires

1. Le mardi 27 juillet 2010, 15:41 par David

Pour sprint 0 je conseille "Phase exploratoire", comme XP
C'est ce que j'ai trouvé de plus clair comme description

Mon avis est que ce n'est pas une bonne idée. Une équipe fait aussi de l'exploration pendant les sprints, par exemple un spike consiste généralement à explorer des solutions.
Quitte à prendre un terme déjà utilisé je préférerai inception (dans le RUP). En plus c'est un mot d'actualité en ce moment.
2. Le mercredi 28 juillet 2010, 02:07 par Fabrice Aimetti

Et pourquoi pas "Phase de lancement" qui correspond au démarrage du projet ?

Bonne idée.
3. Le mercredi 28 juillet 2010, 07:54 par Sébastien Bonnefoy

Je n'ai pas encore lu ton livre, pour l'instant il circule au bureau, mais j'ai pu le feuilleuter et il me semble qu'il n'y a pas grand chose sur les scrums de scrums et le développement de gros projets. C'est la partie du process que j'ai du mal à visualiser.

Effectivement, c'est une partie qui peut être plus développée. Sur le sujet, voir le dernier billet de Schwaber.
4. Le jeudi 12 août 2010, 15:37 par François Michas

Bonjour Claude,
On a le droit a un upgrade a moindre prix si on a acheté la 1ère version ?

pas sûr, faudra négocier avec le libraire.

Sinon ... Comment estime-t-on la charge du sprint 0 ?

il n'y a pas de sprint 0... estimer pour faire un plan de release avant le début du sprint 1, c'est déjà bien...

Merci encore pour ce blog précieux par sa richesse d'expérience