release

Le rythme des saisons

Le rythme des saisons

Un rite saisonnier

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.

Release, mise en production et déploiement

De l'importance du sens des mots

Découpler les activités de planification à moyen terme (release) de celles pour livrer aux utilisateurs finaux (mise en production) et de celles techniques (déploiement). Dans le glossaire de mon livre Scrum, édition 4, je définis 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. Ailleurs dans le livre, je développe l’idée qu’une release n’est pas à confondre avec une mise en production, notamment dans le chapitre 2 (pages 20 et 21) et aussi dans le chapitre 16, qui s’appelle Planifier la release.

Planifier la release

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.
Glossaire R-S

Glossaire R-S

Dans l’édition 4 de mon livre, j’ai ajouté un glossaire. C’est une des nombreuses nouveautés. Le glossaire donne le sens que je donne pour ces termes que j’emploie dans le livre. Il est situé à la fin, entre le quiz et l’index. Je l’ai voulu assez court (il y a 70 entrées) et avec des définitions brèves. Voici les entrées pour les lettres R et S : Raid Agile : une formation différente qui vous fournit les outils et surtout la culture, la clé pour accélérer votre transformation agile.
Bac d'affinage et plan de release

Bac d'affinage et plan de release

Dans une situation où il est nécessaire d’avoir un plan à moyen terme -un plan de release- voilà comment se servir du bac d’affinage. Plan de release, ou pas, c’est la question. Si la réponse est oui, les bacs facilitent grandement son élaboration et son suivi. Pendant le sprint zéro (ou après), on place dans ce bac tout ce qu’on prévoit de faire pour la date de fin de release. Bien sûr il ne s’agit pas de tout décomposer en stories, donc on se retrouvera aussi avec des epics.
Chapitre six

Chapitre six

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. Structure du chapitre La carte montre le plan de ce chapitre sur la Planification de Release.
Chapitre deux

Chapitre deux

Des sprints pour une release

Ce chapitre aborde le cycle de développement (appelé aussi cycle de vie) d’un produit avec Scrum. En résumé Avec Scrum, un produit est développé selon une approche itérative et incrémentale. Le sprint donne le rythme auquel sont produites des versions partielles potentiellement livrables du produit. La release est la séquence de sprints à l’issue de laquelle le produit est livré aux utilisateurs. Changements dans les éditions successives Ce que j’en disais pour le passage de l’édition 1 à l’édition 2.

Retour sur le quiz 1-5

A la fin de mes formations Scrum de 3 jours, je propose aux participants un questionnaire, sous forme d’un QCM de 70 questions et dans un temps limité. L’objectif, clairement sans prétentions et si possible une pincée d’humour, est de les placer dans des situations qui n’ont pas été abordées pendant la formation -on ne peut pas tout voir, même en 3 jours, de les faire réfléchir à la façon d’y réagir puis, et c’est le plus important, d’en discuter tous ensemble.

Division de feature et de story

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.

Le livre Scrum édition 2, la release note

Un produit sort avec sa release note et nous sommes le 7 septembre, date prévue pour la publication de l’édition 2 de mon livre. Quelques lecteurs de la première édition me demandent ce qu’il y a de changé dans la deuxième. Je ne vais pas détailler la moindre modification en détail, je n’ai pas tracé tout. D’ailleurs je n’aurais pas pu, environ 20% de l’ensemble a été modifié, et rien que dans les échanges avec mon éditeur, qui commencent après l’envoi d’une première version modifiée et qui se sont poursuivis sur 3 itérations, il y a eu plus de 600 changements.
Plan de release, ou pas

Plan de release, ou pas

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.

Des chaussures aux étoiles

Agile dans tous les domaines. 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.

Rétrospective de mars 2007

Ce matin, je me suis dit que ce serait bien de publier un billet aujourd’hui. J’ai plein d’idées mais rien de prêt et pas un sujet qui m’apparaisse comme prioritaire. Alors je sous ressers de vieux billets. Un petit coup dans le rétroviseur. C’est tombé sur ce que je disais il y a 4 ans. Voici un extrait, 3 billets du mois de mars 2007 que je vous ai sélectionnés [1]:

Idée de nouveau chapitre

L’agilité au-delà du projet, pour des programmes et des lignes de produit. En préparant ma présentation du 10 novembre à IBM Toulouse, j’ai relu des articles de Jim Highsmith et de Dean Leffingwell sur la scalabilité[1] de l’agile. Je me suis aussi rappelé que j’ai fait du marketing produit[2]. En confrontant ces idées avec mes expériences récentes, je pense être arrivé à une approche qui tient la route. Je me dis qu’avec tout ça, j’ai peut-être matière à un nouveau chapitre dans mon livre.

Séminaire 'L'agilité : du projet au programme et à la ligne de produits'

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.

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.

Extraits en ligne

Mon livre sur Scrum est sorti depuis le 10 février. L’éditeur est content. Moi aussi. Mon éditeur, Dunod, vient de m’annoncer qu’il y a en a déjà plus de 900 de vendus. Wooooowww ! Parmi les lecteurs de mon blog, il en reste peut-être qui pourraient être intéressés par le livre mais aimeraient lire un extrait avant de se prononcer. Ca tombe bien, Dunod vient de mettre des extraits en ligne sur son site.
Sondage sur la fin de release

Sondage sur la fin de release

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 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é.
Cycle de vie avec Scrum

Cycle de vie avec Scrum

Roadmap avec 2 releases

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.