User stories
Upcoming SlideShare
Loading in...5
×
 

User stories

on

  • 318 views

 

Statistics

Views

Total Views
318
Views on SlideShare
231
Embed Views
87

Actions

Likes
0
Downloads
5
Comments
0

1 Embed 87

http://digicampus.upb.edu.co 87

Accessibility

Categories

Upload Details

Uploaded via

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

User stories User stories Presentation Transcript

  • Extremme Programming Ingeniería de Requerimientos Historias de Uso y el Juego de Planificación
  • IR mediante Historias de Usuario • La problemática de los requisitos en el contexto de XP se reduce a la gestión de las HU (User Stories) • Esta practica es denominada “Juego de la Planificación"
  • Historias de Usuario • El tratamiento de HU es dinámico y flexible, en cualquier momento pueden modificarse, reemplazarse, por otras más específicas o generales y añadirse nuevas • Cada HU es lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas • Al comienzo de cada iteración estarán registrados los cambios en las HU y según eso se planificará la siguiente iteración. • Las HU son descompuestas en tareas de programación y asignadas a los programadores para ser implementadas durante una iteración.
  • ¿Cuál es el nivel de detalle adecuado para HU? • Depende de la complejidad del sistema • Debe haber al menos una historia por cada característica importante • Se propone realizar una o dos HU 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. • Para efectos de planificación, las historias pueden ser de una a tres semanas de tiempo de programación (para no superar el tamaño de una iteración ágil).
  • Kent Beck propone un ejemplo de ficha (customer story and task card) en la cual pueden reconocerse los siguientes contenidos: • Generales: fecha, tipo de HU (nueva, corrección, mejora), prueba funcional, número de historia • Estimación y dependencia: prioridad técnica y del cliente, referencia a otra historia previa, riesgo asociado y estimación técnica • Complementarios: descripción, notas y una lista de seguimiento con la fecha, estado cosas por terminar y comentarios. ¿Qué información tiene una HU?
  • Ejemplo: HU Generación Factura Historia de Usuario Número: 4 Usuario: Jefe de ventas Nombre historia: Generación de factura Prioridad en negocio: Media Riesgo en desarrollo: (Alta / Media / Baja) Puntos estimados: 1 Iteración asignada: 2 Programador responsable: Descripción: Se generan las facturas correspondientes a los pedidos realizados, en cada factura deben aparecer los datos del cliente y los pedidos servidos completamente en dicho mes. Observaciones: Las facturas se generan cada 30 días CONFIRMADO con el cliente
  • Juego de Planificación • Espacio de comunicación entre dos tipos de jugadores: Cliente y Programador • El equipo técnico realiza una estimación del esfuerzo requerido para la implementación de las HU • El cliente establece la prioridad de cada HU, de acuerdo con el valor que aporta para el negocio • Se ordenan las HU según prioridad y esfuerzo, y se define el contenido y tiempo de la entrega y/o iteración • Se realiza durante planificación de la entrega, planificación de cada iteración y cuando sea necesario reconducir el proyecto.
  • • Para planificar el trabajo desde el punto de vista técnico las HU son divididas en tareas para las cuales también se realiza una estimación del esfuerzo asociado que no debe superar los 3 días de programación. • Teniendo en cuenta el esfuerzo asociado a HU y las prioridades del cliente se define un release alcanzable y que sea de valor para el cliente • Este release es dividido en iteraciones de no mas de 3 semanas, asignando a cada iteración un conjunto de HU que serán implementadas. Estimación de esfuerzo: Release
  • Estimación de esfuerzo: Velocidad • Las estimaciones de esfuerzo asociado a la implementación de las historias la establecen los programadores utilizando como medida el punto. • Un punto, equivale a una semana ideal de programación. Las historias generalmente valen de 1 a 3 puntos. • El equipo de desarrollo mantiene un registro de la “velocidad” de desarrollo, establecida en puntos por iteración, basándose principalmente en la suma de puntos correspondientes a las historias de usuario que fueron terminadas en la última iteración.
  • Estimación de esfuerzo: Tiempo y alcance • La velocidad del proyecto es utilizada para establecer cuántas historias se pueden implementar antes de una fecha determinada o cuánto tiempo tomará implementar un conjunto de historias. • Al planificar por tiempo, se multiplica el número de iteraciones por la velocidad del proyecto, determinándose cuántos puntos se pueden completar • Al planificar según alcance del sistema, se divide la suma de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto, obteniendo el número de iteraciones necesarias para su implementación.
  • Actividad: Gestión de pedidos Se desea desarrollar una aplicación web de gestión de pedidos de una empresa. La aplicación debe cubrir todos los aspectos relacionados con dicho negocio, teniendo en cuenta la siguiente dinámica de funcionamiento: Los vendedores conciertan los pedidos con los clientes. Para cada pedido el cliente especifica qué artículos desea y la cantidad de cada uno de ellos. Interesa guardar la fecha en la que se realiza el pedido. Es imprescindible que el cuente proporcione su DNI al hacer el pedido. Así se comprobará que el cliente está registrado en el sistema y que, por tanto, disponemos de la dirección y el teléfono del cliente. Los clientes también podrán hacer su pedido vía web. El Jefe de Ventas, posteriormente, debe analizar la viabilidad de cada pedido realizado. Como resultado de este análisis puede aceptar ó denegar por: • El cliente que ha realizado el pedido es un cliente moroso, esto es, no ha pagado alguna factura emitida a su nombre al menos tres meses antes. En ese caso se le envía una carta al cliente explicándole que no se le acepta el pedido hasta que abone dichas facturas. El pedido queda registrado como rechazado. Aunque no va a volver a reconsiderarse en el futuro, es decir, que el cliente deberá realizar el pedido de nuevo si lo desea, interesa guardar los pedidos rechazados.
  • Actividad: Gestión de pedidos El almacenista, todos los días, prepara las entregas de los pedidos. Comprueba cada pedido aceptado para ver si puede servirlo completamente, esto es, a ver si dispone en el almacén de todos los artículos y sus cantidades. En el caso en que sí pueda, realiza la remisión correspondiente y registra el pedido como servido. Si no puede servirlo completamente, entonces, intenta servir todo lo que pueda, realiza la remisión correspondiente y registra el pedido como servido parcialmente. Los pedidos servidos parcialmente volverán a ser considerados por el almacenista al día siguiente para ver si pueden servirlos completamente (lo que falte, claro). En toda remisión debe aparecer la fecha de entrega, el nombre del cliente y todos los artículos con sus cantidades y el pedido en el que se solicitaron. Es posible que en una remisión se mezclen productos de distintos pedidos. Las facturas son generadas mensualmente por el jefe de ventas. En cada factura deben aparecer los datos del cliente y los pedidos servidos completamente en dicho mes. El jefe de ventas también se encarga de comprobar cuándo se pagan las facturas para anotarlo en el sistema. En todo momento el jefe de ventas puede comprobar si un cliente es moroso y el almacenista puede comprobar el stock de cualquier artículo.
  • Gestión de pedidos Objetivo: Estimar y Planificar el proyecto mediante la técnica de Historias de Usuario Actividades: 1: Realizar Diagrama de Procesos 2: Definición de Historias de Usuario – Especificación de HU – Tareas de Ingeniería – Estimación esfuerzo asociado – Planificación de iteraciones 3: Definición primer Release