Scrum - Méthodes agiles

La pratique usuelle de suivi des tâches dans un sprint consiste à mettre à jour quotidiennement le reste à faire et à produire un burndown chart de sprint. Une autre pratique répandue est de suivre l'avancement avec un tableau des tâches avec 3 colonnes (ou 3 lignes).

La première pratique se préoccupe de la valeur estimée en heures du temps restant pour finir la tâche. La seconde est basée sur les états de la tâches. Une tâche du sprint est dans un de ces 3 états :

• à faire
• en cours
• finie

Ces 2 pratiques ne sont pas exclusives : on peut utiliser un tableau des tâches tout en estimant le reste à faire et en produisant un burndown chart^[1]. Mais je pense qu'avec un bon suivi sur le tableau des tâches on peut se passer de l'estimation du reste à faire.

Pour un développeur est-il plus facile d'estimer qu'il reste 6h sur une tâche que de dire qu'elle est en cours et qu'elle sera finie demain ?

Mon expérience avec de nombreuses équipes me pousse à privilégier le suivi par les états plutôt que par les valeurs en heures. J'ai constaté que pour les membres de l'équipe c'est beaucoup plus facile à vivre. Certains sont tourmentés quand on leur demande avec insistance le reste à faire. Ce n'est pas le cas quand il s'agit simplement de donner l'état de la tâche.

En se passant du reste à faire, on évite de perdre du temps à y réfléchir. Mais peut-on assurer un bon suivi ? Cela dépend des équipes et de l'expérience du ScrumMaster. Un bon ScrumMaster va savoir déceler un problème quand une tâche reste en cours plusieurs jours sans se terminer, par exemple.

C'est un choix à faire par l'équipe, par exemple lors d'une rétrospective, pour aller encore plus loin, que dans relever les heures, c'est mal, à la chasse au gaspillage .

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

Suite du débat...

Mon point de vue : trouver de l'intérêt dans le comptage des heures, c'est probablement le symptôme d'une mauvaise application de Scrum.

Lire la suite -->

Le temps qui passe ne se rattrape pas

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.

Vertical ou horizontal ?

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 ?

Savoir analyser un burndown chart de sprint

Lire la suite -->

Et en français !

Lire la suite -->

Pour bien démarrer un sprint, une réunion pour définir son périmètre fonctionnel, faire sa planification et aussi un peu de conception.

Lire la suite -->

C'est l'outil de Scrum qui permet de montrer l'avancement d'une release.

Lire la suite -->

... n'est pas réservé qu'aux étudiants.

Lire la suite -->