Comment j’écris un webservice ou une API dans ma Usertory ?

Tout d’abord, c’est quoi une API ?

API vient de l’acronyme d’Application Programming Interface. Il s’agit d’une solution informatique qui permet de faire communiquer différentes applications par échanges de services ou de données.

Comment je l’écris ? … Tout simplement, vous ne l’écrivez pas !

La réponse est peut-être un peu brute, mais vraie. Nous n’écrivons pas d’API dans nos stories. Le rôle d’un Product Owner et d’un Business Analyst n’est pas d’écrire une solution technique, mais bien d’expliquer le besoin fonctionnel du client ou de l’utilisateur. En fonction de ce besoin, l’équipe de Développement définira la solution la plus appropriée … et donc sûrement la mise en place d’une API.

Dans nos userstories, il faut indiquer le besoin fonctionnel et non la solution technique.

A éviter

En tant que client

Je veux la mise en place d’une API Client

Afin de vérifier que je suis bien client

A privilégier

En tant que client

Je veux que mon statut de client soit vérifié avec un compte auto en cours

Afin de continuer mon parcours de tarification auto et recevoir une tarification appropriée en fonction de mes avantages client

Pourquoi ?

On constate que le besoin de l’utilisateur n’est pas d’avoir une API, mais plutôt que l’on vérifie qu’il soit bien client pour avoir une tarification adaptée à son statut de client.

Lorsque vous écrivez vos Userstories, ayez toujours en tête que ce que vous écrivez doit fonctionner quelle que soit la solution technologique.

Dans notre exemple ci-dessus, plusieurs solutions techniques peuvent apparaitre (une API, un fichier Excel … voire même un agent qui recherche dans ses dossiers papier …), mais pour le client son besoin n’aura pas changé.

Imaginez un jour que la techno API devienne obsolète et que l’on doivent la remplacer par une nouvelle technologie. D’un point de vue fonctionnel, le besoin reste le même. Il s’agira uniquement une migration d’une technologie vers une autre.

Le cas particulier d’un IT Refresh

Dans le cas d’un IT Refresh (ITR), si la connaissance a été perdue, cela peut être considéré comme une dette fonctionnelle. Il est donc préconisé de travailler avec des Userstories et non des Technical Stories pour redéfinir les règles avec le métier et la squad, dans le but de se créer une documentation vivante.

Comment préparer la solution technique ?

Cette préparation doit se faire au plus tôt avec l’équipe de Développement et de Test.

Imaginons une équipe qui découvre uniquement le sujet lors du 3 amigos. il faudra nécessairement :

• Passer la carte en phase d’analyse technique avant tout développement,
• Etudier et valider les solutions techniques,
• Contacter en urgence les contributeurs en croisant les doigts pour qu’ils soient disponibles,

Cette userstory ne sera pas terminée avant un certain temps alors que le Métier attend impatiemment ce sujet car il l’a priorisé comme un “Must Have”.

Pourquoi la préparer au plus tôt ?

• Pour impliquer l’équipe, lui donner le sens de la problématique à résoudre et du temps de réflexion,
• Pour lister les dépendances,
• Pour lister les contributeurs à impliquer,
• Pour remonter au plus tôt les risques (disponibilité, planning …),
• Pour prioriser et adapter notre roadmap en conséquence.

Les ateliers d’Event Modeling

Ces ateliers participatifs permettent d’échanger, de réfléchir sur les solutions fonctionnelles et techniques avec le Métier, les équipes de Réalisation, l’Architecture.

Pour notre question sur la constitution d’une API dans une Userstory, l’Event Modeling permettra à toute l’équipe de préparer son écriture et son découpage.

Un outil efficace pour :

• Une compréhension commune de la problématique,
• Avoir un langage commun avec le Métier,
• Remonter les risques très tôt dans le projet,
• Remonter des dépendances entre technologies,
• Préparer l’écriture et le découpage des Userstories.

En Feature Team ou en Component Team ?

Il est évident que les dépendances pour le développement des fonctionnalités seront différentes en fonction de votre type d’équipe.

- Vous êtes en Feature Team : vous avez surement les profils adéquates pour développer les fonctionnalités. Nous n’aurez pas/peu de dépendances avec d’autres équipes.

- Vous êtes en Component Team : vous dépendez d’autres équipes pour développer les fonctionnalités. Il sera nécessaire de les embarquer, de vérifier la priorité de vos sujets dans leurs équipes, leur planning …

L’écriture de cette Userstory

Très souvent, les équipes suivent les étapes suivant lors de la mise en place d’une API :

1. Création d’un socle technique (Technical Story),
2. Mise en place des appels techniques entre l’outil appelant et l’API (Technical story),
3. Ajout des différentes règles fonctionnelles (Userstories).

Mais, ces étapes ne sont pas recommandées car elles apportent tardivement de la valeur ajoutée business et une complexité pour tester des sujets purement techniques. Il est donc privilégié de démarrer directement en ajoutant itération par itération des règles fonctionnelles.

Pourquoi ?

Cela permettra :

• D’apporter rapidement de la valeur à votre produit,
• D’avoir du feedback du Métier en lui présentant les premiers résultats,
• De faciliter les tests en évitant au Testeur de renter dans le technique en consultant des tables, en lançant des Soapui etc. pour obtenir le résultat attendu.

Etant Agile, il s’agit d’apporter de la valeur fonctionnelle, même minime, mais au plus tôt.

Prenons un exemple

On demande à 2 squads de créer un service de détection client.

Pendant l’Event Modeling, elles ont constaté le besoin de créer une nouvelle API se basant sur les informations d’un service de recherche du client.

Les 2 squads ont fait un choix de découpage différent de la fonctionnalité :

Squad 1 : “Nous choisissons le découpage en 1 Technical Story et 1 Userstory”.

Squad 2 : “ Nous choisissons le découpage par incrémentation en plusieurs Userstories”.

Les équipes développent la 1ère story, puis, réalisent que le développement de l’API est plus complexe que prévu. En résumé, ils ne pourront pas traiter la 2ème story pour cette version/sprint.

Voici le résultat obtenu à la fin de la version/sprint :

Squad 1 : “Nous n’avons pas encore apporté d’évolution fonctionnelle pour l’utilisateur final.”

Squad 2 : “ Notre service répond déjà à une question simple nécessaire pour l’utilisateur final”.

En conclusion

Dans vos réflexions de découpage, posez-vous toujours la question :

Notre découpage apporte-t-il de la valeur au plus tôt ?