Témoignages d'utilisateurs pour l'intégration d'API
Comment rédiger une meilleure user story pour l'intégration. Ceci est l'un des nombreux articles courts sur la rédaction de meilleures user stories avec ScopeMaster®.
De nos jours, une grande quantité de logiciels implique l’intégration de différents composants-applications pour créer un nouveau système. Par conséquent, les exigences logicielles feront souvent référence à la liaison d’un système à un autre. Ce type d'intégration consiste généralement à partager des données entre les applications logicielles. Il s’agit parfois d’un véritable échange bidirectionnel, mais il s’agit le plus souvent d’envoyer des données d’une application à une autre ou de rechercher des données depuis un système externe. Cette intégration logicielle se fait généralement via des API, telles que les API RESTful et utilise souvent des microservices.
Tournons donc notre attention vers la manière d'écrire une meilleure user story pour ce type d'intégration. C’est un domaine dans lequel j’aime beaucoup les exemples de Mike Cohn. Voici un exemple simple : un utilisateur sur une application de commerce électronique accède à la section de saisie d'adresse. Ils peuvent saisir leur code postal et une recherche vers un service externe est effectuée. Alors, comment pouvons-nous écrire au mieux ce type de user story ?
Tout d’abord, nous devons reconnaître qu’un système connecté est généralement un autre utilisateur fonctionnel. Nous devons également garder notre langage simple et clair. Il existe des centaines, voire des milliers de façons d’écrire cela. Voici juste une suggestion de formulation :
Comme un client je vouloir à ajouter mon expédition adresse, en utilisant le Posctode_lookup_api pour récupérer l'adresse complète d'un code postal
Dans ce cas, nous avons généré deux étapes fonctionnelles dans la user story. Un pour créer l'adresse et un autre qui effectue le externe chercher. ScopeMaster est capable d'identifier ces deux étapes fonctionnelles, de déterminer l'intention fonctionnelle et donc de créer une bonne estimation de la taille fonctionnelle.
L'échange de données avec une API RESTful suit généralement un modèle CRUD (créer, lire, mettre à jour, supprimer) ou (mettre, obtenir, publier, supprimer). Il est important de reconnaître lors de la définition et du dimensionnement d'une user story que nous reconnaissons que nous envoyons des données et que nous obtenons une réponse d'un « organisme » externe (ou vice versa). Le « corps » externe, bien qu'il puisse s'agir d'une API, est en fait un type d'utilisateur, ou d'utilisateur fonctionnel pour être plus précis.
En savoir plus sur comment rédiger des user stories de qualité pour l'intégration
Formulation alternative
Il existe de nombreuses façons d’écrire la même user story, peut-être des centaines de façons. Ce que nous décrivons ici ne sont donc que des exemples. Vous pouvez par exemple écrire l'histoire du point de vue du système externe (avec lequel nous intégrons) en tant qu'utilisateur de notre application, par exemple
En tant que service de code postal, je peux répondre aux demandes et envoyer des données d'adresse dès réception d'un code postal.
ou nous pouvons écrire la même chose du point de vue de l'utilisateur de notre application.
En tant qu'acheteur, je peux récupérer mon adresse auprès du service de code postal externe lorsque je saisis un code postal.
Les deux sont des approches valables. Nous recommandons cette dernière pour deux raisons :
- Il se concentre sur le réel utilisateurs expérience.
- Il est écrit du point de vue de notre application, et non de l'application externe.
N'oubliez pas que lorsque vous écrivez une intégration entre deux applications, vous devrez peut-être développer du code aux deux endroits et le tester indépendamment et en tant que système.
Rédaction de témoignages d'utilisateurs d'intégration
