David BROCARD Consultant Indépendant

Hier soir s'est tenu notre premier BVG.

Nous n'étions pas très nombreux mais suffisamment pour dérouler une séance bien animée et débattre des nombreuses métaphores qu'illustre ce jeu.

Le principe en quelques mots :

Des équipes de 5-7 personnes sont constituées.
Dans chacune, on désigne 5 clients, ou plus exactement, des gens qui devront représenter les attentes de ces clients.
Chaque client démarre avec un certain niveau de satisfaction.
On désigne également une équipe de développement (en fait, comme on n'est pas assez nombreux pour que chacun ait un rôle distinct, chacun alterne entre le rôle de client et celui de développeur).
Normalement, on désigne un comptable qui prend du recul et établit les comptes de l'équipe. Dans les faits c'est l'animateur de la séance qui joue ce rôle.

A chaque client sont associées des "Requests", qui ressemblent en fait à des "Features", grands ensembles fonctionnels autonomes et cohérents, constitués de plusieurs histoires utilisateurs.
La valeur est comptée au niveau de la request, et n'est gagnée que si celle-ci est mise en production.
C'est un parallèle judicieux avec la réalité !

A chaque itération l'équipe doit optimiser la valeur gagnée, c'est-à-dire, les requests mises en production
Il faut donc commencer par évaluer la valeur métier, mélange entre la valeur financière en euros et la satisfaction client en unité propre. C'est là qu'apparaît la notion de "modélisation de la valeur métier", celle qui est comptée in fine pour établir le vainqueur du jeu.

Comme la vélocité de l'équipe de développement est limitée (et prédéfinie), il faut choisir les histoires utilisateurs qui tiennent dans l'itération, plus éventuellement consacrer quelques points à la mise en production ou à l'amélioration future de la productivité de l'équipe. Il faut donc diviser la valeur de la request au niveau des histoires utilisateurs.
Ici intervient le deal entre les investissements techniques et la nécessité de livrer pour gagner la valeur./ Très représentatif...

Ce qui est livré à un client rapporte non seulement la valeur en euros mais augmente la satisfaction d'autant de points qu'indiqués sur la fiche de la request. Dans le cas contraire, rien n'est gagné et la satisfaction diminue d'un point. Lorsque la satisfaction atteint zéro, le client part et ses requests ne peuvent plus être considérées, donc sont perdues en termes de valeurs.

Dans la feuille de comptes, on distingue notamment la valeur potentielle et la valeur réellement acquise. La différence : mis en production ou pas ! On relève également la satisfaction client (chiffrée dans un unité à part), le ROI (10% du gain à l'itération précédente).

Notre score :

Plus de 20000 euros je crois, ce qui n'est pas si mal semble-t-il

Nos erreurs (entre autres !) :

• Le jeu commence avec des principes simples puis introduit progressivement de la complexité (vélocité variable, investissements techniques, etc). A partir d'une itération, les requests contiennent des conditions de satisfactions que nous n'avions pas vues. Apparemment le guide du jeu invite les animateurs à ne pas les rappeler aux joueurs. Imparables, non n'avons rien vu et en conséquence perdu de précieux revenus à cette itération.
• On a toujours calculé la valeur jusqu'au niveau des histoires utilisateurs alors que cela n'est pas forcément nécessaire pour arbitrer les choix. Grande leçon d'amélioration.
• Vu le nombre limité d'itérations du jeu, l'investissement technique ne vaut la chandelle que s'il est fait tôt afin de gagner en productivité rapidement. Tout faux !

Les limites du jeu :

• Volontairement, le jeu n'aborde pas les estimations développeurs et les prédéfinie pour se concentrer sur la valeur métier acquise. Notons que le prédécesseur XP Game est fait pour cela !
• Au plan comptable, le revenu est le chiffre d'affaire. Pas de notion de charges, de salaires etc
• On ne dit rien sur les engagements contractuels. Donc on est amené à "sacrifier" la satisfaction de certains clients pour maximiser la valeur globale, ce qui prête largement à discussion dans la réalité
• Le jeu compte six itérations, ce qui n'est pas forcément suffisant pour vraiment illustrer les investissements techniques nécessaires dans la réalité sur le moyen/long terme
• On ne gère pas les relations entre features. Dans la réalité, c'est quasiment impossible même s'il faut tout faire pour définir des features indépendantes

Ce que je trouve le plus intéressant :

• Le plus important : on (ré)apprend que la valeur pour le client se situe à un niveau minimal : celui de la Feature, et non au niveau de la story. En vrai, on peut être amené à définir des "sous-features" aussi appelées "Minimal Marketable Feature" (on reviendra sur ces notions dans de prochains billets).
• Il y a beaucoup de paramètres à prendre en compte pour prendre les décisions et définir la stratégie - satisfaction, valeur financière, investissements pour les prochaines itérations, conditions de satisfaction etc - comme dans la vie réelle
• On nous invite à disposer les cartes d'une certaine façon sur la table pour obtenir la meilleur vision possible de ce qui est à réaliser. Cette disposition est en fait cruciale : impossible de prendre les bonnes décisions sinon. Je trouve même que cette idée et à reprendre en situation réelle (on y reviendra également)
• La finalité (avérée) du jeu est de comprendre la notion de valeur métier et qu'elle a besoin d'être modélisée localement à un contexte. Cette notion de modélisation est fondamentale.
• Les bénéfices tirés des échanges entre participants, notamment si l'équipe est constituée de différents profils (client, développeurs etc) et c'est véritablement une condition de succès pour le jeu