Está en la página 1de 7

HISTORIAS DE USUARIO

JUAN SEBASTIAN CARDONA CASTRO
SERGIO DANILO MORALES HERNANDEZ

ESCUELA COLOMBIANA DE CARRERAS INDUSTRIALES
DESARROLLO INFORMÁTICO
ANÁLISIS DE SISTEMAS DE INFORMACIÓN-3AM
BOGOTÁ
2015

Las historias de usuario describen una funcionalidad que debe incorporar un sistema de software. Generalmente se recomienda la consolidación de historias muy cortas en una sola historia.  Pequeñas: Las historias muy largas son difíciles de estimar e imponen restricciones sobre la planificación de un desarrollo iterativo. CARACTERISTICAS: Las historias de usuario deben ser:  Independientes unas de otras: De ser necesario.  Negociables: La historia en sí misma no es lo suficientemente explícita como para considerarse un contrato. cada historia debe ser importante para alguno de ellos más que para el desarrollador.  Valoradas por los clientes o usuarios: Los intereses de los clientes y de los usuarios no siempre coinciden.  Estimables: Un resultado de la discusión de una historia de usuario es la estimación del tiempo que tomará completarla. Una historia de usuario es una representación de un requisito de software escrito en una o dos frases utilizando el lenguaje común del usuario. combinar las historias dependientes o buscar otra forma de dividir las historias de manera que resulten independientes.HISTORIAS DE USUARIO Las historias de usuario son utilizadas en las metodologías de desarrollo ágiles para la especificación de requisitos. la discusión con los usuarios debe permitir esclarecer su alcance y éste debe dejarse explícito bajo la forma de pruebas de validación. pero en todo caso. también permiten responder rápidamente a los requisitos cambiantes. . son una forma rápida de administrar los requisitos de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para administrarlos. Esto permite estimar el tiempo total del proyecto. y cuya implementación aporta valor al cliente.

Como no se dispone de una formulación de requisitos precisa. y más tarde al cliente. de manera que pueda ser verificada en cada entrega del proyecto. Al momento de implementar las historias. tienen una prioridad asociada definida por el cliente de manera de indicar cuáles son las más importantes para el resultado final. la historia de usuario debe responder a tres preguntas: ¿Quién se beneficia?. Si bien el estilo puede ser libre. Cuando sea posible. Generalmente se espera que la estimación de tiempo de cada historia de usuario se sitúe entre unas 10 horas y un par de semanas. verificar si la historia ha sido completada. estas definen lo que se debe construir en el proyecto de software. por lo que generalmente son verificables. ¿qué se quiere? y ¿cuál es el beneficio? Por ello. Cada historia de usuario debe tener en algún momento pruebas de validación asociadas. ¿CUÁL ES LA FUNCIONALIDAD DE LAS HISTORIA DE USUARIO? Las historias de usuario conforman la parte central de muchas metodologías de desarrollo ágil. lo que permitirá al desarrollador. El estilo breve de las historias podría dificultar su interpretación. la ausencia de pruebas de validación concertadas abre la posibilidad de discusiones largas y no constructivas al momento de la entrega del producto. podría requerir conocimientos de base sobre el modelo o podría haber cambiado desde que fue escrita. serán divididas en tareas y su tiempo será estimado por los desarrolladores. los desarrolladores deben tener la posibilidad de discutirlas con los clientes. algunos autores1recomiendan redactar las historias de usuario según el formato: . Verificables: Las historias de usuario cubren requerimientos funcionales. la verificación debe automatizarse. tales como XP. Estimaciones mayores a dos semanas son indicativas de que la historia es muy compleja y debe ser dividida en varias historias.

. ESTRUCTURA DE UNA HISTORIA DE USUARIO: La estructura de una historia de usuario está formada por:  Nombre breve y descriptivo. Son peticiones concretas y pequeñas.¿POR QUÉ SON IMPORTANTES LAS HISTORIAS DE USUARIO Utilizamos las historias de usuario porque requerimientos agiles:      siguen los principios básicos de Potencian la participación del equipo en la toma de decisiones. lo que es fundamental.  Criterio de validación y verificación que determinará para considerar terminado y aceptable por el cliente el desarrollo de la funcionalidad descrita. Apoyan la cooperación. Menos es más.  Descripción de la funcionalidad en forma de diálogo o monólogo del usuario describiendo la funcionalidad que desea realizar. Contiene la información imprescindible. colaboración y conversación entre los miembros del equipo. Se crean y evolucionan a medida que el proyecto avanza.

A su vez la secretaria dispondrá de un botón para comprobar los productos correspondientes a cada pedido.Y adicionalmente por la información que resulte necesaria por el modelo de implementación: Prioridad. etc. Este albarán puede estar formado por varios pedidos. Riesgo.5 Iteración asignada: 1 Programador responsable: Pedro Pérez-Armando Casas Descripción: Accede a la base de datos mostrando los pedidos pendientes o incompletos y se seleccionan aquellos pedidos para servirlos inmediatamente generando el albaran que se manda al almacenista. Tamaño. Observaciones: Historia de Usuario Número: 2 Usuario: Todos . Historia de Usuario Número: 1 Usuario: Secretaria Nombre historia: Selección de pedidos a procesar (cliente preferente) Prioridad en negocio: Riesgo en desarrollo: Alta Baja Puntos estimados: 3.

Observaciones: Para cada pedido se tiene un glosario que indica las materias primas necesarias para la fabricación de productos. Este glosario físico se consulta manualmente. Historia de Usuario .Nombre historia: Control de acceso de usuarios Prioridad en negocio: Baja Riesgo en desarrollo: Baja Puntos estimados: 1 Iteración asignada: 3 Programador responsable: David Ferrer Descripción: Antes de iniciar la aplicación se solicita el nombre de usuario y su clave para que tenga acceso a los datos que corresponden a su categoría de usuario. con distintos permisos de acceso a los menús de acceso a las funcionalidades que les corresponden. Hay dos tipos de usuario: secretaria y almacenista. Observaciones: Historia de Usuario Número: 3 Usuario: Secretaria Nombre historia: Pedido al proveedor de materias primas Prioridad en negocio: Riesgo en desarrollo: Media Baja Puntos estimados: 4.5 Iteración asignada: 3 Programador responsable: Paco Valverde Descripción: Se introduce manualmente las materias primas que se necesitan y se selecciona el proveedor al cual se van a comprar. se imprime el pedido.

Los patrones no varían. .Número: 4 Usuario: Almacenista Nombre historia: Control de productos semielaborados Prioridad en negocio: Baja Riesgo en desarrollo: Baja Puntos estimados: 1.1 Iteración asignada: 3 Programador responsable: Descripción: El almacenista actualiza periódicamente el stock de productos semielaborados Observaciones: No se produce bajo pedido. lo que incluye los productos terminados. Se incluyen aquí los productos en diferentes etapas de elaboración.