Quelques commentaires suite aux démos de Wilos et Icescrum auxquelles j'ai participé hier en tant que directeur de produit :

  • le public n'apprécie pas d'attendre plusieurs minutes avant le début réel de la démo. L'installation et le raccordement au vidéo-projecteur doivent être rapides ou préparés avant
  • il convient de préciser le contexte de l'installation (serveur, en local ?) et décrire les données de test éventuellement utilisées pour la démo
  • il n'est pas utile de faire de présentation sous forme de diaporama avant la démo
  • la démonstration ne s'adresse pas uniquement au directeur de produit. L'objectif est d'être compris également par le public non averti (intervenants extérieurs qui ont parfois une connaissance limitée du projet)
  • quand ça plante ou que ça ne se passe pas comme prévu, il vaut mieux le dire explicitement. Le but est la transparence, pas l'attente d'un jugement
  • la démonstration est l'aboutissement d'un travail collectif, c'est une bonne chose que cela se voit, en faisant participer plusieurs personnes de l'équipe
  • quand on tombe sur un bug pas la peine de répéter "ça marchait il y a 10 minutes je ne comprends pas"
  • ça ne sert à rien d'essayer de justifier un incident dans le déroulement de la démo en évoquant des problèmes de gestion de configuration, ça fera l'objet de la rétrospective
  • lorsqu'on saisit des valeurs, il vaut mieux prendre des valeurs parlantes plutôt que valeur1, valeur2...
  • il ne faut pas montrer des fonctionnalités qui ne marchent qu'à moitié
  • il ne faut pas aller trop vite dans la démonstration d'une fonctionnalité avec des clics trop rapides. Toute l'assemblée doit bien comprendre ce qui est montré
  • les fonctionnalités doivent être présentées une à une en se référant au backlog : l'objectif de la démonstration est de définir les éléments du backlog qui sont achevés