Modélisation agile du domaine

Scrum ne traite pas l'aspect modélisation. Ce n'est pas une raison pour ne pas en faire.

Dans la famille Agile, il y a Scrum, il y a XP et on trouve aussi la modélisation Agile.

am.jpg Scrum donne un cadre dans lequel on peut appliquer des pratiques de modélisation Agile, de la même façon qu'on peut y inclure des pratiques XP, comme les user stories, la vélocité, le TDD...

En tant que directeur de produit, je trouve qu'un modèle métier est essentiel pour communiquer avec le reste de l'équipe. Comme dans mon cas toute l'équipe comprend UML, j'utilise la représentation connue sous le nom de diagramme de classe pour montrer les concepts du domaine. C'est pour ça qu'on parle aussi de modèle du domaine.

Quand faire de la modélisation ?

Un peu de modélisation au début de chaque itération permet à tout le monde de bien comprendre les concepts sur lesquels vont porter le travail. On peut faire une session de travail spécifique pour cela. En pratique, je préfère utiliser un modèle métier lors de la réunion de planification, en début de sprint. La discussion sur les histoires d'utilisateur[1] s'en trouve grandement facilitée.

Avec quel outil ?

Il n'est pas nécessaire de disposer d'un outil sophistiqué, le plus souvent un diagramme fait sur un tableau est suffisant.

mmWilos.jpg

Modélisation participative

L'appropriation du modèle métier par toute l'équipe ne peut se faire qu'au cours d'une réunion à laquelle toute l'équipe participe. Elle ne marche pas si c'est une personne qui élabore un diagramme sur un outil, même si elle le met à disposition et le fait relire.

Un exemple : lors du dernier sprint du projet Wilos, une histoire d'utilisateur était " en tant que participant, éventuellement à plusieurs projets, je m'affecte à un rôle". A quelques jours de la fin du sprint, l'équipe s'est aperçue que le fait qu'un participant puisse avoir un rôle dans plusieurs projets n'avait pas été prévu dans la base de données et demandait des modifications significatives. Et pourtant il existait un modèle métier et je l'avais lu. Je suis persuadé que cela aurait pu être évité si ce modèle avait été utilisé lors de la réunion de planification. En discutant de cette histoire, nous aurions vu qu'il manquait dans le modèle métier la notion de poste qui joue un rôle concret [2]pour un projet.

Notes

[1] lors de la réunion de planification, l'objectif est d'identifier les tâches pour faire un planning détaillé

[2] c'est RC sur le schéma. Ce schéma a été utilisé lors de la planification du sprint qui vient de commencer