Savoir finir une histoire

Un principe des méthodes agiles est qu'une "user story" doit être complètement finie en une itération. Pas si facile...

Benoît a fait des investigations sur un projet que j'ai initié aux méthodes agiles. Un des constats qu'il fait est que de nombreuses user stories ne sont pas finies en une itération. Quelques unes durent même 5 itérations !
Ce problème est souvent dû à l'accostage développeurs-testeurs. Quand le testeur reçoit le logiciel à tester en toute fin d'itération, au mieux il découvre des erreurs qui ne sont pas corrigées dans l'itération, au pire il diffère ses tests à l'itération suivante.
Cela n'est pas spécifique à cette équipe, comme le montrent des billets récents de Kane Mar et Ed Gibbs.
C'est un dysfonctionnement sérieux auquel il faut s'attaquer.

Pourquoi est-ce un problème ?

  • ce n'est pas satisfaisant pour l'équipe. Elle s'est engagée au début de l'itération à finir une story et le résultat montre que ce n'est pas fini.
  • cela rend la planification plus difficile. Une user story pas finie est comptée à 0 point pour la vélocité alors que du travail a été effectué dessus. Cette décorrélation entre résultat et travail tend à produire un burndown chart en dents de scie, ce qui est perturbant.
  • cela diminue la productivité des développeurs qui doivent se replonger dans le code qui implémente une story qu'ils ont développée dans une itération précédente.

Comment y remédier ?

L'idéal est de faire du TDD et d'utiliser des outils qui automatisent les tests (fonctionnels). En attendant de mettre cela en place, on peut appliquer ce que j'ai fait avec succès sur le projet IceScrum, en tant que propriétaire de produit impliqué dans les tests fonctionnels :

  • définir les tests fonctionnels d'une story au début de l'itération
  • tester dès que le build qui implémente la story est disponible et faire des retours immédiatement (sans passer par l'ouverture officielle d'un bug)

Le testeur doit être impliqué dans la planification de l'itération, s'engager avec le reste de l'équipe et être très réactif pendant l'itération. L'équipe doit aussi être capable de refuser d'inclure une story dans une itération si elle estime qu'elle n'est pas suffisamment définie.

Commentaires

1. Le jeudi 12 octobre 2006, 10:59 par Stéphane

Quand on parle d'équipe multi-disciplinaire, on devrait inclure des testeurs non?

2. Le jeudi 12 octobre 2006, 15:16 par claude aubry

Oui, les testeurs font partie de l'équipe, c'est le premier changement d'organisation qui doit être fait quand on passe à une méthode agile. Ils participent à toutes les réunions d'équipe, ils ont des tâches de test, définies lors de la réunion de planification de l'itération.