Aide visuelle pour les Scrums

La réunion qui a donné son nom à Scrum est plus efficace si l'équipe dispose d'une aide visuelle comme le tableau des tâches

L'objectif de la mêlée quotidienne[1] ou scrum est de :

  • Evaluer l'avancement du travail
  • Identifier les obstacles nuisant à la progression
  • Garder l'équipe concentrée sur l'objectif du sprint
  • Améliorer l'esprit d'équipe
  • Permettre une communication objective sur l'avancement

D'un autre côté Scrum donne un cadre pour l'organisation de ces réunions :

  • durée limitée à 15 minutes
  • tout le monde debout
  • 3 questions posées à chaque membre de l'équipe :
    • Qu’as-tu fait depuis la dernière fois?
    • Que prévois-tu de faire jusqu'à la prochaine réunion ?
    • Qu'est-ce qui pourrait empêcher d'y arriver ?

Pour arriver aux objectifs dans ce cadre plutôt strict, il est souhaitable de disposer d'une aide visuelle. Cet article, Stand-up Meetings and Visual Aids, fait un tour d'horizon des techniques qu'on peut utiliser. Il est écrit par un vendeur d'outil, on comprend qu'il mette en avant la projection[2] de visuels à partir d'un outil[3].

Comme moi aussi je suis impliqué dans un outil Scrum[4], j'ai essayé d'imposer son utilisation lors de ces réunions. Avec un vidéo-projecteur, je projetais le backlog du sprint, contenant la liste des tâches et mettais éventuellement à jour le reste à faire en direct.

J'ai renoncé à cette pratique qui complique la logistique et dont l'inconvénient principal est qu'une seule personne a les mains sur le clavier. Cela ne contribue pas à renforcer l'autonomie et la motivation de l'équipe.

Maintenant je préfère utiliser des cartes [5] collées au mur. Les tâches sont rangées en 3 colonnes : celles qui ne sont pas commencées, celles en cours et celles terminées. Lorsque c'est le tour d'une personne de répondre aux 3 questions, c'est elle qui va physiquement déplacer une carte dans une nouvelle colonne.

Notes

[1] Scrum daily meeting, Standup meeting pour XP

[2] la barre est placée haut avec un écran de 42"

[3] Version One

[4] IceScrum, logiciel libre

[5] ou des post-it

Commentaires

1. Le lundi 05 février 2007, 12:25 par Matthieu

Bonjour,
A quoi correspondent les différentes couleurs de post-it sur la photo ?

2. Le lundi 05 février 2007, 15:31 par claude aubry

C'est pour identifier des thèmes fonctionnels différents. Une tâche est associée à une fonctionnalité (une histoire d'utilisateur). Ce qui est important lorsqu'on fait l'avancement dans les scrums, c'est de savoir où en est l'avancement d'une histoire, en observant l'avancement sur les tâches liées à cette histoire.

3. Le lundi 05 février 2007, 17:00 par Matthieu

ok, donc si j'ai bien compris :
- le backlog produit est composé de fonctionnalités (histoires utilisateur)
- avant un sprint le directeur de produit choisit lesquelles seront traitées dans le sprint, sur la base des estimations de charge faites par l'équipe scrum et de la durée définie pour les sprints
- lors de la réunion de planification du sprint réunissant tout le monde, on décompose chaque fonctionnalité inclue dans le sprint en une série de tâches courtes (moins de 20h)
- chacune de ces tâches est un élément du backlog de sprint
- durant cette même réunion, l'équipe scrum se répartit les tâches de manière autonome; je suppose que sur chacun des post-it il y a le nom d'une personne de l'équipe; certaines tâches pourront être affectées plus tard
- il faut peut-être gérer des dépendances et des priorités entre les tâches (?)
- la mêlée quotidienne permet de suivre l'avancement de chacune des tâches et de ré-estimer le reste à faire
- une fois que toutes les tâches associées à une fonctionnalité sont terminées (dev+TU), celle-ci est prête à subir les tests d'acceptation; c'est là que les post-it de couleurs différentes sont intéressants

est-ce que c'est bien ça ?


4. Le lundi 05 février 2007, 20:41 par claude aubry

Oui c'est ça. C'est simple finalement !

Juste une précision pour les points 2 et 3, je dirais plutôt :

- avant un sprint le directeur de produit définit l'ordre dans lequel elles seront proposées pour le prochain sprint/p>

- lors de la réunion de planification du sprint réunissant tout le monde, on sélectionne les histoires qui seront traitées dans le sprint sur la base de la capacité de l'équipe et on décompose chaque histoire inclue dans le sprint en une série de tâches courtes (moins de 20h)

5. Le lundi 05 février 2007, 21:27 par Matthieu

Compliquons un peu les choses alors... ;o)

Je vois 2 choses qui ne me paraissent pas évidentes :

1) Définir la "capacité" d'un sprint
Tout d'abord je pense qu'il faut déterminer une vélocité de référence, à partir du sprint précédent, pour avoir le rapport entre les points et les jh car il va falloir jongler un peu avec ça.
J'ai lu dans un autre billet que la taille des sprints devait être fixe, mais qu'on pouvait choisir de l'exprimer en délai (ex: 4 semaines) ou en capacité de production (ex: n jh ou n points)
Si on choisit la première solution, il faut recenser le nombre de jh dont on dispose sur cette période en tenant compte des jours fériés, des congés, des entrées/sorties de personnes dans l'équipe, et convertir ce nombre de jh en points pour avoir la capacité de production du sprint.
Si on choisit la 2e solution, il faut là aussi faire une conversion jh/points et recenser le temps de présence de chacun pour déterminer la date de fin du sprint.

2) la correspondante en termes de charge entre l'estimation d'une histoire utilisateur et la somme des estimations des tâches qui la composent.
Si j'ai bien suivi, les histoires d'utilisateur sont des descriptions assez succinctes et elles sont estimées rapidement, en quelques minutes.
Il y a donc peu de chances qu'au moment de la décomposition en tâches et de l'estimation de celles-ci on tombe pile sur la même charge.
Comme ce découpage en tâches se fait en début de sprint je suppose qu'à ce moment il est encore temps d'ajuster le contenu du sprint.


En écrivant tout ça il me vient une autre question : que fait-on si on a terminé le sprint plus tôt que prévu ?
Comme on se base sur la vélocité du sprint précédent, et qu'il me parait raisonnable de penser que la vélocité s'améliore au fil du temps, on n'est pas à l'abri de finir en avance... ;o)
Que fait-on dans ce cas ? on commence plus tôt le sprint suivant ? on meuble avec des choses qui ne sont pas dans la backlog ? on prend des vacances ?

6. Le lundi 05 février 2007, 21:52 par claude aubry

C'est bien plus simple : c'est l'équipe elle-même qui détermine sa capacité à faire. Les éléments du backlog sont sélectionnés dans l'ordre un par un et quand l'équipe estime que la barque est suffisamment pleine, elle dit stop.

Les estimations du backlog de produit sont faites en points et celles du backlog de sprint en heures, il ne faut pas les corréler. J'en parle dans d'autres billets.

Un sprint a une durée fixée qui n'est pas modifiée, ni en cas de retard ni si on est en avance. Si on a fini toutes les tâches du backlog de sprint, on demande au directeur de produit un nouvel élément du backlog de produit. Pour les vacances, il faut attendre que le backlog de produit soit vide, ce qui n'arrive pas tous les jours...

7. Le mardi 06 février 2007, 10:33 par Matthieu

Si les estimations ne servent qu'à aider le directeur de produit à prioriser en lui indiquant le coût de chaque histoire relativement aux autres, il n'y a en effet pas besoin de les corréler avec les estimations en heures des tâches du backlog de sprint.
Mais il me semble que ces points servent aussi à planifier la release... pour cela il faut bien estimer à l'avance combien de points on peut mettre dans chaque sprint non ?

Une autre réflexion me vient au sujet des estimations.
Sur les projets traditionnels l'estimation des charges est généralement un motif de friction entre le client qui trouve que c'est trop cher, et l'équipe de dév qui a tendance à prendre du mou pour absorber les imprévus (difficultés techniques ou mauvaise compréhension fonctionnelle) et qui a du mal à expliquer ses chiffrages, même si finalement ils s'avèrent justes.
J'ai l'impression que les séances d'estimation collectives en présence du directeur de produit sont un bon moyen de désamorcer ce genre de problème :
- le directeur de produit assiste aux délibérations et comprend mieux comment ont été élaborés les estimations, quels sont les choses qui coûtent cher dans ce qu'il a demandé
- il a l'occasion de rechercher avec l'équipe une façon moins coûteuse de répondre à son besoin
- l'équipe peut facilement demander des précisions sur l'histoire utilisateur, mieux la comprendre, lever des incertitudes, et donc l'estimer de manière plus juste

Est-ce que je me fais des idées ou bien ça se passe vraiment comme ça ?
Le directeur de produit n'a-t-il pas la tentation de pousser l'équipe à charger plus la barque ou à faire des concessions au niveau technique ? (solution bricolage plutôt que refactoraing propre par exemple)

8. Le mardi 06 février 2007, 11:40 par Camille Bloch

N'ayant pas de référence personnelle sur le sujet, je ne ferais que m'appuyer sur ce que j'ai lut des méthodes agiles (Scrum et XP principalement).

Pour que les méthodes agiles marchent bien, il faut que le "product owner", (ou "customer") soit intégré à l'équipe de développement. Cela implique qu'il soit en accord avec la démarche agile et qu'il se "prète au jeu".

Si il commence à vouloir faire du bricolage plustôt que du refactoring, en effet, le projet va droit dans le mur...

c'est le risque