Test 1 Dirección

¿Cuál es la idea errónea mencionada sobre los proyectos ágiles?. Que requieren demasiada documentación. Que no requieren priorización. Que no requieren planificación. Que son más costosos.

¿Por qué los proyectos ágiles sí requieren planificación?. Porque requieren menos reuniones. Porque usan un modelo predictivo. Porque distribuyen la planificación a lo largo del proyecto. Porque no dependen del cliente.

En los enfoques ágiles, ¿cuándo se posponen las decisiones de planificación?. Al primer momento disponible. Durante la retrospectiva. Hasta el "último momento responsable". Durante el diseño de arquitectura.

El "último momento responsable" se define como... El momento en que el cliente cambia el alcance. El momento más barato para tomar una decisión. El último momento en que se puede decidir sin afectar el resultado del proyecto. El final del sprint.

Los proyectos tradicionales basados en planes necesitan... Un backlog flexible. Un plan de proyecto detallado. Historias de usuario. Un product roadmap.

La gestión de proyectos tradicional se basa en... Planificación adaptativa. Planificación predictiva. Planificación híbrida. Planificación experimental.

¿Qué desarrolla el proceso de planificación ágil?. Únicamente la visión del producto. Planes y documentos básicos necesarios para ejecutar el proyecto. Solo el cronograma. Solo el backlog inicial.

El desarrollo de producto ágil explora todos los aspectos excepto... Alcance. Calidad. Recursos humanos. Marketing.

¿Qué tipo de enfoque sigue la planificación ágil?. Enfoque predictivo. Enfoque adaptativo. Enfoque estrictamente secuencial. Enfoque documental.

¿Qué caracteriza a la planificación adaptativa?. Que se planifica todo con detalle desde el inicio. Que no hay backlog. Que acepta cambios y ajusta el plan progresivamente. Que no se definen objetivos.

La planificación adaptativa espera que el gerente del proyecto... Defina todo el plan detallado desde el inicio. No haga planificación. Defina un plan de alto nivel para lo lejano y uno detallado para la siguiente iteración. Defina solo tareas técnicas.

La planificación adaptativa también recibe el nombre de... Planificación predictiva. Planificación secuencial. Planificación por oleadas. Planificación cerrada.

La razón de que la planificación por oleadas exista es que... Podemos ver con claridad lo lejano. Solo se planifica una vez. Podemos ver con más claridad lo que está cerca. Los requisitos nunca cambian.

Según el texto, ¿por qué no se puede planificar con mucho detalle lo lejano?. Porque los usuarios no quieren. Porque nuestra visión se vuelve menos clara. Porque el equipo no lo permite. Porque es demasiado costoso.

El Project-level Planning permite... Definir tareas de desarrollo. Asignar tareas en horas. Definir alcance, objetivos y estimación de alto nivel. Elaborar pantallas UI.

El Release-level Planning sirve para... Resolver incertidumbres y ordenar historias por prioridad. Hacer reuniones diarias. Documentar pruebas. Definir únicamente la visión.

El Iteration-level Planning define... La visión del producto. Historias de usuario futuras. Las tareas de desarrollo y estimación en horas. La arquitectura global.

La "Visión del producto" define principalmente... Historias y tareas. Alcance técnico. Qué, quién, por qué, cuándo y suposiciones. Pantallas UI.

El roadmap del producto incluye... Reuniones. Releases, fechas, conjunto de características y enfoque. Casos de prueba. Métricas de velocidad.

La planificación de releases incluye... Tareas en horas. Iteración, capacidad del equipo, historias, prioridades, tamaño y definición de hecho. Pruebas automatizadas. Documentación final.

La planificación de la iteración responde a... Qué quiero como usuario. Historias, definición de hecho, nivel de esfuerzo y tareas. Qué arquitectura usar. Qué pantallas diseñar.

La planificación diaria responde a... Qué quiero como usuario. Qué hice ayer, qué haré hoy, qué me bloquea. Qué arquitectura usar. Qué pantallas diseñar.

La historia del usuario describe... Cómo se implementa una función. Arquitectura y diseño. Qué hace el usuario y cómo responde el software. Pruebas unitarias.

La estructura de una historia de usuario es... Caso, objetivo, tarea. Actor, acción, extensión. Como..., quiero..., para... Qué, cuándo, dónde.

Una característica clave de las historias es que deben estar... Centradas en el cliente. Centradas en el desarrollador. Escritas en lenguaje técnico. No priorizadas.

¿Quién debe escribir las historias de usuario según el texto?. Los desarrolladores. El Scrum Master. Las partes interesadas o expertos del dominio. El equipo de QA.

¿En qué se suelen escribir las historias de usuario?. Diagrama UML. Fichas o tarjetas. Documentos extensos. Una base de datos.

Qué contiene la ficha o tarjeta en la que se escribe la historia de usuario?. Numero de la ficha. Numero de la ficha y nombre del cliente. Descripcion del cliente. Número de característica, número de prioridad y los puntos de la historia.

El número de historia único sirve para... Identificar al desarrollador. Mantener la trazabilidad. Definir la arquitectura. Saber la duración exacta.

La prioridad cualitativa (alta, media, baja) es poco útil porque... Es demasiado técnica. No se puede escribir. Los usuarios tienden a poner todo como "alta prioridad". Requiere horas exactas.

El tamaño estimado de una historia se expresa en... Horas. Euros. Puntos de historia. Líneas de código.

En puntos de historia, una historia con 2 puntos es... Igual de compleja que una de 1. La mitad de compleja. El doble de compleja que una de 1. Más simple que una de 1.

Una historia de usuario debe ser comprobable, esto significa que... Debe ser revisada por el Scrum Master. Debe convertirse en un caso de prueba que se pueda probar facilmente. Debe tener muchas tareas. Debe ser técnica.

Las historias deben ser independientes porque... Se documentan mejor. Permiten mantener backlog técnico. No deben depender unas de otras. Reducen la duración del sprint.

Una historia debe ser alcanzable en... Varias iteraciones. Una release. Una sola iteración y debe tener el tamaño adecuado. Un trimestre.

Los Epics son... Funcionalidades. Fases. Iteraciones. Colecciones de características.

Los Epics duran típicamente... 1 semana. 1 día. Entre 1 y 3 meses. 1 año.

Las Features son... Mas grandes que los epics. Igual de grandes que los epics. Su tamaño depende de las características de los epics. Mas pequeñas que los epics.

Las Features duran típicamente... 1 día. Entre 2 y 4 meses. 1 año. 1 sprint.

Una User Story... Tiene el incremento de valor mas pequeño que se crea desde feature. Tiene el incremento de valor mas grande que se crea desde feature. Su incremento depende de Epic. Su incremento es igual que el de Epic.

Una User Story suele ejecutarse en... Un día. Varias semanas. Menos de una semana. 2 meses.

En un Story-Gathering Workshop, el paso 1 es... Escribir historias. Priorizar. Conseguir una habitación grande y abierta. Crear pruebas.

En el paso 2 del workshop se debe... Dibujar muchos dibujos. Crear documentación. Escribir tests. Revisar duplicados.

En el paso 2 del workshop tenemos: Personas, System maps, Process flows, Concept designs, Storyboards, Paper prototypes y Your own. Personas, Flowcharts, Scenarios, System maps, Process flows, Concept designs, Storyboards, Paper prototypes y Your own. Personas, Flowcharts, Scenarios, System maps, Paper prototypes y Your own. System maps, Process flows, Concept designs, Storyboards, Paper prototypes y Your own.

Entre las caracteristicas del paso 2 estan: Como debe funcionar el sistema y el trabajo. Descripciones de las personas que van a utilizar su sistema y descomponer el trabajo. Probar que todo funciona. Descripciones de las personas que van a utilizar su sistema, como debe funcionar el sistema, organizar y descomponer el trabajo y probar cosas y ver que funciona.

En el paso 3 del workshop se deben buscar historias... Solo técnicas. Solo de interfaz gráfica. Pequeñas, discretas y de extremo a extremo (1 a 5 dias de esfuerzo). Al final del dia entre 10 y 40 historias de alto nivel suelen ser suficientes para entre 3 y 6 meses de planificación. Muy complejas.

¿Qué debe hacerse si hay algo que necesitas hacer, incluso si no está relacionado con el software?. Ignorarlo. Anotarlo en un documento aparte. Crear una tarjeta para ello y escribirlo. Esperar al siguiente sprint.

¿Por qué es necesario el brainstorming en este paso?. Porque las imagenes no capturan todo lo que se debe hacer. Porque se deben generar solo requisitos técnicos. Para decidir la velocidad del equipo. Para eliminar historias de usuario.

¿Qué tipo de actividades también deben capturarse en tarjetas y priorizarse?. Solo las funcionalidades visibles para el usuario. Unicamente tareas del backend. Migración de datos, papeleo, pruebas de carga, capacitación, UAT, etc. Unicamente prototipos UI.

¿Qué se hace en el Paso 5 "Limpiar la lista y hacerla brillar"?. Se crean más historias sin revisar. Se revisa la lista buscando duplicados y cosas pasadas por alto. Se eliminan todas las historias técnicas. Se define el sprint backlog.

¿Cuál es el resultado objetivo del Paso 5?. Tener una lista larga y compleja. Tener solo historias técnicas. Consolidar historias en una lista simple y fácil de entender. Crear la arquitectura del sistema.

Las partes interesadas pueden agregar, modificar o eliminar historias... Solo al inicio del proyecto. Solo durante la retrospectiva. En cualquier momento antes del ciclo. Nunca.

En los métodos ágiles, las estimaciones iniciales de alto nivel... Son totalmente confiables. No deben ser utilizadas jamas. No son de confianza, pero siguen siendo necesarias para crear presupuestos. Se usan solo al final del proyecto.

La estimación ágil se basa principalmente en... Puntos de función y horas exactas. Diagramas UML. Relative sizing y point-based systems. Técnica PERT.

El relative sizing consiste en... Estimar el número exacto de horas de cada tarea. Comparar tareas de forma relativa en vez de usar valores absolutos. Calcular el coste económico directo. Medir líneas de código.

¿Por qué los seres humanos son mejores comparando tareas que estimando en absoluto?. Porque las herramientas lo permiten. Porque es obligatorio en Scrum. Porque es más fácil decidir si algo es más grande o más pequeño que dar un valor exacto. Porque no existe otra forma.

El primer paso del proceso de estimación relativa es... Medir velocidad. Identificar las tareas del proyecto. Dividir tareas en horas. Crear prototipos.

Durante el paso 2 Comparación Relativa... Se estima exactamente cuántas horas durará cada tarea. Las tareas se comparan entre sí en tamaño o complejidad. Se descartan las tareas complejas. Se definen los criterios de aceptación.

Una vez se establece un sistema de estimación relativo en el Paso 3, el equipo... Ya no necesita medir nada. Solo mide horas reales. Mide su velocidad durante un sprint. Calcula costes finales.

El sprint es... El número de miembros del equipo. El coste por iteración. La cantidad de trabajo completado en un período. El tiempo total del proyecto.

Gracias a la estimación relativa y a la velocidad del equipo, se pueden... Crear arquitecturas detalladas. Definir plazos más realistas para el trabajo pendiente. Evitar priorización. Calcular costes exactos.

¿Cuál de las siguientes afirmaciones sobre la estimación relativa es correcta?. Busca precisión absoluta en horas. Requiere mucha documentación técnica. Permite comparar tareas sin necesidad de tiempos exactos. Sustituye la planificación del sprint.

¿Cuál es el principal problema de las estimaciones absolutas?. Son muy fáciles de ajustar. No requieren experiencia. No sabemos si el tiempo real será mayor o menor, generando falta de precisión. Siempre coinciden con el tiempo real.

¿Qué ocurre si una tarea estimada en 3 días requiere 4 días?. No pasa nada, no se ajustan las demás. Deben ajustarse todas las estimaciones al nuevo incremento. Se reduce el backlog. Se elimina la historia.

¿Qué problema produce el ajustar las demás medidas y que queden días en decimales?. Aumentan el valor del producto. Falta de precisión. Simplifican la planificación. Reducen el trabajo.

¿Qué es necesario realizar en las estimaciones?. Reducirlas. No hay que hacer nada. Hacer truncamiento. Realizar ajustes continuos.

¿Qué herramienta evita estos ajustes continuos en los sistemas ágiles?. Diagramas UML. Horas exactas. Puntos de historia. Diagramas de Gantt.

Los puntos de historia utilizan... Tiempo real en horas. Coste económico. Unidades relativas para representar esfuerzo o complejidad. Número de trabajadores.

En un sistema basado en puntos en el que nuestras unidades de medida no importan, la medida es... Absoluta. Dependiente del tiempo real. Relativa no absoluta. Exacta al minuto.

Según el texto, una tarea simple podría valer... 5 puntos. 8 puntos. 1 punto. 10 puntos.

Una tarea mediana podría valer... 1 punto. 3 puntos. 0 puntos. 20 puntos.

Una tarea compleja podría valer... 0 puntos. 2 puntos. 8 puntos. 1 punto.

En lugar de ajustar constantemente los días, los equipos ágiles miden... Tiempo estimado. Horas máximas. Velocidad del equipo. Coste de cada historia.

La velocidad del equipo es... Cantidad de puntos completados en un sprint. El número de miembros del equipo. Las horas trabajadas por día. El valor económico generado.

La triangulación consiste en... Comparar todas las tareas con la más compleja. Usar siempre el mismo tamaño para todas las historias. Tomar algunas historias referencia de muestra y dimensionar las nuestras en relación con las otras. Calcular horas por desarrollador.

En triangulación, las historias de referencia deben representar... Solo historias simples. Tareas técnicas únicamente. Tamaños pequeños, medianos y grandes dentro del proyecto. Historias no priorizadas.

Si una historia se parece a la historia mediana de referencia... Se elimina. Se pasa al backlog técnico. Se le asigna el mismo tamaño. Se divide en tres partes.

En triangulación, si una historia parece un poco más grande o más pequeña... Se ajusta su tamaño en consecuencia. Se mantiene el tamaño mediano. No se modifica. Se clasifica como épica.

Planning Poker es un juego... En el que el cliente estima las historias de usuario. En el que el equipo de desarrollo estima las historias individualmente y luego compara resultados colectivamente. En el que el ganador estima el valor absoluto de la velocidad y lo compara con el valor relativo. En el que el perdedor se queda sin ganancias.

Planning Poker utiliza habitualmente... La serie de números del 1 al 10. Horas en formato decimal. Una baraja de cartas con números usando la serie de Fibonacci o una variante. Notación científica.

En Planning Poker, si todos los miembros del equipo coinciden en la estimación... Se descarta la historia. Se vuelve a estimar. Se mantiene esa estimación. Se pasa a horas.

¿Qué ocurre si hay diferencias entre las estimaciones del equipo en Planning Poker?. Se descartan las estimaciones. Se elige la estimación más alta automáticamente. El equipo discute las diferencias y vuelve a estimar. Se elige la estimación del Product Owner.

¿Cuál es el objetivo del Planning Poker?. Crear arquitectura. Asignar tareas. Llegar a un consenso en la estimación. Eliminar historias del backlog.

La iteración ágil son sprints de trabajo que suelen durar... Entre 1 y 3 meses. Entre 1 y 2 semanas. Entre 2 y 4 días. Entre 4 y 6 semanas.

El objetivo de una iteración ágil es... Crear documentación técnica. Diseñar la arquitectura. Transformar historias de usuario en software funcional y listo para producción. Crear prototipos.

Paso 1: La lista maestra de historias que creamos en el Paso 1 es... Un documento técnico del arquitecto. Un conjunto de diagramas UML. Una colección de historias de usuario que el cliente quiere ver en su software. Un listado de tareas técnicas.

¿Quién prioriza, y estima y constituye la base del plan de proyecto de la lista maestra de historias respectivamente?. El equipo de desarrollo. El Scrum Master. Los clientes la priorizan, el equipo estima y constituye. El arquitecto.

Una buena lista maestra de historias suele tener... 1 semana de trabajo. Entre 1 y 6 meses de trabajo. 1 año de trabajo. Más de 10 meses de trabajo.

Un lanzamiento (release) es... Una entrega diaria. Una agrupación lógica de historias que tiene sentido para el cliente. La retrospectiva del sprint. Un backlog técnico.

El MMF (Minimum Marketable Features) es... El conjunto mínimo de tareas. El conjunto mínimo de características comercializables. Un documento de arquitectura. El diseño del sprint.

En el Paso 2, "Amplia tu evaluación", se busca... La duración exacta de cada historia. Una idea de cuán grande es el proyecto. Documentar todas las pruebas. Crear prototipos visuales.

¿Qué indica el texto sobre la duración que se evalúa?. Si un proyecto durará 1, 3, 6 o 9 meses. La duración diaria de cada tarea. Solo el sprint actual. El coste exacto del proyecto.

En el Paso 3 de priorización, ¿quién tiene la última palabra?. El equipo de QA. El equipo de desarrollo. Los clientes. El Scrum Master.

Aunque el cliente tiene la última palabra, nosotros como equipo también debemos... Ignorar los riesgos arquitectónicos. Sugerir qué historias conviene construir primero. Dejar al cliente priorizar sin intervención. Crear primero las historias más largas.

¿Para qué sirve construir historias al principio del proyecto?. Para eliminar tareas. Para reducir el riesgo arquitectónico. Para terminar la release antes. Para disminuir la velocidad.

La velocidad del equipo se basa en... La motivación del equipo. Los puntos completados por iteración. La cantidad de errores encontrados. La duración total del proyecto.

Al inicio del proyecto, la velocidad... Es estable. Es extremadamente alta. Fluctúa, es decir, no será estable. Es igual todos los días.

¿Por qué fluctúa la velocidad al principio?. Porque el equipo está aprendiendo a trabajar en conjunto. Porque el cliente cambia todo. Porque no hay backlog. Porque no existen historias de usuario.

La velocidad debería comenzar a... Empeorar despues de 2 o 3 iteraciones. Estabilizarse despues de 3 o 4 iteraciones. Aumentar indefinidamente despues de 5 iteraciones. Volverse impredecible despues de 3 o 5 iteraciones.

¿Para qué sirve tener una velocidad estabilizada?. Para asignar tareas por rol. Para predecir fechas de entrega con más confianza. Para medir líneas de código. Para reducir retrospectivas.

En el Paso 5, "Elige algunas fechas", una opción es... Entregar por coste. Entregar por número de pruebas. Entregar por fecha o entregar por conjunto de características. Entregar solo tareas técnicas.

La entrega por conjunto de características consiste en... Variar fechas sin justificar. Entregar lo antes posible sin planificar. Seleccionar un conjunto básico de características y trabajar en ellas hasta que estén listas. Ignorar la priorización del cliente.

¿Qué se muestra en el eje Y del burn-down chart?. El tiempo por iteración. La velocidad del equipo. La cantidad de trabajo restante en puntos o días de esfuerzo. El número de historias nuevas.

¿Qué se muestra en el eje X del burn-down chart?. Costes. Tiempo por iteración. Velocidad. Miembros del equipo.

¿Qué representa la pendiente de la línea en el burn-down chart?. El backlog técnico. La cantidad de errores. La velocidad del equipo. La duración de las reuniones.

¿Qué permite ver el burn-down chart con un solo vistazo?. El diseño del sistema. Cuánto trabajo se ha realizado y cuánto queda, la velocidad del equipo y la fecha prevista de finalización. La arquitectura del producto. El número de reuniones del equipo.

¿Por qué la velocidad del equipo puede fluctuar?. Por cambios en la arquitectura. Porque se pierde un miembro valioso. Porque se agregan diagramas. Porque se eliminan retrospectivas.

Si el equipo disminuye su ritmo de trabajo, ¿qué se observará en el gráfico?. La pendiente se hace más vertical. Una caída en la velocidad. El gráfico sube inmediatamente. El gráfico desaparece.

El burn-down chart es útil porque... Es obligatorio por la norma ISO. Muestra todos los eventos relevantes del proyecto. Reemplaza al backlog. Sustituye al roadmap.

¿Qué otro gráfico es una variante del diagrama de evolución descendente?. Burn-cap chart. Velocity-up chart. El diagrama de evolución ascendente, que es el mismo pero invertido. Release chart.

El diagrama de evolución ascendente se diferencia del descendente porque... No muestra nuevas historias. Presenta el descubrimiento de nuevas historias. Es menos claro. No incluye la velocidad del equipo.

¿Cómo se representa el descubrimiento de nuevas historias en el diagrama de evolución ascendente?. Como una línea discontinua. Como una reducción del alcance. Como un aumento de la línea superior. No se representa.

¿Por qué algunas personas prefieren el diagrama de evolución ascendente?. Porque muestra cambios en el alcance de manera más clara. Porque es obligatorio en Scrum. Porque no muestra tareas. Porque no refleja nuevas historias.

¿Qué se debe hacer para combinar ambos diagramas ascendentes y descendentes en un solo gráfico?. Crear dos backlogs. Usar líneas de colores. Registrar trabajo total en cada iteración del burn-down junto con el trabajo restante. Eliminar las historias de menos prioridad.

El burn-down chart ayuda a mostrar... Solo los problemas del proyecto. Solo el estado final. El estado completo del proyecto a lo largo del tiempo. El reparto de roles del equipo.

En el Paso 1, ¿cómo se calcula el tamaño del proyecto?. En función del número de sprints. En función del número total de historias de usuario. En función del número de miembros del equipo. En función del presupuesto disponible.

¿Qué se calcula en el Paso 2?. La velocidad del equipo. El número de releases. La cantidad de trabajo a completar en el proyecto en días-persona. El total de puntos de historia.

¿Qué representan los "días-persona"?. El número de historias por sprint. El esfuerzo total considerando la disponibilidad del equipo. El número de horas exactas por tarea. El coste total del proyecto.

¿Cuál es el Paso 3?. Determinar las historias de usuario del cliente. Conseguir la estimación real del proyecto. Calcular el tamaño del proyecto. Determinar el cronograma del proyecto basándonos en los días-persona calculados.

¿Qué tipo de costes se incluyen dentro de "otros costes del proyecto"?. Solo salarios. Hardware, software, hospedaje, capacitación y material de oficina o viajes. Unicamente licencias. Reuniones y documentación.

¿Cuál es la fórmula para calcular el coste total del proyecto?. Coste total = puntos por velocidad. Coste total = días-persona por número de historias. Coste total = (tiempo por tasa de recursos) más otros costes. Coste total = horas por velocidad.

¿Cuál de las siguientes afirmaciones es correcta según el texto?. Los días-persona no consideran disponibilidad. Los días-persona pueden convertirse a horas. El coste total no incluye otros costes. La disponibilidad del equipo no afecta al cálculo.

¿Por qué aumentar la velocidad de un equipo puede reducir costes?. Porque reduce la cantidad de historias necesarias. Porque reduce la documentación. Porque permite ahorrar tiempo y, en consecuencia, dinero. Porque disminuye la complejidad técnica.

¿Qué afirma el texto sobre la velocidad del equipo?. Disminuye naturalmente con cada sprint. Permanece constante desde el inicio. Puede aumentar naturalmente con cada sprint. Depende únicamente del Product Owner.

¿Cuál es una forma directa de aumentar la velocidad?. Aumentar reuniones. Añadir más documentación. Eliminar impedimentos o bloqueos. Reducir la colaboración del equipo.

¿Qué significa "evitar obstáculos en el proyecto"?. Ignorar problemas del equipo. Crear estrategias desde el principio para evitar impedimentos. No planificar ningún aspecto técnico. Aumentar la complejidad del backlog.

¿Por qué eliminar distracciones es importante para la velocidad?. Porque reduce el tamaño del backlog. Porque permite al equipo trabajar en tareas no relacionadas. Porque protege al equipo de trabajo no relacionado con el sprint. Porque disminuye la comunicación del equipo.

¿Qué se recomienda respecto a las distracciones?. Permitir cualquier tipo de solicitud al equipo. Concentrar al equipo en múltiples objetivos. Evitar que les pidan trabajo que no esté relacionado con el sprint. Aumentar la multitarea.

¿Qué deben hacer los miembros del equipo en la retrospectiva?. Criticar al Product Owner. Proponer nuevas historias. Aportar ideas para aumentar la velocidad. Redefinir la arquitectura.

¿Por qué es útil pedir aportes al equipo?. Porque cada miembro puede aportar ideas útiles para mejorar la velocidad. Porque así se evitan reuniones. Porque reduce el backlog. Porque reemplaza al Scrum Master.

¿Qué tipo de trabajo no debería solicitarse al equipo durante el sprint?. Trabajo relacionado con los objetivos del sprint. Trabajo de soporte relacionado. Trabajo no relacionado con el sprint. Trabajo priorizado por el Product Owner.

¿Qué efecto tiene eliminar impedimentos rápidamente?. Aumenta la cantidad de bugs. Ralentiza la entrega. Aumenta la velocidad y evita bloqueos. Reduce la colaboración del equipo.

¿Cómo se pueden reducir los costes del proyecto según el texto?. Aumentando la cantidad de historias. No completando los requisitos de menor prioridad. Eliminando retrospectivas. Reduciendo la comunicación del equipo.

¿Qué efecto tiene no completar requisitos de menor prioridad?. Aumenta la duración del proyecto. Reduce la velocidad del equipo. Reduce la cantidad de sprints necesarios. Aumenta el backlog técnico.

¿Por qué en proyectos ágiles se puede tomar la decisión de detener un proyecto?. Porque no se pueden agregar más historias. Porque se entregan todas las historias en un único sprint. Porque la funcionalidad completada se entrega cada sprint. Porque no existe backlog.

¿Cuándo pueden las partes interesadas decidir finalizar un proyecto?. Cuando el equipo pierde velocidad. Cuando el coste del desarrollo futuro sea mayor que el valor que aportará. Cuando el backlog sea grande. Cuando haya pocas reuniones.

Para decidir si se debe finalizar un proyecto en función del coste, es necesario conocer... Solo la velocidad del equipo. Solo el número de miembros. El valor V, el coste real CA y el coste de oportunidad CO. El tamaño del backlog técnico.

¿Qué representa el valor V?. Los requisitos descartados. Los requisitos restantes en el backlog del producto. Los requisitos completados. Las horas totales de trabajo.

¿Qué representa el coste real CA?. El coste de errores en producción. El coste real del trabajo que se necesitará para completar los requisitos en el backlog del producto. El coste de las reuniones. El coste del backlog técnico.

¿Qué representa el coste de oportunidad CO?. El coste de perder un sprint. El coste de un error crítico. El valor de tener al equipo trabajando en un nuevo proyecto. El coste total del proyecto inicial.

¿Cuál es la condición para detener un proyecto según el texto?. V es mayor que AC mas OC. AC es mayor que V mas OC. V es menor que AC mas OC. OC es menor que V menos AC.

¿Qué significa que V es menor que AC mas OC?. Que el coste que asumirá en el proyecto será mayor que el valor que recibirá del mismo. Que el proyecto va muy rápido. Que el backlog está casi vacío. Que no quedan tareas técnicas.

¿Qué pueden hacer las partes interesadas al finalizar el proyecto?. Eliminar el presupuesto sobrante. Guardar el presupuesto sin usar. Utilizar el presupuesto restante para iniciar un proyecto nuevo y más valioso. Aumentar el backlog técnico.

¿Cómo se llama la práctica de trasladar el presupuesto de un proyecto terminado a otro nuevo?. Reasignación horizontal. Redistribución de recursos. Redistribución de capital. Conversión presupuestaria.

En el escenario 1, cuando el cliente descubre nuevos requisitos, el método preferido para restablecer el equilibrio es... Aumentar la documentación. Detener el proyecto. Flexibilidad en cuanto al alcance. Ignorar los nuevos requisitos.

¿Qué otras dos opciones poco ideales se mencionan cuando surgen nuevos requisitos?. Reducir el equipo o cancelar el sprint. Agregar recursos o posponer la fecha. Eliminar todo el backlog. Cambiar de metodología.

¿Cuál es el punto clave en el escenario 1?. Evitar conversar con el cliente. Aumentar el número de historias. Tener la conversación y ofrecer opciones a nuestro cliente. Bloquear el backlog.

En el escenario 2, si el proyecto no avanza tan rápido como se esperaba, ¿qué se debe hacer primero?. Cancelar el sprint. Tomar una o dos características realmente importantes y medir cuánto tiempo lleva construirlas. Reasignar todas las tareas. Eliminar historias del backlog.

¿Para qué se utiliza el tiempo medido de esas características?. Para estimar el coste económico. Para descartar tareas. Para compararlo con las historias restantes y ver si una versión minimalista es posible. Para aumentar la velocidad automáticamente.

¿Qué permite la estrategia "Ser Spartan"?. Eliminar reuniones. Tener la conversación de "necesitamos cambiar el plan" desde una posición de fortaleza e integridad. Evitar priorizar. Aumentar complejidad técnica.

En el escenario 3, cuando se pierde un integrante valioso del equipo, ¿qué se debe hacer primero?. Reemplazar inmediatamente al miembro. Reorganizar toda la arquitectura. Decir al cliente que el proyecto se verá afectado. Cancelar el sprint actual.

¿Por qué no es necesario ponerse demasiado científico en el escenario 3?. Porque los datos exactos no importan. Porque el cliente no quiere detalles. Porque basta con reconocer que la pérdida afectará al proyecto. Porque la velocidad no cambia.

¿Cuándo podrá darse una nueva fecha de entrega más precisa en el escenario 3?. Después de 2 o 3 iteraciones, cuando se mida el impacto en la velocidad del proyecto. En cuanto el miembro se marche. Después de escribir más historias. Solo al final del proyecto.

¿Qué ocurre con la velocidad del equipo tras perder un miembro valioso?. Aumenta. Se mantiene igual. Disminuye. Se hace impredecible por años.

En el escenario 4, cuando el equipo se queda sin tiempo, ¿qué se recomienda?. Cancelar el proyecto. Evitar al cliente. Sentarse con el cliente y buscar formas innovadoras de ayudarlo. Reducir la velocidad.

¿Cuál es el enfoque general en todos los escenarios?. Tomar decisiones sin hablar con el cliente. Ignorar los problemas hasta el final. Conversar con el cliente y ajustar el plan según el contexto. Seguir el plan original sin cambios.

¿Qué tienen en común los escenarios 1 y 2?. Ambos recomiendan ignorar requisitos. Ambos sugieren medir la velocidad. Ambos requieren analizar la situación y ofrecer alternativas. Ambos eliminan la necesidad de backlog.

¿Qué tienen en común los escenarios 3 y 4?. Ambos ignoran la planificación. Ambos dependen únicamente del Product Owner. Ambos requieren una conversación clara con el cliente. Ambos aceleran automáticamente la velocidad del equipo.