Long billet pour vous partager une approche pour concevoir une architecture de vision en mode Agile. En faisant de l’Agilité, on oublie le « big up front design » mais il faut toutefois faire ressortir LA fameuse vision. De plus, il faut le faire avec des gens souvent des opérations qui n’ont aucune expérience avec des pratiques de conception TI. C’est pourquoi j’aime utiliser l’approche par cas d’utilisation pour faire ressortir cette vision et du même coup un carnet de commande et tout ça durant un atelier (qui peut s’étirer sur un ou plusieurs jours).

Je suis présentement chez un client où le projet arrive à un point que certain élément n’ont pas été définis par l’architecture initiale (malheureusement, le projet a débuté en mode Waterfall). Devant élaborer une architecture de vision avec la PO d’une équipe (et ça sans trop pénaliser son équipe) et des gens des opérations (sans trop pénaliser leur équipe du Day to Day), j’ai proposé de faire cet atelier de conception des cas d’utilisations sous forme itérative. Ainsi, avec un carnet de commande de nos cas et avec nos itérations on a la visibilité pour voir si on rentre dans le temps qui nous impartie et rapidement s’adapter dans le cas contraire.

Initialement puisqu’on avait un groupe de 10 personnes et deux personnes de chaque milieux (TI, affaire, utilisateur), j’avais proposé de faire deux équipes qui lors d’une itération s’engagerait à produire N cas d’utilisation du carnet de commande et ensuite le présenter à l’autre équipe lors de leur démo respective. Cette idée n’ayant pas très bien passé on est revenu à l’approche de base qui était les 10 personnes ensemble créant et débattant d’un cas à la fois.

J’aimais l’idée de deux équipes pour différentes raisons :

• Facilité les échanges et les débats.
• Permet de plus facilement suivre les conversations
• Rend imputables plus facilement les membres de leur opinion puisqu’en petit groupe c’est plus difficile de se cacher dans la masse.
• On attaque plus de cas d’utilisation en parallèle.
• Permet de diluer l’impact des leaders/dictateur d’opinion.

Voici comment j’ai structuré l’atelier avec l’autre coach qui m’accompagnait

1. Initiation à la conception par cas d’utilisation.

Durant cette étape je prenais un cas fictif de site de transaction électronique. Cette initiation avait pour but de démontrer avec un cas simple la mécanique de notre rencontre et expliquer chacune des étapes de travail qu’on devra faire soit :

• Définition du processus d’affaire
• Définition des grandes fonctionnalités
• Définition des cas d’utilisation (notre carnet de commande de rencontre)
• Élaboration des cas d’utilisation

L’utilisation de cette technique a portée fruit puisqu’elle a permis d’expliquer, avec quelque chose de simple, un processus de conception qui n’était pas familier à personne (incluant les TI) et tout ça en moins d’une heure.

2. Définition du processus d’affaire

Durant cette étape, le but est de définir le ou les processus affaires. À ce niveau un processus d’affaire est souvent un cycle de vie complet de la chose qu’on veut informatiser ou le problème qu’on veut en faisant le système. Si je fais un parallèle avec mon exemple de site de commerce électronique, le processus inclu la confirmation du panier virtuel jusqu’à la livraison des éléments commandés.

À cette étape c’est tout à fait normale que toutes les fonctionnalités soient obligatoires, c’est un peu plus loin que les nuances pourront être apporté, lorsque la granularité des fonctionnalités sera plus petite.

3. Définition des grandes fonctionnalités

Lors de cette étape on liste toutes les fonctionnalités nécessaires au processus d’affaire pour qu’il fonctionne. C’est à partir d’ici qu’on peut commencer à discerner l’obligatoire du facultatif et même de l’important. Il suffit d’être attentif et de poser les bonnes questions pour faire développer plus les gens métier sur leurs besoins et de la manière d’y répondre.

4.Définition des cas d’utilisation

C’est durant cette étape qu’on va construire notre carnet de commande pour les ateliers à venir et ainsi rendre visible notre avancement. De plus cela nous permettre d’estimer combien d’atelier il va nous falloir. Puisque le processus d’affaire et les grandes fonctionnalités d’affaire étaient bien comprises, faire la liste des cas d’utilisations se fit plutôt facilement. Par contre au début, les gens avaient le syndrome de la page blanche, ne sachant pas par où commencer. Pour les dénouer un peu, je suis revenu sur l’exemple du départ et l’équipe s’est mise en branle immédiatement après.

Il est parfaitement normal de ne pas réussir à lister l’ensemble des cas d’utilisations dès le départ. À pratiquement tous les ateliers de conception que j’ai fait, la liste des cas d’utilisations du départ n’était plus la même à la fin, ça bouge, ça évolue au fil de l’atelier et c’est normal.

Un coup cette étape terminée, l’équipe a priorisé les cas d’utilisation et ensuite elle les a pointés, sous forme de poker planning, selon leur complexités et grosseurs.

5. Élaboration des cas d’utilisation

À cette étape c’est simple c’est le temps d’envoyer nos gens affaires au tableau et de faire ressortir en eux leur talent de « Fait mon un dessin ». Durant mon exemple du départ, je précise qu’un formalisme rigide n’est pas nécessaire, à la place on s’entend sur différent dessin ainsi que leur signification pour représenter les artefacts composantes un cas d’utilisation. La première fois que j’avais fait cet exercice avec des gens affaires je ne l’avais pas fait et cela avait un paralysé au début par peur de ne pas respecter LA norme ISO 985848 des dessins de cas d’utilisation. Aussi pour faciliter cette étape de l’atelier, j’ai souvent dessiné les deux premiers cas pour les mettre en confiance avec l’approche.

Il est normal de modifier des cas d’utilisation dit terminés quand la vision se précise au fil de l’atelier. Il est important de rassurer les gens affaires quand ça se produit. Puisque souvent de leur point de vue, changer ou enlever un cas d’utilisation par un autre c’est faire un pas arrière.

Pour bien définir la porter d’un cas d’utilisation j’aime bien utiliser le mnémonique PME (Processus Métier Élémentaire) définis par Craig Larman.

Définition de PME : Tâche effectuée par une personne/acteur en un lieu et un temps donnés, en réponse à un événement et qui ajoute une valeur commerciale mesurable et laisse les données dans un état cohérent.

À la fin de l’atelier je fais toujours un petit tour de table pour recevoir des feedback sur l’approche et l’atelier lui-même pour pouvoir m’améliorer pour la prochaine fois. Aussi je m’assure que la PO a toutes les informations qui lui faut pour débuter l’écriture de stories lors de son retour dans le projet.

Si vous avez des questions ou commentaires gêner vous pas !

Livre intéressant: