Historias de usuarios para la integración de API
Cómo escribir una mejor historia de usuario para la integración. Este es uno de varios artículos breves sobre cómo escribir mejores historias de usuarios con ScopeMaster®.
Hoy en día, una gran cantidad de software implica la integración de diferentes componentes y aplicaciones para crear un nuevo sistema. En consecuencia, los requisitos de software a menudo se referirán a la conexión de un sistema con otro. Este tipo de integración suele consistir en compartir datos entre aplicaciones de software. A veces se trata de un verdadero intercambio bidireccional, pero sobre todo implica enviar datos de una aplicación a otra o buscar datos desde un sistema externo. Esta integración de software suele realizarse a través de API, como las API RESTful y, a menudo, mediante microservicios.
Así que dirijamos nuestra atención a cómo escribir una mejor historia de usuario para este tipo de integración. Ésta es un área en la que me gustan bastante los ejemplos de Mike Cohn. A continuación se muestra un ejemplo sencillo: un usuario de una aplicación de comercio electrónico llega a la sección de entrada de dirección. Pueden ingresar su código postal y se realiza una búsqueda de un servicio externo. Entonces, ¿cuál es la mejor manera de escribir este tipo de historia de usuario?
En primer lugar debemos reconocer que un sistema conectado es generalmente otro usuario funcional. También debemos mantener nuestro lenguaje simple y claro. Hay cientos, si no miles, de formas en que esto podría escribirse. Aquí hay sólo una frase sugerida:
Como un comprador I desear a agregar mi envío DIRECCIÓN, utilizando el Posctode_lookup_api para recuperar la dirección completa de un código postal
En este caso hemos generado dos pasos funcionales en la historia de usuario. Uno para crear la dirección y otro que realiza la externo buscar. ScopeMaster puede identificar estos dos pasos funcionales, determinar la intención funcional y, por lo tanto, crear una buena estimación del tamaño funcional.
El intercambio de datos con una API RESTful normalmente sigue un patrón CRUD (crear, leer, actualizar, eliminar) o (poner, obtener, publicar, eliminar). Es importante reconocer, al definir y dimensionar una historia de usuario, que reconocimos que estamos enviando datos y recibiendo una respuesta de un "cuerpo" externo (o viceversa). El "cuerpo" externo, si bien puede ser una API, es de hecho un tipo de usuario, o usuario funcional para ser específico.
Más información en cómo escribir historias de usuario de calidad para la integración
Redacción alternativa
Hay muchas maneras de escribir la misma historia de usuario, quizás cientos de maneras. Entonces, lo que describimos aquí son solo ejemplos. Por ejemplo, puede escribir la historia desde la perspectiva del sistema externo (con el que nos estamos integrando) como usuario de nuestra aplicación, por ejemplo.
Como servicio de código postal, puedo responder a solicitudes y enviar datos de dirección al recibir un código postal.
o podemos escribir lo mismo desde el punto de vista del usuario de nuestra aplicación.
Como comprador, puedo recuperar mi dirección del servicio de código postal externo cuando ingreso un código postal.
Ambos son enfoques válidos. Recomendamos este último por dos razones:
- Se centra en lo real del usuario experiencia.
- Está escrito desde la perspectiva de nuestra aplicación, no desde la aplicación externa.
Recuerde que cuando escribe una integración entre dos aplicaciones, es posible que deba desarrollar código en ambos lugares y probarlo de forma independiente y como un sistema.
Escribir historias de usuarios de integración
