Test Ciclo de Vida, Ágil, XP, Lean, Scrum…

¿Qué es el Ciclo de Vida del Software?. Un conjunto de actividades técnicas para programar un sistema. El período de tiempo desde que se decide desarrollar un software hasta que se retira. Un método de planificación basado en iteraciones. Un documento que recoge los requisitos del sistema.

¿Qué describe el Ciclo de Vida de Desarrollo del Software (SDLC)?. La vida útil del hardware asociado al software. Las fases de análisis financiero del proyecto. El proceso de construcción o mejora del software, y los modelos y metodologías usados. Un conjunto de normas ISO para gestionar proyectos.

¿Para qué se utiliza el SDLC según el texto?. Solo para desarrollar desde cero un software nuevo. Para desarrollar, mantener y reemplazar software o sistemas existentes. Para gestionar equipos humanos. Para certificar la calidad del software.

¿Qué es un Modelo de Ciclo de Vida?. Una guía técnica completa y detallada para programar. Un diagrama UML obligatorio. Una definición general de alto nivel de las actividades del ciclo de vida, mostrando dependencias. Un conjunto de herramientas para soporte documental.

¿Qué NO es un Modelo de Ciclo de Vida según la definición?. Una definición general. Una representación de dependencias. Una guía concreta y detallada de actividades. Un esquema de alto nivel.

¿Qué son las Metodologías de Desarrollo del Software?. Un conjunto de actividades, tareas, procedimientos, técnicas, herramientas y soporte documental para posibilitar el desarrollo sistemático del software. Solo un conjunto de buenas prácticas no documentadas. Un estándar para evaluar la calidad del producto final. Una técnica específica para programar en equipo.

¿Qué incluyen las metodologías según el texto?. Solo tareas y actividades. Actividades, tareas, procedimientos, técnicas, herramientas y soporte documental. Únicamente herramientas automáticas de desarrollo. Sagas de versiones y control de cambios.

El Ciclo de Vida del Software se define como…. El conjunto de herramientas necesarias para desarrollar software. El período desde que se decide desarrollar un software hasta que se retira. El proceso de análisis y diseño del sistema. Las fases de prueba y mantenimiento.

El Ciclo de Vida del Desarrollo del Software (SDLC) se refiere a…. El tiempo total durante el cual el software está en el mercado. El proceso de construcción o mejora de software y las metodologías usadas. Las especificaciones técnicas del hardware asociado. El análisis de requisitos del usuario.

Según la definición, el SDLC se usa para…. Planificar sprints en metodologías ágiles. Desarrollar, mantener y reemplazar software o sistemas existentes. Escribir documentación técnica. Diseñar interfaces gráficas.

El Modelo de Ciclo de Vida es…. Una lista detallada de tareas paso a paso. Una definición de alto nivel de actividades del ciclo de vida del software. Una metodología formal de desarrollo. Una guía específica para implementar código.

¿Qué característica NO tiene un Modelo de Ciclo de Vida?. Describe actividades a alto nivel. Muestra dependencias entre actividades. Es una guía concreta y detallada. Se aplica al ciclo de vida del software.

Las Metodologías de Desarrollo del Software son…. Actividades, tareas, procedimientos, técnicas, herramientas y soporte documental que posibilitan el desarrollo sistemático del software. Un tipo de modelo de ciclo de vida. Reglas estrictas de programación. Guías informales sin soporte documental.

¿Qué incluyen explícitamente las metodologías según el texto?. Solo actividades y tareas. Actividades, tareas, procedimientos, técnicas, herramientas y soporte documental. Únicamente procedimientos de diseño. Herramientas automáticas de testing.

¿Qué relación hay entre “modelo de ciclo de vida” y “metodología”?. El modelo es general y la metodología es concreta y detallada. La metodología es más general que el modelo. Son exactamente lo mismo. El modelo solo se aplica en la fase de pruebas.

Los enfoques tradicionales de desarrollo de software se basan en…. Iteraciones cortas y flexibles. Fases/etapas preorganizadas del ciclo de vida. Cambios continuos en requisitos. Desarrollo sin planificación previa.

En los enfoques tradicionales, el flujo de desarrollo es…. Cíclico e iterativo. Multidireccional. Unidireccional. Incremental sin orden.

En el flujo unidireccional, el orden correcto es: Diseño → Pruebas → Requisitos → Desarrollo. Requisitos → Análisis → Diseño → Desarrollo → Pruebas → Mantenimiento. Requisitos → Pruebas → Diseño → Desarrollo. Mantenimiento → Pruebas → Diseño → Requisitos.

¿Cuál de los siguientes es un enfoque tradicional?. Scrum. Kanban. Desarrollo en Cascada. Crystal Clear.

Los modelos iterativos son considerados…. Parte de los enfoques tradicionales. Parte de Ágil. Un subconjunto de Scrum. Una técnica de mantenimiento.

Los modelos incrementales pertenecen a…. Metodologías ágiles únicamente. Enfoques tradicionales. Procesos sin estructura. Técnicas de prueba.

La construcción de prototipos es un modelo…. Ágil. Tradicional. Solo utilizado en DevOps. Exclusivo de la etapa de mantenimiento.

El modelo en espiral combina…. Waterfall + Agile. Iteración + Gestión de riesgos. Scrum + Prototipos. XP + Cascada.

El modelo en V es una extensión del modelo…. Spiral. Iterativo. Cascada. Incremental.

Una desventaja de los enfoques tradicionales es que los requisitos deben definirse…. A mitad del proyecto. De forma continua y cambiante. En la fase inicial, sin cambios posteriores. Solo después de programar.

En enfoques tradicionales, las pruebas comienzan…. En paralelo al desarrollo. Después de cada pequeña funcionalidad. Solo cuando finaliza el desarrollo completo. Nunca se realizan pruebas formales.

Una vez que la aplicación está en la etapa de prueba, en enfoques tradicionales…. Es fácil volver atrás y hacer cambios. No es posible volver atrás sin afectar tiempos y costos. Se permite rehacer requisitos sin problemas. El cliente puede cambiar el alcance sin coste adicional.

Las metodologías tradicionales son adecuadas cuando…. Los requisitos cambian constantemente. El cliente no sabe lo que quiere. Los requisitos son precisos y estables. No existe documentación.

Una afirmación correcta sobre los enfoques tradicionales es: Son ideales para proyectos con alta incertidumbre. Funcionan bien cuando el alcance del proyecto no cambia. No requieren fases definidas. No necesitan análisis previo.

Las metodologías tradicionales surgieron históricamente…. Después del manifiesto ágil. Con las primeras prácticas de DevOps. Antes de los métodos ágiles, desde los años 50–80. En la era del cloud computing.

El modelo Waterfall apareció aproximadamente en…. 1950s–60s. 1990s. 2000s. 2010s.

El modelo iterativo e incremental comenzó a usarse en los…. 1950s. 1970s. 2000s. 2010s.

La construcción de prototipos surgió en los…. early 1980s. 1960s. 2000s. 2010s.

El modelo en espiral pertenece a…. Finales de los 80. 1950s. 2001 con el manifiesto ágil. 2010s.

El modelo en V se caracteriza por…. Ausencia de pruebas. Verificación y validación paralelas a las fases de desarrollo. Cambios constantes de requisitos. Espiral sin control de riesgo.

¿En qué fecha se redactó el Manifiesto Ágil?. 2000. 12 de febrero de 2001. 2005. 1999.

El Manifiesto Ágil fue escrito por…. Usuarios finales anónimos. Gerentes de empresas. Destacados profesionales de la ingeniería del software. Equipos de marketing.

Uno de los objetivos del Manifiesto Ágil es…. Reducir la interacción con los clientes. Evitar cambios durante el proyecto. Establecer valores y principios para desarrollar software rápidamente. Sustituir por completo la documentación.

El enfoque Ágil ofrece una alternativa a…. El desarrollo de videojuegos. Los procesos tradicionales rígidos. La programación orientada a objetos. Las pruebas automatizadas.

¿Cuántos valores define el Manifiesto Ágil?. 2. 4. 8. 12.

¿Cuántos principios contiene el Manifiesto Ágil?. 4. 8. 12. 20.

Se valora más a los individuos y su interacción que…. Que los plazos. Que los procesos y herramientas. Que las métricas. Que la seguridad.

En Ágil se prefiere software que funciona por encima de…. Diseño visual. Documentación exhaustiva. Marketing. Prototipos.

La colaboración con el cliente se valora más que…. La negociación contractual. Las pruebas. La entrega continua. El análisis técnico.

La respuesta al cambio se valora más que…. El diseño. El seguimiento de un plan. La comunicación. La documentación.

La mayor prioridad en Ágil es…. Minimizar costos. Entregar documentación. Satisfacer al cliente mediante entrega temprana y continua. Cumplir estrictamente el plan.

¿Con qué frecuencia se recomienda entregar software funcional?. Cada 6 meses. Cada año. Entre dos semanas y dos meses. Solo al final del proyecto.

¿Cuál es la medida principal de progreso en Ágil?. Líneas de código. Horas trabajadas. Software funcionando. Cantidad de documentación escrita.

El principio “aceptamos que los requisitos cambien” pertenece al bloque…. Colaboración. Entrega funcional. Diseño flexible y adaptación al cambio. Productividad.

La “excelencia técnica” y el “buen diseño” permiten…. Reducir el contacto con el cliente. Mejorar la Agilidad. Evitar pruebas. Reducir el ritmo de trabajo.

Los procesos ágiles promueven…. Horarios extensos y carga continua. Desarrollo sostenible con ritmo constante. Entregas anuales. Equipos rígidos.

La simplicidad en Ágil significa…. No documentar nada. Minimizar el trabajo no realizado. Reducir la calidad. Eliminar fases del ciclo de vida.

Un equipo auto-organizado…. Necesita supervisión constante. Decide cómo organizar su trabajo. Evita elegir sus herramientas. No interactúa con el cliente.

Las mejores arquitecturas y diseños emergen de…. Equipos auto-organizados. El jefe de proyecto únicamente. La documentación pesada. Los auditores externos.

¿Qué método de comunicación es más eficiente según Ágil?. Email formal. Documentación extensa. Reuniones cara a cara. Mensajería instantánea.

¿Qué deben hacer regularmente los equipos según Ágil?. Reducir la comunicación. Reflexionar, ajustar y perfeccionar su comportamiento. Evitar retrospectivas. Cambiar el proyecto completo cada iteración.

El modelo Ágil se basa en…. Un ciclo secuencial rígido. Mejora continua. Eliminación del cliente. Entregas únicas.

Un elemento clave de Ágil es que es…. Lento y controlado. Constante y rápido. Impredecible. Enfocado en documentación.

Los plazos de entrega en Ágil son…. Amplios. Reducidos. Fijos para todo el año. No definidos.

La filosofía Ágil busca evitar…. Entregas continuas. La dispersión. La comunicación diaria. La colaboración con el cliente.

Los equipos deben centrarse en…. Varias tareas simultáneas. Un plan rígido. Una tarea encomendada. Documentación detallada.

Una ventaja de Ágil es…. Mayor cantidad de documentación. Mejora la calidad del producto. Reduce la interacción entre miembros del equipo. Amplía los tiempos de entrega.

El mayor compromiso del empleado conduce a…. Peor ambiente laboral. Menos motivación. Mayor conciencia de equipo. Más rotación.

Ágil ayuda a acortar…. El número de entregas. Los ciclos de producción. La comunicación con el cliente. Las retrospectivas.

Una ventaja clave de Ágil relacionada con la productividad es…. Asignar recursos de forma rígida. Aumentar la documentación. Asignar mejor los recursos y de forma más dinámica. Reducir la frecuencia de entregas.

XP es una metodología Ágil centrada en…. Reducir la comunicación con el cliente. La satisfacción del cliente y la calidad del software. Aumentar la documentación. Planificar exhaustivamente antes de desarrollar.

Los orígenes de XP se remontan a…. Proyectos militares de los 80. Los años 60 con proyectos como Mercury de la NASA. El manifiesto ágil de 2001. Google en 2010.

XP fue introducida por…. Jeff Sutherland. Kent Beck. Ken Schwaber. Winston Royce.

¿En qué año introdujo Kent Beck XP en DaimlerChrysler?. 1999. 2001. 1996. 1990.

¿Cuándo se publicó el libro Extreme Programming Explained?. 1990. 1996. 1999. 2001.

Uno de los principios básicos de XP es…. Documentación exhaustiva. Simplicidad. Ausencia de comunicación. Diseño pesado.

En XP, la comunicación debe ser…. Escrita únicamente. Cara a cara diariamente. Mediante informes semanales. Solo entre jefes de proyecto.

La retroalimentación (feedback) se obtiene…. Solo al final del proyecto. En cada iteración. Mensualmente. De forma opcional.

Un equipo XP debe tener coraje para…. Evitar cambios. Aceptar solo éxitos. Asumir responsabilidad y ser emprendedor. No hablar con el cliente.

En XP el respeto implica…. Trabajar de forma individual. Todos dan y reciben respeto. No cuestionar decisiones. No asumir errores.

En XP el cliente…. Solo interviene al final. Es un observador del proyecto. Define requisitos y trabaja muy cerca de los desarrolladores. No participa en las pruebas.

¿Quién escribe y prioriza las historias de usuario en XP?. El programador. El gestor. El cliente. El entrenador.

En XP, el cliente también…. Programa por parejas. Realiza pruebas de aceptación. Diseña el sistema. Controla el cronograma.

El desarrollador XP crea la funcionalidad basándose en…. Documentos formales de requisitos. Historias de usuario. Planes de negocio. Diagramas UML obligatorios.

El desarrollador está facultado para…. Estimar sus tareas sin interferencia. Dirigir el proyecto. Sustituir al cliente. Omitir pruebas.

El encargado de pruebas ayuda a…. Gestionar el cronograma. Escribir y definir pruebas de aceptación. Redactar contratos. Planificar el presupuesto.

El encargado de pruebas es un rol…. Obligatorio. Opcional. Solo para grandes empresas. Exclusivo del cliente.

El encargado de seguimiento mide…. La motivación del equipo. La velocidad del equipo. Los costos del proyecto. El número de reuniones.

La velocidad en XP se define como…. Tareas realizadas dividido por motivación. Tiempo real dedicado entre tiempo estimado ideal. Tiempo estimado ideal frente al tiempo real dedicado. Funcionalidad entregada al cliente.

El encargado de seguimiento es…. Obligatorio. Opcional. Sustituido por el cliente. Parte de Scrum.

El entrenador en XP…. Supervisa sin enseñar. Proporciona orientación y tutoría al equipo. Es el jefe del proyecto. Reemplaza al cliente.

El entrenador actúa también como…. Auditor. Árbitro entre cliente y equipo. Tester. Programador principal.

El gestor en XP es…. Gerente del proyecto. Un programador sénior. Siempre el cliente. Obligatorio.

El gestor debe…. Diseñar el sistema. Asignar las tareas técnicas. Tener una idea general del proyecto y su estado. Probar el software.

XP promueve…. Entregas anuales. Ciclos de desarrollo cortos. Documentación pesada. Eliminar comunicación con el cliente.

El desarrollo XP es…. Solo incremental. Solo iterativo. Iterativo e incremental. Rígido y secuencial.

Las iteraciones de XP duran…. De 1 a 6 meses. Máximo dos semanas. 24 horas. Solo un día.

Una característica esencial de XP es…. Integración continua. Documentación exhaustiva. Pruebas solo al final. No permitir cambios.

Una de las actividades principales del ciclo XP es…. Análisis exhaustivo inicial. Codificación con programación por parejas. Solo pruebas automáticas. Gestión contractual.

El crecimiento del software en XP se da mediante…. Grandes entregas finales. Pequeñas mejoras continuas. Cambios sin revisión. Eliminación de retroalimentación.

En XP, el juego de la planificación consiste en…. Crear un documento detallado de requisitos. Fusionar la opinión del cliente y del equipo. Hacer pruebas antes del análisis. Planificar solo al final del proyecto.

Las entregas pequeñas en XP buscan…. Reducir el número de iteraciones. Entregar funcionalidad mínima lo antes posible. Entregar todo al final del proyecto. Evitar mostrar avances al cliente.

La metáfora en XP sirve para…. Crear documentación extensa. Alinear al equipo con una visión simple del sistema. Prohibir decisiones técnicas. Sustituir el diseño.

El diseño simple en XP significa…. Crear una arquitectura compleja desde el inicio. Elegir el diseño más rápido sin pensar. Mantener solo lo necesario y evitar redundancia. No documentar jamás.

En XP, las pruebas deben ser…. Específicas del cliente y manuales. Escritas después del código. Escritas por los desarrolladores por cada unidad de código. Opcionales.

TDD consiste en…. Crear pruebas después de programar. Escribir solo pruebas manuales. Escribir pruebas antes del código. Evitar refactorizar.

El código en XP solo se considera completo cuando…. El cliente lo revisa visualmente. La documentación está lista. Todas las pruebas automatizadas pasan. El Product Owner lo aprueba.

La refactorización se utiliza para…. Cambiar la funcionalidad del sistema. Mejorar el diseño sin alterar el comportamiento. Eliminar pruebas. Reducir entregas.

El principio de simplicidad en XP indica…. Diseñar todo para el futuro. Incluir todo lo que pueda necesitarse. Mantener el diseño eficiente y simple. No modificar nunca el código.

La programación por parejas implica…. Dos desarrolladores revisan código por separado. Dos desarrolladores programan juntos en un solo ordenador. Cada desarrollador trabaja en su módulo sin interferencias. El cliente escribe el código.

Un beneficio de la programación por pares es…. Se escribe menos código usable. No se revisa el código. Se obtiene mejor diseño y mejores pruebas. Evita la comunicación.

La propiedad colectiva del código implica…. Solo un programador puede editar cada módulo. Nadie puede modificar el código del otro. Cualquier desarrollador puede modificar cualquier parte. Solo el líder técnico edita el repositorio.

La integración continua recomienda…. Integrar el código una vez por mes. Integrar solo cuando termine el proyecto. Integraciones de pocas horas a un día. Evitar automatizar el proceso.

El objetivo de la integración continua es…. Retrasar errores hasta fases finales. Detectar problemas lo antes posible. No usar pruebas. Evitar colaboraciones.

La regla de “40 horas semanales” en XP dice que…. El equipo debe trabajar horas extras continuas. El equipo debe trabajar solo 4 horas diarias. Las mejores condiciones se dan en un turno normal (8 horas). Debe haber rotación semanal obligatoria.

El cliente en casa (on-site customer) significa…. El cliente nunca participa. El cliente está disponible localmente para resolver dudas. Se consulta al cliente solo al final. El cliente escribe el código.

Los estándares de codificación buscan…. Que cada programador use su estilo propio. Eliminar la necesidad de refactorizar. Homogeneizar el código entre desarrolladores. Evitar la programación por pares.

En XP, las pruebas unitarias deben ser…. Manuales. Opcionales. Frecuentes y automatizadas. Solo escritas por el cliente.

El ciclo TDD sigue el orden…. Codificar → Probar → Refactorizar. Probar → Codificar → Documentar. Prueba falla (Fail test) → Código mínimo (Pass test) → Refactorizar (Refactor). Analizar → Diseñar → Codificar.

La práctica que asegura que todo código sea revisado al menos por otra persona es…. Refactorización. Integración continua. Programación por parejas. Metáfora.

“Short releases” significa…. Reducir el número de entregas. Entregar versiones funcionales en ciclos cortos. Evitar mostrar avances al cliente. Hacer pruebas más largas.

¿Qué asegura que el sistema esté siempre integrado?. Programación por parejas. Juego de planificación. Integración continua. Metáfora.

La metáfora debe…. Ser una descripción técnica detallada. Servir como referencia simple para entender el sistema. Ser un documento difícil de modificar. Definir la arquitectura completa.

Las pruebas en XP requieren…. Solo intervención del cliente. Solo intervención del programador. Participación del cliente en pruebas funcionales. No realizar pruebas unitarias.

La refactorización elimina…. Código duplicado. Casos de uso. Historias de usuario. Pruebas automáticas.

La programación por pares debe detenerse cuando…. Uno o ambos no puedan concentrarse. El código compile. El cliente lo pida. Terminen las pruebas.

La propiedad colectiva busca…. Limitar cambios. Aumentar la responsabilidad compartida. Eliminar revisiones. Reducir la calidad.

El objetivo del diseño simple es…. Soportar todas las funcionalidades futuras. Ser lo más complejo posible. Mantener solo lo necesario en el presente. Evitar refactorizar.

TDD exige que…. Las pruebas se escriban después del código. El código se haga sin pruebas. El código solo existe si hay una prueba que lo valida. Ninguna prueba falle.

El juego de la planificación (planning game) consiste en…. Que el cliente planifique solo. Fusionar la opinión del cliente y del equipo. Eliminar la opinión del cliente. Crear contratos formales.

Las entregas pequeñas permiten…. Tener una versión final sin iteraciones. Funcionalidades mínimas disponibles pronto. Eliminar contacto con el cliente. Reemplazar las pruebas.

La metáfora en XP busca…. Crear una arquitectura compleja. Un lenguaje común para entender el sistema. Reducir la comunicación. Sustituir documentación técnica.

El diseño simple implica…. Incluir todo lo que podría necesitarse en el futuro. Código simple, sin redundancias. Diseños pesados y detallados. Uso obligatorio de patrones complejos.

En la práctica de pruebas (testing), los programadores deben…. Hacer pruebas solo al final. Escribir pruebas por cada unidad de código. Dejar las pruebas al cliente únicamente. No usar automatización.

TDD se basa en…. Escribir código antes que pruebas. Escribir pruebas unitarias antes del código. No realizar refactorización. Probar solo manualmente.

En TDD, el código se considera completo cuando…. La documentación está finalizada. Todas las pruebas automatizadas pasan. El cliente lo autoriza. El programador termina las tareas.

La refactorización del código implica…. Añadir nuevas funcionalidades. Mejorar diseño sin cambiar funcionalidad. Eliminar pruebas. Simplificar eliminando requisitos.

La refactorización busca eliminar…. Comentarios. Código duplicado. Requisitos del cliente. Historias de usuario.

La simplicidad en XP significa…. Hacer diseños complejos. Código eficiente y simple para facilitar cambios. Evitar refactorizar. Crear módulos grandes.

En programación por parejas…. Dos programadores trabajan en ordenadores distintos. Dos trabajan juntos en el mismo monitor y teclado. Solo uno escribe código. Se revisa el código al final.

El objetivo de pair programming es…. Reducir la calidad del código. Que el líder tome todas las decisiones. Revisar todo código productivo por otro desarrollador. Que solo uno participe.

Los desarrolladores en pair programming deben ser…. Pasivos. Observadores únicamente. Participantes activos. Supervisores.

La propiedad colectiva del código significa…. Solo un programador puede modificar el código. Cualquiera puede modificar cualquier parte del código. Solo los jefes pueden tocarlo. Debe bloquearse por módulos.

Integración continua en XP recomienda…. Integrar solo al final. Integrar cada varias semanas. Integrar cada pocas horas o al menos una vez al día. Evitar automatización.

El objetivo de la integración continua es…. Aumentar el costo. Detectar errores temprano. Evitar pruebas. Eliminar iteraciones.

La regla de las 40 horas semanales implica…. Trabajar fines de semana obligatoriamente. 60 horas para terminar más rápido. Un turno normal de 8 horas como máximo. Turnos dobles.

XP afirma que la máxima velocidad se obtiene…. Sin descanso. Con horas extras constantes. Con descanso adecuado y turnos razonables. Solo programando en solitario.

“Clientes en casa” significa…. El cliente trabaja desde su domicilio. El cliente está disponible localmente y plenamente involucrado. El cliente no participa. Los desarrolladores viajan continuamente.

Los estándares de codificación buscan…. Forzar estilos rígidos. Mantener un estilo de codificación uniforme entre programadores. Evitar pruebas unitarias. Eliminar la documentación.

El juego de la planificación une…. Cliente + desarrolladores. Tester + gestor. Coach + desarrolladores. Gestor + marketing.

Las entregas pequeñas permiten…. Evitar feedback del cliente. Minimizar riesgos y obtener feedback rápido. Entregar una única versión final. Evitar cambios.

La metáfora evita…. Documentación. La necesidad de una arquitectura muy detallada. La comunicación. Las pruebas de aceptación.

El diseño simple evita…. Complejidad innecesaria. Refactorización. Pruebas unitarias. Integración continua.

Las pruebas en XP deben ser…. Solo del cliente. Unitarias y por cada unidad de código. Solo automáticas. Solo manuales.

TDD exige escribir pruebas…. Después del código. Antes del código. Solo al final. Solo cuando falla algo.

Refactorizar aumenta…. Complejidad. Acoplamiento. Cohesión. Tiempos muertos.

En pair programming, cuando uno de los dos está cansado…. La pareja sigue igual. El emparejamiento debe finalizar. Lo reemplaza el cliente. Se hace refactorización obligatoria.

La propiedad colectiva permite…. Bloquear el código a programadores nuevos. Mantener mayor flexibilidad y rapidez ante cambios. Perder trazabilidad. Reducir la colaboración.

Una buena integración continua debe…. Hacerse cada pocas semanas. Romper el sistema frecuentemente. Ser frecuente y automatizada. Hacerse sin pruebas.

Lean surge originalmente en la industria de producción de los años…. 70. 80. 90. 60.

La empresa origen del modelo Lean es…. Honda. Toyota. Nissan. Mazda.

El concepto “just in time” es propio de…. XP. Scrum. Lean. Kanban exclusivamente.

Un valor Lean fundamental es…. Añadir más reuniones. Reducir residuos. Documentar más. Aumentar capas de control.

Lean recomienda comenzar un trabajo…. En cuanto alguien esté libre. Solo cuando sea necesario. Cuando el jefe lo ordene. Cada lunes.

Lean Software Development fue popularizado en 2003 por…. Beck y Fowler. Mary y Tom Poppendieck. Schwaber y Sutherland. Jim Highsmith.

Lean tiene cuántos principios fundamentales?. 5. 7. 10. 12.

En Lean, el desperdicio se denomina…. Gemba. Muda. Kansei. Poka-Yoke.

Un ejemplo de desperdicio es…. Comunicación efectiva. Código duplicado. Integración continua. User stories claras.

“Amplificar el aprendizaje” implica…. Que todos aprenden solo de su tarea. Una mentalidad de aprendizaje continuo. Evitar trabajar con nuevas tecnologías. Depender del jefe para aprender.

Según Lean, los desarrolladores deben aprender…. Solo del manual. De otros compañeros y proyectos. Exclusivamente de cursos externos. Únicamente de su especialidad.

“Decidir lo más tarde posible” significa…. No decidir nada. Esperar a tener requisitos claros. Retrasar por vagancia. Consultar solo al jefe.

En Lean, los requisitos tradicionales se sustituyen por…. Diagramas UML. User Stories. Flujos BPMN. Casos de uso largos.

“Entregar lo antes posible” implica…. Entregas grandes y muy separadas. Entregas frecuentes alineadas con user stories. Esperar a terminar todo. Evitar feedback del cliente.

Cada entrega Lean debe incluir…. Todo el backlog. Funcionalidades críticas que aporten valor pronto. Exclusivamente mejoras técnicas. Documentación extensa.

“Potenciar el equipo” significa…. Reducir decisiones del equipo. Aumentar el control del jefe. Hacer que el equipo participe en decisiones. Evitar la comunicación interna.

Una técnica relacionada con potenciar el equipo es…. Planning Poker. Diagrama de Gantt. PERT. Diagramas de clases.

“Crear integridad” implica…. Mantener módulos aislados. Que los componentes del sistema funcionen bien juntos. Integrar solo al final. Evitar cambios por completo.

Lean prioriza la comunicación…. Mediante informes. Cara a cara. Por correo. Solo con documentación.

La integración continua en Lean debe incluir…. Builds y pruebas automatizadas. Integración semestral. Mucha documentación. Integrar solo cuando el jefe lo pida.

Un desperdicio Lean es…. Requisitos ambiguos. Buen flujo de trabajo. Feedback rápido. Integración continua.

Lean recomienda decidir tarde porque…. Permite evitar hablar con el cliente. Permite adaptarse a requisitos cambiantes. Es más cómodo. Reduce el trabajo del equipo.

El aprendizaje continuo es clave porque…. La tecnología cambia muy rápido. Los desarrolladores son inexpertos. Lo exige el cliente. Se reduce el testing.

“Entregar lo antes posible” permite…. Evitar cambios. Obtener feedback temprano. Aumentar documentación. Alargar el proyecto.

“Crear integridad” busca principalmente…. Reducir módulos. Mejor mantenimiento y calidad. Documentación muy detallada. Evitar integraciones frecuentes.

El lema “Piensa en grande, actúa en pequeño…” pertenece a…. Crear integridad. Visualizar todo el conjunto. Eliminar desperdicios. Amplificar aprendizaje.

Visualizar todo el conjunto implica que los desarrolladores deben…. Ver solo su parte del código. Entender cómo encajan sus tareas en el sistema completo. Centrarse únicamente en rendimiento. Evitar ver procesos externos.

Este principio recomienda analizar…. Solo el código fuente. Las interacciones con otros sistemas de la compañía. La interfaz gráfica. El plan de marketing.

Visualizar el conjunto ayuda a…. Detectar mejoras y cambios que aporten valor. Crear más documentación. Reducir comunicación. Aumentar la burocracia.

Este principio busca principalmente…. Extraer más métricas. Optimizar el rompecabezas completo del sistema. Reducir el número de reuniones. Aumentar el tamaño del equipo.

Kanban es una palabra japonesa que significa…. Trabajo en curso. Tarjetas visuales. Flujo continuo. Integración.

El origen de Kanban se encuentra en…. Microsoft. Honda. Toyota. IBM.

Kanban nació como parte del sistema…. Waterfall. Just-in-time (JIT). XP. BPM.

Kanban se define como un sistema de…. Comunicación. Documentación. Producción altamente efectivo y eficiente. Control jerárquico.

Kanban forma parte de…. Metodologías tradicionales. Metodologías ágiles. Gestión burocrática. Modelos predictivos.

Un principio clave de Kanban es…. Aumentar multitarea. Garantizar rapidez por encima de calidad. Calidad garantizada desde la primera vez. Reducir reuniones.

Kanban promueve la…. Mejora continua. Eliminación de retrospectivas. Integración semestral. Separación estricta de tareas.

Kanban es flexible porque…. Nunca permite reordenar tareas. No usa tarjetas. Permite priorizar según necesidades del momento. Exige un plan fijo.

Reducir desperdicio en Kanban significa…. Hacer solo lo justo y necesario. Añadir más pasos. Documentar más. Dividir tareas sin sentido.

En Kanban, desperdicio es…. Requisitos claros. Código innecesario. Comunicación efectiva. Flujos simples.

El tablero Kanban debe ser…. Privado. Difícil de modificar. Accesible y visible por todo el equipo. Solo para el líder del proyecto.

Cada columna del tablero representa…. Un rol del equipo. Un estado del flujo de tareas. El salario de cada miembro. La documentación necesaria.

El tablero Kanban es…. Estático. Continuo y en evolución. Eliminado al acabar la fase. Solo para empresas grandes.

Visualizar el flujo implica…. Esconder tareas en curso. Mostrar partes del trabajo en tarjetas (post-it). Eliminar fases. Crear paneles abstractos.

Las tarjetas Kanban incluyen normalmente…. La foto del desarrollador. Descripción + estimación de horas. Documentos legales. Diagramas UML completos.

El objetivo de visualizar el flujo es…. Ocultar carga de trabajo. Clarificar tareas, prioridades y metas. Aumentar burocracia. Crear más roles.

WIP significa…. Work In Parallel. Work In Production. Work In Progress. Work Integrated Plan.

Limitar WIP implica…. Abrir muchas tareas a la vez. Priorizar el trabajo en curso antes que nuevas tareas. Cambiar tareas constantemente. Hacer multitarea extrema.

En Kanban no se puede…. Finalizar tareas. Refinar prioridades. Abrir una nueva tarea sin terminar otra. Usar tarjetas.

El flujo continuo en Kanban mezcla…. Solo tareas administrativas. Tareas y proyectos. Usuarios y roles. Análisis y marketing.

El seguimiento del trabajo realizado se hace mediante…. Reuniones obligatorias. Informes externos. La información contenida en las tarjetas. Documentos enormes.

Una ventaja de Kanban es poder…. Entregar solo al final. Hacer entregas en cualquier momento. Evitar cambios. Trabajar sin prioridades.

El flujo perfecto permite…. Interrupciones constantes. Cambiar prioridades al vuelo. Aumentar burocracia. Reducir visibilidad.

Los 4 pasos Kanban incluyen…. Trabajar sin tablero. Visualizar, limitar WIP, gestionar flujo, mejorar continuamente. Documentar, validar, aprobar, cerrar. Planificar anual, ejecutar, entregar, archivar.

“Manage flow” consiste en…. Ignorar bloqueos. Controlar interrupciones y medir rendimiento. Escribir reportes. Añadir más fases.

Un bloqueo en Kanban implica…. Continuar sin más. Parar, colaborar, resolver. Eliminar la tarjeta. Crear más trabajo.

La mejora continua en Kanban significa…. No cambiar nada una vez implementado. Revisar, medir y ajustar métodos de forma constante. Rehacer siempre todo. Cambiar de metodología.

Una herramienta popular de Kanban es…. Eclipse. Docker. Trello. Visual Studio Code.

Una característica del método Kanban es que…. Es difícil de asumir por el equipo. Es muy fácil de actualizar y utilizar. Requiere certificación obligatoria. Solo sirve para empresas grandes.

Entre las herramientas Kanban listadas en las diapositivas NO está…. KanbanFlow. LeanKit. Kanbanize. Jira (no aparece en tus diapositivas).

SCRUM es…. Una metodología rígida. Un marco de trabajo ligero. Un proceso totalmente definido. Un método predictivo.

SCRUM ayuda principalmente a…. Aumentar la documentación. Generar valor con soluciones adaptativas. Evitar cambios en el proyecto. Eliminar reuniones.

SCRUM dicta cómo debe hacerse todo el proyecto. Sí. Solo en parte. No. Solo al inicio.

Un sprint es…. Una reunión diaria. Una iteración con límite de tiempo. Un artefacto. Un rol del equipo.

Un sprint suele durar…. 1 semana. 3–4 semanas. 6–8 semanas. 1 día.

El entregable de un sprint debe ser…. Documentación. Un prototipo funcional. Un reporte. Un conjunto de tests.

En SCRUM, el producto entregable de un sprint se llama…. Backlog. Incremento. Documento final. Histórico.

¿Cuántas reuniones principales tiene SCRUM por sprint?. 2. 4. 5. 1.

La primera reunión del sprint es…. Daily Scrum. Sprint Review. Sprint Planning. Retrospective.

El Daily Scrum dura…. 15 minutos. 1 hora. 5 minutos. No tiene límite.

El objetivo del Daily Scrum es…. Revisar el código. Alinear el progreso del equipo. Revisar requisitos. Evaluar rendimiento.

En el Sprint Review…. Se revisa el proceso. Se revisa el incremento con los stakeholders. Se revisa el backlog. Se asignan nuevas tareas.

La última reunión del sprint es…. Daily Scrum. Sprint Planning. Sprint Review. Sprint Retrospective.

La Retrospective se centra en…. Entrega del producto. Mejoras internas del equipo. Métricas financieras. Cambios en requisitos.

Un artefacto de Scrum es…. Product Backlog. Gantt. Diagrama UML. WBS.

El Sprint Backlog contiene…. El trabajo total del proyecto. El trabajo seleccionado para el sprint actual. El trabajo ya terminado. Las pruebas del sistema.

El Product Owner es responsable de…. Guiar técnicamente al equipo. Mantener y priorizar el Product Backlog. Realizar pruebas. Documentar entregables.

El Scrum Master es…. El jefe del equipo. Un facilitador y líder servidor. Un programador senior. El responsable del producto.

El Development Team es…. Un equipo autogestionado. Dirigido por el jefe de proyecto. Externo al producto. Un conjunto de consultores.

Una Historia de Usuario describe…. Un requisito técnico. Un diagrama del sistema. Una funcionalidad desde la perspectiva del usuario. El diseño del software.

La estructura típica de una user story es…. Qué → Cómo → Por qué. As a / I want / So that. Input / Output. Caso de uso formal.

El Product Backlog contiene…. Todo el trabajo posible del producto. Solo las tareas del sprint. Solo bugs. Documentación técnica.

Los burndown charts permiten ver…. El avance del equipo en el sprint. El coste del proyecto. El estado financiero. El backlog histórico.

El Sprint Backlog lo gestiona…. Product Owner. Scrum Master. Development Team. Stakeholders.

SCRUM es especialmente útil para…. Proyectos repetitivos y predecibles. Proyectos complejos con cambios frecuentes. Proyectos sin clientes. Tareas de mantenimiento únicamente.

Un Sprint termina cuando…. El Product Owner lo decide. El tiempo límite se cumple. Todo está 100% perfecto. El equipo termina el backlog.

¿Quién prioriza el Product Backlog?. Scrum Master. Development Team. Clientes. Product Owner.

SCRUM fomenta…. Jerarquía estricta. Equipos autoorganizados. Procesos rígidos. Documentación pesada.

El incremento debe ser…. Solo diseño. Algo usable por el cliente. Un mockup. Solo código sin probar.

El principal objetivo del Sprint Planning es…. Definir objetivos y plan del sprint. Revisar fallos pasados. Medir retrasos. Cancelar tareas previas.

SCRUMBAN surge de combinar: Scrum + XP. Scrum + Kanban. Kanban + Lean. Scrum + Waterfall.

SCRUM fue diseñado originalmente para: Mantener documentación pesada. Entregas rápidas, adaptarse a cambios y requisitos emergentes. Eliminar retrospectivas. Equipos grandes y jerárquicos.

Los equipos SCRUM son: Grandes y centralizados. Pequeños, multifuncionales y autoorganizados. Individuales. Rotativos cada semana.

Kanban se basa principalmente en: Roles obligatorios. Un flujo continuo visual. Sprints fijos. Un incremento mensual.

El objetivo principal de Kanban es: Aumentar el número de reuniones. Crear un flujo de valor continuo y predecible. Reducir la comunicación. Eliminar la visualización del progreso.

Los equipos Kanban miden: La velocidad del sprint. El lead time (tiempo de entrega). Las horas extras. La duración de retrospectivas.

SCRUMBAN utiliza la naturaleza de Scrum para ser: Predictivo. Ágil. Lineal. Documental.

SCRUMBAN utiliza de Kanban principalmente: Reuniones diarias. Mejora continua del proceso. Estimaciones por horas. Historias de usuario largas.

SCRUMBAN combina: La estructura de Scrum con el flujo de Kanban. El flujo de Scrum con las reglas de XP. Fases del modelo V con sprints. Diagramas UML con Kanban.

Un “ScrumBut” es: Scrum perfecto. Scrum pero se eliminan reglas importantes. Una versión mejorada del Scrum Guide. Kanban puro.

“Scrum es ligero” significa que: Se puede adaptar todo sin reglas. Casi todo es obligatorio. No hay artefactos. No se requiere backlog.

Un ejemplo de ScrumBut es: Hacer retrospectiva cada sprint. No usar timebox en los sprints. Tener un Product Owner. Hacer Daily Scrum.

SCRUMBUT no es Scrum porque: Se usa en proyectos pequeños. Al omitir reglas no se obtienen todos los beneficios. Tiene demasiados roles. Elimina la figura del Product Owner.

En SCRUMBAN se usa un tablero: Gantt. UML. Kanban. PERT.

En SCRUMBAN el Product Owner gestiona: El Sprint Backlog. La columna “Pendiente” (Product Backlog). Las tareas en “En progreso”. Las pruebas automatizadas.

El equipo de desarrollo en SCRUMBAN toma tareas: Por orden aleatorio. De la parte superior del backlog, si tiene capacidad libre. Según la opinión del jefe. Una vez al mes.

En SCRUMBAN el Sprint Planning: Sigue siendo obligatorio. Ya no es necesario. Se hace dos veces por sprint. Está limitado a 2 horas.

En SCRUMBAN, las reuniones de revisión (Sprint Review) se hacen: Solo cuando termina un sprint completo. Tras un volumen de trabajo o en intervalos fijos. Una vez al año. Sin Product Owner.

La retrospectiva en SCRUMBAN: Ya no existe. Sigue siendo necesaria. Solo la hace el Scrum Master. Se hace mensualmente.

El Daily Scrum en SCRUMBAN: No existe. Se mantiene igual que en Scrum. Se hace una vez por sprint. Reemplaza la retrospectiva.

El Product Backlog en SCRUMBAN: No se usa. Es idéntico a Scrum, pero en la columna “Pendiente”. Se reemplaza por diagramas. Es opcional.

El Sprint Backlog en SCRUMBAN: Se mantiene. Ya no se utiliza. Se usa solo en proyectos grandes. Requiere estimaciones obligatorias.

Un incremento en SCRUMBAN: Cambia de definición. Mantiene la misma definición que en Scrum. Se elimina. Se reemplaza por documentación.

Una desventaja de SCRUMBAN es que: Tiene demasiadas reglas estrictas. Puede volverse un batiburrillo de metodologías. Obliga a usar sprints largos. No permite adaptación.

En SCRUMBAN los equipos pueden: Inventar prácticas propias si lo necesitan. Seguir siempre reglas estrictas. Evitar retrospectivas. No medir nada.

SCRUMBAN se usa especialmente cuando: Hay requisitos totalmente estables. Los requisitos cambian constantemente. Se trabaja con hardware. El cliente no quiere feedback.

La planificación en SCRUMBAN es: Igual que scrum. Continua y basada en flujo. Por fases. Basada en hitos.

Los roles en SCRUMBAN son: Eliminados. Los mismos que en Scrum (PO, SM, Dev Team). Reemplazados por un único rol. Solo el equipo de desarrollo.

Scrumban permite: Eliminación del Product Owner. Flujo constante + eventos adaptativos. Evitar cualquier reunión. Trabajar sin tablero.

El lead time en SCRUMBAN sirve para: Medir la calidad del código. Medir desde que se solicita un trabajo hasta que se termina. Contar historias de usuario. Estimar roles.

XP se centra principalmente en: Flujo continuo. Calidad del código y prácticas técnicas estrictas. Reducción de residuos. Sprints fijos.

Kanban se diferencia de Scrum en que: No tiene sprints. Tiene roles obligatorios. No usa tableros. Requiere programación en pareja.

Lean se caracteriza por: Uso de timeboxes. Eliminación del desperdicio (Muda). Tener Product Owner. Sprints de 2 semanas.

Scrum exige obligatoriamente: Parejas de programación. Sprint Backlog. Lead time. Limitar el WIP.

XP requiere siempre: Sprint Planning. Programación por parejas. Tablero visual. Retrospectiva diaria.

En Kanban la métrica principal es: Velocidad del sprint. Lead time. Story points. Número de retrospectivas.

Lean recomienda: Decidir lo antes posible. Decidir lo más tarde posible para evitar desperdicio. No cambiar requisitos nunca. Grandes lotes de trabajo.

Scrum organiza el trabajo en: Flujo continuo. Iteraciones llamadas sprints. Historial Kanban. Sistemas de lotes.

Kanban limita explícitamente: La duración de reuniones. El trabajo en curso (WIP). El tamaño del backlog. El número de roles.

Scrumban surge principalmente para: Equipos que no quieren retrospectivas. Combinar Scrum y Kanban. Reemplazar Lean. Proyectos sin Product Owner.

En Scrum, el rol de Product Owner se encarga de: Analizar código. Gestionar el Product Backlog. Crear pruebas unitarias. Limitar el WIP.

XP es especialmente fuerte en: Visualización del flujo. Prácticas técnicas como TDD y refactorización. Sprints grandes. Roles estrictos.

En Kanban el tablero es: Opcional. Continuo y sin sprints. Estructurado por sprints. Solo para bugs.

Lean Software Development incorpora: Principio de “entregar lo antes posible”. Timeboxing. Daily Scrum. Sprint Review.

Scrum exige eventos como: Sprint Planning, Daily Scrum, Sprint Review, Retrospective. Planning Game. TDD. Integración continua obligatoria.

XP mide la productividad mediante: Lead time. Velocidad del equipo. WIP. Burndown chart.

Kanban es ideal para: Requisitos cambiantes día a día. Proyectos sin cambios. Hardware. Grandes diseños iniciales.

Lean promueve: Equipos rígidos. Aprendizaje continuo. Sprint Backlog. Pair programming obligatorio.

En Scrum los incrementos deben ser: Grandes y complejos. Funcionales y potencialmente entregables. Solo documentación. Versiones beta inestables.

Scrumban elimina de Scrum principalmente: Daily Scrum. Sprint Planning. Product Backlog. Sprint Review.

Kanban permite cambiar prioridades: Solo al inicio del sprint. En cualquier momento. Una vez por mes. Nunca.

XP requiere la presencia frecuente del: Product Owner. Cliente on-site. Scrum Master. Lean Coach.

Lean recomienda visualizar: Solo el código. El sistema completo. Únicamente las tareas actuales. Solo la arquitectura.

En Scrum no se puede modificar: El Product Backlog. La duración del sprint (timebox). Las tareas del equipo. Los roles del equipo.

XP promueve entregas: Anuales. Pequeñas y frecuentes. Sin cliente. Solo al final del proyecto.

Scrumban adopta de Kanban: Roles. Flujo continuo y WIP. Timeboxes estrictos. Historias de usuario obligatorias.

Lean busca evitar: Muda (desperdicio). Integración continua. Kanban board. Pruebas automatizadas.

En Scrum el Daily debe durar: 5 minutos. Máximo 15 minutos. 1 hora. No tiene límite.

Kanban NO requiere: Roles definidos. Tablero. Visualización del flujo. WIP.

Scrumban mantiene de Scrum: Sprints. Daily Scrum. Sprint Backlog. Timebox de sprint.