Historias de Usuario

Multiple Choice

Significado de las tres Cs.

• Comunication, Conversation, Criteria

• Calendar, Cost, Comunication

• Carta, conversación, coordinación

• Card, Conversation, Confirmation

Multiple Choice

Significado de las siglas BDD de los criterios de aceptación.

• Base de Datos

• Behavior Driven Development

• Behavior Domain Development

• Test Driven Development

Multiple Choice

Estructura básica de una Historia de Usuario.

• Yo como (rol del usuario) quiero (objetivo) para (beneficio)

• Yo como (evento esperado) quiero (objetivo) para (beneficio)

• Yo como (objetivo) quiero (beneficio) para (rol del usuario)

• Yo como (rol del usuario) quiero (beneficio)

Multiple Choice

Los criterios de aceptación BDD deben describir.

• Un evento y una respuesta esperada del sistema

• Un contexto y una respuesta esperada del sistema

• Un contexto, un evento, datos de entrada y salida y una respuesta esperada del sistema

• Un contexto, un evento y una respuesta esperada del sistema

Multiple Choice

Estructura básica para la creación de criterios de aceptación BDD.

• Dado que-entonces-cuando

• Cuando-entonces-dado que

• Dado que-entonces

• Dado que-cuando-entonces

Multiple Choice

En que enfatiza las historias de usuario

• Aplicar las funcionalidades de objetivos al negocio

• Crear las funcionalidades del negocio

• Administrar funcionalidades y satisfacer a los usuarios

• Describir las funcionalidades de objetivos del negocio

Multiple Choice

Entre los criterios básicos para construir una historia de usuario... ¿se encuentra la "productividad"?

• Verdadero

• Falso

Multiple Choice

para qué NO se usan los criterios de aceptación

• Ayudan a equipo de QA de cara a dar el OK a considerar finalizada la historia de usuario

• Los criterios de aceptación no pueden definir la funcionalidad a implementar

• Los criterios de aceptación se mapean de manera directa sobre test funcionales

• Ayudan al desarrollador a implementar la tarea de forma correcta

Multiple Choice

¿Cual es la estructura para escribir una historia de usuario?

• Quiero<qué> Para<objetivo>

  Como<quién>

• Para <objetivo>

  Quiero<qué>

  Desarrollo<producto/servicio>

• Quiero<qué> Como<quién> Para<objetivo>

• Como <quién> Quiero <qué> Para <objetivo>.

Multiple Choice

La funcionalidad que se desarrollará en un producto o servicio se centra en tareas de desarrollo expresadas como

• Personas

• Proposito u objetivo

• Necesidades

• Todas las anteriores

Multiple Choice

SLICING,Orientación sugerida para dividir ítems del backlog a fin de obtener Historias de Usuario que sean funcionales

• Cortes horizontales por capa de la HU

• Cortes verticales que abarquen todos los niveles de la HU

• No importa la orientación

• Cortes longitudinales

Multiple Choice

Una Historia debe aceptarse cuando se cumpla con algunos criterios de aceptación?

• Verdadero

• Falso

Multiple Choice

En una Historia de Usuario pueden existir mas de 1 escenario para describir los criterios de aceptación?

• Verdadero

• Falso

Multiple Choice

Hipótesis de negocio mayor a 3 meses.

• Épica

• Iniciativa

• Historia de Usuario

• Tarea

Multiple Choice

Funcionalidad o característica menor o igual a 3 meses.

• Épica

• Iniciativa

• Historia de Usuario

• Tarea

Fill in the Blanks

El walking skeleton es el producto que construimos agrupado por las funcionalidades, que se definien en el Backlog como

Fill in the Blanks

El Backbone es la columna vertebral compuesto por

con las cuales se describe la experiencia del usuario en su recorrido

Multiple Choice

Parte de una funcionalidad menor a 2 semanas.

• Épica

• Iniciativa

• Historia de Usuario

• Tarea

Multiple Choice

Actividad técnica menor a 8 horas.

• Épica

• Iniciativa

• Historia de Usuario

• Tarea