Test 2 Dirección

¿Qué se considera un riesgo en un proyecto?. Un evento seguro que siempre ocurre. Un evento incierto que tiene potencial de contribuir al éxito o al fracaso del proyecto. Un error técnico del código. Una tarea incompleta.

¿Qué tipos de riesgos existen según la imagen?. Riesgos lógicos y riesgos físicos. Riesgos humanos y de producto. Riesgos positivos y riesgos negativos. Riesgos funcionales y no funcionales.

¿Cómo se denominan los riesgos positivos?. Amenazas. Ventajas. Oportunidades. Problemas.

¿Cómo se denominan los riesgos negativos?. Oportunidades. Fortalezas. Retos. Amenazas.

¿Cuándo deben gestionarse los riesgos en un proyecto?. Solo al inicio del proyecto. Solo cuando ocurren problemas. Durante todo el proyecto. Solo en la fase final.

¿Qué implica gestionar riesgos durante todo el proyecto?. Ignorar los riesgos hasta que ocurran. Identificarlos, evaluarlos y responder según su probabilidad e impacto. Resolverlos solo en reuniones. Delegarlos al equipo de QA.

La evaluación de riesgos se basa principalmente en... Su tamaño en puntos de historia. Su probabilidad e impacto. Su duración estimada. Su prioridad en el backlog.

¿Qué debe hacerse con las historias de usuario identificadas como alto riesgo?. Dejarse para el final del proyecto. Ignorarse si son complejas. Abordarlas lo antes posible. Eliminarlas del backlog.

¿En qué iteraciones deberían incluirse los elementos de alto riesgo?. En las últimas. En las intermedias. En las primeras en lugar de en las posteriores. En cualquier lugar sin prioridad.

La probabilidad en un riesgo se refiere a... El valor económico del proyecto. La certeza con la que ocurrirá. La posibilidad de que un evento pueda ocurrir. El impacto técnico de un requisito.

¿Qué puede variar la probabilidad de un riesgo?. Entre 50% y 100%. Entre 0% y 25%. Desde poco más del 0% hasta poco menos del 100%. Solo entre 80% y 100%.

El impacto de un riesgo es... Siempre positivo. Siempre negativo. Neutral. Independiente del coste.

¿Cómo puede variar la magnitud del impacto de un riesgo?. Solo en tiempo de entrega. En coste e impacto en la salud, la vida humana o algunos factores críticos. Solo en complejidad técnica. Solo en número de historias del backlog.

¿Qué herramienta ayuda a determinar a qué riesgos prestar más atención?. Diagrama de Gantt. Matriz de probabilidad e impacto. Matriz RACI. Diagrama de clases.

¿Cómo se calcula la exposición de un riesgo?. Coste por velocidad. Impacto menos probabilidad. Probabilidad por impacto. Velocidad por puntos.

La gestión cualitativa de riesgos se basa en... Horas exactas. La matriz de esfuerzo. La matriz de probabilidad e impacto y la exposición. La arquitectura del sistema.

La exposición de un riesgo representa... La complejidad técnica. La velocidad del equipo. El producto de la probabilidad y el impacto. El número de historias asociadas.

¿Qué es el registro de riesgo?. Un documento estático. Un diagrama UML. Un registro que se reevalúa en cada reunión de sprint. Un backlog técnico adicional.

¿Con qué frecuencia se actualizan los valores del registro de riesgos?. Una vez al inicio del proyecto. Cada tres meses. En cada reunión de sprint. Solo al final del proyecto.

¿Por qué se actualiza el registro de riesgo en cada sprint?. Porque los riesgos cambian con el tiempo. Porque debe aprobarlo el cliente. Porque lo exige la arquitectura. Porque reduce la velocidad.

El diagrama de evolución de riesgos representa... La calidad del código. La burndown chart del producto. El estado del riesgo a lo largo de las iteraciones. La velocidad del equipo.

¿Para qué sirve el diagrama de evolución de riesgos?. Para planificar releases. Para eliminar requisitos. Para ver cómo se gestionan y controlan los riesgos. Para medir horas trabajadas.

Desde la perspectiva de la gestión de proyectos, el diagrama de riesgo es... Poco útil. Solo decorativo. Un excelente indicador del control del riesgo. Solo útil al final del proyecto.

¿Qué mide el eje Y en el Risk Burn-down Chart que aparece en la imagen?. La velocidad del equipo. El número de historias restantes. La exposición del riesgo. El coste de sprint.

¿Qué muestra el eje X en el Risk Burn-down Chart?. El número de tareas completadas. La probabilidad. Los sprints. El coste real.

¿Qué indica una línea descendente en el Risk Burn-down Chart?. Que el riesgo está aumentando. Que la exposición del riesgo disminuye con el tiempo. Que se agregan nuevas amenazas. Que no se ha gestionado el riesgo.

La gestión cuantitativa de riesgos se centra en... Medir la exposición del riesgo. Clasificar riesgos en colores. Ignorar riesgos poco probables. Solo registro documental.

¿Cuál de las siguientes si son características mencionadas de los métodos ágiles para mitigar riesgos?. Flexibilidad, comentario, estimación, transparencia, iterativo. Implementación. Estimación. Documentación exhaustiva.

¿Por qué la transparencia reduce riesgos en métodos ágiles?. Porque elimina la necesidad de reuniones. Porque permite detectar y abordar los riesgos lo antes posible. Porque reduce el tamaño del equipo. Porque impide que surjan riesgos nuevos.

¿Qué efecto tiene la entrega iterativa sobre el riesgo?. Aumenta el riesgo técnico. Reduce el riesgo asociado con la inversión. No tiene impacto en el riesgo. Duplica el coste del proyecto.

¿Qué es un Spike en el contexto de proyectos ágiles?. Un documento de requisitos iniciales. Un tipo de sprint donde no se desarrolla código. Una forma particular de mitigar riesgos en proyectos ágiles. Es un tipo especial de historia que se utiliza para actividades con un alto nivel de riesgo técnico o incertidumbre. Una tarea administrativa para cerrar un sprint.

¿Para qué se utilizan principalmente los Spikes funcionales?. Evaluar soluciones técnicas complejas. Determinar comportamiento funcional y determinar cómo descomponerlo, cómo podría organizarse y donde existen los riesgos que influyen en las decisiones de implementación. Calcular la capacidad del equipo. Aumentar la velocidad del sprint.

¿Cuál de las siguientes actividades podría formar parte de un Spike funcional?. Comparar frameworks de back-end. Analizar prototipos, flujos de interacción y técnicas. Seleccionar herramientas de infraestructura. Revisar estándares de codificación.

¿Para qué se usan los Spikes técnicos?. Para investigar enfoques técnicos y viabilidad de la solución. Para validar la satisfacción del cliente. Para reorganizar el backlog. Para estimar únicamente el esfuerzo.

¿Cuál es un posible objetivo de un Spike técnico?. Diseñar una interfaz para el usuario final. Evaluar alternativas de implementación específicas. Crear todas las pruebas unitarias de un módulo. Redactar documentación funcional.

¿Por qué los Spikes deben usarse con moderación?. Porque no se pueden estimar. Porque no aportan valor al usuario de forma directa. Porque aumentan la complejidad del sprint. Porque requieren muchos recursos técnicos.

¿Cuál de las siguientes afirmaciones sobre la estimabilidad de los Spikes es correcta?. No deben estimarse nunca. Deben estimarse, pero probablemente con baja precisión. La estimación de un Spike siempre es exacta. Solo se estiman si el product owner lo solicita.

¿Qué debería entregarse al finalizar un Spike?. Una funcionalidad completa. Un incremento del producto desplegable. Un conocimiento claro o una historia refinada para continuar. Un informe de riesgos obligatoriamente.

¿Qué ocurre si un Spike se alarga demasiado?. Aumenta la probabilidad de encontrar errores. Se convierte en una historia funcional tradicional. Se pierde su propósito exploratorio. Mejora la velocidad del equipo.

¿Qué caracteriza a un Spike respecto a otras historias?. Siempre genera código. No busca entregar valor directo al usuario final. Se incluye solo en releases finales. No requiere definición de terminado.

¿Qué se recomienda hacer después de un Spike para evitar riesgos?. Integrarlo siempre en producción. Crear otro Spike para confirmarlo. Ajustar historias, planificar acciones y evitar repetir errores. No modificar nada hasta el siguiente sprint.

¿Cuándo es especialmente útil un Spike funcional?. Cuando hay incertidumbre sobre factores que influyen en la implementación. Cuando ya se conoce exactamente la solución. Cuando el equipo quiere mejorar la velocidad. Cuando el cliente no proporciona requisitos.

¿Cuál de estos no es un objetivo típico de un Spike técnico?. Evaluar riesgos técnicos. Validar alternativas tecnológicas. Comparar enfoques de implementación. Definir el diseño final del producto.

Un Spike debe generar preferentemente: Código listo para producción. Documentación extensa y detallada. Una comprensión que permita avanzar con menor incertidumbre. Un incremento obligatorio del producto.

¿Cuál es una consecuencia positiva de utilizar Spikes dentro de un sprint?. Aumentan el alcance del sprint. Reducen la incertidumbre del equipo. Eliminan todos los riesgos del proyecto. Evitan la necesidad de estimar historias.

¿Qué tipo de riesgos ayudan a mitigar los métodos ágiles gracias a su carácter iterativo?. Riesgos financieros relacionados con la inversión. Riesgos legales. Riesgos de recursos humanos. Riesgos externos del mercado.

¿Qué propiedad del equipo ágil ayuda a reducir el riesgo de estimación?. Su capacidad de documentación. La naturaleza flexible del rol del Scrum Master. La estimación colaborativa del equipo. La planificación anual.

En la característica de estimable, demostrable y aceptable: Un pico debe ser aceptado por el propietario del producto y debe ser demostrable. Hay que evaluar riesgos técnicos. Hay que validar alternativas tecnológicas. Hay que comparar enfoques de implementación.

En la característica de la excepción no la regla: Cada historia de usuario tiene incertidumbre y riesgo. Una historia de picos debería reservarse para los casos más críticos y de mayor envergadura. Las historias de picos no deben utilizarse como sustituto de un diseño deficiente; solo se aplican cuando una historia normal no permite evaluar adecuadamente la complejidad o el riesgo. Una historia de pico no busca entregar funcionalidad al usuario final, sino obtener información que reduzca la incertidumbre del equipo antes de comprometer un desarrollo mayor. Si todas las historias se transforman en historias de picos, el equipo pierde capacidad de planificación; por eso deben emplearse de manera muy limitada y justificada.

En la característica de implementar el pico en una iteración separada de las historias resultantes: Dado que un pico representa incertidumbre en una o más historias potenciales, planificar tanto el pico como las historias resultantes en la misma iteración es de alto riesgo. Separar el pico de las historias derivadas permite al equipo obtener el conocimiento necesario antes de comprometer capacidad de desarrollo en funcionalidades específicas. Implementar primero el pico reduce la probabilidad de retrabajo, ya que las decisiones técnicas clave se toman con información real y no con suposiciones. Si el pico y las historias se ejecutan juntos, la estimación de esfuerzo puede ser inexacta; por ello, los marcos ágiles recomiendan realizar el pico en una iteración previa para mejorar la planificación.