Juego de rol: Simulación de desarrollo de producto

En este juego de rol, desarrollaremos un canal de ventas en línea para una empresa ficticia.

Desarrollaremos un proyecto de Scrum simulado pero completo, poniendo en práctica

todas las reuniones prescritas en Scrum y utilizando los artefactos relacionados. En
cada paso en el juego de rol se utilizarán las salidas/resultados de los pasos anteriores.

Para efectos prácticos, en este juego de rol nos enfocaremos únicamente en las
páginas web necesarias para un canal de ventas en línea, asumiendo que ya existe
cualquier infraestructura que sea necesaria (base de datos, interfaces de servidor, etc.),
funcionalidad de trastienda (back-office) y recursos humanos, entre otros.

Debido a que no podemos desarrollar páginas web durante un curso de dos días, las
desarrollaremos en papel, utilizando una técnica conocida como "prototipos de papel" o
Paper Prototyping (para más información, consulte el libro: Paper Prototyping: The Fast
and Easy Way to Design and Refine User Interfaces de Carolyn Snyder, Morgan
Kaufmann Publishers; 2003; ISBN-13: 978-1- 55860-870- 2).
Escenario del estudio de caso

VMfoods es una cadena nacional de supermercados de 10 años de antigüedad con

cerca de 100 sucursales. Recientemente, los gerentes se percataron de que sus
clientes llevan un acelerado estilo de vida y no viajan largas distancias para hacer sus
compras. Consideran también que las compras en el supermercado no son un proceso
muy complejo (y ya que VMfoods ofrece siempre productos de alta calidad), la mejor
forma de aumentar su cuota de mercado sería entregando productos a domicilio.

En este sentido, un representante se ha puesto en contacto con su equipo a nombre de

VMfoods para crear un sitio web donde los clientes puedan preparar sus pedidos de
entrega en línea y hacer los pagos por ese mismo medio.

Durante la reunión de visión del proyecto un representante de la empresa (en este

caso, el instructor) le da a usted la visión y los requerimientos genéricos.

Declaración de la visión del proyecto (Project Vision Statement):

Ejercicio: Crear un primer Product Backlog

Con su equipo, elabore un primer Product Backlog (con historias de usuario de alto
nivel, también conocidas como "épicas") para la visión del producto proporcionada.
Algunas épicas ya han sido definidas para su consulta. Elabore elementos
adicionales para el Product Backlog (de 7 a 10).

Elemento Épica/ Descripción de historia de usuario

#
El sitio de compras en línea de VMfoods debe tener la funcionalidad de registro
1
(login) seguro.

2 Habilidad para hacer compras en línea.

Capacidad para buscar fácilmente los productos y tener la funcionalidad de carrito

3
de compras para seleccionar los artículos que se comprarán.
Discusión: Problemas con la creación de un Product Backlog

¿Qué debería hacer en las siguientes situaciones?

l. Los miembros del equipo están en desacuerdo con el Product Owner

respecto a las prioridades.

2. Los elementos del Product Backlog no están bien definidos.

Ejercicio: Reunión de planificación del sprint

Suponiendo que las primeras tres épicas/historias de usuario en su Product Backlog

son las de más alta prioridad, planifique su siguiente sprint con su instructor quién
asumirá el rol de Product Owner. Como parte de su reunión de planificación del sprint,
tome en cuenta los requerimientos detallados que se proporcionan a continuación.
Consulte con el Product Owner cualquier aclaración sobre detalles adicionales.

1. El sitio de compras en línea de VMfoods debe tener la funcionalidad de

registro (login) seguro.
 Como cliente, quisiera que el sitio web tenga la funcionalidad para que el
visitante pueda crear un registro único a fin de que VMfoods pueda mantener
una base de datos de sus visitantes.

 Como desarrollador web, me gustaría dar seguimiento a los datos de usuario

mediante su registro único, a fin de que el cliente pueda utilizar esta información
para personalizar ofertas para los visitantes.

 Como cliente, quiero la posibilidad de ingresar como visitante si no quiero

registrarme con mi información personal.

 La característica de registro (login) debe colocarse en parte superior derecha de

todas las páginas. La primera vez que se registren, se debe obtener la siguiente
información: Nombre, identificación de correo electrónico, domicilio de entrega,
edad (opcional), género (opcional) y número de personas en el hogar (opcional).

 A los clientes se les permite crear una contraseña única para sí mismos.

2. Habilidad para hacer pagos en línea.

 El sitio debe contar también con acceso a varias pasarelas de pago a fin de
permitir el pago.

 La página debe redirigirse a la pasarela de pago cuando el cliente seleccione el

botón para "proceder" después de haber terminado la compra.

 La pasarela de pago debe regresar a la página de pago satisfactorio en el sitio

web, la cual debe incluir enlaces a cualquier descuento por lealtad o descuentos
por referencia que brindemos.

3. Capacidad para buscar fácilmente los productos y tener la funcionalidad de

carrito de compras para seleccionar los artículos que se comprarán.
 Los usuarios deben poder, a simple vista, tener una idea sobre los productos en
el portafolio de VMfoods. Debe incluir una revista descargable que incluya todos
los productos de VMfoods.

 Los usuarios deben de contar con la facilidad de un carrito de compras para

 rastrear los productos que han agregado.

 Si el usuario no ha concluido la transacción en una determinada visita, la función

del carrito de compras debe mostrarlo en la siguiente visita como artículos
pendientes.

 Debe existir un mecanismo donde el cliente pueda cambiar los productos en el

carrito (aumentar la cantidad, cambiar de marca, etc.) sin tener que eliminar el
producto y regresar a buscarlo.

 Las categorías deben mostrarse en las pestañas ubicadas en la página de

aterrizaje (landing page) que lleven a una categoría de páginas por separado al
hacer clic.

 Las pestañas (tabs) deben ubicarse en la parte superior de la página de

aterrizaje en forma lineal, donde los usuarios puedan hacer clic y proceder a las
páginas relevantes.

 Debe haber pestañas con categorías específicas en la página principal que

cuenten con menús desplegables que muestren un máximo de cinco productos
más vendidos en esta categoría.

 El usuario debe poder dirigirse a una página individual de producto al

seleccionar la pestaña respectiva.

 El sitio web debe diseñarse con los siguientes colores: verde para los
encabezados, azul en los sub encabezados y negro para el texto.

 Los productos que se muestran deben aparecer en el margen de la página

principal.

 Las páginas de contacto, de términos y condiciones, sobre nosotros, etc., deben

colocarse y
estar listas para llenarse en la parte inferior de la página.
Responsabilidades del Scrum Master:

1. Crear el Sprint Backlog/Scrumboard del equipo en un tablero o pizarra junto con un Burndown
Chart.
2. Guíe al Equipo Scrum en la creación de tareas; que las escriban en post-its por separado. Guíelos
también en la estimación de tareas.

Ejemplo:
Discusión: Problemas con el desarrollo del Sprint Baddog

¿Qué debería hacer en las siguientes situaciones?

1. Un caso atípico de una persona que no quiere cambiar de opinión:

2. Una persona domina la sesión de planificación y no le da a los demás la

oportunidad de compartir sus ideas:

3. El equipo discute con el Product Owner la prioridad de las historias de usuario:

Ejercicio: Crear entregables/Daily Standups

Haremos una simulación de desarrollo de producto utilizando la técnica de desarrollo de

producto en papel (Paper Product Development). La técnica será explicada por el
instructor. Usted la utilizará para desarrollar las características asignadas en la reunión
de planificación del sprint.

En este juego de rol, la duración del día de trabajo simulado tendrá un time-box de 5
minutos. Un sprint consistirá de 3 días hábiles de 7 minutos (2 minutos para el Daily
Standup y 5 minutos de desarrollo).

Para cada sprint:

Día 1:
• Crear entregables (5 minutos)
• Daily Standup (2 minutos)

Día 2:
• Crear entregables (5 minutos)
• Daily Standup (2 minutos)

Día 3:
• Crear entregables (5 minutos)
• Daily Standup (2 minutos)

Preguntas para las reuniones del Daily Standup:

• ¿Qué complete ayer?
• ¿Qué completaré hoy?
• ¿Hay algún impedimento?
Discusión: Posibles problemas durante la implementación

¿Qué debería hacer en las siguientes situaciones?

1. El gerente ejecutivo intenta interferir:

2. Solución del problema:

Ejercicio: Revisión sprint

Las reuniones de revisión del sprint son parte del proceso de Demostrar y validar el
sprint. Al final de cada sprint, demuestre los elementos que su equipo ha terminado en
el sprint anterior al Product Owner (representado por el instructor o un miembro de otro
equipo).

Registre los siguientes datos:

# de miembros del equipo

# de puntos de historia intentados en el sprint

# puntos de historia completados (velocidad)

Historias de usuario completadas

Historias de usuario aceptadas por el Product

Owner
Discusión: Problemas en la revisión del sprint

¿Qué debería hacer en las siguientes situaciones?

1. Los miembros del equipo se niegan a aceptar cuando el Product Owner rechaza un
elemento en el Product Backlog:

2. Los miembros del equipo se culpan unos a otros por no cumplir las metas del sprint:
Ejercicio: Reunión de retrospectiva del sprint

Al final del sprint, realice una reunión de retrospectiva. Discuta lo que salió bien y
lo que no. Identifique oportunidades de mejoramiento.

¿Qué salió bien?

¿Qué no salió bien?

Oportunidades de mejoramiento: