Ne craignez plus l'effet démo

"Et après avoir enregistré la livraison, on voit que le stock du produit... n'est pas mis à jour..."

Une application pas assez stabilisée, des scénarios déroulés de manière trop hasardeuse, un démonstrateur peu familier de l'application... l'"effet démo" devrait alors être rapidement invoqué pour justifier les comportements inattendus et autres "stacktraces" présentés à l'écran devant un auditoire au mieux interloqué, au pire moqueur.

Pourtant, cet effet et les moments de solitude qui en découlent peuvent être maîtrisés avec peu de préparation. Au travers d'un cas réel, nous vous proposons dans cet article de parcourir les principales astuces vous permettant de sécuriser une démonstration et de combattre l'effet démo qui, un peu à la manière du "Plouf", s'instille sournoisement dans les habitudes d'une équipe. Le cas pris pour exemple de cet article est un projet mené sur un mode "Scrum". Cependant, le principe de la démo reste valable hors de ce contexte.

Vous trouverez en pièce jointe une checklist synthétisant les vérifications à faire afin de mettre toutes les chances de votre côté.

Le besoin

Temps fort d'un projet informatique (Scrum en particulier), la démonstration rassemble, pour quelques heures, l'ensemble des acteurs du projet autour de la même table et permet de partager le travail effectué. Il s'agit d'un moment privilégié à ne pas rater et, ce, dans tous les sens du terme :

• Au sens de la participation tout d'abord : reconnaissance du travail de l'équipe et entretien du lien avec les équipes délocalisées
• ...mais aussi et surtout au sens de la réalisation : en effet, à ce moment du projet, l'application était en pleine construction. Sécuriser les démonstrations devenait nécessaire car :
  • La succession de démonstrations chaotiques depuis plusieurs sprints...
  • ...entraînait un manque de visibilité sur l'avancement...
  • ...entraînant à son tour une perte de confiance du "Product Owner" et du management...
  • ...ainsi qu'une lassitude des équipes de développement

Le besoin était donc de rassurer l'ensemble des acteurs sur le projet et montrer clairement ce qui fonctionnait.

Que montrer ?

Il est courant, au début d'un projet, d'avoir le sentiment de ne rien pouvoir montrer. Mise en place du "socle technique", montée en compétences sur le métier et les différents outils... les raisons sont souvent nombreuses pour justifier l'absence de matière concrète.

D'autre part, les cas d'utilisation des applications de gestion requièrent parfois peu d'interaction avec l'utilisateur, rendant l'exercice de démonstration d'histoires moins... démonstratif.

Dans ce cas, on pourra se tourner vers la présentation de pages de tests exécutables telles que FitNesse ou GreenPepper.  Au-delà de l'aspect tests, ces outils ont l'avantage de rendre visible le fonctionnement de code sans IHM. Dans un premier temps, des pages concernant des briques "techniques" telles que, classiquement, les couches DAO, pourront convenir.

Une fois le rythme de croisière atteint, la construction du contenu de la démo se fait à partir du Jira du projet (ou autre backlog). Sur notre projet exemple, nous nous basions sur les stories validées au cours du sprint voire, si elles étaient suffisamment stables, sur les stories non validées mais terminées. Nous nous assurions cependant que, dans le cadre des scénarios envisagés, elles étaient valides !

La préparation

Contenu des scénarios

Les stories/fonctionnalités sélectionnées sont ensuite instanciées afin de donner naissance à des scénarios proches d'une histoire réelle. Ces scénarios sont de préférence organisés de manière logique pour le sponsor du projet (par exemple, référencer un produit avant de le vendre !).

Une fois les scénarios décidés, ils doivent être écrits afin de laisser place le moins possible à l'improvisation le jour de la démo. Ils seront "relativement détaillés", le niveau de détail dépendant de la confiance dans l'application. De très détaillés pour les fonctionnalités délicates et/ou nouvelles (ex : "Saisir 12 POINT 34 dans le prix de vente du produit"), ils pourront devenir assez sommaires pour des fonctionnalités de base d'un projet avancé et stable (ex : "Créer une commande de deux produits"). Ne pas hésiter non plus à identifier clairement les pièges connus (ex : "Ne PAS cliquer sur 'OK'")...

Rôle du "Responsable de démo"

La multiplication des équipes fait que, naturellement, plusieurs personnes peuvent être amenées à présenter. Dans une situation "de crise" telle que celle subie par notre projet exemple, les premières démonstrations ont été prises en charge par une seule personne, le temps que les présentations se rationnalisent. Cela a permis de mettre en place le process avant réappropriation complète par le client. Ce "responsable de démo" se charge alors de dérouler les scénarios et prend en charge la préparation de la démo à l'aide de la checklist attachée à cet article

Impacts des déploiements automatiques

Nous avons parfois terminé le lundi soir en ayant déroulé et enchaîné avec succès les scénarios mais, le mardi matin, les comportements étaient tout différent... Cela était dû aux déploiements automatiques qui avaient mis à jour l'environnement sur lequel la démonstration allait être effectuée. Ils avaient été oubliés dans l'excitation de la préparation ! Tirez-donc parti de nos oublis et pensez aux tâches automatiques :)

Le déroulement

A ce stade, le contenu de la démo est figé et les acteurs connaissent leur texte ! Il n'est plus envisageable d'ajouter un dernier scénario qui aurait été terminé tard le soir précédent...

Impliquer les équipes délocalisées

Faire participer l'ensemble des équipes à la démonstration est important ; l'exercice est un peu plus complexe lorsqu'on travaille avec des équipes délocalisées. Nous avons utilisé deux outils pour maintenir le lien avec les équipes situées en Europe de l'Est et en Asie : Skype pour l'audio et Mikogo pour le partage d'écran. Cela permet de partager les manipulations du démonstrateur. Attention, cependant, à la réactivité de la connexion réseau qui peut conduire à une démonstration illisible pour vos correspondants !

Respecter les scénarios !

Dans l'euphorie de la présentation, l'improvisation peut prendre le dessus. La démarche peut sembler très scolaire, mais s'astreindre à suivre ligne à ligne chaque étape du scénario et à indiquer chacune comme étant réalisée évite de solliciter des fonctionnalités non prévues de l'application (et donc de faire émerger des bugs potentiels). Réaliser la démonstration à deux (l'un présente, l'autre contrôle) sécurise également le bon déroulement du scénario. On perd bien sûr en spontanéité, mais sur notre projet exemple, l'utilisation d'un déroulement aussi contraint n'a pas duré plus de deux ou trois démonstrations. La stabilité de l'application et la maturité des démonstrateurs augmentant avec le temps, nous avons progressivement allégé le process.

Un exercice de communication

La démonstration est un exercice de communication : ne pas hésiter à expliquer le fonctionnel en illustrant de use cases de la vraie vie, car toutes les personnes du projet ne connaissent pas forcément le domaine/vocabulaire de tous les composants de l'application. Ne pas hésiter non plus à masquer les détails techniques : ils pourront être abordés si des questions en offrent l'occasion.

A ce titre, on respectera également les règles relatives à toute présentation en public :

• limitation du nombre de démonstrateurs : 2 ou 3
• s'assurer que tout le monde voit les manipulations du démonstrateur et l'entend : mouvement de souris lents et connexion avec les équipes délocalisées notamment
• énoncer l'histoire avant de dérouler le scénario permet à l'auditoire de comprendre
• rythme et temps passé
• etc

Impacts et effets collatéraux

Dans des projets possédant plusieurs équipes dédiées à des composants distincts, c'est un très bon moyen d'améliorer la connaissance de tous les acteurs projets sur les aspects fonctionnels du produit. Même sans savoir comment en mesurer l'impact immédiat sur le projet, on peut sans trop de mal imaginer qu'on est plus à même de prendre des décisions adéquates lorsqu'on possède une meilleure connaissance de son environnement !

Même si cet article a pris pour exemple un projet Scrum, la réalisation d'une démo régulière et les lignes directrices de sa préparation présentées ci-dessus ne sont bien sûr pas spécifiques au mode Scrum ! Vos équipes, votre sponsor ne pourront vous être que reconnaissants de présenter leur produit !

Dissocier démo et fin de sprint ?

Nous avions choisi de suspendre les déploiements automatiques de l'environnement de développement pour éviter des éventuelles régressions. Mesure radicale, au grand dam des testeurs qui se retrouvaient ainsi presque 24h sans voir l'application évoluer.

On peut imaginer d'un autre côté dissocier démo et fin de sprint : en faisant une image de l'environnement de développement à la fin du sprint pour la transférer sur un environnement de démo, il serait inutile alors de geler l'environnement de dev le temps de la démo.

Avez-vous pu expérimenter cela dans vos équipes ? Quel(s) retour(s) en avez-vous retiré ?

En conclusion, une démonstration réussie n'aura que des bénéfices sur le projet. Dans le cas du projet pris comme exemple pour cet article :

• L'état du projet a été visible de tous : chacun a pu voir ce qui fonctionnait
• Le product owner était rassuré sur le contenu fonctionnel du projet
• L'émulation créée a été sensible immédiatement
• Chacun a pu faire reconnaître son travail publiquement par l'équipe

Enfin, même si cet article a pris pour exemple un projet Scrum, la réalisation d'une démo régulière et les lignes directrices de sa préparation  présentées ci-dessus ne sont bien sûr pas spécifiques au mode Scrum ! Vos équipes, vos sponsors ne pourront vous être que reconnaissant de présenter leur produit.