Scrum - Méthodes agiles

Comment gérer un sprint avec IceScrum

Lire la suite -->

Comment démarrer avec IceScrum

Lire la suite -->

Emmanuel Chenu a publié des illustrations sur les principales pratiques de Scrum et de l'Agilité. Les dessins sont en anglais et les commentaires qui les accompagnent sont en français.
C'est sympa, mais pourquoi sont-ils tous chauves ? Dans un genre différent, j'utilise maintenant les icônes de IceScrum pour illustrer les rôles Scrum dans mes formations et mes présentations :

Vous avez reconnu les différents rôles ?

La nouvelle version d'IceScrum est disponible au téléchargement, en war ou en bundle.

IceScrum, le projet pour un outil Scrum libre et gratuit. Le Touilleur Express en parle et l'Expresso sans sucre y apporte même ses compétences.

Avec cette nouvelle version, l'outil parle aussi en anglais. L'utilisabilité a été grandement améliorée, notamment pour la gestion des tâches d'un sprint.

C'était vendredi la fin de la release 2 pour IceScrum2.

Lire la suite -->

Le succès d'un projet repose largement sur les personnes qui y participent et sur la façon dont elles travaillent ensemble. Cela est bien connu mais pas toujours appliqué dans nos organisations hiérarchiques. Les méthodes agiles cherchent à favoriser absolument cette idée de collectif, à travers, notamment, les réunions et les travaux en groupe. Comment savoir si ça fonctionne ? Evaluez votre niveau...

Lire la suite -->

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 ?

Cette semaine, j'avais 2 revues de sprint

Lire la suite -->

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é.

Passent les jours et les semaines, les réunions sont les mêmes

Lire la suite -->

Impediment backlog

Lire la suite -->

Frog and backlog

Lire la suite -->