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 sobre 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 tarea 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 débilmente acoplados 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 Recordatorio de Pago".- 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 del servicio y las interfaces que se definen en el diseño de la solución, incluyendo los criterios de entrada (por ejemplo, un específico message type requerido para el primer flujo) y 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 empresariales como 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 esquelética del flujo. El esqueleto debe:

Defina todos los conocidos Estados DSL que una transacción puede seguir en su camino exitoso
Debe tener al menos un DSL terminal state para el camino feliz
Tener un terminal genérico failed o DSL rechazado state– esto puede ser reemplazado más tarde con varios estados de fallo específicos si es necesario
Defina el domain events que impulsará el DSL state transiciones
Defina las respuestas que generarán el domain events
Defina los resultados de todos decisions(si corresponde) utilizado en el camino feliz
No tenga errores en el estudio IPF – es decir, el initiation behaviour, comportamiento de entrada y event el comportamiento se define hasta un punto que significa que el flujo es válido y una transacción puede ser procesada a través de un flujo hacia un DSL de terminal.state. En esta etapa no necesita crear subflows, aunque usted puede querer crear un DSL temporal state para representar un subflujo que se definirá en una etapa posterior.

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, Validaring Pago, Esperaring respuesta del esquema)
[x]Domain events 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 DSL.state, cambie al 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 Mapping

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.
Usted necesitará definir el data mapping para una solicitud (y a veces una respuesta también)
[x]Mapping Las especificaciones deben estar vinculadas a 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 service y la respuesta es gestionada-la transacción será rechazada o continuará procesándose.

2. 3. 3 DADO

Proporciona las precondiciones.

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 surta 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 event es transactionValidated

2. 3. 4 CUANDO

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 (agregue 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 de event generado por la respuesta/salida debe ser definido. Esto corresponderá a la event 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 GUI como parte de los criterios de aceptación.
El estado global que corresponde a la state la transición debe ser proporcionada, si necesita cambiar (en el ejemplo a continuación, el global state permanecerá en un estado pendiente state si la verificación de la accesibilidad del acreedor es satisfactoria).

Ejemplo:

ENTONCES

un event se genera con un código de respuesta y razón correspondiente y lo siguiente state ocurren transiciones

Respuesta

Evento

Código de respuesta

Código de razón

Descripción del código de razón

Transición al estado DSL

Global state

pasar

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:
+	la verificación De Alcance Pasada event con Código de Respuesta
+	la verificación De Alcance Fallida event con Código de Respuesta, Código de Razón y Descripción de la Razón
+	la representación gráfica del flujo que muestra el state transición a Transacción Rechazada o Transacción Completada
+	el state transición de la global state de Pendiente a Rechazado al fallar la verificación de accesibilidad
+	el global state permaneciendo como Pendiente tras la verificación de alcanzabilidad exitosa

2. 4 Agregar Historias de Función de Dominio

Domain functions son desarrollados por los clientes de IPF y son llamados 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 ser descrita 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 external domains 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 el magic values requerido. 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 el magic values necesarios para una serie de diferentes posibles respuestas, y los datos en la solicitud al simulador tendrían que contener esos magic values.

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 necesitará que uno de ellos esté modelado en el simulador.

Consejos y Trucos

Nunca utilice las palabras " event " o " state " sin estar claro cuál es el tipo; es un domain event or a system event. Asimismo, es ya sea un DSL state o un global state.
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 que es una buena idea registrar explícitamente state que cualquier nuevo mensaje externo que una historia esté introduciendo en un flujo debe ser registrado, ya que de lo contrario 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 de usuario o no. Si esta validación se implementa en un conector antes de que se inicie un flujo, no habrá unit of work para el mensaje y así 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, usted no tiene que decidir de antemano si un requisito debe implementarse como una función de dominio, un nuevo servicio, etc. Debe entender las implicaciones de las diferentes opciones, pero deje el decision al proceso de refinamiento. La única excepción a esto es identificar subflows.