Eres un director de proyecto en un equipo que desarrolla firmware de red para sistemas embebidos. Has convocado una reunión para hacer una demostración a un grupo de perfil muy técnico de clientes de la última versión del código en el que ha estado trabajando tu equipo. Esta es la quinta vez que convocas una reunión como esta, y por quinta vez, los clientes piden cambios concretos. El equipo se pondrá a trabajar en una sexta versión, y repetirás el proceso.
¿Cuál de estas frases describe MEJOR esta situación?
El equipo no entiende los requisitos
Los clientes no saben lo que quieren
El proyecto requiere una mejor gestión El equipo está generando valor de forma continua y rápida.
¿Cuál de estos NO es un rol de Scrum?
Scrum Master Miembro del equipo Project Manager Product Owner.
Eres un desarrollador, y tu equipo está empezando a trabajar de manera ágil. Una de tus clientes ha escrito una breve especificación que describe exactamente una nueva funcionalidad que quiere en la aplicación, y te han dicho que trabajes en esa funcionalidad.
¿Qué es lo primero que deberías hacer?
Pedir una reunión con la cliente, porque la filosofía ágil afirma que la forma más efectiva de transmitir información es la conversación cara a cara Leer la especificación
Ignorar la especificación, porque la filosofía ágil valora más la colaboración con los clientes que la documentación exhaustiva Empezar a escribir código, porque la prioridad en el desarrollo ágil es satisfacer al cliente a base de entregas frecuentes de software funcional.
¿Cuál de estas afirmaciones sobre “software que funciona” es correcta? Hace todo lo que los usuarios necesitan Se ajusta a la especificación de requisitos Las dos Ninguna.
¿Cuál de las siguientes describe MEJOR el Manifiesto Ágil? Describe la forma más efectiva de hacer software Contiene hábitos que aplican todos los equipos ágiles Contiene los valores de la filosofía ágil Define reglas para desarrollar software.
Los proyectos de Scrum se dividen en… Fases Sprints Hitos Oleadas.
Eres un gestor de proyectos en un equipo que divide el trabajo del proyecto en fases, empezando con una fase de redacción de requisitos, seguida de una fase de diseño. Se puede empezar a hacer algo de código antes de que los requisitos y el diseño estén terminados, pero normalmente no se da nada por terminado hasta que esas dos fases están completas.
¿Qué término define MEJOR los proyectos que hacéis?
Desarrollo iterativo Desarrollo en oleadas Desarrollo en cascada Scrum.
¿Cuál es la máxima prioridad de un equipo ágil? Maximizar el trabajo no hecho Satisfacer al cliente con entregas frecuentes de software Aceptar los cambios, incluso en las etapas finales Utilizar iteraciones en el desarrollo del proyecto.
¿Cuál de las siguientes afirmaciones sobre la reunión diaria es FALSA? Todo el mundo permanece en pie para hacerla corta Es lo mismo que una reunión de control Es más efectiva cuando todos se escuchan Es una oportunidad para que todos se impliquen.
¿Cuál de estas es la MEJOR descripción de la filosofía ágil respecto a la sencillez? Maximizar el trabajo no hecho Satisfacer al cliente con entregas frecuentes de software Aceptar los cambios, incluso en las fases finales Utilizar iteraciones para el desarrollo.
Eres el jefe de un equipo que acaba de empezar a trabajar ágilmente. El primer cambio que hacéis es tener una “daily standup meeting”, pero algunos miembros del equipo dicen que no les gusta asistir. A pesar de que estás recibiendo información valiosa en cada reunión, te preocupa que esta práctica pueda dañar la cohesión de tu equipo.
¿Qué es lo MEJOR que puedes hacer? Dejar de tener las reuniones diarias, y buscar otra práctica ágil que le guste al equipo Establecer una regla para que cada persona en la reunión tenga que dejar su móvil y prestar atención Reunirte con los miembros del equipo uno a uno después de cada reunión para que te den más detalles de su trabajo Trabajar con el equipo para cambiar su actitud.
Eres el jefe de un equipo de desarrollo, y has dejado claro que no toleras errores. Uno de tus desarrolladores ha pasado varias horas trabajando en un software de prueba para ver si se puede resolver un problema complejo de cierta manera. Cuando se da cuenta de que su idea no funcionará, le gritas delante de todo el equipo y le amenazas con despedirle si lo vuelve a hacer.
¿Qué principio ágil se aplica MEJOR a esta situación?
El modo más eficiente de comunicar información es la conversación cara a cara Mantén a tus trabajadores motivados. Dales el entorno y el apoyo que necesiten, y confía en ellos La prioridad es satisfacer al cliente con entregas frecuentes de software que aporta valor La excelencia técnica y el buen diseño es fundamental.
Trabajas en un equipo de desarrollo, y un cliente le pide a tu equipo añadir una funcionalidad nueva al proyecto. Os da una especificación de requisitos. Está muy seguro de lo que quiere, y promete que no habrá cambios.
¿Qué valor ágil se aplica MEJOR a esta situación? Valoramos más a los individuos y las interacciones que a los procesos y las herramientas Valoramos más el software que funciona que la documentación exhaustiva Valoramos más la colaboración con el cliente que la negociación de contratos Valoramos más la respuesta al cambio que el seguir el plan previsto.
¿Cuál de estos NO es un beneficio de aceptar los cambios en los requisitos? Da al equipo una excusa si no llega a tiempo a una entrega El software será valioso si el cliente puede cambiar de idea Hay más tiempo y menos presión para tomar decisiones Se escribe menos código antes de que haya que cambiar algo.
¿Cuál de estas NO describe la filosofía del equipo sobre “software que funciona”? Tiene la versión final de todas las funcionalidades Es la principal medida de progreso Se entrega con frecuencia Es una forma efectiva de conseguir retroalimentación.
Eres el Scrum Master de un equipo de software de una empresa de automoción que trabaja en el firmware de un sistema de frenos ABS. Tu equipo acaba de escribir el objetivo que se alcanzará cuando se completen los ítems del Sprint.
¿Qué es lo siguiente que debe hacer tu equipo? Descomponer los ítems del Sprint Backlog en tareas Demostrar a los clientes el software funcionando Tener una reunión con los de contabilidad Decidir qué ítems van a estar en el Sprint Backlog.
Eres el Product Owner en un proyecto Scrum en una organización sanitaria. Te han convocado a una reunión con los directivos de la empresa, porque has decidido añadir una nueva funcionalidad en el Sprint más reciente. En la reunión, los directivos te dicen que en el futuro, tienes que hablar con ellos antes de tomar una decisión como esa.
¿Cuál de las siguientes describe MEJOR tu papel?
Eres un líder servicial No estás comprometido con el proyecto Necesitas concentrarte y ser valiente No te han dado la suficiente autoridad para hacer de Product Owner.
¿Cuándo se considera un incremento como “hecho”? Cuando acaba el tiempo previsto para el Sprint Cuando cada ítem del backlog está "hecho" y el Product Owner los valida Cuando se hace la Review y se hace la demostración Cuando el equipo hace la Retrospectiva.
¿Cuál de los siguientes es un ejemplo del compromiso colectivo del equipo? Todos se sienten responsables del Incremento en su totalidad Todos se quedan trabajando hasta tarde, y si es necesario, los fines de semana Cada uno es responsable de una parte importante del proyecto Todos participan en la planificación y la Retrospectiva.
¿Cuándo se considera un Sprint acabado? Cuando el equipo acaba el trabajo Cuando el equipo hace la Retrospectiva Cuando acaba el tiempo previsto para el Sprint Cuando se hace la Review.
Eres un desarrollador para una tienda online. Tu jefe de proyecto te dice que la fecha límite para la entrega de la funcionalidad que estás desarrollando es dentro de tres semanas, aunque tú dejaste claro que necesitas cuatro, y no hay ninguna presión externa para acortar el plazo. Tu equipo está empezando a adoptar Scrum.
¿Qué valor de Scrum NO se está adoptando adecuadamente en tu equipo? Transparencia Respeto Valentía Concentración.
Eres el Product Owner de un equipo Scrum que trabaja en un proyecto de telecomunicaciones. Los clientes te han dicho en una de las reuniones habituales con ellos que ha habido un importante cambio en la legislación. Incorporar este cambio en la aplicación es ahora de alta prioridad, y tiene que ser el objetivo del siguiente Sprint.
¿Cuál de los siguientes se usa para describir el objetivo principal de un Sprint?
El Incremento El Sprint Backlog El Objetivo del Sprint El plan del Sprint.
Eres el Product Owner de un equipo, y el cliente te acaba de dar un nuevo requisito. ¿Qué debes hacer? Actualizar el Product Backlog Tener una reunión de planificación de Sprint Actualizar el Sprint Backlog Exponer el nuevo requisito en el siguiente Daily Scrum.
¿Cuál describe MEJOR cómo el equipo decide qué hay que hacer para completar los ítems del Sprint Backlog? El Product Owner trabaja con el cliente para decidir qué va en el Product Backlog El equipo descompone los ítems del Sprint Backlog en tareas El equipo decide qué ítems del Product Backlog van al Sprint Backlog El equipo decide cuándo cada ítem del Sprint Backlog está "hecho".
¿Cuál de estas cosas NO pasa en una Sprint Review? Se actualiza el Product Backlog para aclarar qué irá en el siguiente Sprint El equipo colabora con los clientes para ver por dónde continuar el desarrollo Se demuestra el software funcionando El equipo revisa el Sprint y planea cómo mejorar.
¿De cuál de estas tareas NO es responsable el Scrum Master? Ayudar al equipo a entender qué pasa en el Daily Scrum Guiar al Product Owner para que gestione bien el Product Backlog Ayudar al equipo a entender los requisitos Ayudar al resto de la organización para que entienda cómo funciona Scrum.
¿Cuál de estos NO es un atributo de los ítems del Product Backlog? Estado Valor Estimación Orden.
¿Cuál de estos NO es un evento de Scrum? Sprint Review Product Backlog Retrospectiva Daily Scrum.
¿Qué es un Incremento? Los ítems del Sprint Backlog que se han completado en el Sprint Los ítems del Sprint Backlog que el equipo planea completar en el Sprint El resultado de descomponer los ítems del Sprint Backlog Una frase que describe el objetivo del Sprint.
¿Qué NO comentan los miembros del equipo en el Daily Scrum? ¿Qué problemas me estoy encontrando? ¿Qué trabajo que tenía previsto no he conseguido realizar? ¿Qué haré desde ahora y hasta el próximo Daily Scrum? ¿Qué he hecho desde el Daily Scrum anterior?.
¿Para qué NO se usan las gráficas burn-down? Entender cuántos Puntos de Historia se han completado en un Sprint Entender cuántos Puntos de Historia falta completar antes del fin del Sprint Saber cuántos Puntos de Historia ha completado cada miembro del equipo Pronosticar si el equipo completará todo lo comprometido.
El total de Puntos de Historia entregados al final de un Sprint es… ...el Incremento ...la Review ...el tiempo ideal ...la velocidad.
¿Qué acrónimo nos recuerda cómo deben ser las historias de usuario? INSPECT ADAPT INVEST CONFIRM.
¿Para qué NO sirve la velocidad? Para medir la productividad a lo largo de los Sprints Para comparar la productividad de dos equipos Para estimar cuánto puede hacer un equipo en un Sprint Saber si el equipo se está comprometiendo a mucho o a poco.
Eres un Scrum Master en un proyecto, y han pedido a tu equipo implementar un nuevo componente. Tu equipo lleva trabajando junto cinco sprints, y en los dos últimos ha subido la velocidad. Ahora os reunís para planificar el sexto sprint, y utilizáis un método en el que dialogáis con el PO sobre lo que vais a implementar, usáis cartas para la estimación y ajustáis las estimaciones poco a poco hasta que llegáis a un acuerdo.
¿Qué método estáis utilizando? Planning poker Planificación convergente Sprint Planning Estimación análoga.
¿Cuál de estas herramientas permite ver los cambios en los Puntos de Historia comprometidos? Gráfica de velocidad Gráfica Burn-up Gráfica de flujo acumulativo Histograma de compromiso.
¿Cómo se escriben las historias de usuario normalmente? Como "persona" quiero "accion" para "beneficio" Como "recurso" quiero "objetivo" para "motivo" Como "rol" quiero "accion" para "beneficio" Ninguna de las anteriores.
¿Qué frase se aplica MEJOR a un tablero de tareas? El Scrum Master lo usa para ver si el equipo sigue el plan Se usa para identificar las nuevas tareas en un Sprint Muestra el total de Puntos de Historia que se han conseguido en un Sprint Visualiza el trabajo del Sprint actual.
¿Qué te dice esta gráfica burn-down acerca del Sprint actual? El Sprint va adelantado El Sprint va retrasado El proyecto tiene problemas La velocidad es muy lenta.
¿Qué diferencia hay entre una gráfica burn-down y una burn-up? Las burn-down restan puntos de historia del total comprometido, y las burn-up los suman En las burn-down hay una línea que muestra los puntos de historia comprometidos Las burn-up tienen una línea que indica el ritmo ideal de trabajo Burn-up y burn-down son lo mismo.
Estás en un equipo Scrum que trabaja en un software para médicos. Habéis pegado todas las historias de usuario en la pared, organizándolas según la importancia de cada funcionalidad para que el software tenga éxito. Luego, habéis utilizado esta información para decidir en qué trabajar primero.
¿Cómo se llama la herramienta que habéis utilizado? Planificación de entregas Walking skeleton Planificación de velocidad Mapa de historias.
El proceso de identificar historias de usuario se resume como… Card - Call - Confession Story - Conversation - Product Card - Conversation - Confirmation Card - Test - Documentation.
La velocidad de tu equipo Scrum en los primeros Sprints ha sido 30, 42, 23. ¿Qué está pasando? Todavía estamos ajustando la escala de puntos de historia Estamos bajando la productividad, y hay que hacer algo La velocidad se está igualando Sprint tras Sprint La velocidad no se está midiendo correctamente.
Las herramientas de planificación de Scrum sirven para que el equipo… ...tome las decisiones lo antes posible ...tome las decisiones justo a tiempo ...tome las decisiones responsablemente ...decida en el último momento que no sea una irresponsabilidad.
¿Qué te dice esta gráfica de velocidad de un proyecto? El proyecto va muy rápido El equipo está entregando cada vez más puntos de historia Los puntos de historia comprometidos en cada Sprint varían mucho El proyecto va con retraso.
¿Qué te dice esta gráfica burn-up de un proyecto? Añadieron algunos puntos de historia el día 4, y quitaron otros el día 7 El equipo está añadiendo historias de usuario cada día El equipo no está progresando Se añadieron historias de usuario el día 4 que provocaron un retraso el día 8.
¿Cuál de estas afirmaciones sobre cómo los equipos XP planifican su trabajo es FALSA? Por ejemplo: van cogiendo las tareas de una "pila" Usan iteraciones de una semana Se centran en el código. No planifican XP es iterativa e incremental.
¿Cómo ayuda XP a los equipos a “acoger el cambio”? Ayudándoles a crear código fácil de modificar Poniendo reglas estrictas para las peticiones de cambios Forzando un proceso de control de cambios Limitando el contacto entre los clientes y el equipo.
Estás en un equipo que desarrolla aplicaciones móviles para los que tienen que viajar para ir al trabajo. Tu equipo ha adoptado XP, pero en lugar de usar ciclos semanales, “slack” y planificar por trimestres, tenéis una reunión diaria, planificais en Sprints y tenéis reuniones de retrospectiva.
¿Qué frase describe mejor a tu equipo?
No está haciendo una planificación adecuada Está en proceso de adoptar XP Usa un híbrido de Scrum y XP Está migrando de XP a Scrum.
¿Cuál de estos NO es común a XP y Scrum? Roles Iteraciones Respeto Valentía.
¿Cuál de las siguientes es una práctica válida para hacer planificación en XP? Planning poker Algún otro "planning game" Técnicas tradicionales de estimación de proyectos Todas las otras respuestas son válidas.
Eres un jefe de proyecto en un equipo XP. Te has dado cuenta de que en los últimos ciclos semanales todos tenían puestos los auriculares y escuchaban música mientras programaban. Estás preocupado porque la falta de “comunicación osmótica” haga el espacio de trabajo menos informativo. Convocas una reunión del equipo para explicar en qué consiste el espacio de trabajo informativo de XP, y propones poner una norma prohibiendo los auriculares en el puesto de trabajo.
¿Qué frase describe MEJOR esta situación? El equipo no está cumpliendo con el espacio de trabajo de XP Estás siendo un líder servicial No entiendes del todo los valores de XP El equipo está usando un híbrido de Scrum y XP.
¿Cuál de las siguientes afirmaciones sobre el Desarrollo Guiado por Pruebas (TDD) es cierta? Los tests se escriben después del código que han de probar Escribir los tests primero puede influir mucho en el diseño Sólo los equipos XP usan TDD Escribir tests ralentiza el proyecto, pero mejora la calidad.
¿Qué implica la integración continua? Configurar un servidor que continuamente está integrando código en una carpeta y avisando al equipo de errores en los tests o en la compilación Utilizar iteraciones para producir software que funciona de forma continua Cada persona del equipo mantiene sus carpetas de trabajo actualizadas con la última versión en el SCV (Sistema de Control de Versiones) Reducir continuamente la “deuda técnica” a base de mejorar la estructura del código sin modificar su comportamiento, e integrando esos cambios.
¿Cuál de estos NO es un ejemplo de irradiador de información? El equipo se sienta junto para absorber información Poner una gráfica burn-down donde todos la vean Tener un tablero de tareas en una zona común Tener una lista de las HUs terminadas en un tablón.
¿Cuál de estas técnicas de XP NO implica retroalimentación? TDD Integración continua Compilación en 10 minutos Historias de usuario.
¿Por qué es mejor utilizar bocetos de interfaz de baja calidad? Los clientes se sienten más cómodos de sugerir cambios Los equipos ágiles dibujan mal El equipo sólo crea un grupo de bocetos en cada ciclo Sólo se usan para interfaces simples. XP valora la sencillez.
¿Cuál de los siguientes hábitos favorece el desarrollo a un ritmo sostenible? Planificar con detalle los siguientes seis meses Asegurarse que todos hacen las cosas bien a la primera Todo el equipo sale de trabajar a la hora acordada, y nadie se queda haciendo horas extras o durante el fin de semana Establecer fechas límite ajustadas.
¿Cuál de los siguientes NO es un beneficio de la programación por parejas? Todos los desarrolladores conocen todo el sistema Hay el doble de ojos vigilando los cambios, por lo que se reducen los errores Las parejas ayudan a estar concentrado a los desarrolladores Se trabaja por turnos, por lo que hay menos cansancio.
Estás en un equipo que continuamente refactoriza, hace integración continua, escribe pruebas de unidad antes de escribir el código y hace otras muchas prácticas de XP.
¿Qué frase explica mejor tu equipo?
Tenéis un jefe estricto que obliga a cumplir las reglas XP Tenéis buenos hábitos Sois muy disciplinados Estáis preocupados de que os despidan si no lo hacéis bien.
¿Qué sucede si la compilación del código de un proyecto tarda más de 10 minutos? Habrá errores en el empaquetado del software El equipo lo compilará con menos frecuencia Los problemas de versiones serán más complicados de resolver Fallarán las pruebas de unidad.
Trabajas en un equipo que hace un sistema operativo para móviles. Intentas subir código de una funcionalidad en la que estás trabajando, pero el SCV te dice que hay muchos conflictos que resolver.
¿Qué práctica te hará prevenir MEJOR este problema en el futuro? Ritmo sostenible Integración continua Compilación en 10 minutos TDD.
Trabajas en un proyecto XP. Estáis haciendo planificación por trimestres. Una funcionalidad es muy importante, y no entregarla a tiempo tendría serias consecuencias. Eres el experto en esa parte del proyecto, y serás quien programe esa funcionalidad. Crees que el diseño está claro, y que sabes exactamente qué hay que hacer.
¿Qué deberíais hacer tú y tu equipo? Añadir una historia de usuario para hacer pronto un spike de arquitectura Hacer un boceto de la interfaz para tener retroalimentación por parte del cliente Añadir una historia de usuario para hacer pronto un spike de riesgo Hacer pruebas de usabilidad adicionales.
¿Para qué NO se usan los mapas de flujo del valor? Entender el lead time de una funcionalidad Encontrar desperdicios en un proceso Descubrir nuevas funcionalidades a implementar Entender el ciclo de vida de una funcionalidad.
Eres un desarrollador en un equipo que está haciendo un software de finanzas. Han pedido a tu equipo crear un nuevo sistema de transacciones, así que os reunís para diseñar el flujo de trabajo que vais a seguir. Luego, ponéis el flujo en una pizarra con una columna por etapa. Después de unas semanas, de seguimiento de las tareas a través de las columnas de la pizarra, os dais cuenta de que hay un par de pasos en el proceso que parece que están sobrecargados.
¿Qué es lo MEJOR que podéis hacer? Trabajar para ser mejores en las etapas más lentas del proceso Añadir más personas al grupo que trabaja en las etapas más lentas del proceso Centraros en terminar el trabajo que hay en la pizarra Limitar el work in progress en las etapas del proceso que están sobrecargadas.
Lean es diferente a metodologías como Scrum y XP porque es una _____________ con _________
Mentalidad / herramientas para reflexionar Metodología / prácticas Plan de mejora de procesos / mediciones Escuela de pensamiento / principios.
Un equipo Lean observó todas las tareas en su proceso, fijándose en cómo progresan por las etapas de su flujo de trabajo. Luego, se centraron en conseguir que su ritmo de trabajo fuera constante.
¿Qué herramienta de Lean les ayuda a ver su trabajo como una serie de elementos que se van eliminando del proceso cuando están terminados?
Esforzarse por ver el desperdicio Toma de decisiones en el último momento Teoría de colas Mediciones.
¿Cuál de las siguientes frases describe MEJOR lo que Lean denomina el coste del retraso? Una lista de funcionalidades ordenadas según lo pronto que las necesita el cliente Es el valor monetario del tiempo que se emplea en desarrollar el producto Consiste en entender la importancia en tiempo de las tareas que hay en cola, para tomar mejores decisiones sobre qué hacer primero Es entender cuánto dinero se pierde cuando el proyecto se retrasa.
¿Cuáles son los siete tipos de desperdicio en desarrollo de software? Trabajo parcialmente terminado, procesos extra, cambio de tareas, heroicidades, exceso de compromiso, defectos y funcionalidades adicionales Trabajo parcialmente terminado, procesos extra, funcionalidades extra, cambio de tareas, comunicación, esperas y defectos Trabajo parcialmente terminado, procesos extra, cambio de tareas, esperas, desplazamientos, defectos y funcionalidades extra Trabajo parcialmente terminado, procesos extra, cambio de tareas, planificación detallada, desplazamientos, defectos y funcionalidades extra.
¿Cuál de las siguientes frases describe MEJOR las prácticas de Kanban? Visualizar el flujo de trabajo, crear un tablero Kanban, limitar el WIP, gestionar el flujo de trabajo, establecer y comunicar claramente las políticas que dirigen el proceso, implementar retroalimentación, mejorar conjuntamente y evolucionar en base a la experiencia Planificar, hacer, comprobar, actuar Visualizar el flujo de trabajo, observar el flujo de trabajo, limitar el WIP, cambiar los procesos, medir los resultados Visualizar el flujo de trabajo, limitar el WIP, gestionar el flujo, establecer y comunicar claramente las políticas que dirigen el proceso, implementar retroalimentación, mejorar conjuntamente y evolucionar en base a la experiencia.
¿Cuál de estos NO es un principio de Lean? Eliminar el desperdicio Implementar mecanismos de retroalimentación Decidir lo más tarde posible Tener visión de conjunto.
¿Cuál de estas frases describe MEJOR para qué se utiliza un tablero Kanban? Para observar cómo las tareas pasan por el flujo de trabajo, y que los equipos puedan decidir cómo limitar el WIP y para hacer el flujo de trabajo más continuo Para hacer un seguimiento de los límites de WIP y el estado actual de las tareas, y que el equipo sepa lo que le queda por hacer Para hacer el seguimiento de los defectos y problemas y crear el modo más rápido para resolver problemas en un producto Para ayudar al equipo a organizarse y ver dónde hay cuellos de botella en su flujo de trabajo.
¿Cuál es el tiempo de ciclo y el lead time de esta funcionalidad según el siguiente mapa de flujo? Lead: 22 días. Ciclo: 30 días Lead: 30 días. Ciclo: 22 días Lead: 52 días. Ciclo: 30 días Lead: 70 días. Ciclo: 42 días.
Un equipo tiene limitado el Work In Progress y empieza a gestionar su flujo de trabajo.
¿Qué es lo siguiente que debería hacer según Kanban? Implementar mecanismos de retroalimentación Decidir y publicar las políticas de gestión del proceso Mejorar colectivamente Entregar tan rápido como sea posible.
Los miembros del equipo que trabaja en la sala junto a tu despacho están pasándolo mal para cumplir con sus compromisos. Siguen comprometiéndose a completar cada vez más trabajo en cada incremento, pero no están logrando sus objetivos. Ahora hay muchas funcionalidades en las dos primeras columnas de su tablero Kanban, y muy pocas en las últimas.
¿Cuál de estos tipos de desperdicio NO es seguramente la causa de los problemas de ese equipo? Cambio de tareas Defectos Desplazamientos Trabajo parcialmente terminado.
¿Cuál de estos principios NO es compartido por Lean y Scrum? Toma de decisiones en el último momento que no sea una irresponsabilidad Iteraciones y retroalimentación Motivación, compromiso Eliminar el desperdicio.
Cuando en una etapa de un proceso se solicita trabajo de la etapa anterior, se habla de… Teoría de colas Desperdicio Un pull system Un inventario.
¿Cuál de las siguientes NO es un ejemplo de pensamiento basado en alternativas? Un equipo desarrolla al mismo tiempo dos formas distintas para implementar una funcionalidad de alto riesgo con la que no tienen mucha experiencia Un equipo identifica objetivos que se pueden entregar pronto en un proyecto para evaluar la bondad del diseño Un equipo fija una fecha de entrega y una serie de dependencias para entregar una funcionalidad de la que no están muy seguros Un equipo pasa tiempo compartiendo conocimientos para que la mayoría puedan trabajar en todas las tareas planificadas para el Sprint.
¿Cuál de estas cosas NO valoran mucho los equipos ágiles? La colaboración con el cliente El software que funciona La respuesta a los cambios La planificación anticipada de forma precisa.
Eres un desarrollador en un equipo que produce videojuegos, y has puesto un montón de esfuerzo en desarrollar una funcionalidad clave para vuestro próximo lanzamiento. Sin embargo, cuando la prueban algunos usuarios, descubres que hace falta hacer algunos cambios importantes y arreglar algunos errores. Con todo, a los usuarios les gustó el juego y le dieron valoraciones medias, pero tú sabes que con los cambios que quieres hacer las valoraciones serían mejores. El juego se va a lanzar dentro de dos semanas, pero crees que te dará tiempo de hacer todos los cambios en el tiempo que queda.
¿Qué es lo MEJOR que puede hacer el equipo?
Rechazar los cambios y lanzar el juego con las funcionalidades como están ahora mismo Priorizar el trabajo y dejar que el equipo se organice para terminar el mayor número posible de funcionalidades para el lanzamiento. Luego, publicar parches con los arreglos y los cambios una vez que el producto está en el mercado Hacer un análisis de las razones por las que no se tuvieron en cuenta esos requisitos Retrasar el lanzamiento del juego unos meses para que todas las funcionalidades estén terminadas.
Estás en un equipo ágil que trabaja en una sala común. En los Daily Scrums, los miembros del equipo piden habitualmente revisar el estado del diagrama burn-down y el diagrama de flujo acumulado.
¿Qué es lo MEJOR que podéis hacer como equipo? Crear un irradiador de información en la sala en la que trabajáis Pedir al equipo que revisen las gráficas antes de la reunión, para no desperdiciar tiempo cada día Dejar la revisión de los diagramas para la reunión de retrospectiva Todas las anteriores.
¿Cuál de las siguientes prácticas NO centra la atención de un equipo ágil? Hacer entregas frecuentes y tempranas Simplicidad Hacer estimaciones correctas Organizarse autónomamente.
Trabajas en un equipo Scrum al que se le pide crear calendarios detallados y listas de hitos, de forma que cualquier retraso en el calendario es motivo de preocupación en las reuniones de los directivos de la empresa.
¿Qué es lo MEJOR que puedes hacer?
Asegurarte de que tu equipo prepara el plan e informa de los cambios, tal y como se le pide Enseñar a los directivos los principios ágiles, y trabajar con ellos otras maneras para informarles de vuestros progresos No cooperar con los directivos Crear la documentación que piden los directivos por tu cuenta, y no molestar al equipo para eso.
Eres el Scrum Master en un equipo de cinco personas que trabaja en la misma sala. En la última retrospectiva, un miembro del equipo comentó que quizá estéis sobrecargados con demasiadas tareas en marcha.
¿Qué es lo MEJOR que puedes hacer? Pedir al equipo que termine el trabajo planificado para cada Sprint Decir a los clientes que cualquier petición te la hagan a ti, para no sobrecargar al equipo Probar a fijar límites de Work In Progress Todas las anteriores.
Eres el Scrum Master en un equipo de cinco personas que trabaja en la misma sala. Tu equipo tiene una reunión de planificación de Sprint dentro de cuatro días.
¿Qué es lo MEJOR que puedes hacer? Nada, porque el equipo se organiza de manera autónoma, y pueden planificar sin mí Asegurarte de que cada ítem del Backlog está bien documentado, para que sea más fácil hacer estimaciones Hablar con los clientes sobre cuándo necesitan que se entregue cada ítem del Backlog, y decirle al equipo cuándo tienen que comprometerse a entregarlos Trabajar con el Product Owner para refinar el Backlog, de forma que esté listo para la reunión.
¿Cuál de estos NO es un principio ágil? Satisfacer al cliente con entregas rápidas y tempranas Comprometerse a menos y entregar más Concentrarse en la excelencia Trabajar a un ritmo sostenible.
¿Cuál es el mejor indicador de éxito en un proyecto ágil? Informes que muestran que no hay problemas críticos Un plan bien desarrollado Se entrega a los clientes software que funciona El equipo es feliz.
¿Cómo crean los equipos ágiles las mejores arquitecturas y diseños? A base de prototipos Organizándose de manera autónoma Documentando Planificando.
Para un equipo ágil, lo más importante en un producto es… La excelencia técnica del mismo La calidad La frecuencia en las entregas El valor que éste le aporta al cliente.
¿Cuál de las siguientes frases describe MEJOR el objetivo de una entrega en un proyecto ágil? Entregar lo antes posible el menor incremento que aporta valor al cliente Entregar el mayor incremento que se pueda terminar en plazo Incluir tantas peticiones del cliente como sea posible Encontrar el menor mercado posible para el producto.
¿Cuál de las siguientes es una técnica para priorizar el trabajo según el valor que aporta al cliente? Planning poker Refinamiento del Backlog Sesiones conjuntas de diseño Votación a mano alzada.
¿Cuál de las siguientes es una herramienta para centrarse en incrementos pequeños que resuelven necesidades del cliente? Análisis de Kano Historias de usuario Conceptos breves Diseño emergente.
¿Qué evento Scrum nos da retroalimentación del cliente sobre software que funciona? Planificación Refinamiento del backlog Retrospectiva del Sprint Revisión del Sprint.
Los equipos Scrum hacen demostración del software funcionando al final de cada Sprint en… La Sprint Demo La Sprint Retrospective La Sprint Review El Product Demo.
¿Cuáles son las preguntas que responde cada miembro del equipo en el Daily Scrum? ¿Qué voy a hacer hoy? ¿Qué voy a hacer mañana? ¿Qué errores he cometido? ¿Qué estoy haciendo hoy? ¿Qué voy a hacer mañana? ¿Qué problemas tengo? ¿Qué hice hoy para llegar al objetivo del Sprint? ¿Qué voy a hacer mañana? ¿Qué obstáculos me he encontrado? Ninguna de las anteriores.
¿Quién toma las decisiones en nombre de los clientes en un equipo Scrum? El Scrum Master El Product Owner Los profesionales ágiles Los miembros del equipo.
¿Cuál de las siguientes herramientas NO sirve para dar transparencia en un equipo ágil? Irradiador de información Demostraciones de funcionalidades Tableros de tareas Valor neto presente.
Eres un profesional ágil en un equipo Scrum nuevo. Como parte de los preparativos para el primer Sprint del equipo, te reúnes con algunos de los clientes del producto que vais a desarrollar para entender sus objetivos. En esa reunión, el grupo crea una lista de funcionalidades categorizada como “Deben estar”, “Podrían estar”, “Deberían estar” y “No estarán”
¿Cuál es la MEJOR forma de describir el método de priorización que están usando?
Priorización relativa Ranking apilado Análisis de Kano MoSCoW.
Estás trabajando en un equipo que usa Kanban para mejorar sus procesos. Cada día ponéis tarjetas en un tablero para visualizar cuántas funcionalidades están en cada fase del proceso. Luego, sumáis el número de funcionalidades en cada columna del tablero y creáis una gráfica que muestra esos totales a lo largo del tiempo.
¿Qué herramienta estáis usando?
Diagrama de flujo acumulado Tablero de tareas Gráfica Burn-down Gráfica Burn-up.
Los equipos ágiles se comprometen con _______ de negocio y ______ de Sprint. Saben que los planes pueden cambiar, y acogen esos cambios sin importar cuándo suceden. Al centrarse en lo que el equipo tiene que conseguir, mantienen las opciones abiertas los jefes / los plazos los objetivos / los objetivos las previsiones / los planes las demandas / las retrospectivas.
Eres un profesional ágil en un equipo Scrum nuevo. Como parte de la primera reunión de planificación, decidís fijar una serie de normas que el equipo seguirá durante el desarrollo del proyecto. Estas normas incluyen las siguientes: “El Scrum diario durará 15 minutos y empezará puntualmente cada día. Ningún miembro del equipo marcará una funcionalidad como ‘completada’ hasta que cumpla con la definición de ‘hecho’ del equipo. El equipo utilizará estándares de codificación previamente definidos y subirá el código al servidor cada día para que durante la noche se compile”
¿Cuál es la MEJOR forma de describir esta lista de normas?
Definición de “listo” Orientaciones administrativas Estatutos del equipo Acuerdos de trabajo.
Eres un profesional ágil en un equipo que desarrolla software para una agencia de publicidad. Más o menos a la mitad de vuestro primer incremento, te das cuenta de que muchas funcionalidades están “En progreso” en vuestro tablero de tareas, pero muy pocas están en la columna de “Hecho”. Al fijarte mejor, ves que los desarrolladores están empezando a trabajar en nuevas funcionalidades cada vez que están esperando una revisión o una prueba de su código.
¿Qué es lo MEJOR que puedes hacer ahora? Pedirle al equipo que ayuden a revisar el código y a hacer pruebas para así terminar tareas pendientes antes de empezar nuevas Asumir que el trabajo estará terminado al final del Sprint, porque el equipo ha avanzado en muchas tareas Incorporar más probadores al equipo, para que avancen en el trabajo pendiente Decirle a los clientes que el equipo no tendrá nada listo para enseñar al final del Sprint.
En una migración de metodología tradicional a ágil ¿cuál NO es un factor para formar los equipos? Los equipos deberían compartir ubicación si es posible Los equipos deberían ser pequeños Los equipos deberían tener un sistema para gestionar cambios de última hora Todos los demás.
Eres un profesional ágil en un equipo de cinco personas que lleva trabajados seis días de un Sprint de dos semanas. Un cliente llama a un miembro del equipo para pedir un cambio urgente.
¿Qué es lo MEJOR que puede hacer ese miembro del equipo? Dejar lo que está haciendo y hacer el cambio que pide el cliente Pedir al cliente que trabaje con el Product Owner para priorizar el cambio Aconsejar al cliente que espere a la siguiente reunión de planificación de Sprint y plantearlo entonces Recordar al cliente que priorice el cambio en el Backlog del producto.
Eres un profesional ágil en un equipo que desarrolla software para contabilidad. En una reunión de planificación de Sprint con el equipo, un probador y un desarrollador discuten sobre lo grande que es una historia de usuario. El desarrollador dice que la historia supone un pequeño cambio de código, por lo que podría hacerse inmediatamente. El probador dice que tiene impacto en muchas áreas cruciales del software, y que habría que hacer muchas pruebas para asegurarse de que funciona correctamente.
¿Qué deberías hacer? Apoyar al probador y recomendar que el equipo estime más esfuerzo para la funcionalidad Alinearte con el desarrollador y reducir las pruebas para aseguraros de que la funcionalidad se entrega a tiempo Sugerir que el equipo use planning poker para alcanzar un acuerdo sobre el tamaño de la historia en el que todos estén de acuerdo Pedir al Product Owner que dé prioridad a las pruebas, porque la funcionalidad es muy importante para los clientes.
|
