WorksheetsHistoria de Usuario-IReqs
Total questions: 18
Worksheet time: 12mins
Las historias de usuario deben contener todos los detalles técnicos y funcionales del producto antes del desarrollo.
Verdadero
Falso
Una historia de usuario está completa solo cuando cumple con todos los criterios de aceptación y escenarios.
Verdadero
Falso
Lo más importante de una historia de usuario es el documento escrito.
Verdadero
Falso
Una historia de usuario puede representar incrementos parciales de funcionalidad con valor.
Verdadero
Falso
Las historias de usuario facilitan la planeación porque:
Definen de antemano los requerimientos técnicos
Permiten estimaciones rápidas de esfuerzo
Eluden la conversación con el cliente
Cuando se menciona que las historias son “insumo para documentación”, se implica que:
Sustituyen todos los documentos
Son la base para generar documentación
No requieren documentación adicional
Los criterios de aceptación deben:
Ser verificables
Ser negociables
Estar alineados con la intención del usuario
Entre las ventajas de las historias de usuario están:
Orientación a resultados
Reducción de documentación inicial
Incremento en la complejidad de planeación
Los elementos esenciales de una historia de usuario son:
Rol
Funcionalidad deseada
Beneficio o valor esperado
La conversación en torno a una historia puede:
Generar ajustes en criterios
Reemplazar criterios formales
Registrar aclaraciones importantes
El desarrollo basado en historias permite:
Evitar escenarios sin probar
Eliminar criterios de aceptación
Controlar incrementos de valor
Los criterios de aceptación se relacionan con:
Validación funcional
Aceptación del Product Owner
Diseño de la interfaz
Las historias deben escribirse:
De forma colaborativa
Con base en conversaciones reales
Únicamente por el Product Owner
En una historia de usuario, los beneficios “para” deben:
Expresar valor de negocio
Justificar la necesidad del usuario
Describir la solución técnica
La simplicidad de las historias de usuario puede fortalecer la comunicación entre el Product Owner y el equipo de desarrollo porque:
Facilita la comprensión y el enfoque en los objetivos comunes.
Hace que el proceso sea más lento y complicado.
Genera confusión sobre los requisitos del producto.
Limita la colaboración entre los miembros del equipo.
¿Qué riesgos enfrenta un equipo respecto a la agilidad y el valor entregado si documenta excesivamente las historias de usuario?
Puede perder flexibilidad y retrasar la entrega de valor.
Mejora la comunicación y acelera el desarrollo.
Aumenta la motivación del equipo y la innovación.
Reduce la necesidad de colaboración entre los miembros.
Los criterios de aceptación son considerados el “contrato” de la historia de usuario porque:
Definen claramente lo que debe cumplirse para que la historia se considere terminada.
Son una lista de tareas que el equipo debe realizar.
Representan los deseos personales del cliente.
Sirven únicamente para documentar el proceso de desarrollo.
¿Cuál es la diferencia conceptual entre una historia de usuario y un requisito funcional tradicional?
Una historia de usuario se centra en las necesidades y experiencias del usuario, mientras que un requisito funcional tradicional describe funciones específicas del sistema.
Ambos se enfocan únicamente en la funcionalidad técnica del sistema.
Una historia de usuario es más detallada y técnica que un requisito funcional tradicional.
Un requisito funcional tradicional siempre incluye la perspectiva del usuario.
