Escribir Historia

English

Entradas

• Historias de Negocio

Salidas

• Historias de Negocio

Solución

Proceso

Tiempo de Desarrollo

• Para adquirir el conocimiento necesario para desarrollar el producto software:
• Para crear el Patrón de Producto: 15 minutos.
• Para aplicar el Patrón de Producto:

Video Explicación

• No aplica

Patrones Relacionados

• Patrón Estimar Historia

Controladores de Calidad

• Ninguno

Plantillas

• Historias_Negocio.doc

Ejemplos

Historia de Usuario

Herramientas de Soporte

• Será necesario un editor de texto como OpenOffice Writer o Microsoft Word.
• Además de una herramienta como [Visual Paradigm for UML]para la realización de los diagramas expuestos.

Contexto Inicial

Este producto puede usarse en cualquier proyecto en el que el proceso de recogida de los requerimientos funcionales del negocio se realice recibiendo historias escritas, lo mas atómicas posibles, por parte del negocio. Además, se usa en los proyectos en los que los requerimientos son cambiantes y es preciso entregar el resultado del proyecto en una fecha determinada que implica un alto riesgo para la consecución del mismo.

Contexto Resultante

Se obtendrán un conjunto de historias, escritas por el negocio, en las cuales se describirán, de la manera mas atómicas posibles, las funcionalidades del aplicativo a desarrollar.

Las historias de usuarios representan una breve descripción del comportamiento del sistema, emplea terminología del cliente, sin lenguaje técnico, se realiza una por cada caracteristica principal del sistema. Se emplean para hacer estimaciones de tiempo y para el plan de lanzamientos, reemplazan un gran documento de requisitos y presiden la creación de las pruebas funcionales.

Problema

El área tecnológica debe ser capaz de conseguir que el negocio entregue las historias lo mas sencillas y atómicas posibles.

Restricciones (Forces)

• Características de las organizaciones: Este patrón puede utilizarse en los proyectos existentes en cualquier tipo de compañía.
• Tipo de sistema a desarrollar: Este producto puede utilizarse en proyectos en los que los requerimientos de usuario sean cambiantes.
• Tipo de Cliente: Debe existir, o debe conseguirse, que el área de negocio destinataria del desarrollo se implique en la consecución del mismo.
• Heurísticas de uso: :Se deben establecer reuniones entre las áreas tecnológicas y de negocio donde la comunicación sea fluida y haya confianza mutua. El espacio de trabajo debe estar organizado conforme a las directrices de la metodología. Es importante que no falte comida y bebida para que las reuniones sean distendidas.

Roles

• Usuarios del área de negocio (2 como mucho)
• Desarrolladores (2 a 12)
• Director de proyecto de desarrollo (1)
• Preparador (1)
• Controlador (1)

Nota: el preparador y el controlador pueden ser la misma persona.

Lecciones Aprendidas

Las reuniones deben de ser cortas y deben de estar dirigidas por un preparador del área de tecnología. Debe hacerse amena la reunión con comida, bebida, anécdotas, etc…. El usuario de negocio debe estar enteramente dedicado al proyecto. Establecer reuniones en las que siempre participe el área de negocio junto con el equipo de desarrollo (programadores incluidos).

Nivel de Madurez

• Este Patrón de Producto no se relaciona con ningún nivel de madurez(N/A).

Conocimientos y Habilidades Básicos

Conocimientos

• Conocimiento del estándar de codificación que define la propiedad del código compartido así como las reglas para escribir y documentar el código y la comunicación entre diferentes piezas de código desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera que el código en el sistema se vea como si hubiera estado escrito por una sola persona.
• Conocimiento de la visión común de cómo funciona el programa en el que se desarrollan las actividades.

Habilidades

• Capacidad de trabajo en grupo.Todos en un equipo XP contribuyen de la manera que pueden.
• Predicción de qué se habrá terminado para la fecha de entrega, y determinación de qué hacer después.
• Capacidad de programación de a pares.Además de generar mejor código y pruebas, sirve para comunicar el conocimiento a través de los equipos.

Recursos de Información

• Álvarez, José R. y Arias Manuel. Método Extreme programming.Recuperado el 2010-03-05 de http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node61.html
• Anaya Villegas, Adrian. A proposito de programación extrema XP(extreme Programming).Recuperado el 2010-02-10 de http://www.monografias.com
• Beck, K.(2000), Una explicación de la programación extrema. Aceptar el cambio. Ed. Addisson Wesley.
• De Seta, Leonardo. Una introducción a Extreme Programming.Recuperado el 2010-03-02 de http://www.dosideas.com/noticias/metodologias/822-una-introduccion-a-extreme-programming.html
• Extreme Programming: A gentle introduction. Recuperado el 2010-03-15 de http://www.extremeprogramming.org/
• Joskowicz, José. Reglas y prácticas en Xtreme Programming. Recuperado el 2010-03-15 de http://iie.fing.edu.uy/~josej/docs/XP%20-%20Jose%20Joskowicz.pdf
• Letelier, Patricio y Panadés Mª Carmen. Metodologías Ágiles en el desarrollo de software: extreme programming. Recuperado el 2010-03-15 de http://www.willydev.net/descargas/masyxp.pdf
• Newkirk, James y Martin, Robert C.(2001), La programación Extrema en la Práctica.Ed Addisson Wesley.

---