NEW
Font size
WorksheetsQuizz PMP-ACP Formativo 2
Total questions: 30
Worksheet time: 47mins
¿Cuál es una ventaja importante de entregar un producto mínimo viable tan pronto como sea posible en un proyecto ágil?
El lanzamiento de un producto mínimo viable puede generar un retorno temprano de la inversión mientras el resto del proyecto aún está en marcha.
Cuanto antes termine el producto mínimo viable, podrá completar el proyecto.
Cuanto antes lance el producto mínimo viable, el equipo podrá trabajar en otras características que los clientes valoren mucho.
El producto mínimo viable es necesario para satisfacer a los usuarios finales, lo que queremos hacer lo más rápido posible.
¿Cuál es la razón más importante por la cual los equipos ágiles intentan ofrecer las partes de mayor valor del proyecto lo antes posible?
Para aprovechar las oportunidades mientras están activas
Para determinar si el proyecto logrará una falla rápida
Para recibir comentarios tempranos de los usuarios
Para tener listo el proyecto antes
Enseña un curso universitario en línea y no tiene tiempo para completar el sitio web del curso al comienzo del semestre. Les informa a los estudiantes que el sitio del curso comenzará como un producto mínimo viable con todas las partes esenciales del curso y que planea agregar características adicionales durante el semestre. ¿Cuál de las siguientes características añade después?
Contenido de estudio para cada lección
Funcionalidad de las calificaciones
Video introductorio para cada lección
Exámenes semestrales y finales
La entrega incremental es una forma en que los equipos ágiles pueden:
Acelerar el proceso de planificación
Adaptar continuamente nuestros procesos ágiles
Aumentar el compromiso de los miembros del equipo
Recibir un retorno temprano de la inversión
¿Por qué es particularmente importante para los equipos ágiles gestionar los riesgos del proyecto?
Los métodos ágiles ofrecen menos oportunidades para abordar activamente los riesgos que los métodos tradicionales.
Los métodos ágiles implican un mayor riesgo que los métodos tradicionales.
El riesgo y el valor están inversamente relacionados.
Los riesgos tienen un mayor impacto en un entorno del proyecto ágil.
¿Cuál de las siguientes opciones no es cierta para la gestión de riesgos en proyectos ágiles?
El equipo debe abordar los mayores riesgos en las primeras iteraciones.
El equipo debe priorizar las acciones de respuesta al riesgo sobre la entrega de características de valor.
El equipo debe minimizar el riesgo ya que el riesgo es el inverso del valor.
El equipo de desarrollo debe participar en la identificación y gestión de riesgos
Una pequeña empresa evalúa dos proyectos potenciales y se pregunta cuál implementar primero. El proyecto A tiene una ganancia de $700.000 en 5 años y el proyecto B tiene una ganancia de $400.000 en 2 años. ¿Qué debería hacer la organización?
Calcular la IRR de ambos proyectos y seleccionar la que tenga la tasa más baja.
Calcular el ROI de ambos proyectos y seleccionar el que tenga el período de recuperación más largo.
Calcular el NPV de ambos proyectos y seleccionar el que tenga el menor costo
Calcular el NPV de ambos proyectos y seleccionar el que tenga el valor más alto.
Una patrocinadora considera el valor comercial de dos proyectos. ¿Cómo podría aplicar el concepto de tasa interna de retorno (IRR) para elegir entre estos proyectos?
Elije el proyecto con el costo más bajo
Elije el proyecto con los menores ingresos.
Elije el proyecto con los mayores ingresos.
Elije el proyecto con la tasa de descuento más alta.
El proyecto A tiene una IRR de 10% y el proyecto B tiene una IRR de 8%. ¿Qué proyecto representa la mejor tasa de retorno?
Depende del periodo de recuperación
El proyecto A
El proyecto A o el B, dependiendo del NPV
El proyecto B
¿Qué indicador financiero usaría una organización para elegir entre seguir dos proyectos con plazos significativamente diferentes?
Valor actual neto
Valor actual
Retorno de la inversión
Tasa interna de retorno
¿Cuál no sería una buena razón para cambiar a entregar el producto en incrementos?
Localizar cuellos de botella en el flujo de trabajo
Recibir un retorno temprano de la inversión
Reducir la cantidad de trabajos que necesiten repetirse
Mantener baja la curva de costo de cambio
Después de que el propietario del producto priorizó la lista de características de acuerdo con el valor comercial, una parte interesada clave lo llama a usted, el líder del equipo, y dice: "tenemos que mover la característica C a la parte superior de la lista porque es el proyecto preferido del vicepresidente de Marketing". ¿Cómo debe responder?
Dado que esto suena como una situación política complicada y no desea involucrarse en ella; responda sin comprometerse y notifique a su patrocinador sobre la solicitud.
Dígale a la parte interesada que le pasará esta solicitud al propietario del producto, quien tendrá en cuenta la justificación del vicepresidente para cambiar esta característica a una prioridad más alta.
Explique amablemente que no puede hacer eso porque las características A y B brindan más valor comercial, por lo que el equipo las desarrollará primero.
Responda educadamente y luego ignore la solicitud, ya que no tiene ningún sentido y el interesado claramente no comprende qué tan diferente es la gestión ágil de la de un proyecto tradicional.
¿Cuál sería una herramienta que su equipo podría usar para determinar qué problemas planteados en una retrospectiva son más importantes de resolver?
Dinero de monopolio
MoSCoW
Método de los 12 puntos
Mapeo del flujo de valor
El equipo ágil está planificando las herramientas que usará para su proyecto. Debate cómo debe mostrar qué trabajo está en progreso. De las siguientes opciones, ¿qué es lo más probable que seleccionen?
Trabajos pendientes de la historia del usuario
Hoja de ruta del producto
Tablero de tareas
Estructura de desglose del trabajo
Si su equipo no pone límites a su trabajo en progreso (WIP), ¿qué es probable que suceda?
No habrá cuellos de botella, pero algunas personas estarán desocupadas
No habrá cuellos de botella, pero todos estarán ocupados.
Todos estarán ocupados, pero no podremos decir dónde están los cuellos de botella.
Algunas personas estarán desocupadas pero no podremos decir dónde están los cuellos de botella.
Su patrocinador pidió una actualización rápida de cómo está funcionando el proyecto en términos de gasto, alcance y cronograma. ¿Cuál de las siguientes herramientas le mostrará?
Gráfico de la gestión del valor ganado
Gráficos de riesgo del trabajo pendiente
Mapa del flujo de valor
Diagrama de plan acumulativo
¿Cuándo es más probable que use indicadores clave de rendimiento en su proyecto ágil?
Cuando el equipo quiera saber cuánto trabajo hicieron en la última iteración.
Cuando el patrocinador le pregunte cuándo estará listo y cuánto costará el proyecto
Cuando el cliente desee ver cómo se verá el producto final
Cuando quiera comparar las estimaciones competitivas de los proveedores
¿Cuál es un problema potencial de confiar en la gestión del valor ganado (earned value management, EVM) para evaluar el rendimiento de un proyecto ágil?
La EVM no le permite saber qué tan bien está el proyecto en términos de costo
La EVM no le permite saber qué tan bien está el proyecto en términos de entrega de calidad
La EVM es una herramienta ineficaz para proyectos ágiles porque implican muy poca planificación inicial.
La EVM no le permite saber qué tan bien está el proyecto en términos de programación.
¿Qué herramienta usaría un equipo ágil para transmitir cuánto trabajo queda en su proyecto?
Gráfico de Gantt
Hojas de cálculo
Notas adhesivas en una pizarra en blanco
Software para cronogramas
A la mitad del proyecto, los indicadores de gestión del valor ganado se ven bien. Esto le dice que en este punto del proyecto:
Los incrementos de producto que se lanzaron ya están entregando valor al cliente.
Las características que se han desarrollado satisfacen los valores y las prioridades de las partes interesadas
El equipo ha implementado con éxito valores y principios ágiles.
El proyecto todavía está en camino de cumplir con sus objetivos de gasto, alcance y cronograma
El patrocinador del proyecto quiere saber por qué su equipo no usa el software para cronogramas para seguir el cronograma del proyecto. Al responder, ¿qué no diría?
El software para cronogramas presenta datos de una manera que puede ser difícil de comprender rápidamente.
El software para cronogramas no puede ilustrar las dependencias de tareas.
El software para cronogramas puede enmascarar problemas con estimaciones mal hechas.
El software para cronogramas realmente no permite que todo el equipo participe en el proceso de seguimiento y actualización de tareas
A su equipo le gustaría saber si a las personas que realmente usarán el software les resultará fácil de entender y aprender. ¿Qué les podría ayudar a hacer eso?
Pruebas de la unidad
Demostración del producto
Pruebas realistas
Pruebas de usabilidad
¿Qué nos dirá si el sistema que construimos aún funciona según lo previsto después de incorporar al repositorio de código el código nuevo y revisado?
Refactorización
Pruebas de usabilidad
Pruebas exploratorias
Integración continua
¿Qué herramienta o técnica le permitiría a un equipo descubrir y resolver problemas más rápidamente?
Integración continua
Refactorización
Juegos de planificación
Pruebas de usabilidad
Su equipo usa el desarrollo guiado por pruebas y todas las pruebas del código que escribe en esta iteración devuelven resultados fallidos. ¿Cuál es la razón más probable para esto?
Hay errores en el código
Debe refactorizarse el código.
Las pruebas son defectuosas.
Aún no se termina el código.
Su equipo sigue un enfoque proceso de desarrollo guiado por pruebas. ¿Qué término abreviado podría usar para describir lo que hace?
Red, green, clean (Rojo, verde, limpio)
Test, code, refactor (Probar, codificar, refactorizar)
Green, red, refactor (Verde, rojo, refactorizar)
Code, test, clean (Codificar, probar, limpio)
Su equipo usa un desarrollo guiado por pruebas. Escribió el código y realizó las pruebas, pero las pruebas fallaron. ¿Qué debe hacer a continuación?
Escribir nuevas pruebas
Verificar la precisión de las pruebas
Refactorizar el código
Escribir un nuevo código
Su equipo usa un desarrollo guiado por pruebas. ¿Cómo describiría su enfoque?
Verificamos que las pruebas estén funcionando antes de integrar el código
Pensamos cómo probar la funcionalidad antes de codificarla
Pensamos cómo escribir el código antes de escribir las pruebas
Confirmamos el comportamiento deseado del código antes de probarlo.
Al rediseñar el contrato estándar de su empresa para un proyecto ágil, ¿qué sería más importante enfatizar?
Proporcionar comentarios frecuentes al contratista
Utilización e implementación rápidas por parte del contratista
Divulgación completa entre el equipo y el contratista
Compromisos a corto plazo con el contratista
Intenta explicarle a su oficina de gestión de proyectos (project management office, PMO) las diferencias entre la gestión de proveedores en un proyecto ágil y en un proyecto tradicional. Les dice que los contratos ágiles suelen _______.
Durar solo una iteración a la vez
Fomentar una cooperación más estrecha entre el equipo y el proveedor
Incluir criterios de aceptación más estrictos
Especificar las fechas límite más frecuentes.
