Si je vous dis que lorsque vous faîtes le plein de votre voiture, vous faîtes du Scrum, est-ce que vous me croyez ?
Instant particulier vendredi dernier : fin du sprint 6 mais surtout dernier Scrum Debriefing pour moi. En effet c’est sylvain qui prend la suite de Karma. Je me rends compte que Scrum va faciliter le passage de connaissances juste avant de partir.
De l’importance de faire une démonstration au client
Vendredi nous avons donc effectué la démonstration de plusieurs fonctionnalités en présence du responsable du développement et de l’ergonome. Nous devions implémenter entre autre une fonction de navigation qui permet de charger rapidement une donnée (une contre-partie) à partir d’un écran de capture de deals standard.
Bref nous voilà partis dans la démonstration… clique, clique…. hop, clique… (vous voyez ?)…. clique
Et c’est là que l’ergonome demande « …et si la personne ne met rien dans votre champ ? … « .
Et bien nous avions beau avoir regardé ce changement dans tous les sens, nous avions complétement oublié un cas simple. Tout ceci pour dire que grâce à la revue de sprint nous avons trouvé un nouveau cas particulier qui sera corrigé dès demain. Merci Scrum.
En effectuant une démonstration devant le client, le développeur (ou les développeurs) qui ont implémenté la fonctionnalité reçoivent directement un « merci » ou un « c’est pas ce que j’ai demandé » du client… Exercice parfois délicat, il faut rappeler à notre client préféré qu’il y a 10 jours c’est lui qui a demandé cette fonctionnalité. D’où l’importance de lui demander de raconter comment il fera la recette lui-même de la fonctionnalité.
Raconte moi une histoire
Il faut que le client vous raconte une histoire. C’est de cette façon que les questions surgissent. Prenons un exemple :
Le client: – « En tant qu’utilisateur je souhaite changer la langue de l’interface sans devoir quitter l’application. J’en ai besoin pour charger des concepts financiers exotiques et je ne veux pas perdre ma session. »
Moi: – « Très bien. Comment veux-tu changer de langue ? »
– « Je veux cliquer sur une drapeau sur l’écran principal. Là une liste de drapeaux apparaît. Je clique sur le drapeau Japonais et toute l’interface bascule en japonais. »
– « Les labels s’affichent verticalement sur cette barre ? »
– « En fait non, car cela n’a pas de sens pour cet écran »
– « Et est-ce que le choix de la langue doit être sauvegardé si tu quittes et tu reviens dans l’application ? »
– « Oui c’est important »
– « Comment faire si nous n’avons pas la traduction d’un champ ? »
– « Affichez alors le label par défaut. En anglais comme actuellement »
Il faut demander au client de se projeter et d’imaginer la solution complétement terminée, afin qu’il identifie tous les besoins et que rien ne soit oublié. Ici il faudra implémenter la persistance du choix de la langue. Cela peut se faire en base de données mais nous n’avons pas besoin d’en parler ici.
La durée du sprint, tu peux la mettre à 13 jours ?
Non. Mise en situation : ce matin avec 2 personnes importantes de chez nous, nous avons effectué notre planification pour le Sprint 7. J’ai donc piloté les discussions entre les développeurs, l’ergonome, l’ingénieur financier et le responsable du produit chez nous. C’était assez acrobatique. A noter que c’est la première fois que le client final (le chef du produit) vient à notre réunion. Je me demandais comment Scrum serait perçu. Et bien cela s’est très bien passé.
J’ai détecté quelque chose de nouveau avec Scrum. Lorsque le client final nous demande quelque chose, nous avons tendance à chercher trop tôt à résoudre tout le problème et donc à couvrir trop tôt l’ensemble de la demande. Je m’explique. L’une des demandes est d’implémenter une fonction de macro pour enregistrer à l’écran une saisie, afin de la rejouer automatiquement plus tard. Rappelons que nous sommes dans du web. Donc la solution est du côté du serveur dans notre framework. Et bien les développeurs discutaient de la manière de sauver en base ce scénario… alors que le client a un besoin fonctionnel.
Il a fallut à cet instant recadrer et expliquer que le choix technique n’a aucunes importances pour l’instant. En 10 jours, implémentons une partie sans la persistance, effectuons la démonstration au client, et nous serons capable d’aborder la persistance plus tard. Peut-être qu’en voyant cette fonction de macro nous allons décider de l’abandonner. D’où l’importance de ne pas consommer d’énergie pour rien pour l’instant.
L’histoire du plein d’essence
Pour moi Scrum peut se comparer au plein d’essence de ma voiture. Je fais le plein une fois, je roule avec le crédit d’essence que j’ai en faisant attention lorsqu’il ne reste plus beaucoup d’essence. Je peux suivre la consommation à l’aide d’une jauge qui me dit « ce qu’il reste » et pas ce que j’ai consommé.
Réfléchissez à ceci : à quoi cela sert-il de savoir que pour venir de Paris, vous avez consommé 10 litres si ensuite vous devez passer le week-end à la campagne ?
A rien.
Ce week-end vous êtes à la campagne. Votre consommation sera différente.
Ce qui est important c’est le « reste à consommer » qui est représenté par le « reste à faire » en Scrum.
La manière dont vous avez consommé une partie de votre énergie sur un projet n’est pas une certitude sur comment vous allez dépenser le reste… D’où mes grandes idées sur l’inutilité d’un suivi avec un diagramme de Gantt… On ne peut pas prédire l’avenir d’un projet en regardant le passé. Il faut chaque jour se remettre en question afin de voir si le projet est sur les rails ou s’il part dans le décor.
Je termine sur l’image du réservoir d’essence pour rappeler l’importance d’être constant dans la durée d’un Sprint. En effet, il n’y a rien de pire que de changer la durée d’un sprint. 10 jours c’est une durée qui ne doit pas changer. Votre réservoir fait 45 litres et pas 60 litres… Le fait de ne pas pouvoir modifier ce volume vous force à prendre des décisions. Lorsqu’il ne reste que 6 litres et que vous êtes à 20 km d’une pompe, vous prenez une décision. Scrum c’est la même chose.
Pensez à moi la prochaine fois que vous ferez le plein, vous êtes entrain de faire du Scrum.
0 no like
