Spécifications en milieu agile : Comment peut-on encore se passer des Uses Cases ?
« Walking on water and developing software from a specification are easy if both are frozen » Edward Berard
Il y a quelques années, lors d’une mission en milieu Agile, j’ai eu la chance de découvrir une façon efficace de faire participer l’ensemble de l’équipe aux spécifications. En effet, 2 fois par semaine, un groupe de travail se constituait avec l’architecte, un ou deux développeurs, un expert métier et le PO. Ensemble, nous revisitions pendant 1 heure, les Uses Cases qui méritaient de l'être. Ainsi, toute l’équipe connaissaient au fur et à mesure, les règles métiers et les processus Front / Back issus des actions utilisateurs. Les solutions pour les cas compliqués étaient trouvées de concert. Les parcours utilisateurs restaient toujours frais dans la mémoire de l'équipe de développement.
Plus tard, j’ai tenté d’initier les mêmes pratiques dans d’autres projets, sans succès. Les habitudes ont la vie dure. Paradoxalement, le plus difficile pour une équipe Agile est de réussir à sortir du cycle en V. Pour aider vos équipes, une des solutions est de changer la façon de spécifier. Car, les spécifications sont indispensables en méthode Agile et la conception est une des difficultés importantes dans la mise en place de l’Agilité. Cet article ne va pas faire la description de l’ensemble des méthodes de spécifications en milieu Agile mais uniquement le focus sur les Uses Cases.
Qu’est-ce qu’un Use case ?
Un cas d’utilisation ou Use case est une série d’actions ou/et d’événements provoqués par un utilisateur sur un système informatique dans le but d’obtenir un résultat. Par exemple, un internaute fait une recherche sur un site internet de vente en ligne dans le but de savoir si le site vend un produit spécifique. L’UC s’attachera à décrire l’ensemble des interactions possibles dans le cadre de cette action. Il permet de décrire ce que le futur système devra faire, sans spécifier comment il le fera.
BPMN et UML sont deux spécifications complémentaires. UML met l'accent sur l'analyse et la conception d'un système d'information alors que BPMN vise l'analyse et la conception des processus métiers qui font intervenir et interagir des systèmes.
Le but principal de BPMN est d'avoir un support compréhensible par tous dans l'équipe, des spécialistes métier jusqu'aux développeurs.
Ci-dessous, ce UC décrit très simplement cette action utilisateur. Un UC peut également décrire beaucoup plus précisément les actions avec les interactions entre modules applicatifs.
Une première étape essentielle est de bien analyser le besoin client.
Pour faire une application qui marche et surtout qui soit utile, cela nécessite de savoir ce qu'il faut vraiment développer. Souvent, le client arrive avec un cahier des charges qui décrit une solution qu’il a imaginé pour résoudre son problème mais, il ne décrit pas son problème. Le premier travail à faire est de découvrir ce que le client a réellement besoin. Une fois, ce point éclaircit, le travail de spécification en équipe peut commencer.
Les spécifications, un travail à faire avec l'ensemble de l'équipe.
Casez les silos ! Il n'est pas rare de voir le PO aller tout seul à la restitution du besoin client pour après, transmettre sa vision au concepteur et à l'UX. C'est absurde. D'abord et avant tout, exigez que l'ensemble de l'équipe participe à la restitution du besoin ! L'interprétation et les questions se poseront en groupe. Une vision commune pourra émerger. Plus besoin de réexpliquer ce dont le métier a besoin aux autres membres de l'équipe et les spécifications peuvent être pensées par l'ensemble de l'équipe. De la même façon, il est essentiel qu'une proximité importante existe entre les développeurs et les utilisateurs finals. Vos développeurs doivent participer aux tests utilisateurs, aux ateliers UX ou êtres invités à faire de l'immersion avec les utilisateurs.
Appréhendez les spécifications comme un processus plutôt que comme une documentation figée.
Il y a de forte chance que les besoins métier évoluent au fur et à mesure du projet et donc, cette adaptation pourra se faire d’autant plus facilement que les spécifications sont une activité partagées par l'ensemble de l'équipe. L'Impact Mapping, l'Event Storming ou les User story Mapping sont des méthodes reconnues pour spécifier en équipe. Mais au-delà de ces méthodes, instituer en début de projet, des ateliers autours des Uses Cases sera très bénéfique.
Sécurisez le périmètre fonctionnel en prenant le temps de passer en revue les UC.
Faire des Workshops autours des uses Cases permettent avant tout de s’assurer que les cas utilisateurs ont tous été pris en compte et qu'il ne reste plus de trou dans la raquette.
Ces ateliers permettent également de profiter de l’intelligence collective et de diffuser facilement la compréhension et la connaissance au sein de l’équipe de développeurs, ce qui permettra d’obtenir une vision commune. L’équipe prendra alors son autonomie dans les décisions tout le long du projet.
Enfin, cette méthode permet également de faciliter l’écriture des Uses stories et de les accompagner en tant que spécifications didactiques et visuelles.
Basez votre architecture applicative sur les Uses Cases permet une meilleure évolutivité de votre application.
Un choix d'architecture applicative est toujours stratégique : Data Driven Architecture versus Domaine Driven Design. Le choix d'une architecture Data driven présente l’inconvénient de ne pas distinguer la nature de la donnée c'est à dire la nature business de la donnée / l'intention utilisateur.
Le domaine driven ne se pose pas la question de la donnée mais les intentions business. Cette architecture demande de démarrer en listant les Uses Cases c'est à dire ce que le système doit est capable de faire vis-à-vis des différents utilisateurs et de leurs comportements. On ne s'intéresse donc pas aux données dont on va avoir besoin mais aux comportements qui vont pouvoir être assignés à mon système d'information.
Au départ, il ne s'agit pas d'avoir une liste exhaustive de tous les UC mais plutôt d'avoir de quoi démarrer les développements. Quelques cas nominaux seront parfaits pour cela.
Se baser sur le UC permet d'éviter l'Over Engineering.
Une règle simple doit être intégrer par les équipes : Ne jamais écrire du code qui ne soit pas directement lié à un UC. Parce que lorsque l'on écrit du code en dehors d'un UC, cela veut dire que l'on écrit du code "au cas où", du code qui ne répond pas à un objectif métier. Cela créé inévitablement de l'Over-Engineering.
Faire une navette spatiale à la place d'un vélo est sûrement un challenge existant mais, le problème c'est que c'est très coûteux à maintenir une navette spatiale et qu’entre-temps, votre budget projet aura explosé. Les cimetières sont remplis de magnifiques produits.
Définir des produits et services digitaux qui répondent aux besoins de leurs utilisateurs et d'optimiser leurs réalisations sont les seuls objectifs qu’une équipe doit s’assigner.
Un merci à Arnaud LEMAIRE et à ses conférences sur le sujet et à Cyril DUPORT, pour l'inventivité des méthodes en œuvre dans ses équipes.
Commentaires
Enregistrer un commentaire
Nous espérons que l'article vous a intéressé et qu'il vous inspirera un commentaire.