Guía de Historias de Usuario para Proyectos de Implementación de IPF

El propósito de este artículo es proporcionar algunas orientaciones sobre cómo redactar historias de usuario al definir requisitos para una solución construida con IPF. Se asume que el lector ya tiene conocimiento de las historias de usuario en el contexto del desarrollo ágil de software.

Cuando se redacta una historia de usuario en el contexto de una solución que se está construyendo con IPF, debe referirse explícitamente a los componentes y conceptos de IPF. Lo más habitual es que esto implique la definición del flujo en IPF Studio, pero también puede referirse a otros IPF core servicios y funciones empresariales (Servicio de Alcance, SEPA CT STEP2 scheme pack etc). Mientras que las historias de IPF deben proporcionar tanto detalle como sea razonable, aún deben seguir los principios ágiles normales de INVEST que son:

  • Independiente

  • Negociable

  • Valioso

  • Estimable

  • Pequeño

  • Probable

Proceso Típico de Redacción de Historias de Usuario para IPF

1. Defina el Alcance

El(s) equipo(s) ágil(es) acuerdan un alcance para una pieza de trabajo definida que consideran alcanzable dentro de un par de sprints, generalmente dentro de un solo épico. Esta épica define el alcance y proporciona el contexto necesario; el contexto puede variar desde un texto simple que describe las necesidades del negocio, hasta diagramas o incluso modelos de casos de uso, dependiendo del nivel de complejidad y reutilización funcional.

Una implementación de IPF consiste en servicios acoplados de manera flexible definidos por un cliente (a menudo conteniendo uno o más flujos) así como algunos servicios predefinidos proporcionados por IPF.

Un posible cliente definió un servicio con un flujo como un 'Servicio de Ejecución de Pagos'.- esto podría recibir una solicitud de pago en un formato Pain001 y luego gestionar la orquestación de la solicitud interactuando con funciones bancarias como contabilidad, divisas, sanciones y fraude. Este tipo de servicio de orquestación tendría un conjunto extenso de flujos para manejar devoluciones y otros casos extremos.

Otro servicio definido por un posible cliente con un flujo es un "Servicio de Recuperación de Pagos".- esto podría manejar todo el procesamiento de Camt056 y, si se necesita enviar un retorno, iniciar un flujo en el Servicio de Ejecución de Pagos para enviar un Pacs004 al esquema.

Un ejemplo de un servicio predefinido sin un flujo es el Servicio de Notificación - esto envía informes de estado de pago (Pain002s) a canales para proporcionar el estado de una transacción en etapas definidas de procesamiento.

El diseño de la solución describe los límites del servicio, cómo interactúan los servicios y qué sucede dentro de esos servicios (por ejemplo, flujos). Generalmente se crea junto con el alcance y se hace referencia a él al crear las historias de usuario.

2. Redacción de Historias de Usuario

2.1 Creando un Nuevo Servicio

A medida que se construye la solución, se añadirán nuevos servicios. Es una buena idea tener una historia de usuario de 'inicio rápido' cada vez que se deba crear un nuevo servicio. Esta historia de usuario técnica permite a los ingenieros crear el proyecto, configurar el repositorio, etc., y debe describir los límites y las interfaces del servicio que se definen en el diseño de la solución, incluyendo los criterios de entrada (por ejemplo, un tipo de mensaje específico requerido para el primer flujo) y los criterios de salida (por ejemplo, una notificación) para el servicio. Las actualizaciones a un servicio justifican sus propias historias de usuario.

Es probable que la configuración del servicio se utilice para almacenar parámetros utilizados durante el procesamiento. Documente y mantenga toda la información sobre los ajustes de configuración (tanto los de negocio como los técnicos) en un espacio que se utilice para compartir información entre equipos, como Confluence o SharePoint.

2.2 Creando un Flujo Inicial

Si se está creando un flujo por primera vez, es sensato tener una historia dedicada para crear una versión básica del flujo. La versión básica debe:

  • Defina todos los conocidos Estados DSL que una transacción puede seguir en su camino exitoso

  • Debe tener al menos un estado DSL terminal para el camino feliz.

  • Tener un estado de DSL genérico fallido o rechazado en el terminal – esto puede ser reemplazado más adelante por varios estados de fallo específicos si es necesario.

  • Defina el domain events que impulsará las transiciones de estado del DSL

  • Defina las respuestas que generarán el domain events

  • Defina los resultados de todas las decisiones (si las hay) utilizadas en el camino feliz.

  • No debe haber errores en el estudio de IPF, es decir, el comportamiento de iniciación, el comportamiento de entrada y el comportamiento de eventos están definidos en un grado que significa que el flujo es válido y una transacción puede ser procesada a través de un flujo hasta un estado DSL terminal. En esta etapa, no es necesario que cree subflujos, aunque puede que desee crear un estado DSL temporal para representar un subflujo que se definirá en una etapa posterior.

Usted debe asegurarse de que:

  • Los estados DSL se nombran en tiempo presente y representan una acción que la solución construida con IPF está realizando; generalmente tendrán una palabra en ‘ing’ (por ejemplo, Validating Payment, Awaiting scheme response)

  • Los eventos de dominio se nombran en tiempo pasado y representan un hecho sobre algo que ha ocurrido en el payment flow, generalmente tendrán una palabra con ‘ed’ (por ejemplo, Pago Validado, Pago Aceptado por CSM)

  • Se añaden referencias a los campos donde sea posible para que los ingenieros sepan claramente a qué se refieren (por ejemplo, para definir una validación utilizando límites de participantes: El monto del pago (PmtInf. CdtTrfTxInf. Amt. InstdAmt.value) es menor que el límite del participante del agente acreedor (Reachability. CSMParticipant. Limit. Amount).

2.3 Actualizar un Flujo/Agregar Historias de Subflujo

La mayoría de las historias de usuario se basarán en flujos existentes, ya sea un flujo inicial (ver arriba) o iteraciones posteriores. Es útil dibujar el flujo actualizado en una aplicación de diagramación, marcando el cambio (por ejemplo, un nuevo estado de DSL, cambio en el nombre de un domain event, etc.) en un color separado y adjuntándolo a la historia. Esto es más sencillo que crear una rama en el estudio IPF para un usuario empresarial, y permite una mayor independencia.scheduling ya que el cambio está claramente destacado y no requiere ninguna fusión de flujos.

Utilice los criterios de aceptación en la historia para definir los cambios en el flujo con más detalle utilizando la sintaxis gherkin (escenario, dado, cuando, entonces) haciendo referencia a los estados de DSL y domain events para dejar claro dónde se encuentra el requisito en el flujo.

2.3.1 Mapeo

Al enviar y recibir información con otros sistemas (External Domains en términos de DSL), mapping se requiere del modelo de datos de flujo hacia y desde el sistema externo.

  • Deberá consultar una especificación técnica para las solicitudes y respuestas; esto debe estar vinculado desde la historia, en lugar de definirse dentro de la propia historia.

  • Deberá definir los datos mapping para una solicitud (y a veces una respuesta también)

  • Las especificaciones de mapeo deben estar vinculadas desde la historia, en lugar de definirse dentro de la historia misma, a menos que sea una muy, muy simple.mapping

  • Aunque el mapping La hoja cubrirá todos los datos requeridos en la solicitud, vale la pena incluir los datos más importantes en los criterios de aceptación para ayudar a la legibilidad y proporcionar contexto.

2.3.2 Escenario Gherkin

Proporciona una visión general de lo que la historia intenta lograr en una frase corta y el camino que ha tomado la transacción hasta el punto en que se está realizando el cambio.*

_Example: Se realiza una solicitud desde el flujo de Ejecución de Pagos al CSM servicio y la respuesta es gestionada-la transacción será rechazada o continuará procesándose.

2.3.3 DADO

Proporciona las condiciones previas.

  • Enumere el(los) flujo(s) por el(los) que ha pasado una transacción hasta este punto.

  • Especifique la clave domain events en el(los) flujo(s) que deben haber ocurrido antes de que la historia tenga efecto

  • Enumere el/los servicio(s) que son modificados por la historia.

Ejemplo:

DADO

se ha enviado un pago al flujo de ejecución de pagos
Y

el último evento es transactionValidated
2.3.4 CUÁNDO

Proporciona el desencadenante para el comportamiento requerido (podría ser un domain event, el resultado de un decisión, aggregate function or flujo/subflujo, un tipo específico de respuesta de un sistema bancario, etc.).

Ejemplo:

CUANDO

se envía una solicitud al servicio de Alcance
Y

la solicitud está estructurada de acuerdo con la especificación (agregar enlace a mapping página y especificación)
Y

la solicitud contiene el BIC del Agente Acreedor
Y

se ha recibido una respuesta (agregue enlace a la especificación)
2.3.5 ENTONCES

Se utiliza para describir el comportamiento requerido:

  • El nombre del evento generado por la respuesta/salida debe ser definido. Esto corresponderá al evento definido en Payments DSL y utilizado en el Comportamiento de Entrada.

  • Si se requiere un código de respuesta que sea diferente al resultado de un dominio externo (por ejemplo, el dominio externo devuelve BANK4532, pero usted desea que el flujo lo maneje como IPF031), entonces esto debe especificarse en la historia. El código de respuesta definido por el usuario será de un conjunto predefinido importado en el Payments DSL(por ejemplo, ISO) o un custom conjunto de códigos definidos en el Payments DSL.

  • Si la respuesta es un fallo, entonces se debe definir un código de razón junto con una descripción del código de razón.

  • Si el IPF Operational Dashboard se está utilizando, entonces puede ser valioso describir lo que se esperaría ver en la interfaz gráfica de usuario como parte de los criterios de aceptación.

  • El estado global que corresponde a la transición de estado debe ser proporcionada, si necesita cambiar (en el ejemplo a continuación, el estado global permanecerá en un estado pendiente si la verificación de alcanzabilidad del acreedor pasa).

Ejemplo:

ENTONCES

se genera un evento con un código de respuesta y un código de razón correspondientes y ocurren las siguientes transiciones de estado.

Respuesta

Evento

Código de respuesta

Código de razón

Descripción del código de razón

Transición al estado DSL

Estado global

pass

verificación De Alcance Exitosa

ACPT

GY. 001.002

Agente del acreedor accesible

Transacción completada

fail01

verificación De Alcance Fallida

RJCT

GY. 200.001

Agente de Acreedor Inválido

Transacción Rechazada

Rechazado

fail02

verificación De Alcance Fallida

RJCT

GY. 200.002

Agente acreedor no accesible

Transacción Rechazada

Rechazado
Y

lo siguiente es observable en el IPF Operational Dashboard:
+

el evento reachabilityCheckPassed con Código de Respuesta
+

el evento reachabilityCheckFailed con Código de Respuesta, Código de Razón y Descripción de Razón
+

la representación gráfica del flujo que muestra la transición de estado a Transacción Rechazada o Transacción Completada
+

la transición de estado del estado global de Pendiente a Rechazado al fallar la verificación de alcanzabilidad
+

el estado global permaneciendo como Pendiente tras la verificación de alcanzabilidad exitosa

2.4 Agregar Historias de Función de Dominio

Las funciones de dominio son desarrolladas por los clientes de IPF y se invocan desde el flujo a través de una solicitud. La función de dominio proporcionará una respuesta al flujo.

Si la función es simple, entonces la lógica de la función puede describirse en la historia de usuario; de lo contrario, es recomendable describir la función donde se mantiene la documentación del proyecto y referirse a ella desde la historia de usuario.

Utilice el nombre de la función definida en el Payments DSL biblioteca de funciones al referirse a ella en la historia de usuario.

2.5 Configuración y Configuración de Historias

Algunas historias estarán relacionadas con la configuración de datos, cambios de configuración, usabilidad de la interfaz gráfica, etc., y no se prestarán naturalmente al uso de la sintaxis gherkin. En estos casos, describa el requisito de la manera más clara posible e ignore el formato Dado, Cuando, Entonces.

Asegúrese de utilizar siempre Given, When, Then al describir los requisitos de flujo.

Algunos ejemplos son:

  • Creación o modificación de estructuras de datos de Entidad de Procesamiento

  • Creando o modificando CSM Agente y CSM Estructuras de datos de Configuración del Agente

  • Crear o modificar la configuración técnica o empresarial para un Servicio

2.6 Historias del Simulador

Si se están construyendo simuladores para representar dominios externos en el Payments DSL(ej. una plataforma contable o un sistema de divisas), entonces se requerirá una historia de usuario para crear el simulador.

Las historias de los simuladores deben:

  • Proporcione un contexto general y haga referencia a cualquier diagrama de arquitectura para que quede claro qué se está simulando (por ejemplo, un sistema de FX o un sistema contable).

  • Proporcione enlaces a las especificaciones técnicas para el dominio externo que se está simulando.

  • Sea claro sobre cuáles son los datos mínimos que necesita el simulador.- En general, la solicitud debe proporcionar los datos necesarios para ser válida y para realizar pruebas significativas.

  • Especifique los valores mágicos requeridos. Magic values son valores (por ejemplo, un nombre o cantidad específica) que impulsarán una respuesta específica.

Ejemplo:

Se requiere un simulador para representar un sistema que verifica si se puede debitar una cuenta y devuelve una respuesta de validación que, si es exitosa, incluye una dirección.

La historia de usuario debe definir los valores mágicos necesarios para una serie de posibles respuestas diferentes, y los datos en la solicitud al simulador deben contener esos valores mágicos.

En este ejemplo, se utiliza una cantidad específica para impulsar las respuestas del simulador:

Escenario

Solicitar Datos

Respuesta Esperada

La transacción pasa la validación, sin enriquecimiento.

Cantidad = 1.01

Pasar

La línea de dirección 1 está completada.

La transacción pasa la validación, datos enriquecidos en la respuesta.

Cantidad = 1.02

Pasar

La línea de dirección 1 está completada.

La ciudad está poblada.

La transacción no supera la validación.

Cantidad = 1.03

Fallar
No es necesario cubrir cada escenario de fallo, ya que pueden ser cientos. Solo necesita cubrir cada escenario de fallo que genere un comportamiento diferente en el flujo. Si un grupo de fallos resulta en el mismo comportamiento, entonces deberá modelar uno de ellos en el simulador.

Consejos y trucos

  • Nunca utilice las palabras "evento" o "estado" sin aclarar cuál es el tipo; es un domain event o un evento del sistema. Igualmente, es un estado de DSL o un estado global.

  • Una vez que haya creado un simulador con una historia de simulador, agregar nuevos escenarios al simulador puede ser mejor gestionado como parte de la historia de flujo relevante, dependiendo del nivel de complejidad.

  • Utilizando un modelo de proceso de negocio, como BPMN, junto con un diagrama de secuencia UML, se ayuda a clarificar el alcance épico, especialmente al tratar con parte de un proceso complejo de extremo a extremo que ha sido desglosado en múltiples IPF flows y servicios.

  • Si utiliza Jira o una herramienta similar, el campo 'componentes' puede ser utilizado para listar los servicios relevantes en lugar de los criterios de éxito.

  • Porque message logging En IPF es flexible, no hay un registro predeterminado; por lo tanto, es una buena idea indicar explícitamente que cualquier nuevo mensaje externo que una historia esté introduciendo en un flujo debe ser registrado, ya que de lo contrario esto puede pasarse por alto fácilmente.

  • Siempre especifique cómo desea que se llamen los mensajes externos en la interfaz gráfica de usuario.

  • Piense en si desea ver los mensajes que no cumplen con un esquema (por ejemplo, XSD) en la interfaz gráfica o no. Si esta validación se implementa en un conector antes de que se inicie un flujo, no habrá unidad de trabajo para el mensaje y, por lo tanto, no habrá nada en ODS. Si desea ver que un mensaje de correo no deseado fue recibido y rechazado en la interfaz gráfica de usuario, deberá realizar esta validación en el flujo.

  • Como BA, no debe decidir de antemano si un requisito se implementará como una función de dominio, un nuevo servicio, etc. Debe comprender las implicaciones de las diferentes opciones, pero deje la decisión al proceso de refinamiento. La única excepción a esto es la identificación de subflujos.