Accueil > Méthodes Agiles, Web > Passage de Spécifications Fonctionnelles aux User Stories

Passage de Spécifications Fonctionnelles aux User Stories

Je vais vous présenter un retour d’expérience sur la mise en place des Récits Utilisateurs (ou US : User Stories) chez un grand opérateur téléphonique français dans le cadre d’une mission de validation / Product Owner (PO) sur laquelle je suis intervenue. La méthodologie de gestion de projet est la méthode Agile Scrum adaptée au contexte client. L’organisation était la suivante : une équipe de développement composée de 11 développeurs, 4 MOE et un poste de validation interne , une équipe AMOA, une équipe MOA, une équipe de Recette. Au début de la mission, j’occupais le poste de validation interne pour ensuite évoluer vers un poste de PO.

Le problème des spécifications fonctionnelles incohérentes

Les Spécifications Fonctionnelles (SF)  livrées par l’équipe AMOA étaient souvent volumineuses; ce qui impliquait une réelle perte de temps pour que l’équipe de développement puisse accéder aux règles métiers à implémenter. De plus, comme cela est souvent le cas avec un turnover fréquent des équipes, j’ai pu effectuer les constats suivants :

  • Beaucoup d’évolutions fonctionnelles étaient formulées via des fiches de demande d’évolution qui n’étaient pas systématiquement reportées dans les SF.
  • Les AMOA responsables de ces évolutions étaient souvent différents, ce qui provoquait des problèmes de cohérences dans les différentes demandes.
  • Énormément d’aller-retour entre l’équipe de développement et la MOE, et entre ces derniers et les  AMOA.
  • Il y avait  souvent des décisions prises oralement et non reportées sur les SF. Beaucoup de perte d’informations.
  • Un développement non conforme aux règles spécifiées.
  • La MOE était souvent interrompue dans son travail.

Comme dans la plupart des missions, j’ai débuté par une lecture des SF pour monter en compétence sur le fonctionnel. Ce fut une étape très compliquée pour moi car j’avais d’un côté des spécifications très volumineuses et de l’autre des applications  non conformes aux SF. En conséquence, il m’arrivait souvent d’ouvrir des tickets JIRA pour tracer des anomalies qui, après discussions avec l’équipe de développement et le chef de projet, s’avéraient non fondées pour la simple raison que les SF n’étaient pas fiables

Au début, je trouvais cette excuse assez facile, mais au fil du temps, je m’en suis vite rendu compte car je constatais beaucoup d’incohérences, ce qui m’amenait à échanger souvent avec l’équipe AMOA pour essayer d’identifier le vrai du faux. Mais je vais vous le dire franchement, il était juste impossible de continuer à fonctionner comme cela.

Lors de nos rétrospectives, le problème de mises à  jour des SF était souvent abordé tout en sachant que nous n’avions que peu d’actions là-dessus puisque le problème venait d’une autre équipe à savoir l’équipe AMOA.

Pour essayer de résoudre ce problème et d’améliorer l’efficience ainsi que la productivité de l’équipe, mon responsable a fait appel à deux coachs agiles. Quand ils sont arrivés, ils ont commencé par étudier notre pratique de Scrum :

  • Les chefs de projets tenaient un backlog sous forme de fichier excel  qu’ils remplissaient avec l’ensemble des fonctionnalités à développer.
  • Les fonctionnalités étaient chiffrées lors des planning meeting qui avaient lieu au début de chaque sprint.
  • Un ou plusieurs développeurs étaient identifiés pour travailler sur chaque fonctionnalité embarquée dans le sprint.
  • Avant de commencer à développer une fonctionnalité, le ou les développeurs concernés étaient obligés d’aller fouiller dans les SF pour identifier quelle partie était concernée ; tâche non aisée à la vue de la volumétrie.

Afin de remédier à tous ces problèmes, nous avons instauré une composante de Scrum, les User Stories.

Passage de spécifications fonctionnelles aux User Stories

Formation à l’écriture des User Stories

Nous avons démarré ce coaching par une formation à l’écriture des User Stories sous forme d’atelier. A chaque atelier, un développeur était convié afin de prendre son avis sur la mise en place des User Stories et mieux évaluer leurs besoins pour les développements. La  première étape était d’identifier les différents utilisateurs des applications afin de mieux cerner le périmètre de chacun pour ensuite créer les Personas . Ceci est une étape importante dans la définition des User Stories.

Exemple de Persona:

Après avoir bien cerné le périmètre du projet, nous sommes passés au découpage des fonctionnalités en User Stories; ainsi,  une fonctionnalité, suivant son importance, pouvait être découpée en une ou plusieurs User Stories. Une User Story est un ensemble de scénarios permettant réaliser en partie ou en globalité une fonctionnalité du projet/produit.

Exemple de fonctionnalité: Affichage de la liste des offres auxquelles je suis éligible.

Traduction en user story, on commence par énoncer le contexte de la manière suivante :

IN ORDER TO souscrire une offre
AS web   (Utilisateurs autorisés à réaliser cet acte)
I WANT TO  voir la liste des offres auxquelles je suis éligible

Ensuite, décrire les différents scénarios permettant d’arriver à ce résultat.

GIVEN je suis sur le canal web
GIVEN j’ai saisi le numéro de ma ligne
GIVEN je suis éligible offres ADSL et OU Fibre
WHEN je clique sur le bouton « Valider »
THEN la page de sélection d’offres s’affiche avec la liste des offres auxquelles je suis éligible

Comment découper une fonctionnalité en User Stories

La plus grosse difficulté était de savoir comment découper une fonctionnalité de sorte qu’une User Story puisse contenir en partie ou en totalité le besoin fonctionnel. Une User Story ne doit pas être trop grosse fonctionnellement et techniquement, le but est qu’elle ait une complexité  telle qu’elle puisse être réalisée sur une itération. Les User Stories étaient ensuite regroupées, priorisées pour former une Storymap sur notre board et puis créées dans JIRA pour assurer leur historisation.

Ci-dessous une photo de notre board; la colonne « A faire » contient l’ensemble des US chiffrées, prêtes pour le développement. Celles-ci sont priorisées suivant la date de livraison des projets en cours. Quand une US est prise par un développeur, celui-ci la déplace dans la colonne « En cours » et puis pose son avatar dessus et remplit son trigramme et la date de début du développement; il fait évoluer le statut de l’US dans JIRA pour la faire passer en « In progress » et ainsi de suite jusqu’à ce qu’elle soit complètement terminée.

Pendant ces ateliers, nous traitions des cas concrets; ainsi, au bout de quelques séances, nous avions établi un modèle standard afin d’avoir une manière unique permettant de décrire une fonctionnalité. Nous nous sommes donné une marge de six mois avec les coachs agiles  pour mettre en place au fur et à mesure cette méthodologie  et avant de laisser définitivement les SF de côté. Mais la bonne nouvelle est que l’équipe de développement l’a adopté dès sa mise en place!

Voici un exemple de fonctionnalité développée pour la réalisation du projet « Mise en place du mandat SEPA sur le parcours de souscription des offres aux lignes fixes« .

Fonctionnalité: Gestion du paiement par prélèvement automatique

L’objectif de cette fonctionnalité est de soumettre au client un formulaire de saisie avec tous les renseignements nécessaires  pour la génération du mandat Sepa et de descendre ces informations dans le système d’information.

Elle a été découpée en deux US:

  • Mise en place de la page de paiement

IN ORDER Pouvoir fournir un mandat SEPA aux clients
AS Tous canaux de vente
I WANT TO payer ma commande par prélévement automatique

AFFICHAGE DES CHAMPS DE SAISIE DES COORDONNÉES BANCAIRES

GIVEN Je suis arrivé sur la page de paiement
GIVEN SEPA embrayé
WHEN je choisis un mode de paiement par prélévement bancaire
THEN la page de saisie des coordonnées bancaires s’affiche
THEN les champs de saisie du code IBAN sont affichés en premier
THEN En dessous de l’IBAN, le champ de saisie du code BIC est affiché
THEN En dessous du champ BIC est affiché le wording suivant: « Voir un exemple ». Au passage de la souris sur « Voir un exemple » un layer explicatif du BIC IBAN apparait en effet roll over. L’exemple utilisé est celui existant sauf qu’il n’est pas directement intégré dans la page comme c’est fait actuellement
THEN En dessous, est affiché le wording suivant: « Le titulaire du compte est il le titulaire de la ligne ? »
THEN En dessous, sont affichés deux radios boutons « oui » et « non »; aucun radio bouton n’est précoché
GIVEN l’étape précédente terminée
WHEN Je clique sur « Continuer » sans cocher un radio bouton
THEN le message d’erreur « Vous devez préciser si le titulaire de la ligne est également le titulaire du compte bancaire. » est affiché en rouge au dessus de l’IBAN (voir pj.)

CAS 1: TITULAIRE LIGNE = TITULAIRE COMPTE BANCAIRE

GIVEN Le titulaire de la ligne est le titulaire du compte bancaire
WHEN je coche le radio bouton « Oui »
THEN Les champs « Nom du titulaire du compte » et « Prénom du titulaire du compte » sont affichés préremplis en majuscule par le nom et prénom du client saisi sur la page de coordonées; ces champs sont grisés. (voir pj)

CAS 2:TITULAIRE LIGNE != TITULAIRE COMPTE BANCAIRE

GIVEN Le titulaire de la ligne est différent du titulaire du compte bancaire
WHEN je coche le radio bouton « Non »
THEN Les champs « Nom du titulaire du compte » et « Prénom du titulaire du compte » sont affichés et vides et sont en saisie libre
THEN Un entonnoir de saisie de l’adresse du tiers payeur est affiché (voir pj.)
THEN je peux rebasculer sur le radio bouton « Oui » et le « CAS 1″ est traité
  • Validation paiement :

IN ORDER Finaliser la souscription d’une offre SRR
AS Tous canaux de vente
I WANT TO valider la page de paiement
GIVEN SEPA embrayé
GIVEN je suis arrivé sur la page de paiement
GIVEN j’ai choisi un paiement par prélévement automatique
GIVEN j’ai fini de remplir mes coordonnées bancaires
WHEN je clique sur le bouton « Continuer »
THEN le webservice de gestion de mandat SEPA est appélé avec la liste des informations en pj.
GIVEN L’appel du webservice de gestion de mandat SEPA terminé
WHEN Le webservice est indisponible
THEN une page d’erreur s’affiche avec le message suivant « Notre service est actuellement indisponible. Veuillez réessayer ultérieurement. Nous nous excusons pour cet inconvénient. »
THEN Blocage du parcours

OU

GIVEN L’appel du webservice de gestion de mandat SEPA terminé
WHEN Le webservice est disponible
THEN le webservice génére une RUM et l’envoie aux fronts avec les éléments en pj.
THEN les informations saisies sur la page de paiement sont descendues dans le SI
THEN La page de confirmation de la commande s’affiche

 

Points forts de cette expérience

Ce fut un partage de connaissances très intéressant car, même si  j’avais déjà eu une première expérience dans l’écriture des US,  cela m’a tout de même permis de voir une autre manière de les écrire tout en gardant la même logique.

Les fonctionnalités étaient décrites plus simplement et sont donc plus compréhensibles, il n’y a plus de risque d’oubli de règles fonctionnelles. Les développeurs ont adopté rapidement cette nouvelle méthodologie, le gain de temps au niveau des développements est énorme car il y a moins d’aller-retour entre PO, AMOA et développeurs, les fonctionnalités sont bien cernées avant d’entamer les développements et l’équipe s’en retrouve plus productive.

Les éventuels problèmes étaient identifiés en avance de phase pendant l’étude et écriture des US.

Nous avons gagné plus de temps sur la recette interne car tous les scénarios étaient déjà décrits dans les User Stories  et nous avons réussi à développer et tester les User Stories dans un même sprint.

Points faibles

Les User Stories étaient créées dans JIRA et classées par projet; dans chaque ticket JIRA nous rajoutons l’étiquette du projet pour créer facilement des filtres; en plus de l’étiquette du projet et l’étiquette « OnBoard » qui signifie que le post-it est créé est collé sur le board. Une fois la User Story validée, on la sort du board à la fin du sprint. Le problème qui se posait malgré tout cela était de savoir comment retrouver une US fermée après quelques  années.

Synthèse

Après une année de pratique de cette nouvelle méthodologie, je peux vous dire qu’elle est d’un succès  inestimable.

La solution que nous avons établie  pour historiser les US est de créer un manuel dans Confluence contenant les applications ainsi que les évolutions apportées sur celles-ci. Ainsi, pour chaque projet nous décrivons le contexte et puis reportons les User Stories associées. Celui-ci est mis à jour par chaque PO à la fin de l’étape d’écriture des US.

  1. 28/05/2016 à 17:48 | #1

    Au cours des prochains mois, je vais accompagner une organisation à effectuer une transition similaire. Je vais m’inspirer de votre texte pour mettre en évidence les leçons apprises…

    Excellent article. Félicitations. Et MERCI pour le partage.

  1. 13/03/2014 à 15:20 | #1


neuf − 4 =