Le processus de production logicielle est un long chemin. C’est un voyage passionnant mais c’est loin d’être un long fleuve tranquille ! Cela nécessite écoute du client, analyse du besoin, expertise durant toutes les phases, vision d’ensemble, gestion des ressources, travail en équipe, etc.
Cette mécanique, quand elle est bien huilée, fait des merveilles. Mais parfois, un grain de sable s’immisce dans l’un des rouages et c’est le drame.
Une image valant mieux qu’un long discours, nous vous proposons quelques exemples à ne pas suivre, tirés de notre monde matériel, pour mieux illustrer l’importance de bien maîtriser l’ensemble du processus de production en suivant quelques commandements de base.
C’est parti pour le premier épisode de cette trilogie ! Attention, certaines images peuvent heurter la sensibilité des plus rigoureux…
1- La solution doit répondre au besoin
Allez, commençons par la base. Il n’y pas de solution sans problème. Il est donc essentiel de comprendre le besoin du client avant de chercher à en produire la solution.
Si le client n’est pas très bavard, charge à nous de le faire parler, à nous de maîtriser l’art précieux de la maïeutique !
Cela tombe sous le sens mais c’est toujours utile de le rappeler.
Dans cet exemple, vraisemblement, il a manqué quelques informations au cahier des charges :
Et dans le cas où vraiment vous n’arrivez pas à comprendre ce que veut le client, nous vous conseillons de vérifier que vous parlez la même langue (on ne sait jamais).
Mais surtout, ne faites pas semblant d’avoir compris. Banissez les certitudes du genre “Oui c’est bon, ça doit être ça qu’il a voulu dire.”.
Une méthode qui a fait ses preuves consiste à reformuler de manière précise le besoin avec vos mots et à vérifier que le client valide votre formulation.
Ici, on a beau chercher, difficile de penser que quelqu’un de l’équipe a pu se dire “Là, c’est bon, on y est, il va être content le client, c’est sûr !” :
Conclusion : prenons le temps d’analyser le besoin et de formuler les exigences.
2- La solution doit satisfaire les exigences
En effet, une fois le besoin cerné et formulé, il est essentiel de préciser le cadre à respecter pour considérer la solution comme valide :
- Quels sont les impératifs à satisfaire ?
- Quelles sont les limites du cadre à ne pas dépasser ?
On appelle cela les critères d’acceptation. Travailler ces critères en amont de la production prend certes du temps mais quand on prend conscience du coût d’une rectification d’un produit, on n’hésite plus et on respecte ce passage obligé !
Il existe de nombreuses méthodes pour formuler un critère d’acceptation. L’une d’elles est le langage naturel Gherkin. Simple et facile à comprendre, il permet de décrire un cas d’usage d’une fonctionnalité. Pour cela, Il décompose un scénario de test en trois principales étapes :
- Contexte (Given)
- Action (When)
- Résultat attenu (Then)
Dans l’exemple, suivant, le besoin était sans doute “Placer ici un mode de repos.” :
Manifestement, cela n’était pas suffisant (“Oups !”).
Grâce à Gherkin, on aurait pu décrire un critère d’acceptation simple, qui aurait éviter de livrer “ça” :
“EN TANT QUE personne me baladant, QUAND je commence à resentir la fatigue ALORS je dois pouvoir me reposer.”
Notez le terme “je dois POUVOIR” ! Chaque mot est important…
Mais vous allez me dire “Mais, ça passe, vous chipotez, on peut s’asseoir, là, sur le bord.”.
Ok, on voit donc l’importance de la formulation. Je rajoute donc un critère d’acceptation :
“EN TANT QUE groupes de 3 personnes, QUAND l’un de nous commence à resentir la fatigue ALORS nous devons pouvoir nous asseoir tous les 3 en même temps.”
Mais on pourrait échanger sur le sujet pendant des heures avant de trouver un consensus. Cela montre l’intérêt de faire relire et de challenger ces exigences !
Alors on est parfois tenté de penser qu’une maquette suffit largement, que cela fait gagner du temps et qu’il est inutile de détailler par écrit parce que “baaah, ça se voit, quoi !”. Sauf que l’on ne pose pas tous le même regard sur les choses. Et ça donne parfois ce genre de choses :
C’est tellement simple, bon sang, il suffisait de préciser “je dois pouvoir monter JUSQU’EN haut” !
La communication, c’est la base… Ecrite, orale, gestuelle, peu importe, assurons-nous que nous nous sommes compris !
3- La solution doit être applicable
Parfois, la solution satisfait les exigences, malheureusement, elle n’est pas viable à cause d’un élément du contexte que l’on a oublié de préciser ou de prendre en compte. Ballot !
“Les enfant, venez voir, papa vous a préparé une surprise !” :
En fait, finalement, c’est ce qu’il se passe quand les Tests Unitaires passent mais pas les critères d’acceptation.
Et cela va encore dans le sens de soigner le processus qualité à toutes les étapes de la production logicielle. Tous les types de tests sont importants et l’un ne se substitue pas à l’autre.
Un petit dernier pour la route ? Allez :
“Ce qui se conçoit bien s’enonce clairement” donc, logiquement, tant que l’on ne parvient à formuler simplement les choses, c’est qu’il reste des zones à éclaircir.
Bonus
Et nous terminerons sur une question en bonus. Selon vous, en regardant cette capture d’écran de la solution, l’on peut dire que :
- Le client a un besoin bizarre
- Le client a mal exprimé son besoin
- L’équipe de production a mal compris le besoin
- Le ménage de fin de chantier n’a pas été bien fait, quel dommage !
On vous laisse réfléchir…
C’est fini pour aujourd’hui. La suite au prochain épisode !
Experte en qualité web, fondatrice de Gonogo Consultech : conseil en stratégie web et fournisseur de la solution HorusTest.
Optez pour une stratégie qualité pérenne ! HorusTest permet de créer et de gérer vos tests automatisés simplement, sans écrire une seule ligne de code et sans compétences techniques.
