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.
Incertitudes et planification par vagues

Incertitudes et planification par vagues

Ç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. Avoir un plan de release comme ça, avec les incertitudes dans les prévisions, 3 sprints avant la fin de la release, c’est déjà pas mal.
Bac d'affinage et plan de release

Bac d'affinage et plan de release

Plan de release ou pas ?

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. Le résumé en fin de chapitre Une caractéristique importante des méthodes agiles est leur capacité à prendre en compte les changements.
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.
Plan de release, ou pas

Plan de release, ou pas

À vous de voir

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. Sirius consiste en des bibliothèques Java sur la base de OREKIT et Commons Math.

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]:

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

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. Je commence par le chapitre 2 : Des sprints pour une release.