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.
Mot-clé - release
Plan de release, ou pas
20 samedi août 2011 08:14
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.
La planification de release nécessite de mesurer la vélocité et d'en déduire la capacité prévue.
Un plan de release produit avec iceScrum.
Adaptation et anticipation, c'est un vieux débat, qui continue, comme le montre ce billet de Rebecca Wirfs Brock.
Il y a des situations où on peut se passer de la planification de release. Je donne des exemples dans les pratiques de ScrumBan.
Rétrospective de mars 2007
17 jeudi mars 2011 09:28
Ce matin, je me suis dit que ce serait bien de publier un billet aujourd'hui.
Idée de nouveau chapitre
07 dimanche novembre 2010 22:36
L'agilité au-delà du projet, pour des programmes et des lignes de produit.
Séminaire "L'agilité : du projet au programme et à la ligne de produits"
28 jeudi octobre 2010 14:53
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
Extraits en ligne
23 mardi mars 2010 09:24
Mon livre sur Scrum est sorti depuis le 10 février. L'éditeur est content. Moi aussi.
Sondage sur la fin de release
21 mercredi octobre 2009 06:52
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 fin d'une release
04 vendredi septembre 2009 00:06
Une release est une séquence de sprints, mais quand finit-elle ?
Cycle de vie avec Scrum
14 dimanche juin 2009 23:04
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.
Après le début de la release et avant le début du premier sprint de cette release, il y a une période de temps de durée variable, parfois appelée improprement sprint zéro.
Un exemple de cycle de vie, avec une représentation temporelle de type "timeline" :
Cette timeline a été faite en mars, pendant le sprint 2 de la release de printemps. Le sprint 1 était fini, et les sprints 3 et 4 prévus dans cette release dont la fin était prévue au 30 avril. La release d'été commençait alors et devait se finir le 30 juin.
Une timeline montre toute la vie du produit. Avant la date du jour, c'est l'historique. Après, cela constitue, en ajoutant le contenu prévu pour les futures releases, la roadmap du produit.
Plan de release en couleurs
30 jeudi avril 2009 00:00
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 :
La release apparaît dans le bandeau supérieur, avec ses attributs. En dessous, les sprints sont présentés de façon séquentielle de gauche à droite, avec pour chacun son numéro, son but, sa vélocité prévue et ses dates de début et fin.
Les éléments du backlog planifiés (associés aux sprints) sont estimés en points. Le type d'élément (user story, story technique ou défaut) est montré par les icônes en haut à gauche des postits. La couleur du cadre du bas reprend celle de la feature associée à l'élément.
Ma présentation de vendredi au SigmaT8
14 dimanche décembre 2008 23:58
Plein de têtes nouvelles au séminaire de vendredi parmi la cinquantaine de personnes présentes.
Ma présentation sur le plan de release (et le planning poker et la vélocité) est accessible sur le site SigmaT ou ici en fichier attaché.
La présentation a été filmée par Olivier, mais le son n'est vraiment pas bon. Comme Vincent a enregistré sur son dictaphone avec une meilleure qualité de son, on va voir s'il y a moyen de mixer les deux.
Estimation en points et planification de release
08 lundi décembre 2008 08:00
C'est le sujet de ma présentation de vendredi au SigmaT8.
Programme du SigmaT8
25 mardi novembre 2008 20:52
Après le succès de l'Agile Tour du 16 octobre, nous reprenons les séminaires trimestriels à Toulouse. En attendant de nouvelles formules pour 2009.
Donc le prochain SigmaT, le 8ème en 2 ans, aura lieu le 12 décembre. Un programme varié, avec un retour d'expérience, de la modélisation agile et un sujet que je présenterai sur la planification de release.
Le 16 octobre nous avions distribué aux premiers inscrits des cartes de planning poker. Il nous en reste encore quelques-uns à donner le 12 décembre. Or nous n'avions pas expliqué quelle utilisation en faire lors de la conférence. L'objectif de ma présentation est de réparer cet oubli. Au-delà du simple exercice de planning poker, je présenterai, à partir de mes expériences sur les projets :
- l'estimation en points
- la mesure de la vélocité de l'équipe et son utilisation
- la planification à moyen terme, selon le type de release
Tout le détail du programme et les inscriptions sur www.sigmat.fr
Adaptation et anticipation
05 mardi août 2008 23:17
L'agilité favorise l'adaptation mais n'interdit pas un peu d'anticipation
Planning de release
09 mercredi juillet 2008 23:44
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.
Ponts en mai, appentis en juin
15 jeudi mai 2008 07:16
Mi avril, je m'étais mis d'accord avec un charpentier pour la construction d'un appentis. Il s'était engagé à faire les travaux en mai. Je l'appelle hier, il me dit : vous comprenez, avec tous ces ponts, on a pris du retard, je ne pourrai venir chez vous qu'en juin
. Ce que je comprends surtout c'est que le 17 avril, il n'avait pas pensé qu'il y aurait des ponts en mai pour ses prévisions de travaux. Après tout, les artisans ne sont pas formés à la gestion de projet.
Il arrive aussi que des étudiants, sensibilisés eux à la gestion de projet, utilisent ce genre d'argument -faire passer une situation prévisible pour une vicissitude imprévue- pour tenter de justifier un manque de résultat. Par exemple, à la fin d'un sprint j'ai quelquefois entendu qu'à cause du projet temps réel l'équipe n'avait pas pu consacrer autant de temps qu'elle aurait souhaité sur mon projet. Je ne suis pas dupe, le responsable du projet temps réel a dû entendre la même chose.
Agile ou pas, la planification agile doit tenir compte des événements connus à l'avance, comme les ponts en mai. Pour Scrum cela peut influencer la durée du sprint. Par exemple, une équipe de 5 personnes qui fait habituellement des sprints de 3 semaines dispose de 5 fois 5 fois 3 soit 75 jours de ressources. Elle commence un nouveau sprint le 28 avril et les membres de l'équipe font les ponts de mai. Pour avoir en gros les mêmes ressources que pour les autres sprints[1], il est logique de passer la durée de ce sprint à 4 semaines. Cela devrait être anticipé dans le planning de la release.
Notes
[1] ce qui rend la mesure de la vélocité plus pertinente
Mesures agiles
11 lundi février 2008 19:45
La mesure la plus connue dans les méthodes agiles est probablement la vélocité. Mais il y a d'autres mesures simples à faire lors d'un développement agile permettant d'obtenir des indicateurs et des courbes (burndown charts, courbes diverses).
Au cours de chaque sprint, on peut mesurer :
- tous les jours, le nombre d'heures restant à faire, ce qui permet de produire le burndown chart de sprint qu'on peut analyser selon sa forme
A la fin d'un sprint :
- le nombre de builds produits pendant le sprint, ce qui permet de savoir si des versions ont été produites, notamment pour les tests
- le nombre de problèmes restant à résoudre, ce qui permet de se faire une idée de leur variation au cours du projet
- la vélocité donc, ce qui permet de calculer la vélocité moyenne qui sert à planifier
- le nombre de points restant à faire d'ici la fin de la release, ce qui permet d'obtenir le burndown chart de release
- le nombre de user stories faites pendant le sprint, le nombre de stories restant dans le backlog et le nombre de stories à estimer ce qui permet d'obtenir des indications même s'il n'y a pas d'estimation en points
- le nombre de points des stories dans les différents états, pour produire les burnups et les courbes de croissance
- le nombre de cas de tests écrits, le nombre de cas de tests passés ce qui permet d'obtenir un Big visible chart
Bientôt tout ça disponible dans IceScrum ?
« billets précédents - page 1 de 2
