IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Scrum et XP depuis les Tranchées

Comment nous appliquons Scrum


précédentsommairesuivant

9. Comment nous faisons les démos de sprint

La démo de sprint (ou revue de sprint comme certains l'appellent) est une partie importante de Scrum que les gens ont tendance à sous-estimer.

« Oh devons-nous vraiment faire cette démo ? Il n'y vraiment pas grand-chose d'amusant à montrer ! »
« Nous n'avons pas le temps de préparer une &%$# de démo! »
« Je n'ai pas le temps d'assister aux démos des autres équipes ! »

9-1. Pourquoi nous insistons pour que tous les sprints finissent par une démo

Une démo de sprint bien faite, bien que ça puisse sembler peu marquant, a un effet profond.

  • L'équipe se voit attribuer le mérite pour le travail accompli. Ils se sentent bien.
  • Les autres personnes découvrent ce que l'équipe fait.
  • La démo donne un retour vital de la part des intervenants.
  • Les démos sont (ou devraient) être un évènement social où les différentes équipes peuvent interagir entre elles et discuter de leur travail. Cela a de la valeur.
  • Faire une démo force l'équipe à terminer leur travail et à le livrer (même si c'est seulement pour environnement de test). Sans démo, nous garderions une énorme pile de choses terminée à 99%. Avec les démos nous avons peut-être moins d'éléments terminés, mais ils sont réellement terminés, ce qui est (dans notre cas) une bien meilleure chose que d'avoir une pile entière de tâches qui sont à peu près terminés et qui pollueront le prochain sprint.

Si l'équipe est plus ou moins obligée de faire une démo, si elle n'a pas quelque chose qui fonctionne vraiment, la démo sera embarrassante.
L'équipe bégaiera et hésitera pendant la démo et les applaudissements ne seront qu'à moitié sincères. Les gens se sentiront désolés pour l'équipe, et seront peut-être irrité d'avoir gâché du temps pour assister à une démo aussi nulle.

Ca blesse. Mais l'effet est comme une médecine amère. Le prochain sprint, l'équipe essaiera d'avoir des choses vraiment terminées ! Ils se diront que « bien, peut-être nous ne pouvons montrer que 2 choses au prochain sprint au lieu de 5, mais merde cette fois ça MARCHERA ! ». L'équipe sait qu'elle aura à faire une démo, peu importe quoi, ce qui augmente les chances qu'il y ait quelque chose d'utile à montrer. J'ai vu arriver cela plusieurs fois.

Checklist pour les démos de sprint

  • Assurez-vous de présenter clairement l'objectif du sprint. S'il y a des personnes à la démo qui ne connaissent pas du tout votre produit, prenez quelques minutes pour le présenter.
  • Ne dépensez pas trop de temps à préparer la démo, surtout pas pour une démo tape-à-l'oeil. Ignorez ce qui ne marche pas et concentrez vous sur la démonstration du code qui marche.
  • Gardez un rythme élevé, autrement dit essayez de préparer une démo rythmée plutôt qu'une jolie démo.
  • Gardez la démo à un niveau métier, oubliez les détails techniques. Concentrez-vous sur « ce que nous avons fait » plutôt que sur « comment nous l'avons fait ».
  • Si possible, laissez l'audience essayer elle-même le produit.
  • Ne montrez pas les tas de corrections de bugs mineurs et de fonctionnalités insignifiantes. Mentionnez-les mais ne les montrez pas, car ça prend trop de temps et ça écarte l'attention des histoires plus importantes.

9-2. S'occuper des choses « indémontrables »

  • Un membre de l'équipe : « Je ne vais pas présenter cet élément, parce que ce n'est pas démontrable. L'histoire est 'Améliorer la montée en charge pour que le système puisse supporter 10000 utilisateurs simultanément'. Je ne peux tout de même pas inviter 10000 utilisateurs à la démo ? »
  • Scrum master : « Cet élément est-il terminé ? »
  • Membre de l'équipe : « Oui, bien sûr ».
  • Scrum master : « Comment le sais-tu ? »
  • Membre de l'équipe : « J'ai installé le système sur un environnement de tests de performance, j'ai démarré 8 serveurs de charge et j'ai stressé le système avec des requêtes simultanées ».
  • Scrum master : « Mais as-tu une indication comme quoi le système peut supporter 10000 utilisateurs ? ».
  • Membre de l'équipe : « Oui. Les machines de test sont pourries, cependant elles ont supporté 50000 requêtes simultanées pendant mon test ».
  • Scrum master : « Comment le sais-tu ? »
  • Membre de l'équipe (frustré): « Ben j'ai ce rapport ! Vous pouvez voir par vous-même, il montre comment le test était configuré et combien de requêtes ont été lancées ! »
  • Scrum master : « Excellent ! Alors voilà ta « démo ». Montre juste le rapport et fais le passer dans l'audience. Mieux que rien, non ? ».
  • Membre de l'équipe : « Ah, c'est suffisant ? Mais c'est moche, il faudrait le rendre plus présentable.».
  • Scrum master : «OK, mais n'y passe pas trop de temps. Ca n'a pas besoin d'être joli, juste informatif. »

précédentsommairesuivant

Copyright © 2009 Henrik Kniberg. La copie, modification et/ou distribution par quelque moyen que ce soit, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Image non disponible