Pourquoi la qualité logicielle se joue avant la première ligne de code

La Discovery : il s'agit de déterminer les problèmes auxquels sont confrontés les utilisateurs, et souvent creuser longtemps pour découvrir le vrai besoin derrière la demande exprimée. Établir des priorités entre ces problèmes est ensuite une question d'ordre stratégique, tant s'atteler à la résolution d'un problème plutôt qu'un autre engage l'entreprise.

Le Design : une fois le problème clairement posé, on peut imaginer des solutions, souvent organisationnelles et logicielles. Reste alors à décrire de manière exhaustive et cohérente le comportement attendu, c'est-à-dire les fonctionnalités de l'application. Certains incluent cette étape dans la Discovery, je préfère l'en dissocier.

La Delivery : et enfin la mise en œuvre à proprement parler, développement, test, mise en production. Je passe vite ici, car ce n'est pas l'objet aujourd'hui.

Définition de persona : ce sont vos utilisateurs types, auxquels vous donnerez un petit nom afin de susciter l'empathie de vos équipes. Outre le rôle/la fonction, il est important pour vous d'expliciter ce qui motive ces personnes, les raisons qui les poussent à utiliser votre produit ou vos services, le contexte dans lequel ils le font, leur aisance avec la chose informatique (computer litteracy), et les frustrations qu'ils rencontrent actuellement avec les produits et services concurrents. Ce travail est donc l'aboutissement d'une phase de recherche utilisateur, qualitative et quantitative.

Les processus/workflows : il s'agit ici de décrire l'interaction de plusieurs acteurs avec le système dans le but d'atteindre un but commun (validation de la demande de congés d'un salarié, par exemple). Cette vision nous est généralement assez naturelle, et vous pourrez vous appuyer sur le formalisme d'UML pour plus de systématisme.

L'étude de modularité : la modularisation est un sujet incontournable tant il conditionne l'évolutivité de votre système d'information sur le long terme, j'en ai souvent parlé . Ne vous méprenez pas, le sujet n'a rien de technique. Il est généralement porté par des tech guys, qui s'appuient sur les heuristiques du Domain-Driven Design, mais la délimitation des fameux bounded contexts repose bien sur l'étude de votre métier. Autrement dit, c'est un sujet totalement fonctionnel, tant et si bien que cette modularité structurera souvent votre offre produit, vue du client.

Les processus et la modularité vous offrent une vision globale, en largeur, du système que vous souhaitez construire. Le User Story Mapping (Jeff Patton) est un outil de gestion du backlog qui conserve et s'appuie sur cette vision transversale, mais cette fois-ci centrée sur l'utilisateur et sa User Journey. Car c'est bien là le problème de la gestion de backlog : à trop ordonner des tickets, on a tôt fait d'oublier l'utilisateur, même si ces tickets  sont censés être des User Stories. Peu importe à un manager de pouvoir s'authentifier par reconnaissance de l'iris si ensuite l'application ne lui permet pas de valider cette demande de congés.

La conception fonctionnelle est un exercice subtil, qui demande de travailler dans le détail (exploration "en profondeur") sans jamais perdre la vision globale (exploration "en largeur", que nous venons de voir). L'Example Mapping (Matt Wynne) est à mon sens la pratique idoine  pour descendre à la granularité la plus fine (règles de gestion, exemples/tests), découvrir tout un tas de cas limites et constater, une fois de plus, que le diable se cache dans les détails. Cette pratique fait la différence entre le tout-venant des produits sur le marché et un très bon produit. À noter que cet exercice alimente également le backlog : à mesure que l'on va dans le détail, il devient évident que l'on ne pourra pas tout implémenter à la fois…

L'Example Mapping va avec son propre formalisme, mais rien ne vous empêche de l'enrichir, le but étant que les différents acteurs autour de la table (PM, Dev, QA) se comprennent et épuisent autant que possible la complexité du sujet. Dans cette perspective, vous voudrez peut-être établir un Modèle Conceptuel de Données (un par bounded context). Le MCD ou "diagramme entités/relations" fait émerger les concepts du domaine – parfois implicites – et les relations qui les lient. Cette modélisation est indépendante de tout paradigme de langage, notamment la programmation orientée objet : le MCD n'est pas un diagramme de classes. Il modélise le "quoi", pas le "comment".

De manière générale, à vous de trouver le bon formalisme pour être efficace : ce seront parfois des maquettes d'écrans (n'hésitez pas à commencer par un simple crayonné, idéal pour laisser libre cours à la pensée), parfois des diagrammes de séquence UML, des diagrammes d'états-transitions pour représenter le fonctionnement d'un automate fini ou bien encore une matrice de rôles et droits applicatifs dans le cadre d'un système de contrôle d'accès basé sur les rôles (RBAC).