Integración de reglas empresariales a User Stories

Question

Tengo un conjunto de historias de usuarios y tengo un conjunto de reglas comerciales (principalmente leyes que vinculan mis requisitos para cumplir). En Agile SDLC no estoy seguro de dónde se encuentran estas "reglas" adjuntas a mis historias de usuario.

Por ejemplo, una historia de usuario como:

Como médico Quiero añadir la información del paciente con el fin de crear un nuevo archivo de paciente.

Y una regla como:

La siguiente información se debe introducir en el registro de cada paciente: (a) paciente: (i) nombre y apellido; (ii) dirección; (iii) fecha de nacimiento; y (iv) sexo;

Estos dos claramente se unen, pero ¿cómo puedo vincularlos? Como las definiciones de aceptación de prueba en mi historia de usuario? ¿Otra historia de usuario?

Answer 1

Hay algunas maneras diferentes que he visto esta manejado:

1. Un artefacto se crea para mantener la regla de negocio y se almacena en algún depósito central de todas las reglas por lo que este es conocida en todo el se mantiene un equipo de desarrollo y un almacén de conocimiento. Esto puede ponerse feo ya que puede haber cientos de reglas dentro de unos pocos años de desarrollar una aplicación.

2. Las reglas se pueden poner en tarjetas separadas dentro de la historia del usuario. Por lo tanto, si bien la historia del usuario es esa línea, puede haber de 6 a 8 tarjetas que completen todas las tareas de esa historia. Por ejemplo, debe haber un nuevo formulario para el paciente creado, validación en el formulario, etc. Por lo tanto, no es difícil ver este cultivo en la línea de una tarjeta como una forma de rastrear el requerimiento de esa manera. Esto es lo más natural en mi opinión, aunque aquí no es donde la lista específica se va a escribir al 100%, ya que la tarjeta podría ser "asegurar que algunos campos en el formulario sean obligatorios".

3. No hay un enlace explícito, sino que la regla es algo que debe observar QA o BA para que el usuario verifique que el formulario hace cumplir esta regla. Esto es similar a uno, pero la pregunta es cuál es la responsabilidad del desarrollador en esto. En este caso, es algo para QA rastrear en lugar de desarrolladores posiblemente.

La historia del usuario está destinada a iniciar una discusión, no es una lista completa de los requisitos. La regla es algo que debería surgir cuando el desarrollador discute con el usuario qué se necesita para crear un nuevo archivo de paciente en mi mente.

---

me gusta la idea de aferrarse a las tarjetas para un par de carreras después se realizó la historia, pero sí veo el punto de que finalmente serán destruidas las tarjetas. Al mismo tiempo, debe haber un código en algún lugar que implemente las reglas en su área adecuada. Para usar el ejemplo que publicó, es posible que en algunos lugares se note la lista de campos obligatorios, ya que existe la capa de UI que debe mostrar los campos y probablemente un mensaje de error, pero también debe haber alguna capa de lógica de negocios que tiene esta lógica para ver que algunos campos se completaron específicamente antes de tratar de crear un nuevo archivo de paciente. El sistema que se está construyendo también incluirá las reglas de una forma u otra también.

Answer 2

Como criterios de aceptación. Después de todo, estas son reglas que se pueden ejecutar como pruebas. Definitivamente no historias nuevas, eso sería incorrecto ya que no hay un objetivo entregable.