Des sprints pour une release

Ce chapitre deux parle de cycle de vie pour développer un produit

Écritures

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 :

Lire aussi