Font size
WorksheetsEvaluación ISII - 1er corte
Total questions: 25
Worksheet time: 14mins
¿Cuál es el rol de Scrum encargado de maximizar el valor del producto?
Scrum Master
Product Owner
Development Team
Stakeholders
El Sprint Review tiene como propósito:
Planear el siguiente Sprint
Revisar el incremento y adaptarlo si es necesario
Evaluar la velocidad del equipo
Detectar fallas técnicas
El artefacto de Scrum que refleja el trabajo pendiente por realizar en el producto es:
Backlog
Sprint Backlog
Incremento
Roadmap
El comando para crear una nueva rama en Git es:
git init
git branch nombre_rama
git merge
git checkout
En GitHub, un Pull Request se usa para:
Solicitar acceso a un repositorio
Proponer la integración de cambios
Descargar el proyecto
Eliminar ramas remotas
Una Historia de Usuario debe incluir:
Un caso de uso completo
Como [rol] quiero [funcionalidad] para [beneficio]
Solo requisitos técnicos
Diagramas UML
Una HU debe ser:
Larga y detallada
Ambigua para flexibilidad
Independiente, negociable, valiosa, estimable, pequeña, comprobable
Redactada solo por desarrolladores
Un equipo tiene dificultades para estimar tareas. ¿Qué técnica podría ayudar?
Kanban
Planning Poker
Backlog Grooming
Retrospectiva
La velocidad del equipo se calcula como:
El número de HU completadas en un Sprint
Los puntos de historia completados en un Sprint
El número de commits realizados
La cantidad de errores corregidos
Durante la Sprint Review, el cliente insiste en incluir una nueva funcionalidad que no estaba planificada. ¿Qué debe recomendar el Scrum Master?
Aceptarla en el Sprint actual.
Añadirla al Product Backlog y priorizarla en el siguiente Sprint.
Cancelar el Sprint en curso.
Asignar horas extras al equipo para cumplir con todo.
El equipo de desarrollo no logra cumplir los objetivos de tres Sprints consecutivos. ¿Qué debería revisarse primero en la Retrospectiva?
La definición de 'Hecho'.
La duración del Sprint.
La experiencia del Product Owner.
La cantidad de ceremonias realizadas.
Un Product Owner prioriza siempre lo que él considera más importante, sin consultar a stakeholders. ¿Cuál es el principal riesgo?
Que se generen bugs en producción.
Que el producto entregue poco valor al negocio.
Que el Scrum Master asuma su rol.
Que el Sprint Backlog quede incompleto.
En un Daily Scrum, un integrante reporta siempre 'todo va bien' pero no entrega avances. ¿Qué debería hacer el equipo?
Ignorarlo, pues el Daily no es de control.
Señalarlo en la Retrospectiva y ajustar la dinámica.
El Scrum Master debe pedir un informe escrito.
El Product Owner debe evaluar su desempeño.
El Incremento de producto en Scrum se considera entregable cuando:
Está probado y cumple con la definición de 'Hecho'.
Tiene documentación técnica lista.
El Scrum Master lo aprueba.
Está integrado en la rama principal.
Un equipo distribuye tareas en Jira, pero no mide tiempos ni avances. ¿Qué indicador falta implementar?
Velocidad del equipo.
Product Backlog.
HU pendientes
HU por rol.
En un proyecto, varios miembros editan el mismo archivo y surgen conflictos. ¿Qué práctica mejora la situación?
Evitar commits múltiples.
Sincronizar ramas con git pull frecuente.
Cambiar de herramienta.
Centralizar en un solo desarrollador.
Un cliente propone la HU: "El sistema debe generar reportes PDF". ¿Por qué no es adecuada?
Porque no es un requisito funcional.
Porque no cumple la característica de completitud.
Porque está en español.
Porque es muy específica.
Una HU correctamente escrita es:
El sistema debe permitir generar reportes PDF.
Se necesitan reportes mensuales.
El software tiene que ser rápido.
Como estudiante, quiero descargar mis notas para revisar mi progreso.
Los criterios de aceptación permiten:
Verificar cuándo una HU está completa.
Describir la arquitectura.
Priorizar requisitos.
Estimar la duración del Sprint.
Si una HU no es comprobable, ¿qué problema genera?
No se puede asignar al Product Owner.
No se puede validar en pruebas.
No se puede estimar en Planning Poker.
No se puede incluir en el backlog.
Un equipo nuevo estima en horas y nunca logra cumplir el Sprint. ¿Qué alternativa podría ayudar?
Cambiar a estimaciones con puntos de historia.
Usar Planning Poker con horas.
Reducir el Sprint a la mitad.
Eliminar el backlog.
En la secuencia de Fibonacci usada en estimación, ¿por qué se omiten algunos números?
Para simplificar y reflejar incertidumbre creciente.
Para evitar números primos.
Para reducir el backlog.
Porque el cliente lo pide así.
Si un equipo usa horas en lugar de puntos de historia, ¿qué limitación aparece?
No permite medir progreso relativo entre tareas.
Es más rápido pero menos ágil.
El cliente no lo entiende.
Las horas nunca cambian.
Durante una retrospectiva, el equipo identifica que la comunicación entre desarrolladores y testers es débil y está causando retrasos. El artefacto de Scrum que deberiaa actualizarse para reflejar estas mejoras es el
(Nota: Escribir la respuesta toda en mayusculas )
(a)
La reunión diaria en Scrum, que dura un máximo de 15 minutos y permite al equipo sincronizarse, se denomina (Nota: La respuesta en mayusculas)
(a)
