Historias de Usuario y demás artefactos XP

Empezaré con lo que considero la herramienta básica para la aplicación de XP, las Historias de Usuario.

61

Las historias de usuario son la técnica utilizada en XP para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer, sean requisitos funcionales o no funcionales. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas.

Respecto de la información contenida en la historia de usuario, existen varias plantillas sugeridas pero no existe un consenso al respecto. En muchos casos sólo se propone utilizar un nombre y una descripción o sólo una descripción, más quizás una estimación de esfuerzo en días. Beck (2004, p. 73) presenta un ejemplo de ficha (customer story and task card – figura 9)

62

Dependiendo de la complejidad del sistema, debe haber al menos una historia por cada característica importante, para así realizar una o dos historias por programador por mes. Si se tienen menos, probablemente sea conveniente dividir las historias, si se tienen más lo mejor es disminuir el detalle y agruparlas. Jeffries (2001)

No hay que preocuparse si en un principio no se identifican todas las historias de usuario. Al comienzo de cada iteración estarán registrados los cambios en las historias de usuario y según eso se planificará la siguiente iteración. Las historias de usuario son descompuestas en tareas de programación y asignadas a los programadores para ser implementadas durante una iteración. El modelo de historia de usuario a utilizar es el propuesto por Letelier (2003), el cual se muestra en la Tabla 1, a continuación:

Historia de Usuario

Número: Nombre Historia de Usuario:

Modificación (o extensión) de Historia de Usuario (Nro. y Nombre):

Usuario: Iteración Asignada:

Prioridad en Negocio:

(Alta / Media / Baja) Puntos Estimados:

Riesgo en Desarrollo:

(Alto / Medio / Bajo) Puntos Reales:

Descripción: Observaciones:

Tabla 1: Modelo de Historia de Usuario a utilizar (Letelier y otros, 2003)

Las Pruebas de Aceptación permiten confirmar que la historia ha sido implementada correctamente. Las tarjetas o tablas de las pruebas de aceptación/unitarias constituyen otro de los artefactos utilizados, en XP, señalado en la siguiente tabla.

63

Caso de Prueba de Aceptación

Código: Historia de Usuario (Nro. y Nombre): Nombre:

Descripción:

Condiciones de Ejecución: Entrada / Pasos de ejecución: Resultado Esperado:

Evaluación de la Prueba:

Tabla2: Modelo propuesto para una prueba de aceptación. (Letelier y otros, 2003)

Otro artefacto de XP son las Task Card o Tarea de Ingeniería, en ellas los desarrolladores junto con el manager del proyecto y previa consulta y validación de todas las historias de usuario, proceden a anotar las tareas de desarrollo de aplicaciones relacionadas a cada historia de usuario. El grupo programador, dada las practicas metodológicas se apoyará en estás para la ejecución del producto de software. Dichas tareas siguen el formato presentado en la Tabla 3.

Tarea de Ingeniería

Número Tarea: Historia de Usuario (Nro. y Nombre): Nombre Tarea:

Tipo de Tarea :

Desarrollo / Corrección / Mejora / Otra (especificar)

Puntos Estimados:

Fecha Inicio: Fecha Fin: Programador Responsable:

Descripción:

Tabla 3 Modelo propuesto para una tarea de ingeniería (Letelier y otros, 2003).

En la tarjetas de tareas de ingeniería, y siguiendo el formato arriba descrito (Tabla 3); los desarrolladores junto con el manager del proyecto y previa consulta y validación

las tareas de desarrollo de aplicaciones relacionadas a cada historia de usuario. El grupo programador (par programando); dada las practicas metodológicas se apoyará en estás para la ejecución del produc

Por ultimo, se suele utilizar opcionalmente las Responsabilidad –

dividen en tres secciones que contienen la información del nombre de la clase, sus responsabilidades y sus colaboradores y pueden ser utilizadas dependiendo la utilidad y el valor que le aporten al desarrollo. En la siguiente figura se muestra cómo se distribuye esta información.

Figura 10 Modelo de tarjeta CRC (Anaya y Plaza, 2007)

Una clase es cualquier persona, cosa, evento, concepto, pantalla o reporte. Las responsabilidades de una clase son las cosas que conoce y las que realizan, sus atributos y métodos. Los colaboradores de una clase son las demás clases con las que trabaja en

responsabilidades.

64

En la tarjetas de tareas de ingeniería, y siguiendo el formato arriba descrito (Tabla 3); los desarrolladores junto con el manager del proyecto y previa consulta y validación de todas las historias de usuario, proceden a anotar las tareas de desarrollo de aplicaciones relacionadas a cada historia de usuario. El grupo programador (par programando); dada las practicas metodológicas se apoyará en estás para la ejecución del producto de software.

Por ultimo, se suele utilizar opcionalmente las Tarjetas CRC (

Colaborador) como artefacto dentro de XP. Estas tarjetas se dividen en tres secciones que contienen la información del nombre de la clase, bilidades y sus colaboradores y pueden ser utilizadas dependiendo la utilidad y el valor que le aporten al desarrollo. En la siguiente figura se muestra cómo se distribuye esta información.

Figura 10 Modelo de tarjeta CRC (Anaya y Plaza, 2007)

Una clase es cualquier persona, cosa, evento, concepto, pantalla o reporte. Las responsabilidades de una clase son las cosas que conoce y las que realizan, sus atributos y métodos. Los colaboradores de una clase son las demás clases con las que trabaja en conjunto para llevar a cabo sus responsabilidades.

En la tarjetas de tareas de ingeniería, y siguiendo el formato arriba descrito (Tabla 3); los desarrolladores junto con el manager del proyecto y de todas las historias de usuario, proceden a anotar las tareas de desarrollo de aplicaciones relacionadas a cada historia de usuario. El grupo programador (par programando); dada las practicas metodológicas se

to de software.

Tarjetas CRC (Clase - como artefacto dentro de XP. Estas tarjetas se dividen en tres secciones que contienen la información del nombre de la clase, bilidades y sus colaboradores y pueden ser utilizadas dependiendo la utilidad y el valor que le aporten al desarrollo. En la siguiente

Figura 10 Modelo de tarjeta CRC (Anaya y Plaza, 2007)

Una clase es cualquier persona, cosa, evento, concepto, pantalla o reporte. Las responsabilidades de una clase son las cosas que conoce y las que realizan, sus atributos y métodos. Los colaboradores de una clase son las conjunto para llevar a cabo sus

65