Drupal et Scrum depuis les tranchées - La démo de l'itération

Qu'on se le dise, la démo doit être vécue comme une célébration, chacun(e) doit venir fièrement montrer les avancées qu'il/elle a réalisé. Mais avant d'ouvrir le champagne, une démonstration se prépare.

La démonstration a généralement lieu en fin de dernière semaine d'une itération, disons le jeudi et dure 1h à 2h au maximum. Scrum nous encourage à livrer des incréments de logiciel fonctionnels, la conséquence directe de cela est que l'on ne commence pas de grosse fonctionnalité le dernier jour du sprint, on se concentre plutôt sur la préparation de la démo. On ne pousse pas non plus un gros patch à l'arrache susceptible de casser le travail des petits copains.
L'équipe se rassemble pour identifier un scénario des fonctionnalités terminées à présenter. Chaque membre de l'équipe vient présenter son travail, il est important que chacun(e) s'exprime et montre ce qu'il/elle a fait. Une fois le scénario établi, on prépare un environnement de test pour le client pour qu'il puisse, une fois la démo passée, retrouver ce qui a été fait et tester par lui même le puzzle assemblé au cours de l'itération. Bien souvent vous aurez besoin de créer des contenus / utilisateurs, préparer des fichiers à transférer et tomberez sur des bugs de dernière minute. Profitez de ce temps de préparation pour identifier et corriger cela pour que votre démonstration soit réussie.

On le sait, bien souvent les développeurs ne sont pas les meilleurs communiquants du monde. Cela ne veut pas dire qu'il ne savent pas parler, bien au contraire, ils aiment en général parler de ce qu'ils font. Faites donc travailler ceux qui en ont besoin. En faisant une démo du projet vous racontez une histoire, rendez cela le plus fluide possible en apprenant à meubler dans les temps faibles et en rendant la présentation interactive.

Sont conviés à la démonstration toutes les parties prenantes, l'équipe projet, le scrum master, le/la porteur/se de projet mais peuvent aussi participer les utilisateurs finaux, la direction, etc. C'est un moment adapté pour collecter les avis et potentiellement ajuster le comportement des fonctionnalités par la suite si des sujets importants sont soulevés. Attention cependant à veiller à ce que tout le monde sache se tenir pendant la réunion.
C'est pendant la démo que Drupal est un produit intéressant. Une conversation sur une demande du/de la porteur(se) du projet peut vite arriver à identifier des évolutions simples à mettre en œuvre. "Serait-il possible de trier par...", "pourriez-vous réordonner les blocs...", "que se passe-t-il si on inverse l'ordre des champs...". Ces exemples de questions peuvent souvent être démontrés tout de suite grâce à la flexibilité de Drupal, vous donnant ainsi la possibilité de décider rapidement de changement à adopter ou non. Appuyez-vous au maximum sur les modules contribués pour valider les critères d'acceptation des fonctionnalités et échanger pendant une démo avec le/la porteur/se de projet sur les possibilités supplémentaires données par les modules pour donner suite à des changements ou non.

La première fois que vous terminerez une itération avec votre équipe nouvellement agile, il se pourra que vous n'ayez fermé aucune demande de fonctionnalité et donc n'ayez rien à montrer... cela fait partie du jeu, l'équipe comprendra alors qu'il ne faut pas reproduire cette expérience et veillera à avoir des choses à démontrer lors de l'itération suivante.