Cómo escribir historias de usuarios en desarrollo ágil

Para un desarrollo ágil, las historias de usuario son la base del desarrollo. Es diferente del método tradicional de desarrollo en cascada, pero divide los requisitos originales en historias granulares más pequeñas para facilitar la división de tareas, la estimación del tiempo de desarrollo y la recepción de tareas de desarrollo.

Ventajas y Beneficios

Muy breve.

Permite a los desarrolladores y clientes discutir los requisitos durante todo el ciclo de vida del proyecto

Casi no requiere mantenimiento

Solo se considera durante el uso

Mantenga un contacto cercano con los clientes

Permite dividir los proyectos en pequeños incrementos

Adecuado para proyectos con requisitos inestables o poco comprendidos.

Podría ser más fácil estimar el esfuerzo de desarrollo

Plantilla de historias de usuario

Las historias de usuario pueden seguir esta plantilla: Como tipo de usuario, quiero lograr objetivos gt; ; y así <; obtener algún valor >>p>

Traducido al chino: como tipo de usuario >, espero <;

Las historias de usuario deben seguir la regla INVEST

Ser independiente y evitar dependencias de otras historias.

Negociabilidad, una historia de Scrum no es un contrato para comenzar algo en estilo cascada, la historia no necesita ser demasiado detallada, el desarrollador puede dar las sugerencias adecuadas.

Valiosa, la historia debe reflejar el valor para el usuario.

Estimable, la historia debe poder estimar el tiempo de desarrollo de la tarea.

Tamaño adecuado. Las historias deben ser lo más pequeñas posible y el equipo debe intentar completarlas en un sprint (2 semanas).

Testabilidad: las historias de usuario deben ser comprobables, preferiblemente con interfaces comprobables y automatizadas. Cada tarea debe tener una prueba Junit.

Algunas lecciones aprendidas:

Nunca use And y Or en historias de usuario, ya que estas dos palabras son palabras de ramificación para tareas de ramificación, deben separarse en dos historias: Generalmente en este caso , Se pueden completar 4-5 historias en 1 sprint (2 semanas como 1 iteración).

Organización de datos: normalmente, 1 sprint (2 semanas por iteración) puede completar alrededor de 50 tareas.

Las historias de usuario se utilizan para describir historias de usuario y no incluyen ninguna tecnología, marco, etc. Las tareas pueden incluir marcos, tecnologías y otro contenido.