7 : Présentation des spécifications en BML

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).

  1. 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.

  1. 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 :

  1. 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).
  1. 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).

Principes de l’articulation de BML avec les outils de ticketing et les outils de test

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.

Publié par

djoliot64

Formateur "Modern Product Agility" (MPA), je suis coach agile expérimenté depuis plus de 10 ans (Crédit Agricole, Société Générale ...). Auparavant carrière riche : certification de logiciels embarqués AIRBUS, Responsable méthodes/qualité MOE de grandes DSI bancaires, Directeur de projet, conseil en Portfolio Management, Architecte d'entreprise ... Auteur de 5 livres, nombreux articles, créateur de solutions (Langage BML, algorithme des tamis successifs, démarche CNV-A)

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s