Analyser et formaliser le besoin en agile

Positionnement du sujet d’analyse

Dans une organisation, l’activité d’analyse est omniprésente ; elle est réalisée à différents moments et se situe à différents niveaux d’abstraction. L’approche qui consiste à décomposer des objectifs de haut niveau (les objectifs stratégiques de l’entreprise) en objectifs de plus bas niveau (les objectifs opérationnels) est très largement répandue et s’appuie sur une terminologie utilisée depuis de nombreuses années. Or, avec l’arrivée de l’agilité, cette approche évolue et est accompagnée d’un nouveau vocabulaire.

La transformation agile des entreprises passe souvent par la création d’une nouvelle organisation, mais cette nouvelle organisation ne vient pas toujours remplacer l’ancienne. Souvent, l’organisation ancienne, hiérarchique, est conservée moyennant quelques ajustements, et une nouvelle organisation agile, en réseau et opérationnelle, est créée afin de mieux répondre aux nouveaux enjeux de compétitivité des entreprises : satisfaction des clients, réduction du "time-to-market", adaptation au changement… Certes, l’objectif final est bien d’aller vers une seule organisation agile, mais en matière...

Gestion de la demande

La demande support à un nouveau besoin peut être d’origines diverses et trouver sa source dans une opportunité d’affaires, une volonté de réduction des coûts, un changement au niveau du marché, une contrainte dans le respect de normes, de législations et/ou de réglementations, etc. Dans une approche traditionnelle, les phases d’avant-projet sont souvent baptisées étude d’opportunité, étude de faisabilité et définition fonctionnelle du besoin. Ces phases permettent de produire un cahier des charges, et c’est sur la base de ce document qu’un contrat peut être signé entre un client et un fournisseur.

En agile, les études d’opportunité et de faisabilité ne disparaissent pas et nous verrons comment elles sont réalisées. Les demandes de changement à l’origine des projets doivent être consignées, évaluées et priorisées avant de prendre la décision de les mettre en œuvre. Cette gestion des demandes suit un processus éprouvé durant lequel la demande va passer d’un état à un autre.

La gestion de la demande doit prendre en considération les objectifs de haut niveau de l’organisation et permettre la priorisation en prenant la forme d’une gestion de portefeuille appelée Portfolio Management. La gestion de portefeuille demande des compétences différentes de la gestion de projet. Elle nécessite des compétences en gestion de stratégie et gestion du risque.

Des objectifs des parties prenantes aux features de la solution

Dans le chapitre Besoins et exigences, nous avons vu les nombreux pièges pouvant exister lorsque l’on parle d’expression du besoin".

Les pratiques agiles, comme Scrum, ou les frameworks d’agilité à l’échelle, comme SAFe, fixent un cadre mais ne donnent pas beaucoup de détails (ou pas de détails) sur la manière d’identifier les besoins. On vous indique simplement qu’il faut rédiger des histoires utilisateur mais dans les faits, vous avez très peu d’indications sur la manière de les recueillir et de les identifier, sur la manière de les documenter et de les organiser entre elles. Le terme "exigence" (requirement en anglais) n’apparaît quasiment pas dans les documents officiels décrivant ces frameworks.

Si vous prenez la dernière version du Scrum Guide de novembre 2020, qui fait 15 pages, le mot "exigence" apparaît une seule fois, dans la phrase "Toute allusion au monde de l’informatique (par exemple : les tests, les systèmes, la conception, les exigences, etc.) a été supprimée."… Scrum considère que le terme "exigence" n’est réservé qu’au domaine de l’informatique, ce qui est une erreur. À aucun moment Scrum ne vous explique comment trouver les exigences sur le produit. Dans d’autres frameworks, comme SAFe par exemple, il apparaît à différents niveaux le terme NFR, Non Functionnal Requirement, mais rarement le terme Requirement seul en tant que tel.

D’ailleurs, nous pourrions nous demander pourquoi NFR apparaît un peu par surprise, alors que la notion d’exigences fonctionnelles (EF, FR en anglais) n’est pas présente de manière aussi évidente. Cela sous-entend-il que les EF sont tous ce qui n’est pas NFR ?

Ceci est un réel problème car aucun des frameworks agiles ne vous explique comment faire, aucune des pratiques agiles ne vous dit comme réaliser les activités d’ingénierie, et en particulier les activités d’ingénierie des exigences. Or l’expérience montre qu’un projet agile réussit si l’équipe agile maîtrise...

Innovation et conception orientée utilisateur

Story Mapping

Les approches agiles à petite échelle, comme Scrum, mettent l’accent sur le court terme. Le mode itératif oblige à se concentrer sur l’itération en cours et au maximum sur les deux itérations suivantes. Le risque est d’oublier l’objectif à long terme, illustré par la vision du produit.

Le Story Mapping est une technique qui permet justement de mettre en perspective l’ensemble des choses à faire. Il permet d’organiser et de prioriser le travail à faire. Contrairement à l’approche Backlog "classique", le Story Map est une représentation visuelle et est facile à appréhender.

Carnet de produit (Product Backlog)

Le carnet de produit est une liste de choses à faire et contient des items qui peuvent être de différents types. Nous y trouvons bien évidemment des histoires utilisateur, mais nous pouvons y trouver d’autres types d’items, comme par exemple des histoires techniques, des anomalies, des incidents ou des problèmes, des items pour mener des études, etc.

Une unique liste priorisée simplifie également la visibilité sur le reste-à-faire. Au lieu de séparer les demandes de changement, les corrections d’anomalies et le traitement de nouvelles histoires, l’équipe agile obtient une vue complète et claire du reste-à-faire en combinant les différents types d’items dans une seule liste priorisée. Beaucoup d’équipes agiles passent à côté de ce point en conservant des budgets pour les demandes de changement et les corrections d’anomalies. Cela trouble la vélocité de l’équipe ; une unique liste priorisée du travail à faire, indépendamment de l’origine de ce travail, offre une meilleure transparence et un meilleur axe de négociation.

Feature

Nous avons très largement utilisé le concept de feature jusqu’à présent, mais intéressons-nous maintenant à la manière dont elle est décrite et quels sont les éléments qui la composent.

Une feature permet d’identifier une caractéristique, un aspect ou un attribut d’un produit. Elle peut être fonctionnelle ou non fonctionnelle, et est toujours visible du point de vue de l’utilisateur. La responsabilité de la rédaction d’une feature est du niveau Product Management.

Une feature peut être décrite suivant le modèle suivant :

Figure 52 - Modèle de feature

Histoire utilisateur

Le concept d’histoire utilisateur (User Story) est très largement employé en agilité. Nous avons déjà introduit ce concept dans le chapitre Contexte de l’agilité, lorsque nous avons présenté le contexte général de l’agilité. Nous avons fait également le choix dans cet ouvrage de considérer que les User Stories et les Epics font partie de la famille des histoires utilisateur. La seule différence réside dans leur niveau de granularité.

1. Rédiger une bonne histoire utilisateur

Rédiger une bonne histoire utilisateur nécessite un peu de pratique. Il faut avoir à l’esprit qu’une histoire utilisateur est à la fois le support de l’expression d’un besoin du point de vue de l’utilisateur, et un élément de planification. C’est pour cette raison que sa rédaction nécessite une collaboration forte entre le Product Owner et l’équipe qui va réaliser l’histoire.

La rédaction d’une bonne histoire utilisateur nécessite une compréhension du contexte métier et de la vision de la solution, mais également une capacité d’abstraction par rapport à la technique (sa mise en œuvre).

a. Modèle de description

Dans le chapitre Contexte de l’agilité, nous avons vu qu’une histoire utilisateur exprime un besoin d’un utilisateur et qu’une bonne pratique consiste à l’exprimer sous la forme "En tant que <utilisateur>, je veux <faire quelque chose> afin de <atteindre un objectif>". Cette phrase n’est que la partie visible de l’iceberg, puisqu’une histoire utilisateur est bien plus que cette simple phrase (voir les "3C" de Ron Jeffries).

Figure 53 - Attributs types d’une histoire utilisateur

Afin de gérer correctement son contenu et son cycle de vie, une histoire utilisateur est a minima composée des attributs suivants.

• Identifiant : l’identifiant est utilisé pour faire référence à l’histoire utilisateur ; il est en général composé d’un chiffre précédé des lettres "EPIC" pour une Epic, ou de l’acronyme HU (pour...