Bonjour ! Dans notre dernière leçon, nous avons appris à explorer et clarifier les demandes d'un client grâce à l'écoute active et au questionnement stratégique, notamment avec la méthode QQOQCP. Nous avons vu comment passer de la demande de surface au besoin réel, au "pourquoi" qui se cache derrière.
Aujourd'hui, nous allons franchir l'étape suivante, qui est au cœur du rôle d'un Tech Lead ou d'un Chef de Projet Technique : traduire ces besoins client en exigences fonctionnelles claires pour l'équipe technique. C'est le moment où vous devenez le pont entre le monde du client et celui des développeurs. En tant que Software Engineer, vous avez l'habitude de recevoir des exigences ; cette leçon vous apprendra à les formuler.
Nous allons aborder :
- La distinction cruciale entre un besoin et une exigence.
- Comment structurer ces exigences dans un format agile, la User Story.
- L'art de rédiger des critères d'acceptation qui rendent une exigence non-ambiguë et testable.
1. La traduction : du besoin à l'exigence
Le client exprime des besoins, des problèmes, des désirs. Votre équipe, elle, a besoin d'instructions précises sur ce que le système doit faire. Le passage de l'un à l'autre est un acte de traduction fondamental.
Pour commencer, clarifions la terminologie avec un document de référence sur l'Ingénierie des Exigences.
L'Ingénierie des exigences pour les Nuls
Ce document, "L'Ingénierie des exigences pour les Nuls", synthétise très bien les concepts de base. Il vous aidera à bien distinguer ce qui relève du problème (le besoin) et ce qui relève de la solution (l'exigence).
Veuillez consulter les diapositives (slides) 6, 10, 14 et 15. Vous pouvez y accéder rapidement en faisant défiler le document. Concentrez-vous sur : La distinction entre le "Domaine du problème" et le "Domaine de la solution" (slide 6). La différence de formulation entre un besoin ("J'ai besoin de...") et une exigence ("Le système DOIT...") (slide 10). Les différents types d'exigences (fonctionnelles, non fonctionnelles, etc.) (slide 14). Les caractéristiques d'une bonne exigence (atomique, non ambigüe, vérifiable...) (slide 15).
Ce que vous devez retenir est que votre travail consiste à transformer une phrase comme "J'ai besoin de savoir quels sont mes meilleurs clients" (un besoin) en une série d'exigences claires comme "Le système DOIT permettre à l'administrateur de générer un rapport des 10 clients ayant le plus grand chiffre d'affaires sur les 12 derniers mois." (une exigence fonctionnelle).
L'exigence doit être vérifiable. C'est ce qui la rend exploitable par une équipe technique. On ne peut pas "vérifier" un besoin, mais on peut vérifier si un système répond à une exigence.
2. Le contenant : du Cahier des Charges au Product Backlog
Historiquement, ces exigences étaient consignées dans un long document appelé cahier des charges. Bien que les méthodes agiles aient changé l'approche, comprendre l'esprit de ce document reste pertinent.
Le cahier des charges d'une application ! (web/mobile)
La vidéo "Le cahier des charges d'une application !" d'Hugo Taschet, développeur, explique très bien, avec son expérience personnelle, pourquoi la formalisation des besoins est vitale. Elle montre aussi comment des concepts agiles comme les User Stories s'intègrent dans cette démarche.
Regardez les passages suivants : De 02:46 à 05:03 : pour comprendre les conséquences concrètes de l'absence de spécifications claires. De 05:03 à 09:22 : pour saisir en quoi un cahier des charges est un "outil de travail, de communication, voire de traduction". De 16:49 à 18:07 : pour voir comment les "User Stories" sont définies comme "la fonctionnalité décrite du point de vue naïf du client".
Comme l'explique la vidéo, le client a souvent du mal à formaliser son idée. Votre rôle est de l'accompagner dans ce travail de "traduction". Dans un contexte Agile et Scrum, ce "cahier des charges" prend une forme vivante et évolutive : le Product Backlog.
Le Product Backlog est simplement une liste ordonnancée de tout ce qui est connu et nécessaire pour le produit. Chaque élément de cette liste est une exigence, le plus souvent exprimée sous forme de User Story.
3. Le format agile : la User Story
La User Story est un format simple mais puissant pour formuler une exigence en se concentrant sur la valeur apportée à l'utilisateur. Sa structure standard est :
En tant que
<type d'utilisateur>, je veux<réaliser une action>afin de<atteindre un objectif/bénéfice>.
Cette structure vous force à ne jamais oublier le "Qui" et le "Pourquoi" que nous avons vus dans la leçon précédente.
Découpage et rédaction
Une fonctionnalité complexe (par exemple, "gérer mon profil") est souvent trop grosse pour être réalisée en une seule fois. On la découpe alors en plusieurs niveaux :
- Epic : Une grande fonctionnalité, comme "Gestion du profil utilisateur".
- User Story : Un morceau de cette fonctionnalité qui apporte de la valeur, comme "En tant qu'utilisateur, je veux pouvoir changer mon mot de passe afin de sécuriser mon compte".
Pour apprendre à bien découper et rédiger ces User Stories, nous allons nous appuyer sur une vidéo très complète.
Comment bien écrire ses User Stories ?
La vidéo "Comment bien écrire ses User Stories ?" de la chaîne Thiga est une référence pratique. Nous allons la regarder en plusieurs parties pour bien assimiler chaque concept.
Regardez d'abord la section de 01:39 à 05:34. Elle explique le découpage d'une opportunité en Epics, puis en User Stories. Ensuite, regardez de 07:59 à 09:18, qui présente les critères INVEST, un excellent moyen de vérifier la qualité de vos User Stories.
Pour rappel, les critères INVEST sont un excellent guide pour s'assurer qu'une User Story est bien formulée :
- Indépendante
- Négociable
- Valeur (apporte de la valeur)
- Estimable
- Small (suffisamment petite pour être réalisée en un Sprint)
- Testable
Le Guide de démarrage Scrum (ressource LINK) que nous avons utilisé dans des leçons précédentes contient également un excellent résumé de la User Story et des critères INVEST dans sa section Annexe.
4. Rendre l'exigence claire : les Critères d'Acceptation
Une User Story seule reste une phrase. Ce qui la rend claire et non-ambiguë pour l'équipe technique, ce sont ses critères d'acceptation. Ce sont les conditions qui doivent être satisfaites pour que la story soit considérée comme "terminée". Ils forment le contrat entre le demandeur (Product Owner/client) et l'équipe de réalisation.
Un format très efficace pour rédiger ces critères est le langage Gherkin, qui utilise une structure simple : Given-When-Then (Étant donné-Quand-Alors).
Comment bien écrire ses User Stories ?
Reprenons notre vidéo sur les User Stories pour voir comment rédiger des critères d'acceptation efficaces.
Regardez la vidéo de 09:18 à 12:57. La première partie (jusqu'à 11:43) détaille la structure complète d'une User Story, incluant les fameux critères. La seconde partie (à partir de 11:43) explique concrètement comment utiliser le format Gherkin (Given/When/Then).
La structure Given-When-Then est idéale car elle décrit un comportement :
- Given (Étant donné) : Le contexte initial, l'état du système avant l'action.
- When (Quand) : L'action effectuée par l'utilisateur.
- Then (Alors) : Le résultat attendu, le changement observable dans le système.
Cela permet de décrire très précisément les cas passants, les cas d'erreur, les cas limites, ce qui est exactement l'information dont un développeur a besoin pour coder et tester la fonctionnalité.
Testez votre compréhension !
Reprenons la demande de la leçon précédente : "J'ai besoin d'un bouton pour exporter la liste de tous nos utilisateurs en PDF."
En supposant, après questionnement, que l'utilisateur est un "Administrateur Marketing" qui a besoin de cette liste pour une campagne postale mensuelle, rédigez une User Story complète.
Incluez :
- Un titre clair.
- Une description au format "En tant que...".
- Au moins deux critères d'acceptation, dont un au format Gherkin.
Show answer
Titre : Export des utilisateurs pour campagne postale
Description : En tant qu'Administrateur Marketing, je veux exporter la liste des utilisateurs actifs avec leur adresse postale afin de préparer l'envoi de notre catalogue mensuel.
Critères d'acceptation :
- Le fichier exporté doit être au format PDF et contenir les colonnes :
Nom,Prénom,Adresse,Code Postal,Ville. - Étant donné que je suis connecté en tant qu'Administrateur Marketing sur la page "Liste des utilisateurs", quand je clique sur le bouton "Exporter pour campagne postale", alors un fichier nommé
export_utilisateurs_YYYY-MM-DD.pdfest téléchargé par mon navigateur. - Étant donné qu'un utilisateur n'a pas d'adresse postale renseignée, alors il ne doit pas apparaître dans l'export.
Conclusion
Traduire un besoin client en exigence fonctionnelle est une compétence qui mélange compréhension du métier, structure et rigueur. C'est le passage obligé pour transformer une idée en un produit fonctionnel.
Points clés à retenir :
- Distinguez besoin et exigence : Le besoin est le problème, l'exigence est la caractéristique que la solution doit avoir pour résoudre ce problème.
- La User Story est votre outil principal en Agile : Son format (
En tant que... je veux... afin de...) garantit de toujours garder l'utilisateur et la valeur au centre. - Découpez pour mieux régner : Les grandes fonctionnalités (Epics) doivent être découpées en User Stories plus petites et réalisables (respectant INVEST).
- Les critères d'acceptation sont le contrat : Ils définissent ce qui signifie "terminé" et rendent l'exigence claire et testable. Le format Gherkin (
Given-When-Then) est un excellent moyen de les rédiger sans ambiguïté.
Maintenant que vous savez comment définir clairement ce qui doit être fait, une question se pose : que se passe-t-il lorsque le client veut changer d'avis en plein milieu du projet ? C'est ce que nous verrons dans la prochaine leçon, où nous apprendrons à mettre en place un processus pour gérer les demandes de changement du client en cours de projet.