Série - Le quiz Scrum

Fil des billets - Fil des commentaires

Quizz, la question 11 sur les storytests

La question était :

Une story présentée en démo fonctionne comme prévu mais on y découvre un cas de test auquel on n’avait pas pensé (les 4 autres passent). Que faire ?

Les 157 réponses se partagent de la façon suivante :

  1. Elle est considérée finie à 80% 0.64 %
  2. On modifie le code vite fait 1.27 %
  3. Elle est considérée comme finie et on ajoute une entrée dans le backlog de produit pour le cas trouvé 76.43 %
  4. Elle n’est pas considérée comme finie 21.66 %

Nous avons donc une story pour laquelle on (le Product Owner avec l'équipe) a identifié 4 storytests pendant le sprint. Il est conseillé qu'au plus tard au milieu du sprint, ils soient connus, pour éviter d'avoir des stories non finies à la fin. Dans notre exemple, la story est présentée à la revue, c'est donc que les tests ont été passés avec succès avant. Le Product Owner a considéré que cette story était finie.

La découverte d'un nouveau cas en revue fait partie du feedback, qui est accueilli favorablement. Mais de mon point de vue -comme celui de plus de 3/4 des répondants- cela ne remet pas en cause la fin de la story. On ajoutera une entrée dans le backlog pour traiter le comportement découvert en revue.

Cela met en évidence que l'ensemble cohérent des 5 storytests correspond à 2 entrées dans le backlog ; dans cet exemple, ce n'est pas voulu au départ, dans d'autres circonstances, c'est le résultat de l'application de techniques de décomposition de stories (quelques unes sont présentées page 177 de mon livre).

Quizz, la question 12 sur l'ingénierie du logiciel

La question était la suivante :

L’application à développer s’appuie sur du code existant dont on sait que la qualité n’est pas exceptionnelle. Que faire ?

184 participants pour ce douzième quizz, avec la répartition suivante :

  1. L’améliorer quand un bug est trouvé qui porte sur ce code existant 41.3 %
  2. Améliorer ce code existant en priorité 9.78 %
  3. Surtout ne pas toucher à ce code 4.35 %
  4. Ajouter des tests pour couvrir tout le code existant 44.57 %

Cette fois il n'y a pas une réponse qui récolte la majorité des suffrages, mais 2, les réponses 1 et 4 qui se détachent largement, presque à égalité.

Écrire des tests pour couvrir tout le code existant peut apparaître comme la solution qui rassure le plus. Cependant cela risque de prendre beaucoup de temps. Il est préférable d'ajouter un test et de faire du refactoring sur les parties où sont trouvés des défauts.

C'est le quizz 13 qui est maintenant en ligne, il porte sur l'usage d'un indicateur.

Quizz, la question 13 sur le burndown chart

La question était la suivante :

Au milieu du sprint, le burndown chart de sprint remonte. Vous êtes ScrumMaster, que faire ?

Les réponses suivantes étaient proposées :

  1. Vous regardez s’il reste du mou
  2. Vous l’envoyez immédiatement au grand chef
  3. Vous le remplacez par un burnup
  4. Vous passez un savon à l’équipe

3.9 % des 154 répondants sont partisans de tancer l'équipe. Ce n'est pas la réaction appropriée d'un ScrumMaster, dont le rôle est décrit dans cet ancien billet de presque 5 ans.

Plus de 5% sont d'avis qu'il faut en référer au chef. Comme la transparence est de mise, ce burndown devrait être visible par tout le monde y compris le grand chef, ce n'est donc pas utile de lui envoyer. De plus le burndown chart de sprint est un indicateur qui sert essentiellement à l'équipe.

Le remplacer par un burnup, choix de 13% des votants, cela semble une astuce du ScrumMaster pour masquer un mauvais indicateur. Comme on dit ce n'est pas en cassant le thermomètre qu'on guérit le malade. Cependant il est vrai que le burnup à 2 courbes est souvent plus parlant qu'un burndown, parce qu'il montre l'évolution du total en plus du reste à faire, comme le montre cet exemple de burnup de sprint en tâches. Et si le burndown remonte, c'est probablement parce que du travail a été ajouté (par exemple une tâche qui n'avait pas été identifiée avant).

C'est donc la réponse 1, plébiscitée par les quizzés, qui est la chose à faire en premier. S'il ne reste pas assez de mou, il faudra revoir les objectifs du sprint en "déscopant" une story.

Pour espérer qu'il en reste, il aura fallu, évidemment, garder du mou lors de la planification du sprint.

Là, je m'attends à une question, qu'on m'a d'ailleurs posée cette semaine au cours de ma formation Scrum de 3 jours :

il est de combien le mou ?

Quizz, réponse à la question 14

La question était :

Vous êtes coach et vous mettez Scrum en place avec une équipe qui a l’habitude de travailler à l’arrache : elle ne connait pas les pratiques d’ingénierie du logiciel. Que faites-vous en premier ?

J'avais cité la méthode à La Rache dans un de mes tous premiers billets. Elle est encore répandue de nos jours, on en avait d'ailleurs parlé à l'Apéro Web sur Scrum à la Cantine en début d'année.

Nombre de votes : 192

Répartition des choix :

  • Lancer tout de suite le premier sprint, l’équipe fera de son mieux : 8.85 %
  • Faire appel à un expert en architecture pour aider l’équipe au début du premier sprint : 7.81 %
  • Former l’équipe à Scrum et mettre en place l’intégration continue avant de lancer le premier sprint : 79.69 %
  • Ajouter des testeurs dans l’équipe : 3.65 %

Près de 4 participants sur 5 font le même choix que moi. Avant de lancer le premier sprint, dans cette période qu'on appelle improprement sprint zéro, il me semble préférable de prendre le temps de bien former l'équipe et d'installer un bon environnement de développement. L'expérience montre que c'est difficile à faire pendant les sprints.

- page 2 de 2