Flashcards Seminario 2: Historias de Usuario.

¿Cuál es la definición canónica de Historia de Usuario según Kent Beck y Martin Fowler? Fundamentos de HU

Es la unidad mínima de funcionalidad en un proyecto ágil. El progreso se demuestra entregando código probado e integrado que implementa una historia. Debe ser comprensible para el cliente, probable por los desarrolladores, valiosa para el negocio y lo bastante pequeña para construir media docena en una iteración.

¿Cuál es el objetivo primordial de las Historias de Usuario en el desarrollo ágil? Fundamentos de HU

Lograr la interacción, comunicación y colaboración continua con el equipo y el usuario/cliente, muy por encima de documentar exhaustivamente los requisitos del sistema.

¿Qué NO es una Historia de Usuario (3 conceptos clave)? Fundamentos de HU

1) No es un requisito tradicional del sistema ni un contrato cerrado (es algo negociable). 2) No es un requisito de software técnico, sino una necesidad de un usuario. 3) No es una especificación detallada, sino 'la promesa de una conversación'.

¿En qué se diferencian los Casos de Uso (RUP) y las Historias de Usuario (XP/Scrum) respecto a la Planificación y la Duración? Fundamentos de HU

Los Casos de Uso NO se usan para planificar y pueden implementarse a lo largo de varias iteraciones. Las Historias de Usuario SÍ se usan directamente para planificar y deben implementarse, probarse e integrarse en una única iteración.

¿En qué se diferencian los Casos de Uso y las Historias de Usuario respecto al Soporte físico, Comunicación y Pruebas? Fundamentos de HU

Los Casos de Uso son documentos extensos de archivo con comunicación textual/diagramas y pruebas en documentos separados. Las HU son tarjetas para uso directo basadas en comunicación verbal y contienen sus pruebas de aceptación en el reverso de la tarjeta.

¿Quién escribe las Historias de Usuario en XP, en Scrum y en la práctica real? Roles y Formato Canónico

- En XP: El cliente (On-site Customer). - En Scrum: El Product Owner (con ayuda de clientes, stakeholders y equipo de desarrollo). - En la realidad: Cualquier miembro del equipo de desarrollo con conocimiento suficiente del dominio del problema.

¿Quiénes integran el 'Customer Team' (Stakeholders) que participa en la definición y priorización de HU? Roles y Formato Canónico

1) Clientes reales (usuarios finales), 2) Product Manager / Product Owner, 3) Probadores (Testers/QA) y 4) Diseñadores de interacción (UX/UI).

¿Cómo se identifican y definen los roles o personas del sistema? Roles y Formato Canónico

Mediante sesiones de 'Brainstorming' para listar perfiles y caracterizarlos según: frecuencia de uso del software, objetivos que se plantean al usarlo, forma habitual de acceso y nivel de experiencia en el dominio.

¿Cuál es la plantilla o formato canónico de una Historia de Usuario y qué representa cada cláusula? Roles y Formato Canónico

'Como [rol], Quiero [característica/objetivo], Para [valor de negocio/beneficio]'. - Como (Quién): Rol de usuario que usará la funcionalidad. - Quiero (Qué): Actividad o eje central de la historia. - Para (Por qué): Propósito o beneficio de negocio que justifica la historia.

¿Qué significa el modelo 'CCC' propuesto por Ron Jeffries? Las 3 C y Tarjeta Física

1) Card (Tarjeta): 2-3 frases que describen la intención de la HU. 2) Conversation (Conversación): Diálogo continuo con el usuario/cliente donde se detallan los requisitos. 3) Confirmation (Confirmación): Pruebas de aceptación que verifican que la HU ha sido implementada correctamente.

¿Qué ocurre si una tarjeta (Card) de Historia de Usuario incluye demasiados detalles escritos? Las 3 C y Tarjeta Física

Una tarjeta con demasiados detalles limita y sustituye la conversación con el cliente. La tarjeta solo debe recordar la intención y provocar las preguntas adecuadas para la etapa de Conversación.

¿Qué información se registra en el ANVERSO y en el REVERSO de una tarjeta física de HU? Las 3 C y Tarjeta Física

- Anverso: Identificador (ID), Título, Descripción canónica (Como/Quiero/Para), Estimación (PH), Prioridad y Dependencias. - Reverso: Pruebas o Criterios de Aceptación que delimitan el alcance y las condiciones de satisfacción.

¿Qué aspectos delimitan las pruebas de aceptación en la narración de una HU? Las 3 C y Tarjeta Física

Delimitan la parte exacta a abordar por la HU especificando: 1) Flujos alternativos en la actividad, 2) Límites de aceptación y 3) Pruebas de aceptación por parte de los clientes.

¿Cuáles son las 4 propiedades fundamentales de los Criterios o Pruebas de Aceptación? Confirmación y BDD

1) Propiedad del Product Owner (aunque cualquiera pueda redactarlas). 2) Escritas en lenguaje de negocio con claridad y sin ambigüedad. 3) Pruebas de caja negra e independientes de la implementación (describen QUÉ resultado se espera, no CÓMO programarlo). 4) Se implementan en la misma iteración que la HU.

¿Cuál es la estructura del formato BDD (Behavior-Driven Development) para redactar pruebas de aceptación? Confirmación y BDD

- DADO (Given): Contexto inicial o precondición del sistema. - CUANDO (When): Evento o acción realizada por el usuario. - ENTONCES (Then): Resultado observable o postcondición esperada del sistema.

¿Cuál es la diferencia entre Pruebas de Aceptación y Pruebas Unitarias? Confirmación y BDD

Las Pruebas de Aceptación son de caja negra, en lenguaje de negocio y propiedad del Product Owner para validar que se construye el producto correcto. Las Pruebas Unitarias son técnicas (caja blanca), escritas por desarrolladores sobre los módulos de código para verificar su funcionamiento interno.

¿Qué significan las siglas del modelo I.N.V.E.S.T. de Bill Wake? INVEST y Definition of Done

- I: Independiente (Independent) - N: Negociable (Negotiable) - V: Valiosa (Valuable) - E: Estimable (Estimable) - S: Suscinta / Pequeña (Small) - T: Testeable / Probable (Testable)

Explica las propiedades Independiente (I), Negociable (N) y Valiosa (V) de INVEST. INVEST y Definition of Done

- Independiente: Debe poder desarrollarse y entregarse sin depender rígidamente de otras HU. - Negociable: No es un contrato cerrado; sus detalles se ajustan en la conversación. - Valiosa: Debe aportar valor directo al usuario o al comprador (evitando HU puramente técnicas).

Explica las propiedades Estimable (E), Suscinta (S) y Testeable (T) de INVEST. INVEST y Definition of Done

- Estimable: El equipo puede calcular su esfuerzo para priorizarla y planificarla. - Suscinta (Small): Pequeña en esfuerzo (2-3 personas/semana o entre 1/10 y 1/6 de la velocidad del Sprint). - Testeable: Posee criterios objetivos para ejecutar la etapa de Confirmación.

¿Qué es la 'Definición de Terminado' (Definition of Done - DoD)? INVEST y Definition of Done

Es un acuerdo formal de calidad entre los desarrolladores y los clientes/Product Owner que establece los requisitos técnicos y de verificación que toda HU debe cumplir para considerarse completada.

Cita los 6 aspectos principales a considerar en una Definition of Done (DoD). INVEST y Definition of Done

1) Tipos y grado de pruebas (unitarias e integración). 2) Código documentado, revisado y sin incidencias críticas. 3) Entorno específico de cierre (preproducción, testing o producción). 4) Nivel de documentación. 5) Nivel de calidad del software (métricas). 6) Criterios de aceptación comprobados y aprobados por el PO.

¿Cuál es la diferencia crítica entre Criterios de Aceptación y Definition of Done (DoD)? INVEST y Definition of Done

Los Criterios de Aceptación son particulares y específicos de CADA Historia de Usuario (reglas funcionales de negocio). La DoD es un acuerdo de calidad transversal aplicable a TODAS las Historias de Usuario del proyecto.

¿Cuáles son los 4 niveles de la pirámide de granularidad de requisitos ágiles (de mayor a menor)? Granularidad y RNF

1) Temas (Themes): Grandes proyectos o subproductos globales. 2) Épicas (Epics): Súper historias; conjunto de HU relacionadas entre sí. 3) Historias de Usuario: Tarea concisa que aporta valor en una iteración. 4) Tareas (Tasks): División técnica de una HU para el desarrollo.

¿Qué reglas rigen la descomposición de una Historia de Usuario en Tareas técnicas? Granularidad y RNF

1) Tratables individualmente por los desarrolladores. 2) Duración de entre medio día (4h) y 3 o 4 días de trabajo. 3) Al terminar la tarea debe generarse un entregable. 4) No dedicar excesivo tiempo a estudiar detalles previos. 5) Incluir siempre tareas de prueba, documentación y automatización.

¿De qué 4 formas se pueden gestionar los Requisitos No Funcionales (RNF) en metodologías ágiles? Granularidad y RNF

1) Como restricciones asignadas a Temas, Épicas, HU o Tareas. 2) Como Criterios de Aceptación dentro de una HU. 3) Como parte transversal de la Definition of Done (DoD). 4) En un documento de especificación específico para los RNF globales al sistema (o como HU propias de calidad).

¿Qué es el Product Backlog y qué representa la Prioridad dentro de él? Priorización y Product Backlog

Es la lista priorizada y dinámica de HU que contiene toda la funcionalidad deseable del producto. La prioridad representa el valor que le da el cliente a cada HU según la medida en que satisface sus necesidades.

¿Cómo se estructura un Mapa de Historias de Usuario (User Story Mapping)? Priorización y Product Backlog

- Eje horizontal superior (Backbone): Flujo cronológico de actividades del usuario de izquierda a derecha. - Eje vertical: Prioridad, necesidad u opcionalidad (de arriba abajo). - Cortes horizontales: Definen las entregas o Releases sucesivas (empezando por el MVP o Walking Skeleton).

¿Cuáles son los 5 criterios fundamentales para priorizar Historias de Usuario? Priorización y Product Backlog

1) Valor de negocio para el cliente. 2) Valor/impacto para los usuarios (muchos usuarios estándar o pocos usuarios muy importantes). 3) Riesgo e incertidumbre. 4) Dependencias con otras HU priorizadas. 5) Tamaño y esfuerzo de desarrollo.

¿Cuál es la regla de oro sobre la evolución de la Prioridad y el Tamaño de una HU a lo largo del proyecto? Priorización y Product Backlog

'La prioridad puede cambiar, el tamaño NO'. El cliente puede reordenar la prioridad de una HU según el mercado, pero su esfuerzo relativo en Puntos de Historia permanece constante salvo que cambie su alcance.

¿Qué significan las categorías del método de priorización MoSCoW? Priorización y Product Backlog

- Must: Obligatorio para finalizar el proyecto (crítico). - Should: Debe completarse por todos los medios, pero el éxito inmediato no depende de él. - Could: Se completa si no afecta a los objetivos principales. - Would (Won't): Se completa solo si sobra tiempo o en futuras versiones.

¿Qué son los Puntos de Historia (PH) y qué variables combinan frente a los Días Ideales? Estimación, Planning Poker y Velocidad

- Puntos de Historia: Medida relativa del tamaño de una HU comparada con otras del mismo equipo; combina Esfuerzo necesario + Complejidad + Riesgo/Incertidumbre. - Días Ideales: Un día de trabajo continuo sin interrupciones.

¿Qué expresa el Cono de Incertidumbre en la estimación de proyectos? Estimación, Planning Poker y Velocidad

Muestra que al inicio del proyecto la incertidumbre es máxima (las estimaciones pueden variar hasta en un factor de 4x, de 0.25x a 4x) y disminuye progresivamente a medida que avanza el proyecto y se toman decisiones.

¿Qué es el Planning Poker, qué secuencia de cartas utiliza y cuál es el rol del moderador? Estimación, Planning Poker y Velocidad

Es una técnica de estimación por consenso que usa cartas con la secuencia de Fibonacci (0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, café). El moderador gestiona la reunión y controla los tiempos, pero NO estima.

¿Cómo funciona la dinámica de votación en el Planning Poker cuando no hay consenso? Estimación, Planning Poker y Velocidad

Todos los estimadores eligen su carta en secreto y la revelan a la vez (evitando el efecto anclaje). Si no hay consenso, las personas con las estimaciones más altas y más bajas justifican sus razones, se discute brevemente y se vuelve a votar hasta lograr consenso.

¿Qué es la Velocidad del equipo y cuáles son los 3 métodos para calcularla? Estimación, Planning Poker y Velocidad

Es la cantidad de Puntos de Historia (PH) que un equipo puede completar en una iteración. Se obtiene mediante: 1) Datos históricos ('el tiempo que hizo ayer'). 2) Ejecutar una iteración inicial de prueba. 3) Hacer un pronóstico mediante 'cálculo de recursos'.

¿Cuál es la fórmula del Cálculo de Recursos para pronosticar la Velocidad con Factor de Dedicación? Estimación, Planning Poker y Velocidad

1) Días de trabajo brutos = Nº Programadores × Días laborables de la iteración. 2) Capacidad teórica = Días de trabajo brutos × (PH por día ideal). 3) Velocidad = Capacidad teórica × Factor de dedicación (%). (Ej: 5 prog × 10 días × 80% = 40 PH).

¿Cuáles son las 3 etapas del proceso de división de Historias de Usuario grandes (Richard Lawrence)? Patrones de División y Spikes

1) Preparar la HU de entrada: Verificar INVEST y comprobar si supera 1/10 a 1/6 de la velocidad. 2) Aplicar los patrones de división (o crear un Spike como último recurso). 3) Evaluar la división: Comprobar que las nuevas HU tengan tamaño similar, sean cortes verticales, cumplan INVEST y permitan despriorizar o eliminar partes.

Explica los patrones de división 1 (Pasos del flujo de trabajo) y 2 (Reglas de negocio). Patrones de División y Spikes

1) Pasos del flujo de trabajo: Identificar los pasos secuenciales que realiza el usuario e implementarlos incrementalmente. 2) Reglas de negocio: Si una HU incluye varias condiciones o límites de negocio (ej. saldo negativo vs. límite diario en cajero), crear historias separadas para cada regla.

Explica los patrones de división 3 (Mayor esfuerzo de desarrollo) y 4 (Sencillo / Complejo). Patrones de División y Spikes

3) Mayor esfuerzo: Dividir varias alternativas de modo que la primera absorba el esfuerzo de infraestructura base y las siguientes sean adiciones pequeñas. 4) Sencillo / Complejo: Preguntarse '¿qué es lo más simple que podría funcionar?', implementar ese núcleo primero y dejar las variaciones complejas para nuevas HU.

Explica los patrones de división 5 (Variaciones en datos) y 6 (Métodos de entrada de datos / Vista IU). Patrones de División y Spikes

5) Variaciones en datos: Dividir según el tipo, formato o idioma de los datos (ej. mensajes en español y luego en inglés) o criterios de búsqueda (título, autor, ISBN). 6) Métodos de entrada / IU: Empezar con una interfaz simple (ej. navegador escritorio) y añadir luego interfaces más complejas (ej. app móvil).

Explica los patrones de división 7 (Niveles de calidad), 8 (Operaciones múltiples) y 9 (Escenarios de caso de uso). Patrones de División y Spikes

7) Niveles de calidad: Implementar la funcionalidad básica primero y optimizar rendimiento/accesibilidad en HU posteriores. 8) Operaciones múltiples: Dividir verbos genéricos ('Gestionar', 'Administrar') en operaciones CRUD individuales (Alta, Baja, Edición, Búsqueda). 9) Escenarios de caso de uso: Dividir cada escenario o flujo alternativo en una HU.

¿Qué es un SPIKE y por qué motivos puede originarse? Patrones de División y Spikes

Es un tipo especial de HU acotada en el tiempo usada para reducir un riesgo o incertidumbre técnica o funcional y aumentar la seguridad al estimar una HU. Se origina por desconocimiento del dominio/tecnología, HU demasiado grandes de impacto incierto, riesgos técnicos de diseño o riesgos funcionales de interacción.

¿Cuál es la diferencia entre un SPIKE Técnico y un SPIKE Funcional? Patrones de División y Spikes

- SPIKE Técnico: Analiza aproximaciones en el dominio de la solución (decidir entre comprar o construir una librería, evaluar rendimiento o impacto de carga). - SPIKE Funcional: Resuelve incertidumbres en el dominio del problema sobre cómo el usuario debe interactuar con el sistema (ej. prototipo de histograma con usuarios).

¿Cuáles son las 5 Reglas de Oro sobre la gestión de los SPIKES? Patrones de División y Spikes

1) Se tratan como cualquier otra HU (van al backlog, se priorizan y estiman). 2) Su resultado NO es código de producción, sino información útil (decisión, prototipo, diseño). 3) Su solución debe ser demostrable al equipo. 4) Debe aceptarse mediante criterios de aceptación propios. 5) Se resuelve en una iteración previa/diferente a la de la HU que lo creó.

¿Qué ventaja estratégica de priorización se obtiene al dividir una HU grande en lonchas verticales? Patrones de División y Spikes

Permite intercalar y adelantar otras funcionalidades críticas de negocio (como el carrito de compra o el pago con tarjeta) justo después de implementar la loncha básica (ej. búsqueda por título), posponiendo las variaciones menos urgentes (ej. búsqueda por ISBN) al final del backlog.

Ningún término con ese filtro.