Le but de cet article sur “l’ATDD manuel” est d’expliquer comment pratiquer cette démarche de Business Modeling Language (BML) sans avoir un outil dédié et donc :
- Avoir des spécifications plus rigoureuses
- Pouvoir générer de manière “systématique” les scénarios de test
Qu’est-ce que BML ?
Business Modeling Language (BML) est un formalisme de spécification, défini par Didier JOLIOT depuis 25 ans, qui vise à décrire pour un parcours utilisateur, c’est à dire, en agile, un processus restreint à un cas d’usage. C’est un formalisme protégé par la marque “Modern Product Agility”.
Les spécifications fonctionnelles (exigences de la solution) sont un préalable indispensable pour déterminer en agile » les critères d’acceptation » (les scénarios de test).
- Les spécifications des US
La spécification BML est celle vue en ATDD “manuel”, avec, par conséquent, des règles de gestion (cf. articles précédents de cette série). Elle est donc sous forme tabulaire. Toutefois, dans chaque cellule de table de décision nous aurons une syntaxe textuelle qui va bien au-delà de la syntaxe « Gherkin » traditionnellement utilisée pour les critères d’acceptation. Ceux-ci, issus de la spécifications BML, seront donc beaucoup plus précis.
- Les spécifications des “fonctionnalités de haut niveau”.
Ces fonctionnalités sont celles qui intègrent les US INVEST, voire des macro-fonctionnalités de taille encore supérieure (MUC). La forme de cette spécification de haut niveau sera graphique.
BML permet donc, en plus des règles de gestion des US, de spécifier des règles métiers de haut niveau.
Les critères d’acceptation, qui en seront déduits, seront compatibles Gherkin, mais aussi plus rigoureux. Des contrôles automatisés sur les spécifications sont possibles. Le formalisme va au-delà des données. A contrario c’est un formalisme strict, nécessitant de respecter des règles plus contraignantes.
BML pour spécifier le fonctionnement d’un cas d’usage d’un produit et ses évolutions
Comme nous l’avons vu, mais il est bon de le répéter, BML va :
- Présenter le produit dans son ensemble, les multiples tickets d’évolutions étant “intégrés” dans cette vision utilisateur. Pour celui-ci, en effet, peu importe les tickets de réalisation, il lui faut un produit “qui marche” :
- Faire que les nouveautés fonctionnent (on retrouve les artefacts agiles) et s’intègrent bien avec l’existant.
- Faire que l’existant non touché continue de fonctionner (absence de régression).
- Fournir une liste d’exigences fonctionnelles (règles métiers et, dans le détail, règles de gestion) pour chaque cas d’usage décidé par le pilotage de projet : notion de modèle de parcours métier.
Ce qu’il faut retenir
Le schéma suivant résume l’intérêt et le positionnement de BML dans un projet, notamment en agile (nous verrons l’impact de l’approche agile ultérieurement).
On notera donc toute l’importance d’avoir un référentiel d’exigences fonctionnelles en BML, puisqu’il est en ATDD manuel la source des critères d’acceptation.
Il permet par ailleurs des analyses d’impact, en évitant, par exemple, des RG erronées.
Généralement, c’est le Product Owner qui sera dépositaire de ce référentiel (quitte à ce que les développeurs ajoutent des règles “techniques”). Un outil de ticketing comme JIRA pointera, pour chacun de ces éléments, vers ce référentiel.
Attention, le schéma doit être commenté :
- A gauche, les tickets de développement sont nombreux : on peut avoir pour un sujet plusieurs tickets qui ajoutent, modifient, suppriment des règles dans la solution c’est-à-dire dans le produit qui sera donné à l’utilisateur.
Une histoire de haut niveau une fois terminée peut être remaniée (changement de contexte métier par exemple, c’est l’incertitude !). Il faudra donc un ticket pour la changer … alors que l’utilisateur, lui, verra toujours la même fonctionnalité (même si elle se perfectionne), en ignorant les tickets qui se sont succédé.
- A droite, c’est le cliché du produit à un instant T de son développement.
L’auteur
Didier JOLIOT, Ingénieur Coach agile et formateur
Didier a une grande expérience professionnelle : développeur puis responsable qualité et certification de logiciels temps réels critiques. Ex : Airbus (A320, A340), missiles, spatial, nucléaire, sous-marins, … Il a été ensuite expert spécifications et tests auprès d’équipes MOE, puis de MOA bancaires. Il a été aussi directeur de projet, et enfin expert auprès des managers pour la stratégie des SI (« Portfolio Management » et architecture d’entreprise).
Il pratique depuis 2012 l’agilité. Il a été coach agile pour le Product management de très gros projets « agiles à l’échelle » au Crédit Agricole et à la Société Générale, et pour de nombreuses équipes Scrum.
Il a écrit 5 livres et de nombreux articles. Il enseigne, depuis des années, dans plusieurs écoles d’ingénieur et dans les entreprises. Il a créé, de plus, plusieurs méthodes : le langage « Business Modeling Language (BML) », l’algorithme ATDD des tamis successifs, la CNV-A, etc.
