07 - Modèle de structuration des exigences

La description de l’usage des récits utilisateurs, ainsi que les techniques à employer pour les rédiger correctement font l’objet de nombreuses communications. Au-delà de la rédaction - modèle 3C, SMART, INVEST - divers autres critères ou techniques de structuration et d’organisation sont aussi à considérer lors des étapes de leur utilisation en développement.

Reprendre l’explication du concept de Récit Utilisateur (US) ainsi que leurs spécificités : (définition de READY), estimation (Planning Poker Game), priorisation (WSJF, MoSCoW), ou bien leurs validations technique ou comportementale (définition de DONE)n’est pas le but de cette chronique. Nombreux sont ceux qui - au-delà du principe théorique - offrent sur leurs blogs de précieux conseils pratiques. Par contre, je ne pouvais totalement exclure un minimum de description afin de préparer les deux "cartouches" suivants (08 - Estimation et contrat de réalisation (métrique des demandes de changements) et (09 - Notion de backlogs fonctionnel, technique et organisationnel). De plus, l’usage des US comme de leur regroupement en Features a déja fait l’objet d’un traitement ici (05 – Consensus produit ou service / Impact mapping - Story mapping).

Tout commence avec des objectifs SMART

Avant toutes autres considérations techniques, le primordial nécessite de comprendre les services attendus du produit à développer - globalement mais avec exactitude. Cette analyse implique aussi bien les aspects fonctionnels que technologiques, mais surtout les impacts organisationnels en matière de ressources humaines et bien d’autres interdépendances ou contraintes (figure suivante : carte conceptuelle du contexte). L’ensemble de ces informations peut provenir d’une session de Design Thinking (aspect traité dans le cartouche 04).

Note : l’interdépendance de ces techniques permet difficilement d’en connaître la précédence ou la prédominance.

Rédiger des récits utilisateurs détaillés nécessite de s’appuyer sur des objectifs exprimés de préférence dans un format non ambigu qualifié de "SMART". Ce standard se présente selon des critères définis par les lettres de l’acronyme : Spécifique, Mesurable, Acceptable, Réaliste, Temporellement défini. Les objectifs ainsi répertoriés sont réputés "complets", donc ne nécessitant pas d’explication supplémentaire à leur compréhension globale. Il en découle une capacité de vérification validant qu’un objectif SMART est atteint. En revanche, le développement proprement dit exigera du métier une spécification plus détaillée ; mais un respect relatif du formalisme SMART facilite ensuite la rédaction progressive de récits utilisateurs opérationnellement développables.

Le(s) Backlog(s) regroupe(nt) les User Stories

Dans un contexte Agile, la liste des fonctionnalités à produire (backlog regroupant un ensemble d’US) se présente dans un premier temps comme une vision sommairement détaillée du futur produit - mais assez exhaustive pour permettre à une équipe de comprendre et d’estimer son développement. A ce point il n’est pas question d’autre chose, puisque dans un contexte réellement Agile, la spécification détaillée, le codage, les tests techniques et la validation fonctionnelle permanente se feront lors d’une seule étape engageant simultanément le métier et des membres de l’équipe de développement. Bien évidemment, lorsqu’une vraie méthode agile ne peut être mise en œuvre (ressources délocalisées et non engagées à temps plein dans la réalisation), il sera alors nécessaire de - plus ou moins - revenir à l’ancien mode de spécification. En clair, si les modes projet et plateau ne peuvent être effectifs, les dangers découlant d’une pseudo agilité sont tels qu’il est préférable d’abandonner la démarche Agile et de s’en tenir à des spécifications détaillées classiques. Le plus souvent, dans la réalité, il sera tenté de mettre en œuvre une hybridation des deux approches. A chacun la responsabilité de ses choix en regard, au final, des succès ou des échecs relatifs et du recours au qualificatif "Agile". C’est de l’ambiguïté de cette situation que découle la nécessité d’une notion de "READY" (une obligation de spécification détaillée précédant l’étape de test/codage / validation), et de celle de "DONE" (une obligation de remplir un certain nombre de conditions afin d’obtenir l’acceptation de la fonctionnalité par le métier). Dans ce cas, il convient de prévoir aussi la préparation préalable d’un nombre de récits permettant de répondre aux besoins de deux sprints (au minimum).

Citation : Selon Alexandre Bourret (NutCache.com) "On ne détaille une fonctionnalité que si celle-ci doit être réalisée dans le prochain sprint. De cette façon, il est possible de profiter de l’expérience déjà acquise lors des sprints précédents, mais également de s’adapter beaucoup plus facilement et rapidement à des demandes de modifications ou à des changements de priorité des clients."

Comment rédiger une User Story

3C, la communication avant tout

Depuis ses origines, XP recommande d’utiliser la formule 3C proposée par Ron Jeffries. Selon son expertise, une User Story représente la conjonction de trois éléments :

1 - le Carton ou Post-It, qui permet de donner une forme tangible et durable au besoin métier.

2 - une Conversation éventuellement en plusieurs étapes d’approfondissement impliquant l’ensemble des personnes concernées.

3 - la Confirmation qui consiste à formaliser le consensus obtenu au sujet de la pertinence descriptive de l’objectif de l’US.

Citation : Martial SEGURA (Blog Œil de Coach) recommande que le Product Owner rédige les User Stories collégialement avec le couple « développeur-testeur : "pour s’assurer de la bonne compréhension et de la complétude des récits de l’utilisateur. Par expérience, ce mode de travail à 3 est plus long au moment de la spécification mais le temps investi, en amont, est largement rentabilisé lors de l’exécution des tests et des livraisons. Ce fonctionnement apporte une vraie cohésion par une meilleure compréhension, une meilleure qualité et une meilleure collaboration entre chaque membre de l’équipe."

INVEST, le formalisme d’un standard

INVEST, un acronyme et une astuce mnémotechnique permettant de retenir les caractéristiques d’une bonne rédaction d’User Story :

I - Indépendante : une US doit se suffire à elle-même (dans la limite d’un sprint), car les dépendances induisent des problématiques de testabilité et de planification.

N - Négociable : une US devrait pouvoir être modifiable jusqu’à son inclusion dans un sprint. La concision de sa description initiale a pour but de permettre l’adaptation de détails au moment du développement. Note : pour pouvoir la modifier en cours de développement ou même ensuite sans déséquilibrer le « contrat projet », il faut disposer d’une métrique des changements (cartouche 11 à venir).

V - Valuable : une US a pour objectifs d’apporter une fonctionnalité utile au métier ou à l’utilisateur final. Cette notion de « valeur » se trouvant généralement difficile à évaluer financièrement à ce niveau, l’intérêt de l’US sera exprimé dans une vision de l’objectif à atteindre lequel sera calibré relativement aux autres dans un range de 1 à 10 (comme avec SAFe).

E - Estimable : une US doit être (dans un premier temps) décrite à un niveau de détail « nécessaire et suffisant » pour que l’équipe de développement soit en capacité de l’estimer, généralement lors d’une séance de Planning Poker Game (qui aurait mieux fait de se nommer : Étape de compréhension et d’estimation consensuelle).

S - Small : une US doit rester d’une granularité suffisamment fine permettant de la développer lors d’un sprint unique.

T - Testable : une US doit préciser, avant d’être acceptée en développement, les cas de tests permettant de valider son comportement.

Respecter ces consignes à la lettre serait l’idéal, mais dans la réalité des développements certaines de ces considérations sont plus ou moins systématiquement oubliées. L’important s’avère alors le résultat concrètement obtenu plus que la forme méthodologique par elle-même. Astuces : rédiger les règles de gestion dans le style « cas de tests »

SMART, des utilisateurs et des objectifs

Avant même d’écrire des récits utilisateurs, il est indispensable d’identifier nos utilisateurs types (Personae en Design thinking). Ensuite il faudra imaginer, lors d’ateliers impliquant ces utilisateurs, leurs interactions avec le produit (Customer journey). L’aboutissement de ces travaux s’exprimera éventuellement par un Story mapping (figure précédente).

Conseil : afin de débuter avec de bonnes bases l’écriture des récits utilisateurs, utilisez de préférence des demandes exprimées sous la forme d’objectifs dits SMART. Cette technique sera détaillée dans le cartouche "09 – Backlog structuré".

Les concepts opérationnellement structurant

Dans la réalité des projets de taille intermédiaire, et sans interdépendances majeures, la simple notion d’User Story s’avère souvent suffisante. Parfois, organiser les récits en un ou deux autres niveaux de structuration (Epic, Feature) peut s’avérer efficace en termes de décomposition de la complexité (figure suivante).

Note : Dépendant des frameworks et outils utilisés, ces concepts de structuration ne recouvrent pas les mêmes réalités. C’est particulièrement vrai pour la notion d’EPIC (grosse US à découper pour XP, niveau intermédiaire de structuration dans Jira, ou niveau supérieur d’expression des objectifs pour SAFe). Dans de nombreuses organisations, il existe des tables de correspondance entre ces abstractions, lesquelles d’ailleurs ne règlent concrètement pas grand-chose des problèmes posés. Quelle misère cette agilité dans un flou contradictoire et continu …

L’élargissement aux solutions complexes

Évidemment tout cela semblerait trop simple si toutes les organisations projetaient leur nécessaires évolutions en les cadrant dans des structures aussi basiques que celles qui viennent d’être décrites.

Note : Mon principe méthodologique de recherche a toujours été de ne pas réinventer la roue, même si celle utilisée me semble parfois ovale. En matière de développement à l’échelle ou coordonnée, le standard actuel d’amélioration continue se nommant SAFe, j’utilise donc ce framework. De plus, les "trains" (ART) de son niveau "Program" s’organisant lors d’un cérémonial en mode plateau et en mode projet, je considère donc cette étape de planification et de synchronisation - le PI Planning - comme "Agile" dans le sens original du terme (même si cela ne représente parfois que 2 ou 3 jours par trimestre).

En préalable au détail d’une structure complète adaptable à toute forme d’organisation il est nécessaire d’assimiler des notions supérieures, mais non opérationnellement structurantes au niveau des développements : les concepts de Strategic Theme et de Value Stream. Le "thème stratégique" représente le plus haut niveau de réflexion concernant la mise en œuvre d’objectifs de différenciation concurrentielle. La "chaîne de valeur" matérialise une série d’étapes et d’éléments permettant la génération d’un flux continu de profit. Dans SAFe, cette organisation de l’évolution des systèmes - intégrant la notion structurante d’EPIC- se situe au niveau "Portfolio". Plus bas se distingueront Capability et ART. L’Agile Release Train se présente comme un concept couplant un regroupement de travaux d’équipes relativement individuelles (mais en partie interdépendantes) avec une time box composée de plusieurs sprints (généralement 4 sprints de développement suivis d’un sprint d’exploration et d’organisation). La structuration basique standard des exigences d’évolution s’exprime généralement ainsi :

L’Epic (niveau Portfolio de SAFe) matérialise une importante vision de l’évolution qui nécessite une approbation du plus haut niveau avant la conception et la mise en œuvre d’un produit minimum viable (MVP). L’Epic (ou épopée) se compose de nombreux récits utilisateurs. Elle correspond souvent à une fonctionnalité principale du produit, ou une nouvelle idée, dont les détails ne seront précisés que lorsque cela deviendra nécessaire au développement. Cette approche permet d'éviter aux équipes de perdre du temps à décrire à l'avance et en détail des besoins éventuellement en évolution ou qui finalement ne seront pas implémentés.

La Capability (niveau Large Solution de SAFe) matérialise la réalisation d’un groupe de « Services » nécessitant généralement la simultanéité de plusieurs trains (ART) afin d’être obtenue lors d’un seul PI (Program Increment).

La Feature (niveau d’un groupe d’équipes nommé « Train » par SAFe) comporte un Service nécessaire à l’utilisateur dont le développement est réalisable par un seul train et lors d’un seul Program Incrément comportant généralement 5 sprints de deux semaines chacun. La feature est généralement le premier niveau nécessitant la justification d’une hypothèse de bénéfice.

La User Story (niveau équipe « Team ») est une spécification applicative de niveau comportemental (BDD, Behiavor Driven Développement). Son détail initial se limite au nécessaire et suffisant pour permettre à l’équipe (durant le Planning Poker Game) d’approfondir sa compréhension des fonctionnalités et de les évaluer en termes de charge. Priorisée par le Product Owner, l’US consiste en une fonctionnalité élémentaire dont la réalisation est possible par une seule équipe lors d’un seul sprint. L’US est le premier niveau incluant des critères de comportement et de vérification permettant son acceptation (READY) dans un sprint de développement puis sa validation fonctionnelle (DONE) par le métier.

Une notion additionnelle de "tâche" permet de décomposer des US, généralement en raison de diverses contraintes de réalisation. Des abstractions de haut niveau, généralement qualifiée de "Release" sont utilisées pour définir des évolutions progressives au niveau de Services (MMF), de MVP, ou de l’application entière. L’ensemble de ces structures se visualise dans la figure suivante.

À bientôt pour la suite de l’aventure Agile à l’échelle et coordonnée

Décrire des récits utilisateur et même leur structuration est une chose. Les estimer en termes de charge de développement, les prioriser (MoSCoW, WSJF) en est une autre qui fera l’objet du cartouche d’août (08 - Estimation et Contrat produit). Les trois principales "décompositions" organisant la mise en œuvre des développements et leurs impacts collatéraux (technologies, process, ressources humaines) sur une organisation conséquente seront traitées dans le cartouche de septembre (09 - Backlogs spécialisés).

En annexe voici quelques liens sur des articles de blogs où des aspects plus pratiques de la rédaction des récits utilisateurs sont détaillés.:

Comment rédiger vos User Stories comme Hulk ?
Comment bien créer ses User Stories ?
La User Story du myope 10 stratégies pour des User Stories suffisamment petites