Soy muy nuevo en el desarrollo ágil de software y trato de entender la regla de tamaño que se debe seguir al escribir historias de usuario valiosas.
Guión
Actualmente estoy involucrado en una cartera de proyectos de importación de datos. Esto implica establecer una funcionalidad de importación y exportación entre la aplicación y los adaptadores. Sin embargo, la funcionalidad de importación/exportación se implementa para un par de adaptadores. Cómo manejará la historia de usuario de un nuevo adaptador: configuración de importación/exportación. la funcionalidad es la misma para todos los adaptadores. Me gustaría aclarar las siguientes dudas 1. ¿Deberíamos repetir el contenido de las historias de usuario si la funcionalidad es la misma? 2. ¿Deberíamos escribir historias más detalladas o más cortas?
No hay una respuesta "correcta". Sin embargo, hay algunos puntos sobre las historias de usuarios que pueden resultarle útiles para guiar su decisión:
1) Las historias de usuarios se escribieron originalmente en tarjetas de 3x5. Esto se seleccionó intencionalmente porque era imposible incluir todos los detalles en una tarjeta de ese tamaño, por lo que los desarrolladores tendrían que hablar con el usuario o el PO y escribir sus propias notas de la conversación.
2) Las historias de usuario deben expresar la necesidad que se está resolviendo, no la implementación. Eso significa que para algo como importar, el comienzo de su historia de usuario probablemente sea tan simple como:
Como usuario nuevo, quiero importar mis datos desde un archivo plano para no tener que escribirlos todos a mano.
y tal vez incluir una copia de un archivo de importación como ejemplo.
Generalmente, una historia de usuario es un trabajo que se puede terminar en un Sprint.
Si el suyo tomará más tiempo, se considerará un Epic , que contendrá Historias de usuarios adicionales dentro de él. Si esas Historias adicionales parecen ser similares pero tienen diferentes Criterios de Aceptación , deben escribirse como Historias de Usuario separadas .
Desde este lado de la pantalla, parece que deberías dividir esa historia. ¡Buena suerte!
El equipo de desarrollo y el propietario del producto deben trabajar juntos para resumir los criterios de aceptación de cada nueva funcionalidad. Si hay un cruce en el valor entregado de otras partes del trabajo realizado, ese trabajo completado se puede hacer referencia en todos los nuevos elementos de trabajo que se generan para el producto. Esto proporciona contexto y un marco para abordar un nuevo trabajo teniendo en cuenta la funcionalidad existente. Si el nuevo trabajo que se genera tiene un alcance lo suficientemente grande, el equipo de desarrollo debe estar facultado para administrar/dividir el trabajo como mejor le parezca antes de incorporarlo a su sprint.
Todd A. Jacobs
jithin antonio
Todd A. Jacobs
shawn adams