Scrum - Méthodes agiles

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.

Lire la suite -->

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.

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 ?

Une release est une série de sprints successifs. C'est une période de temps. Comment et quand déterminer la fin de la série et donc la fin de la release ?

Il y a la façon adaptative : la fin de la release n'est pas fixée, elle est envisagée à la fin de chaque sprint. On parle de release ajustable.

Il y a la façon prédictive : la date de fin de la release est décidée, c'est ce qu'on appelle une release à date fixée. Cela comporte des avantages.

Une release ajustable peut devenir à date fixée pendant son déroulement. A la fin d'un sprint, on décide avec le product owner que le produit est dans un état qui permet dé définir à quelle date on pourra finir la release.

On peut évoquer un troisième type de release, même s'il n'est pas agile, c'est la release à périmètre fixé (dans la pratique, le périmètre n'est jamais fixe). Le périmètre est défini par les éléments du backlog à faire.

A quoi sert de connaître le type de release ? Cela est déjà une information publiée, importante pour l'équipe et à l'extérieur. Cela permet également de faire une planification :

• pour une release à périmètre fixé, l'objectif de la planification est de calculer la date de fin.
• pour une release à date fixée, l'objectif de la planification est de calculer les fonctionnalités (stories) qui seront finies à cette date.

IceScrum permet déjà une planification automatique en associant des éléments du backlog sur les sprints en fonction de la vélocité estimée et du poids en points des éléments. Une nouvelle story d'IceScrum, développée actuellement, est d'améliorer cette planification en prenant en compte les types de release.

Est-ce par télépathie, car cette idée je viens de la présenter chez un client dans le cadre de réflexions sur les forfaits agiles ? Toujours est-il que le développeur de l'équipe en charge de cette story est parti, à son initiative, sur un autre type de release, la release à points (on pourrait dire release à taille fixée). Une release à taille fixée a un objectif défini en nombre de points à faire. A chaque sprint on mesure la vélocité et on diminue le nombre de points restant à faire. La release se termine quand on arrive à 0.

L'idée est intéressante pour les projets au forfait (et pourquoi pas de la TMA) : le contrat porterait sur un nombre de points et le client peut ajuster le contenu et les priorités. Mais cela nécessite d'avoir une équipe stable dont on connait la vélocité.

Une revue qui permet un feedback concret sur le produit (c'est mieux que sur de la documentation).

Lire la suite -->

Ce n'est pas de la science-fiction, mais un workshop pour préparer la planification d'une release.

Lire la suite -->

Le meilleur moyen de savoir si une méthode agile est adaptée à votre contexte : l'essayer

Lire la suite -->

Les titres auxquels vous avez échappé :

• lettre à release
• release tailor

Lire la suite -->

La technique des blocs de temps a du bon

Lire la suite -->

Le backlog est un élément clé dans le processus Scrum. Mais il y a plusieurs backlogs...

Lire la suite -->

A la fin de chaque itération on livre un produit potentiellement livrable. Quel usage en fait-on ? Qu'est ce qui fait la différence avec la fin de release où on livre vraiment le produit ?

Lire la suite -->

La release, du demi-fond.

Lire la suite -->