Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Gestion de projet agile
  3. Analyser et formaliser le besoin en agile
Extrait - Gestion de projet agile De la définition du besoin à la livraison d'un produit de qualité
Extraits du livre
Gestion de projet agile De la définition du besoin à la livraison d'un produit de qualité Revenir à la page d'achat du livre

Analyser et formaliser le besoin en agile

Introduction

Dans ce chapitre, que nous pouvons qualifier de chapitre cœur de cet ouvrage, nous présenterons une démarche d’expression des besoins éprouvée et robuste dans un contexte agile et détaillerons toutes les activités nécessaires, depuis l’analyse des besoins jusqu’à la définition d’une solution. Nous consacrerons du temps à la phase d’exploration et à la phase de préparation car ce sont des moments importants dans le cycle agile. Un focus sera fait bien évidemment sur la notion d’histoire utilisateur et sur la manière de documenter et de gérer le Backlog du produit.

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.

1. Au niveau du Portfolio Management

La gestion de portefeuille (Portfolio Management) permet de comprendre une suite de changements dans une organisation. Afin de connaître, comprendre et suivre l’ensemble des projets présents dans une entreprise, la gestion de portefeuille a pour objectifs d’identifier et d’évaluer chaque projet, afin de pouvoir ensuite leur donner une priorité.

Même si l’agile offre un moyen flexible de s’adapter au changement, il faut toujours gouverner, arbitrer, contrôler, suivre et prendre des décisions. L’agilité va nécessiter une gestion différente des changements dans l’organisation en adoptant...

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

1. Innovation

L’innovation n’est pas quelque chose de nouveau. Depuis la nuit des temps, l’homme a toujours su trouver de nouvelles solutions pour s’adapter aux changements de son environnement. Dans un monde où les besoins des utilisateurs et leurs usages changent de plus en plus vite, où la digitalisation va bon train, l’innovation est devenue aujourd’hui incontournable pour les entreprises. Ces dernières doivent s’adapter et innover, sinon elles meurent.

Contrairement à l’invention ou à la découverte, l’innovation n’est pas la création de quelque chose de nouveau, c’est le fait d’apporter une amélioration à un produit existant en répondant aux besoins des utilisateurs tout en procurant un avantage compétitif à l’entreprise.

Dans le domaine de l’ingénierie, l’innovation permet de trouver des solutions à des problèmes complexes en faisant appel à l’expérimentation et à la mise en œuvre des idées nouvelles.

2. Conception orientée utilisateur

La conception orientée utilisateur, ou centrée utilisateur, est plus récente. Elle consiste à considérer les utilisateurs et leurs besoins tout au long du processus de développement d’un produit. Une norme internationale ISO 13407, devenue ISO 9241-210, a même été rédigée pour cadrer cette approche.

La norme ISO 9241-210 définit les conditions de mise en œuvre d’une approche centrée sur l’humain, principalement sur des critères d’ergonomie et d’utilisabilité, avec la définition de cinq principes :

  • Préoccupation constante des utilisateurs, de leurs tâches et de leur environnement.

  • Participation active de ces utilisateurs dans le recueil de leurs besoins et la transformation en exigences (fonctionnelles et non fonctionnelles).

  • Répartition appropriée des fonctions entre les utilisateurs et la technologie.

  • Conception des solutions de manière itérative, jusqu’à ce que la solution satisfasse les exigences des utilisateurs.

  • Intervention d’une équipe de conception multidisciplinaire.

Nous...

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.

1. Bénéfices du Story Map

Les bénéfices du Story Map sont nombreux :

  • Meilleure visibilité sur le flux de travail (workflow) et/ou la chaîne de valeur. 

Sur l’axe horizontal du Story Map et de la gauche vers la droite, nous pouvons matérialiser toutes les étapes du flux de travail et/ou de la chaîne de valeur.

  • Meilleure visibilité sur les features du produit.

De manière exhaustive, il est possible en seul coup d’œil de voir l’ensemble des features à réaliser pour le produit.

  • Support à de nombreuses discussions et échanges.

La construction et la maintenance du Story Map nécessitent de nombreuses discussions et échanges au sein de l’équipe, c’est donc un très bon support à la communication.

  • Mise en perspective des activités macroscopiques à mener.

Le Story Map permet de se projeter sur le moyen et le long terme. Il permet alors d’éviter la perte de sens qui peut être ressentie avec l’utilisation d’itérations courtes au sein du projet.

  • Organisation du travail à faire.

Le Story Map permet de structurer le travail à faire et de pouvoir ainsi affecter des activités à réaliser à différents niveaux de responsabilité.

  • Priorisation du travail à faire.

Grâce à quelques...

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.

1. Initialisation du carnet de produit

Dans l’absolu, l’initialisation du Backlog Produit devient possible dès lors que des informations ont été recueillies auprès des parties prenantes et qu’une vision du produit a été posée. Cette condition pourrait paraître suffisante pour créer une première version du Backlog, mais nous conseillons fortement de ne pas se précipiter et de travailler si possible en amont avec la technique du Story Mapping, dont nous venons de voir tous les bénéfices.

Pour initialiser le carnet de produit, une des premières choses à réaliser va être d’identifier les différents thèmes et caractéristiques du produit. Cette identification se fait généralement lors d’ateliers avec les utilisateurs et les métiers. L’objectif est d’arriver à une première liste de features et d’y associer ensuite les rôles d’utilisateurs.

La première version du Backlog peut être assez facilement construite à...

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 :

images/rfig3-y.png

Figure 52 - Modèle de feature

  • Numéro : la feature doit être identifiée avec un numéro, ce numéro doit être unique et invariant.

  • Nom : le nom de la feature doit également être unique et suffisamment explicite du point de vue de l’utilisateur ou du métier. Il est d’usage d’exprimer le nom sous la forme <verbe> + <complément>.

  • Description : il s’agit de fournir une description succincte de la feature sous forme textuelle. Ce texte est libre de tout format.

  • Hypothèse de bénéfices : il s’agit de lister tous les bénéfices apportés par la feature dans le cas où celle-ci serait réalisée. Ces bénéfices peuvent être...

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).

images/fig3-49.png

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...