Este simulador ha sido desarrollado para practicar preguntas situacionales sobre practicas ágiles, tipo las del examen. 0% Simulador PMI ACP 1 / 114 Nos encontramos en la iteración ocho de nuestro proyecto y el practicante ágil está preocupado porque la métrica de velocidad del equipo sigue siendo baja y los interesados del proyecto esperan tener incrementos funcionales mayores en las revisiones de producto. ¿Cuál de las siguientes opciones sería la mejor opción para intentar mejorar el rendimiento del equipo? Reducir el tiempo de las iteraciones. Proteger al equipo de desarrollo de interrupciones en su trabajo. Añadir más trabajo en las iteraciones. Incrementar el tamaño del equipo. IncorrectoEl practicante ágil debe proteger al equipo de interrupciones para que este centrado en su trabajo y comprometido con él. Algunas practicas podrían ser limitar el uso en ciertas horas de herramientas como teléfono, mail, video presencia o limitar el acceso de los interesados a los miembros del equipo de desarrollo durante la iteración interactuando el propio líder ágil con ellos y resolviendo sus dudas. Incrementar el tamaño del equipo haría aumentar el presupuesto del proyecto, reducir el tiempo de las iteraciones no tiene por qué tener una relación directa con mayor rendimiento del equipo y añadir mas trabajo en la iteración no solucionaría el problema porque no serían capaces de abordar el trabajo añadido. CorrectoEl practicante ágil debe proteger al equipo de interrupciones para que este centrado en su trabajo y comprometido con él. Algunas practicas podrían ser limitar el uso en ciertas horas de herramientas como teléfono, mail, video presencia o limitar el acceso de los interesados a los miembros del equipo de desarrollo durante la iteración interactuando el propio líder ágil con ellos y resolviendo sus dudas. Incrementar el tamaño del equipo haría aumentar el presupuesto del proyecto, reducir el tiempo de las iteraciones no tiene por qué tener una relación directa con mayor rendimiento del equipo y añadir mas trabajo en la iteración no solucionaría el problema porque no serían capaces de abordar el trabajo añadido. 2 / 114 CEOLEVEL.INC esta empezando a adoptar prácticas ágiles en sus proyectos e implementa una estrategia de entrega incremental para la generación de los productos. Si se implementa de forma correcta las practicas ágiles, la mejora más importante que tendrá CEOLEVEL.INC debería ser: Tendrá más detallado el alcance del proyecto desde el arranque del mismo Mejorará el proceso de compras con proveedores que enviarán materiales según sea necesario Obtener un ROI más temprano mediante la entrega incremental del producto. Tendrá un mejor control de costes mediante pagos incrementales durante el proyecto. IncorrectoUna de las ventajas de utilizar entregas incrementales durante los proyectos es obtener un retorno de inversión más temprano en el proyecto y mejorar el time to market. CorrectoUna de las ventajas de utilizar entregas incrementales durante los proyectos es obtener un retorno de inversión más temprano en el proyecto y mejorar el time to market. 3 / 114 En CEOLEVEL.INC hace unos 3 meses que se empezó un proyecto con una planificación adaptativa e incremental. Durante el segundo mes de proyecto los miembros del equipo ágil discutían constantemente, costaba mucho tomar decisiones conjuntas y necesitaban mucha orientación del líder de su equipo. A día de hoy el equipo ha resuelto sus problemas y el líder de equipo y no está tan involucrado en el día a día porque el equipo se ha vuelto más autosuficiente. ¿Qué ha pasado en el último mes? El equipo ha pasado de la etapa de Norming a la etapa de Performing. Nada, los equipos tienen fases en las que discuten más y otras menos. El equipó ha pasado de la etapa de Storming a la etapa de Norming. El líder del equipo está dejando de hacer su trabajo, porque tendría que seguir en el día a día del equipo. IncorrectoEn la etapa de desarrollo grupal de «storming» definida por Tuckman el equipo empieza a entender cómo se toman decisiones grupales pero aún hay relaciones confusas en el equipo y existe mucha incertidumbre entre ellos que hace que el equipo aun no sea autosuficiente y cueste tomar decisiones conjuntas llevando a disputas y discusiones. Cuando el equipo evoluciona y salta a la siguiente etapa de «norming», las relaciones se entienden mejor en el equipo, hay compromiso con los objetivos y empieza el proceso de optimización para llegar a la última etapa de «performing» CorrectoEn la etapa de desarrollo grupal de «storming» definida por Tuckman el equipo empieza a entender cómo se toman decisiones grupales pero aún hay relaciones confusas en el equipo y existe mucha incertidumbre entre ellos que hace que el equipo aun no sea autosuficiente y cueste tomar decisiones conjuntas llevando a disputas y discusiones. Cuando el equipo evoluciona y salta a la siguiente etapa de «norming», las relaciones se entienden mejor en el equipo, hay compromiso con los objetivos y empieza el proceso de optimización para llegar a la última etapa de «performing» 4 / 114 En la planificación de un proyecto ágil que realizamos inicialmente y que vamos revisando, ajustando y actualizando durante todo el proyecto es establecida por: La estimación de las tareas, dependencias y duración. El calculo de puntos de historia y la velocidad. Cálculo de los paquetes y alcance del proyecto. El camino crítico. IncorrectoLos elementos más importantes en la agilidad son los puntos de la historia y la velocidad. Un punto de la historia es una unidad de medida relativa para expresar el esfuerzo estimado de la historia de usuario. La velocidad es la cantidad de ítems o historias de usuario que finaliza un equipo en una iteración. CorrectoLos elementos más importantes en la agilidad son los puntos de la historia y la velocidad. Un punto de la historia es una unidad de medida relativa para expresar el esfuerzo estimado de la historia de usuario. La velocidad es la cantidad de ítems o historias de usuario que finaliza un equipo en una iteración. 5 / 114 Como equipo ágil acabáis de finalizar la iteración 12 del proyecto, habéis generado un incremento del producto que ha sido revisado con los stakeholders y obtenido feedback de ellos. La iteración ha durado tres semanas desde que empezasteis a trabajar con las historias de usuario hasta que se generó el incremento. ¿Qué representa estas tres semanas? Tiempo de ciclo (cycle time). Lead Time (tiempo de espera). WIP (trabajo en progreso). Tiempo ideal. IncorrectoEl cycle time es el tiempo transcurrido desde que empezamos un trabajo hasta que finalizamos el trabajo. Podemos calcular el cycle time de una historia de usuario o como en este caso, el de la iteración (que es fijo). CorrectoEl cycle time es el tiempo transcurrido desde que empezamos un trabajo hasta que finalizamos el trabajo. Podemos calcular el cycle time de una historia de usuario o como en este caso, el de la iteración (que es fijo). 6 / 114 Durante la iteración dieciséis de nuestro proyecto ha habido reorganizaciones importantes y cambios grandes sobre la dirección del producto. El equipo de desarrollo siente que la iteración en curso se debería suspender o cancelar hasta que se tomen decisiones. ¿Quién sería el responsable de tomar esta decisión? El equipo de desarrollo El patrocinador El líder ágil El producto owner IncorrectoEl dueño del producto (Product Owner) es la única persona en el proyecto que puede cancelar una iteración en curso. CorrectoEl dueño del producto (Product Owner) es la única persona en el proyecto que puede cancelar una iteración en curso. 7 / 114 Durante la consecución de un proyecto ágil, el producto Owner quiere realizar una reunión de refinamiento para ajustar el product backlog ya que se han introducido nuevas historias de usuario que aún no están estimadas y quiere revisar con el equipo detalles que han cambiado de otras historias para ver si tiene afectación en las estimaciones, además quiere dividir el contenido de una épica en historias de usuario más pequeñas para poderlas tratar en posteriores iteraciones. ¿Cuándo sería el mejor momento para realizar esta reunión de refinamiento? Durante la planificación de la iteración Justo después de la planificación de la iteración En la retrospectiva del equipo, al final de la iteración En cualquier momento de la iteración IncorrectoLas reuniones de refinamiento del product backlog se deben ir realizando según se necesiten, no hay un momento establecido para llevarlas a cabo. Dependerá de la necesidad de actualización del product backlog. Podemos hacer más de una reunión de refinamiento por iteración, la única restricción que tiene es que la suma de las duraciones de las reuniones de refinamiento no puede ser mayor al 10% del tiempo total de la iteración. CorrectoLas reuniones de refinamiento del product backlog se deben ir realizando según se necesiten, no hay un momento establecido para llevarlas a cabo. Dependerá de la necesidad de actualización del product backlog. Podemos hacer más de una reunión de refinamiento por iteración, la única restricción que tiene es que la suma de las duraciones de las reuniones de refinamiento no puede ser mayor al 10% del tiempo total de la iteración. 8 / 114 Un producto owner (dueño de producto) trabaja con dos equipos ágiles, son dos proyectos de alta visibilidad/importancia dentro de la organización CEOLEVEL.INC y se ve desbordado por las peticiones de los dos equipos ágiles solicitando aclaraciones de las historias de usuario y prioridades generales dentro de sus respectivos proyectos. ¿Qué debería hacer el agile project manager? Solicitar las dudas por escrito antes de las reuniones con cada equipo, para que el producto owner tenga pueda organizarse el trabajo y no impacte negativamente. Facilitar una reunión entre producto owner y cada uno de los equipos ágiles para encontrar una solución al problema. Explicar a los miembros de los equipos que deben ser autosuficientes y que no pueden solicitar tantas aclaraciones al producto owner, que además si esta situación sigue ocurriendo se verá reflejada en sus evaluaciones de carrera. Debería liberar al producto owner de uno de los proyectos y dirigir él el otro. IncorrectoEl agile project manager, coach, scrum master, etc. que es la figura de líder de los equipos ágiles debe actuar como un facilitador, utilizando el liderazgo servicial. Él no puede y no debe tomar decisiones en nombre de todos, o resolver problemas técnicos de los miembros de los equipos, pero puede facilitar métodos para llegar a resolver los impedimentos. En este caso el desbordamiento de trabajo del prodcut owner para que lleguen a solucionar los problemas de forma conjunta y consensuada. El líder ágil es quien tiene mayor conocimiento sobre las practicas agiles, herramientas y técnicas. Debe tener dominio de las softskills para guiar, ayudar y hacer crecer a los equipos tanto a los product owners como a los miembros del equipo de desarrollo para el buen funcionamiento de los proyectos agiles. CorrectoEl agile project manager, coach, scrum master, etc. que es la figura de líder de los equipos ágiles debe actuar como un facilitador, utilizando el liderazgo servicial. Él no puede y no debe tomar decisiones en nombre de todos, o resolver problemas técnicos de los miembros de los equipos, pero puede facilitar métodos para llegar a resolver los impedimentos. En este caso el desbordamiento de trabajo del prodcut owner para que lleguen a solucionar los problemas de forma conjunta y consensuada. El líder ágil es quien tiene mayor conocimiento sobre las practicas agiles, herramientas y técnicas. Debe tener dominio de las softskills para guiar, ayudar y hacer crecer a los equipos tanto a los product owners como a los miembros del equipo de desarrollo para el buen funcionamiento de los proyectos agiles. 9 / 114 Gestionas un proyecto en el que identificas que no tienes suficiente capacidad interna en el equipo para completarlo en las fechas acordadas. Para conseguir cumplir con las fechas decides subcontratar una parte importante del proyecto y contactas con proveedores claves para lanzar una RFP y elegir uno. Durante este proceso descubres que un familiar tuyo es gerente de una de las empresas proveedoras y se pone en contacto para decirte que quiere presentar una propuesta. ¿Cómo deberías actuar ante esta situación? Ya que es una persona de confianza y familiar, darle el proyecto a él sin mencionar nada a tu empresa sobre el conflicto de intereses. Sabes que es una persona responsable, ha realizado proyectos para grandes empresas siempre con buenos resultados y crees que aportará valor al proyecto. Dado el conflicto de intereses no dejar participar a tu familiar en el proceso de selección de proveedor. Comunicar el conflicto de intereses a tu empresa y realizar la selección del proveedor basándote en criterios objetivos. Informar a tu empresa del conflicto de intereses y facilitar información a tu familiar para que presente una propuesta ganadora para llevarse el contrato. IncorrectoSiguiendo el código ético del PMI, debemos comunicar el conflicto de intereses a nuestra organización y seleccionar el proveedor basándonos en criterios objetivos y no personales. CorrectoSiguiendo el código ético del PMI, debemos comunicar el conflicto de intereses a nuestra organización y seleccionar el proveedor basándonos en criterios objetivos y no personales. 10 / 114 Nos encontramos en la iteración dieciocho de nuestro proyecto ágil y el líder ágil se encuentra analizando la métrica de velocidad del equipo durante estás iteraciones. Se encuentra preocupado porque el equipo no es capaz de estabilizar la velocidad en el proyecto, tienen bajadas y subidas, pero no llegan a ser constantes. ¿Qué significa esto? No es motivo de preocupación, porque mejorará Es motivo de preocupación ya que el equipo no es capaz de mostrar previsibilidad. No es motivo de preocupación porque no impedirá la entrega de valor al cliente. Es motivo de preocupación porque afectara al feedback del equipo. IncorrectoQue el equipo no sea capaz de estabilizar la velocidad significa que el equipo no está evolucionando en las etapas de desarrollo grupal y no es capaz de comprometerse con los objetivos marcados para las iteraciones, de esta manera será complicado alcanzar las metas del proyecto. CorrectoQue el equipo no sea capaz de estabilizar la velocidad significa que el equipo no está evolucionando en las etapas de desarrollo grupal y no es capaz de comprometerse con los objetivos marcados para las iteraciones, de esta manera será complicado alcanzar las metas del proyecto. 11 / 114 El producto Owner de un proyecto tiene la responsabilidad de guiar el producto aportando valor en todas las iteraciones, conoce el negocio y muchas veces es parte del cliente. También es propietario del product backlog y de su estado, por lo que debe priorizarlo y tenerlo actualizado durante el proyecto para que este reflejado el trabajo pendiente del equipo, para ello utilizará diferentes técnicas. ¿Cuáles de los siguientes criterios de priorización son claves en la priorización del product backlog? La estrategia de la organización y la dificultad. El tamaño de las historias de usuario y la estimación del equipo. El valor para el cliente y los riesgos. La criticidad y la estimación. IncorrectoEl valor para el cliente y los riesgos son los dos factores críticos que debe contemplar el product owner a la hora de priorizar el product baklog, también influyen después otros aspectos como: dependencias entre historias de usuario, costes, conocimiento o recursos. CorrectoEl valor para el cliente y los riesgos son los dos factores críticos que debe contemplar el product owner a la hora de priorizar el product baklog, también influyen después otros aspectos como: dependencias entre historias de usuario, costes, conocimiento o recursos. 12 / 114 Estamos trabajando en la iteración quince de nuestro proyecto que consta de 30 iteraciones. El producto owner se encuentra actualizando planificaciones para adaptar cambios y actualizar el roadmap del producto con más detalle. ¿Es esto una situación normal o el equipo ágil no ha realizado bien el trabajo y por eso ahora se tienen que hacer ajustes? No, es un indicativo de que el proyecto no está yendo bien y el producto owner junto a sponsor, cliente e interesados deben decidir si continuar o cancelar el proyecto porque el ROI del mismo no sea justificable. Sí, porque al llegar a la mitad de ejecución del proyecto es obligatorio hacer una reunión de replanificación del proyecto de 6 horas máximo donde hacemos revisión del valor entregado, trabajo pendiente y lecciones aprendidas para ajustar la mitad final del proyecto. No, el equipo no habrá finalizado las iteraciones del proyecto con el trabajo seleccionado y por eso ahora deben actualizar las entregas y planificación, porque el rendimiento ha sido más bajo de lo esperado. Sí, en los proyectos agiles normalmente cuando llegamos a la mitad del proyecto se deben realizar ajustes para adaptar las planificaciones según lo aprendido de las iteraciones anteriores, comentarios de los interesados, lecciones aprendidas, etc. para detallar las futuras entregas y sus contenidos. IncorrectoDe forma genérica se dice que llegados a la mitad en la ejecución de los proyectos agiles la norma es realizar ajustes en los productos para que esa incertidumbre que hemos ido despejando en las iteraciones anteriores basadas en la inspección y mejora continua quede reflejada en la planificación. Esto lo realizamos de forma continua durante todo el proyecto y es el propio PO quien decide la “nueva” ruta del producto basándose en su conocimiento de negocio y feedback obtenido de los interesados del proyecto. CorrectoDe forma genérica se dice que llegados a la mitad en la ejecución de los proyectos agiles la norma es realizar ajustes en los productos para que esa incertidumbre que hemos ido despejando en las iteraciones anteriores basadas en la inspección y mejora continua quede reflejada en la planificación. Esto lo realizamos de forma continua durante todo el proyecto y es el propio PO quien decide la “nueva” ruta del producto basándose en su conocimiento de negocio y feedback obtenido de los interesados del proyecto. 13 / 114 En los proyectos ágiles la comunicación/colaboración directa del cliente con el equipo es básica. ¿Cuál de las siguientes opciones es la mejor forma de compartir la información? Mediante documentación detallada. Usando herramientas visuales sencillas. Mediante reuniones de seguimiento con los interesados que agenda el dueño del producto. De acuerdo al plan de comunicaciones definido en la fase inicial del proyecto. IncorrectoLa mejor manera de informar a los interesados del proyecto es con herramientas visuales entendibles para todos y que inciten a tener una conversación para llegar a un entendimiento común. Normalmente se les llama radiadores de información. CorrectoLa mejor manera de informar a los interesados del proyecto es con herramientas visuales entendibles para todos y que inciten a tener una conversación para llegar a un entendimiento común. Normalmente se les llama radiadores de información. 14 / 114 Estamos en la primera iteración de un nuevo proyecto ágil, algunos interesados del proyecto no conocen la agilidad ni la forma de trabajar que conlleva, por lo que tú como practicante ágil del proyecto decides realizar una reunión con algunos interesados claves del proyecto para informales y hacerles un primer acercamiento a la agilidad de tal manera que se vayan familiarizando con las practicas, lo que se espera de ellos y que beneficios les aportará. Durante esta reunión uno de los interesados del proyecto te pregunta por los beneficios de hacer entregas incrementales durante el proyecto. ¿Cuál de las siguientes afirmaciones sería un beneficio de las entregas incrementales? Se reducen los costes del proyecto porque los equipos son más pequeños y multifuncionales. Se entrega valor al cliente más rápido, desde la primera iteración, porque el incremento se revisa al final de cada iteración y el estado es potencialmente entregable. Se introducen menos errores en los incrementos, ya que el código se entrega a los usuarios con mayor frecuencia. Con las entregas incrementales se pueden gestionar más clientes simultáneamente, ya que cada uno recibe regularmente una entrega. IncorrectoLa única afirmación correcta es que se entrega valor de forma más temprana, al final de cada iteración se revisa el incremento con los interesando y este incremento está en estado potencialmente entregable. Es decir, no es obligatorio hacer entregas después de cada iteración, si por ejemplo en nuestro roadmap hemos definido hacer entregas cada 3 iteraciones en la planificación de la release detallaremos que entra en esa entrega contando con la capacidad de 3 iteraciones. En la primera iteración no lanzaremos la entrega, únicamente revisaremos el incremento generado. CorrectoLa única afirmación correcta es que se entrega valor de forma más temprana, al final de cada iteración se revisa el incremento con los interesando y este incremento está en estado potencialmente entregable. Es decir, no es obligatorio hacer entregas después de cada iteración, si por ejemplo en nuestro roadmap hemos definido hacer entregas cada 3 iteraciones en la planificación de la release detallaremos que entra en esa entrega contando con la capacidad de 3 iteraciones. En la primera iteración no lanzaremos la entrega, únicamente revisaremos el incremento generado. 15 / 114 Estamos iniciando un proyecto ágil donde el product owner se encuentra elaborando la hoja de ruta de nuestro proyecto (roadmap) de seis meses de duración. El product owner conocedor del negocio sabe de la importancia de posicionar bien el producto en el mercado de forma temprana y quiere lanzar seis entregas durante nuestro proyecto. Las duraciones de las iteraciones son de dos semanas. Transmite esta información al facilitador del equipo ágil para ver si el resto del equipo se puede comprometer con los objetivos y el facilitador le contesta que no hay ningún problema. ¿Por qué responde eso el facilitador? Porque sabe que es una planificación inicial a alto nivel y esto cambiará durante el proyecto. Porque confía en el equipo. Porque el incremento generado en cada iteración debe ser potencialmente entregable. Porque las fechas de entregas las fija únicamente el product owner. IncorrectoAl final de cada iteración se genera un incremento del producto que debe ser potencialmente entregable el realizar la entrega a cliente o no, depende de las fechas que fijemos de entregas, pero si quisiéramos podríamos hacer una entrega en cada iteración del proyecto. En cada iteración se realizan las fases de análisis, diseño, implementación y test de cada tarea, por lo que el resultado es un incremento funcional que potencialmente podría ser entregado. CorrectoAl final de cada iteración se genera un incremento del producto que debe ser potencialmente entregable el realizar la entrega a cliente o no, depende de las fechas que fijemos de entregas, pero si quisiéramos podríamos hacer una entrega en cada iteración del proyecto. En cada iteración se realizan las fases de análisis, diseño, implementación y test de cada tarea, por lo que el resultado es un incremento funcional que potencialmente podría ser entregado. 16 / 114 Nos encontramos en un proyecto que tendrá tres equipos geográficamente distribuidos trabajando sobre un mismo producto. ¿Cuál sería el modelo más adecuado para crear el producto siempre que se pueda? Equipos en ubicaciones en la misma zona horaria, trabajando en los mismos sistemas mientras se aprovechan los ricos canales de comunicación. En el modelo ágil no podemos tener equipo distribuidos, han de estar en la misma ubicación. Cada equipo distribuido compuesto por un grupo de desarrollo completo que desarrolle subsistemas desacoplados del producto. Da igual como formemos los equipos, el rendimiento de los equipos no se verá afectado por las distribuciones. IncorrectoMientras menos dependencias tengamos entre el trabajo de los equipos distribuidos mejor, ya que sino dificultará mucho la producción del producto. La mejor opción siempre que el producto lo permita sería realizar subsistemas desacoplados (sin dependencias) del producto. CorrectoMientras menos dependencias tengamos entre el trabajo de los equipos distribuidos mejor, ya que sino dificultará mucho la producción del producto. La mejor opción siempre que el producto lo permita sería realizar subsistemas desacoplados (sin dependencias) del producto. 17 / 114 Como practicante ágil de un proyecto de integración de comunicaciones, debes capturar y analizar métricas de rendimiento, así como realizar pronósticos de fechas de finalización según los datos obtenidos. ¿Qué métrica es clave para poder realizar este tipo de análisis y pronósticos? MVP Todas las anteriores Velocidad Cadencia IncorrectoLa velocidad del equipo es la cantidad de puntos de historia entregados por el equipo en la última iteración y normalmente cogemos las 3, 4 o 5 últimas velocidades del equipo en las ultimas iteraciones para hacer el promedio y que sea más realista. Esta velocidad nos ayuda a saber la cantidad de trabaja que puede realizar el equipo en la iteración cuando la está planificando y ha hacer previsiones en el proyecto como fechas de finalización de todas las historias del product backlog, etc. CorrectoLa velocidad del equipo es la cantidad de puntos de historia entregados por el equipo en la última iteración y normalmente cogemos las 3, 4 o 5 últimas velocidades del equipo en las ultimas iteraciones para hacer el promedio y que sea más realista. Esta velocidad nos ayuda a saber la cantidad de trabaja que puede realizar el equipo en la iteración cuando la está planificando y ha hacer previsiones en el proyecto como fechas de finalización de todas las historias del product backlog, etc. 18 / 114 Estamos realizando un proyecto ágil y durante la revisión del producto un stakeholder nos pide incluir una nueva funcionalidad que no estaba contemplada pero que considera clave. ¿Qué herramienta debería usar el equipo ágil para recoger esta nueva funcionalidad? La historia de usuario. El acta de constitución del proyecto. La matriz de requisitos del proyecto. El product backlog. IncorrectoLas historias de usuario son una manera de representar un elemento en el product backlog. Es una o más oraciones en lenguaje cotidiano o comercial del usuario o cliente que captura lo que el usuario o cliente desea lograr. CorrectoLas historias de usuario son una manera de representar un elemento en el product backlog. Es una o más oraciones en lenguaje cotidiano o comercial del usuario o cliente que captura lo que el usuario o cliente desea lograr. 19 / 114 El acta de constitución de un proyecto ágil es un poco diferente a la de un modelo tradicional de gestión. ¿Cuál de las siguientes sentencias sería más cierta acerca de las diferencias en el acta de constitución entre ambos modelos? En un proyecto ágil no es necesario firmar un acta de constitución del proyecto. En el modelo ágil es más liviana, reconociendo la incertidumbre inicial y la respuesta al cambio. En el modelo ágil revisamos el acta de constitución en cada iteración para asegurar su cumplimiento. El modelo ágil no requiere realizar un estudio de negocio para asegurar el ROI. IncorrectoEl acta de constitución sigue siendo importante para el éxito del proyecto ágil, pero es menos detallada (más ligera) que la formada en el modelo tradicional siguiendo el valor ágil colaboración con el cliente antes que negociación de contratos. CorrectoEl acta de constitución sigue siendo importante para el éxito del proyecto ágil, pero es menos detallada (más ligera) que la formada en el modelo tradicional siguiendo el valor ágil colaboración con el cliente antes que negociación de contratos. 20 / 114 Trabajamos en un proyecto ágil donde utilizamos como herramienta visual un tablero Kanban para saber en que trabaja cada miembro del equipo y en qué punto se encuentran, el equipo al inicio se reparte todas las tareas de la cola de trabajo y las introducen en el tablero dentro de la columna “en progreso” ya que trabajan en paralelo con ellas. El practicante ágil identifica en una de las retrospectivas del proyecto que el tiempo de ciclo (cycle time) de cada tarea es muy elevado y nos está ocasionando problemas por tener que repetir trabajo que no cumple con la calidad esperada. ¿Cuál sería la primera medida que deberíamos tomar? Es normal tener tareas que se tengan que repetir por no pasar los estándares de calidad, el equipo está trabajando correctamente y no debería hacer cambios. Limitar el WIP (Work In Progress, Trabajo en progreso) de las columnas del tablero Kanban para que cada persona del equipo trabaje únicamente en una tarea y cuando la finalicen cojan otra de la cola de trabajo pendiente. Realizar más validaciones a las tareas una vez finalizadas para asegurar la calidad. Aumentar la cantidad de trabajo en paralelo de cada miembro del equipo para que, aunque algunas tareas tengan defectos, otras se finalicen correctamente y tengamos un mayor valor de entrega al cliente. IncorrectoIntroducir y respetar los limites del trabajo en progreso (WIP), cambia de sistema “push” a un sistema “pull”. Observar, limitar y entonces optimizar la cantidad de trabajo en progreso es esencial para tener éxito, como resultado se consigue mejorar el tiempo de entrega de servicio, mejora la calidad y aumenta la tasa de entrega. CorrectoIntroducir y respetar los limites del trabajo en progreso (WIP), cambia de sistema “push” a un sistema “pull”. Observar, limitar y entonces optimizar la cantidad de trabajo en progreso es esencial para tener éxito, como resultado se consigue mejorar el tiempo de entrega de servicio, mejora la calidad y aumenta la tasa de entrega. 21 / 114 Durante la planificación de la iteración, el equipo está discutiendo el diseño de una historia de usuario. Un miembro del equipo afirma que se debe iniciar un documento de diseño ya que el sistema es de naturaleza compleja. Otro miembro del equipo responde que en Agile no hay documentación. ¿Cómo debería responder el practicante ágil? Explicar que los valores ágiles priman el producto funcionando a la documentación exhaustiva, esto no quiere decir que no tengamos que documentar. Pregunte al propietario del producto si es aceptable que los miembros del equipo dediquen tiempo a la documentación. Seguir el plan de gestión del proyecto. Apoyar que en los frameworks ágiles no se debe documentar ya que prima la entrega de valor y la interacción entre las personas. IncorrectoUno de los valores ágiles hace referencia a que la mejor medida de progreso es el producto funcional frente a la documentación exhaustiva. Esto no quiere decir que no debamos documentar en el proyecto. Por lo que el equipo si tiene una característica compleja que necesite de un diseño se ha de realizar y documentar. El valor ágil hace referencia a que documentar en exceso priva de entregar valor al producto, convirtiéndose en desperdicio. Muchas veces hay documentación de proyectos que nadie sabe que se ha hecho o nunca se consulta, revisa. CorrectoUno de los valores ágiles hace referencia a que la mejor medida de progreso es el producto funcional frente a la documentación exhaustiva. Esto no quiere decir que no debamos documentar en el proyecto. Por lo que el equipo si tiene una característica compleja que necesite de un diseño se ha de realizar y documentar. El valor ágil hace referencia a que documentar en exceso priva de entregar valor al producto, convirtiéndose en desperdicio. Muchas veces hay documentación de proyectos que nadie sabe que se ha hecho o nunca se consulta, revisa. 22 / 114 Un equipo de desarrollo ágil acaba de planificar la iteración en curso, identificando las tareas técnicas para desarrollar las historias de usuario seleccionadas y de las que serán responsables durante la próxima iteración. ¿Qué herramienta será la que proporcione mejor transparencia de la progresión del equipo de desarrollo durante la iteración en curso? Retrospectiva. MoSCoW Burn down chart. Gantt chart. IncorrectoLos burn down charts (gráfico de quemado de puntos de historia) se utilizan para ver la progresión del equipo durante la iteración. El propio equipo de desarrollo actualiza el grafico cuando completa tareas para que quede reflejado y cualquier interesado del proyecto pueda ver como va la iteración en curso. Es un radiador de información (formas de hacer visible información, también llamados controles visuales). CorrectoLos burn down charts (gráfico de quemado de puntos de historia) se utilizan para ver la progresión del equipo durante la iteración. El propio equipo de desarrollo actualiza el grafico cuando completa tareas para que quede reflejado y cualquier interesado del proyecto pueda ver como va la iteración en curso. Es un radiador de información (formas de hacer visible información, también llamados controles visuales). 23 / 114 Durante los proyectos ágiles debemos hacer entrega de valor al cliente en ciclos cortos. En la planificación de las iteraciones buscamos aportar el máximo valor con la capacidad del equipo actual. ¿Cómo se llama el conjunto de funcionabilidades más pequeño que se debe realizar para que el cliente perciba valor? Minimal Viable Product (MVP) Minimal Marketable Feature (MMF) Mitigación de riesgos Tareas IncorrectoEl conjunto de funcionalidades más pequeño que se debe realizar para que el cliente perciba valor. MMF se refiere al paquete de funcionalidad que es lo suficientemente completo para ser útil para los usuarios o el mercado, pero lo suficientemente pequeño como para que no represente todo el proyecto CorrectoEl conjunto de funcionalidades más pequeño que se debe realizar para que el cliente perciba valor. MMF se refiere al paquete de funcionalidad que es lo suficientemente completo para ser útil para los usuarios o el mercado, pero lo suficientemente pequeño como para que no represente todo el proyecto 24 / 114 Tu equipo ágil está estimando historias de usuario del product backlog, el producto owner lee las historias de usuario y se pide una estimación con puntos de historia, estáis utilizando la técnica de planning poker para hacer la estimación. Cuando levantáis las cartas de estimación y no hay consenso en ellas, el Scrum Master pide de inmediato que se vuelva a estimar la historia de usuario. ¿Qué se está haciendo mal en el proceso de estimación? Las estimaciones de las historias de usuario se tendrían que hacer en días ideales. Nada, se está realizando bien el proceso de estimación con planning poker. Pedir reestimar de inmediato cuando las estimaciones no son iguales, primero hay que comentar el porqué de las diferencias en las estimaciones. Las historias de usuario es recomendable estimarlas con horas, ya que nos facilita después estimar las tareas durante en el sprint planning. IncorrectoEl equipo antes de reestimar debe discutir las diferencias en las estimaciones, porque puede ser que algunas personas del equipo hayan contemplado riesgos, dependencias, etc. que otros no, por lo tanto, antes de volver a estimar de inmediato se discute porque cada uno ha dado su valor de estimación y así entender las diferencias. De esta forma cuando volvamos a estimarla partiremos de una visión común. CorrectoEl equipo antes de reestimar debe discutir las diferencias en las estimaciones, porque puede ser que algunas personas del equipo hayan contemplado riesgos, dependencias, etc. que otros no, por lo tanto, antes de volver a estimar de inmediato se discute porque cada uno ha dado su valor de estimación y así entender las diferencias. De esta forma cuando volvamos a estimarla partiremos de una visión común. 25 / 114 Arrancamos un nuevo proyecto interno dentro de la organización, y nos disponemos a formar el equipo ágil que lo ejecutará. Unos meses atrás se realizo un proyecto bastante similar dentro de la organización y las personas que formaron el equipo de aquel proyecto están disponibles. ¿Sería buena idea volver a formar el equipo con las personas que hicieron el anterior proyecto o sería mejor formar un equipo nuevo? Sería mejor formar un equipo nuevo, porque así tendremos diferentes puntos de vista y podremos aportar mayor valor al producto. Cualquiera de las opciones sería valida, el resultado del proyecto no se verá afectado en ningún caso. Sería recomendable volver a formar el equipo que ya había trabajado junto porque tendrán una mayor sinergia. La mejor opción seria coger miembros del equipo anterior y poner personas nuevas dentro del equipo. IncorrectoIdealmente utilizar un equipo con experiencia es mejor opción, porque la colaboración en los equipos ágiles es muy importante y el equipo tarda en alcanzar etapas maduras de evolución de equipo hasta llegar al “performing” definido por Tuckman en las etapas de desarrollo grupal. Por lo que si empezamos el proyecto con un equipo que ya se conoce entre sí el rendimiento en principio ha de ser mayor desde el primer momento. CorrectoIdealmente utilizar un equipo con experiencia es mejor opción, porque la colaboración en los equipos ágiles es muy importante y el equipo tarda en alcanzar etapas maduras de evolución de equipo hasta llegar al “performing” definido por Tuckman en las etapas de desarrollo grupal. Por lo que si empezamos el proyecto con un equipo que ya se conoce entre sí el rendimiento en principio ha de ser mayor desde el primer momento. 26 / 114 Nuestra organización está haciendo una transformación cultural para poder realizar más proyectos con frameworks ágiles, ¿Los project managers del modelo tradicional que factor clave tiene que tener en cuenta para poderse adaptar y tener éxito? Dirigir el trabajo de una manera más incremental. Solo asignar tareas en las planificaciones de las iteraciones. Ceder el control y que en cada iteración un miembro del equipo haga esa función. Cambiar de una mentalidad de gestión más controladora a una mentalidad facilitadora. IncorrectoLos equipos de desarrollo ágiles son autogestionados, no necesitan tener un PM que les asigne trabajo o que les mida y controle el trabajo. Por lo que debe cambiar su mentalidad controladora a una mentalidad facilitadora, de líder servicial. CorrectoLos equipos de desarrollo ágiles son autogestionados, no necesitan tener un PM que les asigne trabajo o que les mida y controle el trabajo. Por lo que debe cambiar su mentalidad controladora a una mentalidad facilitadora, de líder servicial. 27 / 114 Eres un practicante ágil en un equipo recién creado. Como parte de la preparación para el primer sprint del equipo, te reúne con algunas de las partes interesadas del producto que vamos a crear para comprender sus objetivos. En esta reunión, el grupo crea una lista de características categorizadas como «Debe tener», «Podría tener», «Debería tener» y «No tendré». ¿Cuál es la mejor manera de describir el método de priorización que están usando? Priorización relativa Kano análisis MoSCoW Etiquetas IncorrectoEstán utilizando el método MoSCoW para la priorización. Ayuda al equipo a comprender la perspectiva empresarial de las funciones del product backlog. CorrectoEstán utilizando el método MoSCoW para la priorización. Ayuda al equipo a comprender la perspectiva empresarial de las funciones del product backlog. 28 / 114 Arrancan dos proyectos nuevos en la organización que se implementarán con frameworks agiles y la PMO considera que una persona es necesaria en ambos proyectos. Se toma la decisión de que trabaje en ambos proyectos en paralelo para poder cumplir con las fechas de entregas. En un día, de forma aproximada dedica el 50% del tiempo a cada uno de los proyectos. ¿Cuál será el principal desperdicio que se genera al tener esta persona en dos proyectos? Defectos Horas extras Trabajo parcialmente finalizado Task Switching IncorrectoSiempre que podamos debes intentar evitar tener personas asignadas a varios proyectos a la vez. Esto genera tiempos de cambios de trabajo, desconcentración, perdida de información y los estudios estimas que alrededor del 40% del trabajo de una persona puede perderse cuando tenemos esta casuística en personas del equipo. CorrectoSiempre que podamos debes intentar evitar tener personas asignadas a varios proyectos a la vez. Esto genera tiempos de cambios de trabajo, desconcentración, perdida de información y los estudios estimas que alrededor del 40% del trabajo de una persona puede perderse cuando tenemos esta casuística en personas del equipo. 29 / 114 Los enfoques ágiles se están volviendo muy populares en todas las organizaciones hoy en día. Una de sus principales ventajas frente al modelo tradicional es la flexibilidad que nos brinda para adaptarnos al cambio. ¿En que tipo de proyectos tiene especial importancia esta flexibilidad al cambio y por lo tanto son candidatos a ser realizados con marcos de trabajo ágiles? Proyectos simples. Proyectos complejos. Proyectos anárquicos Proyectos complicados. IncorrectoLos proyectos complejos son los idóneos para ser realizados con enfoques ágiles, ya que partimos de incertidumbre en el proyecto y esto nos dificulta y no nos asegura que los requerimientos que identifiquemos en un esfuerzo inicial sean los adecuados al negocio al final. Para los proyectos complejos es difícil tener un plan detallado y no vale la pena escribirlo, porque las cosas pueden cambiar de manera abrupta generando desperdicio de trabajo. La forma adecuada para guiar un proyecto complejo es la aproximación experimental, por eso las practicas ágiles se definen como empíricas, basadas en el aprendizaje de cada iteración (que están limitadas a periodos cortos y que se revisan al final con los interesados para obtener su feedback). CorrectoLos proyectos complejos son los idóneos para ser realizados con enfoques ágiles, ya que partimos de incertidumbre en el proyecto y esto nos dificulta y no nos asegura que los requerimientos que identifiquemos en un esfuerzo inicial sean los adecuados al negocio al final. Para los proyectos complejos es difícil tener un plan detallado y no vale la pena escribirlo, porque las cosas pueden cambiar de manera abrupta generando desperdicio de trabajo. La forma adecuada para guiar un proyecto complejo es la aproximación experimental, por eso las practicas ágiles se definen como empíricas, basadas en el aprendizaje de cada iteración (que están limitadas a periodos cortos y que se revisan al final con los interesados para obtener su feedback). 30 / 114 Durante la ejecución de un proyecto ágil el practicante ágil identifica que los miembros del equipo de desarrollo están realizando la reunión diaria cada día, pero que les sobra tiempo de los 15 minutos y vuelven a trabajar en el tiempo restante, de media están empleando unos 8 minutos por reunión. ¿Es correcto no emplear los 15 minutos de la reunión diaria? No, si dura menos de 15 minutos es que se está haciendo algo mal porque siempre suelen alargarse más de 15 minutos. Sí, pero deben avisar al practicante ágil de su finalización y seguir trabajando. Sí, si el equipo comenta lo necesario en la reunión y sobra tiempo, deben cerrar la reunión y seguir con su trabajo de la iteración. No, la reunión ha de durar 15 minutos siempre para asegurar la inspección dentro del equipo. IncorrectoLa reunión diaria puede durar un máximo de 15 minutos pero si el equipo acaba antes debe seguir con el trabajo de la iteración. Podemos tener un equipo de 4 personas y si no están teniendo problemas con sus tareas diarias seguramente no empleen los 15 minutos y sería desperdicio de trabajo alargarla. CorrectoLa reunión diaria puede durar un máximo de 15 minutos pero si el equipo acaba antes debe seguir con el trabajo de la iteración. Podemos tener un equipo de 4 personas y si no están teniendo problemas con sus tareas diarias seguramente no empleen los 15 minutos y sería desperdicio de trabajo alargarla. 31 / 114 El propietario de un producto es muy agresivo y tiende a obligar a los miembros del equipo a aceptar más trabajo del que pueden realizar. Esto está provocando el agotamiento del equipo. ¿Cuál es la mejor forma de resolver este problema? El líder ágil debe hablar con el propietario del producto para explicarle buenas prácticas en las planificaciones, avisarle del agotamiento del equipo y el peligro que esto supone. Se debe cambiar al propietario del producto. Se deben añadir más personas al equipo para que el trabajo se pueda repartir mejor. El equipo viendo la practica abusiva del propietario del producto debe “inflar” sus estimaciones. IncorrectoEl líder ágil debe hablar con el propietario del producto para explicarle buenas prácticas en las planificaciones, avisarle del agotamiento del equipo y el peligro que esto supone. CorrectoEl líder ágil debe hablar con el propietario del producto para explicarle buenas prácticas en las planificaciones, avisarle del agotamiento del equipo y el peligro que esto supone. 32 / 114 Tu equipo ágil acaba de empezar la reunión de revisión del producto con los stakeholders adecuados al incremento que revisamos y que el propio producto owner ha invitado. ¿Durante esta reunión de que no obtendremos recomendaciones? Sobre la idoneidad de las características. Sobre las estimaciones de las características. Sobre nuevos requerimientos identificados. Sobre la usabilidad de las características. IncorrectoLos interesados del proyecto en la revisión del producto al final de la iteración nos darán feedback del incremento generado por el equipo de desarrollo idoneidad, usabilidad y nuevas características que identifiquen a partir de lo generado, pero no darán feedback sobre las estimaciones. CorrectoLos interesados del proyecto en la revisión del producto al final de la iteración nos darán feedback del incremento generado por el equipo de desarrollo idoneidad, usabilidad y nuevas características que identifiquen a partir de lo generado, pero no darán feedback sobre las estimaciones. 33 / 114 En los proyectos ágiles necesitamos tener equipos de alto rendimiento multifuncionales que trabajen de forma colaborativa para generar los incrementos del producto funcionales durante las iteraciones y se comprometan con los objetivos de las entregas. Los equipos de alto rendimiento ágiles se caracterizan por: Está comprometido con los objetivos del proyecto y respeta la jerarquía de roles y títulos del equipo. Generan gran cantidad de valor para el cliente mediante la colaboración y evitando los conflictos. Son autoorganizados, empoderados para la toma de decisiones basada en el consenso y tienen desacuerdos constructivos. Es dueño de sus compromisos y toman todas las decisiones del proyecto. IncorrectoLos equipos de alto rendimiento agiles se caracterizan por ser autoorganizados, empoderados, toman decisiones conjuntas y tener desacuerdos constructivos. Los desacuerdos constructivos hacen referencia a que cada uno puede tener su punto de vista en las estimaciones, en cómo hacer una historia de usuario, etc. pero que de forma grupa son capaces de llegar a consenso. Muchas veces cuando existen desacuerdos y hemos de encontrar una solución se utilizan técnicas de decisión participativa (votaciones) como: Voto simple, pulgares, Jim Highsmith’s espectro de decisión o el puño de cinco. CorrectoLos equipos de alto rendimiento agiles se caracterizan por ser autoorganizados, empoderados, toman decisiones conjuntas y tener desacuerdos constructivos. Los desacuerdos constructivos hacen referencia a que cada uno puede tener su punto de vista en las estimaciones, en cómo hacer una historia de usuario, etc. pero que de forma grupa son capaces de llegar a consenso. Muchas veces cuando existen desacuerdos y hemos de encontrar una solución se utilizan técnicas de decisión participativa (votaciones) como: Voto simple, pulgares, Jim Highsmith’s espectro de decisión o el puño de cinco. 34 / 114 En un proyecto ágil grande el equipo identifica junto a su product owner un grupo de historias de usuario como prioritarias para el proyecto y el producto owner las prioriza en función de su valor para ir haciendo una entrega incremental. El equipo finalizada iteraciones entregando todas las historias de usuario que habíamos identificado como prioritarias y cuando empiezan la iteración treinta i dos del proyecto ven que las siguientes historias de usuario están priorizadas al mismo nivel y no tiene demasiado detalle, por lo que están confusos en que trabajo se ha de completar para las siguientes iteraciones. ¿Cómo reconduciríamos esta situación? Completando las historias de usuario en cualquier orden. Repriorizando el product backlog frecuentemente. Esperando a que aparezcan historias de usuario más prioritarias para el producto. Ir completando las historias de usuario más sencillas. IncorrectoEl product backlog tiene que ser repriorizado frecuentemente para asegurar la entrega de valor al cliente. En este caso podríamos hacer sesiones de refinamiento del product backlog para detallar mejor las historias de usuario con el producto owner, restimarlas y repriorizarlas en función. CorrectoEl product backlog tiene que ser repriorizado frecuentemente para asegurar la entrega de valor al cliente. En este caso podríamos hacer sesiones de refinamiento del product backlog para detallar mejor las historias de usuario con el producto owner, restimarlas y repriorizarlas en función. 35 / 114 Estamos trabajando en un proyecto ágil con el marco de trabajo de Scrum para CEOLEVEL.INC hemos realizado la planificación del sprint (iteración) y el equipo de desarrollo esta trabajando en las historias de usuario del sprint backlog. En mitad del sprint el producto owner nos pide incluir una tarea urgente y crítica dentro del sprint. ¿Cómo debería actuar el equipo de desarrollo? El equipo debe negarse ya que la planificación del sprint ya se ha realizada y una vez se fija y se forma el sprint backlog esta no se puede modificar. Además, no se tiene más capacidad para realizar la nueva tarea que propone el producto owner y se debe posponer para el siguiente sprint. El equipo de desarrollo debe negociar con el producto owner incluir la nueva tarea a cambio de quitar alguna historia de usuario de las que se habían seleccionado, de lo contrario no podrán finalizar todo el trabajo previsto. El producto owner no puede realizar cambios en el sprint backlog si no es con el consentimiento del equipo de desarrollo. El equipo de desarrollo debe dejar el trabajo que este realizando para ponerse a implementar la tarea urgente y crítica que nos ha pedido el producto owner, ya que él es el propietario del producto y el que prioriza el valor del mismo. El producto owner puede cambiar la planificación y añadir la historia de usuario si así lo cree oportuno, por lo que el equipo de desarrollo no puede intervenir en esta decisión. IncorrectoEl product owner es propietario del product backlog, allí puede cambiar prioridades, añadir o quitar historias de usuario en función de sus criterios, pero el sprint backlog que se forma después de realizar la reunión de planificación de la iteración (sprint plannig en el caso de scrum) es propiedad ya del equipo de desarrollo, por lo que el producto owner no puede hacer cambios en el si no es con el consentimiento/acuerdo del equipo de desarrollo. CorrectoEl product owner es propietario del product backlog, allí puede cambiar prioridades, añadir o quitar historias de usuario en función de sus criterios, pero el sprint backlog que se forma después de realizar la reunión de planificación de la iteración (sprint plannig en el caso de scrum) es propiedad ya del equipo de desarrollo, por lo que el producto owner no puede hacer cambios en el si no es con el consentimiento/acuerdo del equipo de desarrollo. 36 / 114 Desde hace tres iteraciones el practicante agile del proyecto identifica que están apareciendo más defectos de los habituales en las características construidas por el equipo. Tras realizar un estudio del problema llega a la conclusión de que el problema viene por la definición de las historias de usuario/requerimientos del product backlog. El producto owner no escribe las historias de usuario y sus criterios de aceptación de forma clara y no es capaz de comunicar esta información al equipo originando desperdicio al tener que repetir trabajo. ¿Qué debería hacer el practicante ágil en esta situación? Hablar con el equipo de desarrollo para que comente esta problemática en la retrospectiva de la iteración y así poder llegar a solucionar el problema con el producto owner. Hablar con el patrocinador del proyecto para tomar medidas correctivas. Hablar con el producto owner para que detalle mejor las historias de usuario, si el problema se sigue repitiendo solicitar un cambio de producto owner para que no penalice al equipo. Informar al responsable funcional del producto Owner para que hable con él y tome medidas para que esto no vuelva a ocurrir. IncorrectoEn las retrospectivas están presentes todos los miembros del equipo ágil incluido el producto owner y el practicante ágil, es el momento idóneo para lanzar problemas que hayan ocurrido durante la iteración, buscar mejoras, solución de problemas, etc. CorrectoEn las retrospectivas están presentes todos los miembros del equipo ágil incluido el producto owner y el practicante ágil, es el momento idóneo para lanzar problemas que hayan ocurrido durante la iteración, buscar mejoras, solución de problemas, etc. 37 / 114 Durante el transcurso de nuestro proyecto ágil debemos realizar prácticas/eventos para asegurar la inspección de nuestro producto, como las reuniones diarias, las planificaciones de iteración, las revisiones de producto y las retrospectivas. ¿Quién debe facilitar estas reuniones al equipo ágil? El patrocinador del proyecto Cualquier persona del equipo. El líder ágil. El Product Owner. Incorrecto El líder ágil es quien facilita los eventos, el líder ágil dependiendo del framework usado será el Scrum Master, Coach, practicante ágil, líder ágil, ágil Project manager, etc. El se encarga de facilitarla, agendarla, informar cuando se producirá y asegurarse de que se produzca. Otros detalles como quien debe acudir a la reunión dependerán de la reunión en sí, por ejemplo en la revisión del producto el producto owner es quien invita a los interesados necesarios para la revisión del incremento generado en la iteración. Correcto El líder ágil es quien facilita los eventos, el líder ágil dependiendo del framework usado será el Scrum Master, Coach, practicante ágil, líder ágil, ágil Project manager, etc. El se encarga de facilitarla, agendarla, informar cuando se producirá y asegurarse de que se produzca. Otros detalles como quien debe acudir a la reunión dependerán de la reunión en sí, por ejemplo en la revisión del producto el producto owner es quien invita a los interesados necesarios para la revisión del incremento generado en la iteración. 38 / 114 Los proyectos agiles son característicos por la colaboración que se necesita entre el propio equipo y el cliente. ¿Cuál de las siguientes sería una característica clave que ha de tener un buen líder servicial (servant leader)? Gestión del rendimiento. Escucha activa. Gestión de tareas. Liderazgo de mando. IncorrectoLa escucha activa es una de las softskills requeridas para un buen líder servicial. CorrectoLa escucha activa es una de las softskills requeridas para un buen líder servicial. 39 / 114 Nuestra empresa CEOLEVEL.INC inicia un proyecto ágil, hemos realizado un estudio de negocio para asegurar el ROI del proyecto, tenemos la visión del producto y se ha firmado el acta de constitución. Estamos seleccionando a las personas que formaran el equipo de desarrollo y surge la duda de si es mejor hacer un equipo pequeño o un equipo con muchos miembros para tener más capacidad de trabajo. ¿Cuál sería la premisa que debemos tener en cuenta? Las practicas ágiles recomiendan usar equipos grandes. Depende la urgencia del proyecto. Es indiferente. Las practicas ágiles recomiendan utilizar equipos pequeños. IncorrectoEn las practicas ágiles tener equipos muy grandes dificulta su gestión, cuantas más personas hay en el equipo, más limitaciones de espacio, rutas de comunicación, proximidad tendremos y requieren una mayor coordinación, que dificultará su colaboración diaria. Erróneamente en la practicas ágiles a veces se piensa que mientras tengamos un equipo más grande es mejor, pero estudios demuestran que muchas veces es contraproducente porque el esfuerzo que ganamos de las personas lo perdemos en los factores anteriormente mencionados. Por lo que por ejemplo en scrum nos dicen que los equipos deben ser de entre 3 a 9 personas +/-2 (que son el Scrum master y el Product Owner). Tanto scrum master como product owner pueden contabilizar como miembros del equipo de desarrollo si además del dicho rol también colaboran técnicamente en el proyecto.Además, si tenemos un equipo grande por ejemplo de 20 personas excederíamos muchas veces la norma de 15 minutos máximo en la reunión diaria y estaríamos “rompiendo” las normas.Si necesitamos tener más personas en el proyecto lo que debemos crear son más equipo, pero no un equipo muy grande. Y cuando tengamos muchos equipos seguramente necesitemos usar un escalado de agilidad para su correcta gestión/coordinación como (SAFe, Nexus, LeSS, etc.) CorrectoEn las practicas ágiles tener equipos muy grandes dificulta su gestión, cuantas más personas hay en el equipo, más limitaciones de espacio, rutas de comunicación, proximidad tendremos y requieren una mayor coordinación, que dificultará su colaboración diaria. Erróneamente en la practicas ágiles a veces se piensa que mientras tengamos un equipo más grande es mejor, pero estudios demuestran que muchas veces es contraproducente porque el esfuerzo que ganamos de las personas lo perdemos en los factores anteriormente mencionados. Por lo que por ejemplo en scrum nos dicen que los equipos deben ser de entre 3 a 9 personas +/-2 (que son el Scrum master y el Product Owner). Tanto scrum master como product owner pueden contabilizar como miembros del equipo de desarrollo si además del dicho rol también colaboran técnicamente en el proyecto.Además, si tenemos un equipo grande por ejemplo de 20 personas excederíamos muchas veces la norma de 15 minutos máximo en la reunión diaria y estaríamos “rompiendo” las normas.Si necesitamos tener más personas en el proyecto lo que debemos crear son más equipo, pero no un equipo muy grande. Y cuando tengamos muchos equipos seguramente necesitemos usar un escalado de agilidad para su correcta gestión/coordinación como (SAFe, Nexus, LeSS, etc.) 40 / 114 En los proyectos agiles a veces nos encontramos resistencia al cambio por parte de interesados del proyecto que no entienden el funcionamiento del framework y que ven que tienen que acudir a reuniones de revisión del producto más frecuentemente. ¿Cuál de los siguientes beneficios es la mejor manera de conseguir la implicación de estos interesados? Eliminar el proceso de gestión del cambio, sin tener que abrir peticiones de cambio y que tengan que pasar por el CCB. Transparencia en el proyecto y menos dependencias de informes formales. Poder introducir cambios en mitad de las iteraciones para ver los resultados al final de la misma, aumentando la capacidad de cumplir con los objetivos del proyecto. La entrega temprana y continua de incrementos de trabajo funcionales, proporcionando visibilidad del progreso y la posibilidad de realizar cambios más frecuentes. IncorrectoEn los proyectos agiles es de vital importancia la implicación del cliente/interesados del proyecto para obtener feedback de los incrementos y obtener buenos resultados. El principal beneficio que perciben es que en iteraciones cortas tienen un incremento del producto funcional sobre el cual pueden validar el funcionamiento, sugerir mejoras, nuevas funcionalidades y siguientes pasos para ajustarlo a sus necesidades de negocio. Por lo que si hacemos una buena gestión de los interesados en nuestro proyecto será muy beneficioso para ellos, verán el valor que les aporta la agilidad y conseguiremos una rápida implicación y satisfacción de los mismos. Además, esta colaboración ayuda al equipo ágil a despejar la incertidumbre del producto e ir redefiniendo la hoja de ruta según las necesidades identificadas. CorrectoEn los proyectos agiles es de vital importancia la implicación del cliente/interesados del proyecto para obtener feedback de los incrementos y obtener buenos resultados. El principal beneficio que perciben es que en iteraciones cortas tienen un incremento del producto funcional sobre el cual pueden validar el funcionamiento, sugerir mejoras, nuevas funcionalidades y siguientes pasos para ajustarlo a sus necesidades de negocio. Por lo que si hacemos una buena gestión de los interesados en nuestro proyecto será muy beneficioso para ellos, verán el valor que les aporta la agilidad y conseguiremos una rápida implicación y satisfacción de los mismos. Además, esta colaboración ayuda al equipo ágil a despejar la incertidumbre del producto e ir redefiniendo la hoja de ruta según las necesidades identificadas. 41 / 114 Empiezas un proyecto en una organización como practicante ágil y te presentan a tu equipo. Eres el líder (coach, scrum master) y transcurrido 1 mes del proyecto ya empiezas a conocer un poco a los miembros de tu equipo, identificar sus objetivos individuales y motivaciones personales. ¿Cuál debería ser tu actitud frente a esto? Ignorar los objetivos individuales y motivaciones personales de los miembros del equipo, ya que hemos de colaborar como un grupo y eso nos alejaría de nuestros objetivos. Cultivarlos, los objetivos individuales y las motivaciones personales son claves para el éxito de una persona. Comprenderlos, tratar de alinear los objetivos individuales y motivaciones de cada miembro con los objetivos del proyecto para que los miembros del equipo se realicen y crezcan personal y profesionalmente. Utilizarlos como arma de negociación con los miembros del equipo. Persuadiéndolos para que eleven su rendimiento. IncorrectoLa motivación de las personas/equipos, va más allá de un salario. Por lo que un buen líder ágil ha de intentar alinear los objetivos personales con los del equipo y proyecto. La productividad del equipo tiene relación con la motivación del mismo y debemos intentar tener un equipo apasionado, comprometido y no resistente al cambio.Para ello una buena practica es alinear los objetivos personales con los de proyecto e involucrar al responsable de carrera, functional manager de la persona para que estos objetivos sean medidos según los valores ágiles, no es lo mismo trabajar en un equipo tradicional a un equipo ágil. Por ejemplo, en un modelo tradicional se presupone que una persona con cierto nivel ha de empezar a dirigir personas o equipos mientras que en un modelo ágil nadie esta por encima de los demás, son más horizontales, por lo que los objetivos de carrera también tienen que ser revisados y ajustados. CorrectoLa motivación de las personas/equipos, va más allá de un salario. Por lo que un buen líder ágil ha de intentar alinear los objetivos personales con los del equipo y proyecto. La productividad del equipo tiene relación con la motivación del mismo y debemos intentar tener un equipo apasionado, comprometido y no resistente al cambio.Para ello una buena practica es alinear los objetivos personales con los de proyecto e involucrar al responsable de carrera, functional manager de la persona para que estos objetivos sean medidos según los valores ágiles, no es lo mismo trabajar en un equipo tradicional a un equipo ágil. Por ejemplo, en un modelo tradicional se presupone que una persona con cierto nivel ha de empezar a dirigir personas o equipos mientras que en un modelo ágil nadie esta por encima de los demás, son más horizontales, por lo que los objetivos de carrera también tienen que ser revisados y ajustados. 42 / 114 Nos encontramos en la reunión de planificación de la iteración siete de nuestro proyecto. El equipo ágil está seleccionando las historias de usuario del product backlog (priorizado por valor, A aporta más valor que B, C y D) que realizará durante esta iteración. Teniendo en cuenta que la media de velocidad del equipo es de 8 puntos de historia y que las historias de usuario no tienen dependencias entre sí. ¿Qué historias de usuario serían las más adecuadas para realizar en esta iteración?Historia de Usuario A – 3 Puntos de historiaHistoria de Usuario B – 2 Puntos de historiaHistoria de Usuario C – 5 Puntos de historiaHistoria de Usuario D – 3 Puntos de historia Seleccionamos las historias de usuario A, C y D Seleccionamos las historias de usuario A, B y C Seleccionamos las historias de usuario A, B y D Seleccionamos las historias de usuario B, C y D IncorrectoLa velocidad del equipo nos indica la capacidad máxima que podemos coger para la planificación del sprint en base al trabajo realizado en pasadas iteraciones del proyecto, en este caso no podemos exceder los 8 puntos de historia, por lo que cogeremos las historias de usuario de arriba abajo (de más valor a menos) hasta completar estos 8 puntos de historia de capacidad de equipo. CorrectoLa velocidad del equipo nos indica la capacidad máxima que podemos coger para la planificación del sprint en base al trabajo realizado en pasadas iteraciones del proyecto, en este caso no podemos exceder los 8 puntos de historia, por lo que cogeremos las historias de usuario de arriba abajo (de más valor a menos) hasta completar estos 8 puntos de historia de capacidad de equipo. 43 / 114 En los proyectos ágiles, la velocidad del equipo, el gráfico de quemado de historias de usuario (burn down chart), la lista de impedimentos además de otros suelen ser comunicados mediante: Son únicamente internos para el equipo. Reuniones periódicas con los interesados del proyecto. Informes de estado enviados periódicamente vía mail a los interesados. Radiadores de información. IncorrectoUn radiador de información es cualquier artefacto que transmita información del equipo o del proyecto, y que se encuentra visible tanto para el equipo como para la organización. Normalmente los radiadores de información suelen estar en la ubicación de trabajo del propio equipo de desarrollo. Se suelen utilizar para:características entregadas vs características por entregarQuien trabaja en quéLas características seleccionadas para la iteraciónMetricas de Velocity y de defectosRecomendaciones de las retrospectivasRegistros de riesgo, etc. CorrectoUn radiador de información es cualquier artefacto que transmita información del equipo o del proyecto, y que se encuentra visible tanto para el equipo como para la organización. Normalmente los radiadores de información suelen estar en la ubicación de trabajo del propio equipo de desarrollo. Se suelen utilizar para:características entregadas vs características por entregarQuien trabaja en quéLas características seleccionadas para la iteraciónMetricas de Velocity y de defectosRecomendaciones de las retrospectivasRegistros de riesgo, etc. 44 / 114 Según los valores ágiles firmados en el manifiesto ágil, ¿Cuál de las siguientes opciones describe mejor una de las creencias fundamentales? Los equipos especializados obtienen mejores resultados en los proyectos. Las mejores lecciones aprendidas las encontramos al final del proyecto. Los proyectos ágiles se pueden medir fácilmente revisando el incremento generado y comparándolo a la planificación inicial del proyecto. La mejor medida de progreso es el estado del producto actual. IncorrectoUno de los valores ágiles hace referencia a que es más importante tener un producto funcional que una documentación exhaustiva, no quiere decir que no tengamos que realizar documentación en el proyecto, pero sí, que la mejor medida mejor que ningún reporte, grafico, etc. es ver el producto funcionando. CorrectoUno de los valores ágiles hace referencia a que es más importante tener un producto funcional que una documentación exhaustiva, no quiere decir que no tengamos que realizar documentación en el proyecto, pero sí, que la mejor medida mejor que ningún reporte, grafico, etc. es ver el producto funcionando. 45 / 114 El equipo de desarrollo trabaja en la planificación de la iteración 4 del proyecto. Se han seleccionado las historias de usuario de acuerdo a las priorizaciones del product owner y se han descompuesto en tareas técnicas para implementar por el equipo. ¿Quién asigna estas tareas a los miembros del equipo de desarrollo? El manager. El product owner. El líder ágil. El mismo equipo de desarrollo. IncorrectoEl equipo de desarrollo es autogestionado, por lo que ellos mismos seleccionaran las tareas que realizará cada miembro. Los miembros del equipo son voluntarios (eligen entre ellos) para hacerse cargo de la tarea. Aunque cada miembro seleccione sus tareas, la responsabilidad del resultado de la iteración es compartida. No porque un miembro se quede atascado con una tarea durante la iteración y no la complete al final de la misma será culpa suya. Para eso esta la reunión diaria, para que el equipo comparta el estado de su trabajo y se identifiquen impedimentos. Si esto ocurre, por ejemplo, una persona del equipo una vez finalizada su tarea y antes de coger la siguiente ayudará a la persona con problemas en su tarea (identificado en la reunión diaria) para desatascarla y después cogerá otra nueva. Los objetivos de las iteraciones son compartidos por los miembros del equipo ágil y funcionan como un grupo, no de manera individual, por lo que la responsabilidad es compartida. CorrectoEl equipo de desarrollo es autogestionado, por lo que ellos mismos seleccionaran las tareas que realizará cada miembro. Los miembros del equipo son voluntarios (eligen entre ellos) para hacerse cargo de la tarea. Aunque cada miembro seleccione sus tareas, la responsabilidad del resultado de la iteración es compartida. No porque un miembro se quede atascado con una tarea durante la iteración y no la complete al final de la misma será culpa suya. Para eso esta la reunión diaria, para que el equipo comparta el estado de su trabajo y se identifiquen impedimentos. Si esto ocurre, por ejemplo, una persona del equipo una vez finalizada su tarea y antes de coger la siguiente ayudará a la persona con problemas en su tarea (identificado en la reunión diaria) para desatascarla y después cogerá otra nueva. Los objetivos de las iteraciones son compartidos por los miembros del equipo ágil y funcionan como un grupo, no de manera individual, por lo que la responsabilidad es compartida. 46 / 114 En la iteración que estamos realizando dentro del proyecto hay una tarea a implementar que implica realizar un cambio en producción el sábado a la una de la mañana. Ningún miembro del equipo de desarrollo se presta voluntario para realizarla. ¿Cómo deberíamos solucionar esta situación? El líder ágil debe asignarle la tarea a una persona del equipo ya que ninguno quiere realizarla. El equipo de desarrollo debe decir quien la realizará. Se debe asignar a la persona con más experiencia dentro del equipo. El dueño del producto debe decidir quién realizará la tarea. IncorrectoEl equipo de desarrollo debe tomar la decisión, ya que son autogestionados. Deben ser capaces de tomar decisiones conjuntamente. CorrectoEl equipo de desarrollo debe tomar la decisión, ya que son autogestionados. Deben ser capaces de tomar decisiones conjuntamente. 47 / 114 El product owner de nuestro proyecto quiere acudir a las reuniones diarias del equipo para estar informado del progreso de la iteración y de los impedimentos que el equipo de desarrollo vaya identificando durante la misma. ¿Cómo debería actuar el practicante ágil del proyecto? Dejar decidir al equipo si quieren que esté presente el product owner o no. Invitarlo a la reunión diaria para que atienda y participe en ella. Decirle al producto owner que en la reunión diaria solo puede estar el equipo de desarrollo. Invitarlo a la reunión, pero únicamente de oyente, no puede participar en ella. IncorrectoEl producto owner del proyecto puede acudir a la reunión diaria, pero no puede participar en ella ya que sino podemos correr el riesgo de exceder los 15 minutos de reunión. Solo puede acudir de oyente, igual que el practicante ágil, los únicos que pueden participar (hablar) en la reunión son los miembros del equipo de desarrollo. CorrectoEl producto owner del proyecto puede acudir a la reunión diaria, pero no puede participar en ella ya que sino podemos correr el riesgo de exceder los 15 minutos de reunión. Solo puede acudir de oyente, igual que el practicante ágil, los únicos que pueden participar (hablar) en la reunión son los miembros del equipo de desarrollo. 48 / 114 Empezamos un proyecto utilizando un marco de trabajo (framework) ágil y el dueño del producto (producto owner) genera un roadmap (hoja de ruta) con fechas de entregas, hitos y características que componen estas entregas. Las primeras entregas tienen bastante detalle, pero las entregas finales solo son fechas con características a alto nivel sin detalle. El cliente le pide explicaciones al PO (Product Ownwe, dueño del producto) porque quiere saber que se va entregar con detalle en cada punto del proyecto. ¿Cómo deberíamos responder? Realizaremos la planificación en detalle en la primera (y segunda si fuera necesario) iteración del proyecto, donde se realizarán talleres, reuniones con interesados, toma de requisitos y análisis para acotar el alcance del proyecto y donde fijaremos los detalles de las entregas, hitos y contenidos de las mismas. En los proyectos agiles que parten con incertidumbre y donde el cambio es bienvenido, la planificación es adaptativa a los resultados de las iteraciones, por lo que es importante detallar lo cercano y conocido pero es desperdicio planificar al detalle características lejanas e inciertas, que iremos detallando con las revisiones de producto, su feedback, lecciones aprendidas y acomodando cambios para satisfacer las necesidades reales de negocio según nos acerquemos ya que harán cambiar las planificaciones iniciales. En la primera iteración desglosaremos la WBS con sus WP y el diccionario de la WBS, para poder después hacer una planificación por oleadas (Rolling wave plannig). En los proyectos ágiles no se realizan planificaciones. Se trabaja en el presente con lo que descubrimos en cada iteración. IncorrectoBajar en detalle las planificaciones de todo el proyecto en un entorno complejo donde partimos de incertidumbre requeriría hacer una primera secuencia de inicialización como en el modelo tradicional con el componente que nos llevaría más tiempo despejar la incertidumbre y muchas veces no podríamos hacerlo, teniendo que hacer estimaciones imprecisas contar con grandes reservas de contingencia (inaceptables) y dar una falsa sensación de detalle que en ese punto inicial no se puede tener. Por eso los proyectos agiles que parten con incertidumbre planifican en detalle lo conocido y crítico del proyecto, pero dejan a alto nivel lo desconocido/lejano, que iremos despejando, planificando y detallando a medida que avancemos y conozcamos más. De ahí la importancia de tener una inspección continua, con las reuniones diarias, las revisiones del producto y retrospectivas en ciclos cortos (iteraciones) para tener control sobre el proyecto donde el alcance no está del todo cerrado e identificar problemas/desperdicio de la forma más temprana posible para no afectar al valor generado, presupuesto del proyecto y hacer rework. De esta forma colaborativa entre cliente y equipo se construyen las características realmente necesarias para el producto, porque muchas veces en estos proyectos complejos lo que inicialmente define negocio no es necesariamente correspondido con las necesidades reales de usuarios/mercado. CorrectoBajar en detalle las planificaciones de todo el proyecto en un entorno complejo donde partimos de incertidumbre requeriría hacer una primera secuencia de inicialización como en el modelo tradicional con el componente que nos llevaría más tiempo despejar la incertidumbre y muchas veces no podríamos hacerlo, teniendo que hacer estimaciones imprecisas contar con grandes reservas de contingencia (inaceptables) y dar una falsa sensación de detalle que en ese punto inicial no se puede tener. Por eso los proyectos agiles que parten con incertidumbre planifican en detalle lo conocido y crítico del proyecto, pero dejan a alto nivel lo desconocido/lejano, que iremos despejando, planificando y detallando a medida que avancemos y conozcamos más. De ahí la importancia de tener una inspección continua, con las reuniones diarias, las revisiones del producto y retrospectivas en ciclos cortos (iteraciones) para tener control sobre el proyecto donde el alcance no está del todo cerrado e identificar problemas/desperdicio de la forma más temprana posible para no afectar al valor generado, presupuesto del proyecto y hacer rework. De esta forma colaborativa entre cliente y equipo se construyen las características realmente necesarias para el producto, porque muchas veces en estos proyectos complejos lo que inicialmente define negocio no es necesariamente correspondido con las necesidades reales de usuarios/mercado. 49 / 114 Tu empresa CEOLEVEL.inc empieza el primer proyecto ágil dentro de la organización, se realiza una reunión de inicio donde parte del equipo de dirección está presente y donde tú como practicante ágil estas explicando la relación entre el cliente y el equipo de desarrollo, las responsabilidades de cada uno de ellos y lo que se espera durante el proyecto en función de sus roles específicos para el buen funcionamiento del proyecto. ¿Cuál de las siguientes afirmaciones sería la más correcta? El cliente define como se realizará el trabajo. El product owner ayudado con el feedback del cliente define el valor y verifican la experiencia del usuario. El development team prioriza el trabajo en función del valor y lo organiza en iteraciones para entregarlo de forma temprana. El cliente define los criterios de aceptación y la estimación del trabajo. IncorrectoEl producto owner es la figura conocedora del negocio y quien guía la entrega de valor al cliente, para ello utilizará técnicas de priorización del product backlog en las que incluirá a los interesados del proyecto para obtener feedback de las características claves del proyecto y poder priorizar correctamente el trabajo. También verificarán la experiencia de usuario una vez implementadas las características en el proyecto. CorrectoEl producto owner es la figura conocedora del negocio y quien guía la entrega de valor al cliente, para ello utilizará técnicas de priorización del product backlog en las que incluirá a los interesados del proyecto para obtener feedback de las características claves del proyecto y poder priorizar correctamente el trabajo. También verificarán la experiencia de usuario una vez implementadas las características en el proyecto. 50 / 114 Nos encontramos en la iteración doce de nuestro proyecto, el equipo ágil se encuentra cohesionado y en una etapa madura de su desarrollo grupal. Otro agile project manager de la organización nos pregunta si podríamos hacer un cambio de personas en el equipo porque necesitaría una persona con conocimientos avanzados de bases de datos que no tiene en su equipo y sabiendo que en tu proyecto no necesitas de habilidades tan expertas te propone cambiar esa persona por una de su equipo. ¿Es recomendable realizar cambios de personas en el equipo durante un proyecto ágil? Es indiferente. Depende de las circunstancias del proyecto, en este caso como no necesitamos una persona con habilidades tan expertas en base de datos para nuestro proyecto no habría problema en realizar el cambio. Como regla general, no hay que mover a las personas entre equipos/proyectos. Siempre que se tengan las habilidades necesarias para poder construir el producto no afectaría al rendimiento del equipo. IncorrectoComo regla general y buena práctica no deberíamos mover personas entre equipos/proyectos porque esto haría retroceder al equipo en las etapas de desarrollo grupas, dificultando la toma de decisiones conjunta, las relaciones entre ellas, etc. Esto puede y normalmente afecta de manera negativa cuando el equipo ya se encuentra cohesionado es autosuficiente y se cambia un miembro o se introduce alguno nuevo. CorrectoComo regla general y buena práctica no deberíamos mover personas entre equipos/proyectos porque esto haría retroceder al equipo en las etapas de desarrollo grupas, dificultando la toma de decisiones conjunta, las relaciones entre ellas, etc. Esto puede y normalmente afecta de manera negativa cuando el equipo ya se encuentra cohesionado es autosuficiente y se cambia un miembro o se introduce alguno nuevo. 51 / 114 CEOLEVEL.INC está realizando un proyecto interno de transformación digital, se ha formado un equipo ágil para la implementación del mismo compuesto por siete miembros y están en la octava iteración del proyecto que está previsto acabar en seis meses. En las últimas iteraciones como practicante ágil has identificado que dos miembros del equipo están teniendo disputas y están creando mal ambiente dentro el equipo, creándose bandos dentro del mismo y a veces llegando a faltarse al respeto. Esto está afectando al rendimiento del equipo y viendo que en las dos últimas iteraciones ha bajado la velocidad del equipo significativamente, ya que no trabajan como un grupo unido. ¿Cómo deberías actuar ante una situación así? Escalar el problema a los responsables de carrera de los miembros para que quede constancia en la revisión anual. Reunir a las personas afectadas en una sala y mediar hasta que lleguen a solucionar el problema y vuelvan a trabajar como un equipo unido. Sacar del proyecto a uno de los miembros en conflicto para asegurar la consecución de los objetivos y mejorar de nuevo el rendimiento del equipo. Exponer en la retrospectiva con el equipo ágil la bajada de velocidad en las últimas iteraciones y analizar las causas para que ellos mismo encuentren una solución al problema. IncorrectoEl practicante ágil debe facilitar al equipo información, para que el propio equipo se consciente, analice y tome decisiones al respecto. El practicante ágil no debe tomar las decisiones por el equipo, simplemente exponer las situaciones identificadas para que el equipo autorganizado y autogestionado sea capaz de resolver los conflictos por si mismo y crezca en su desarrollo grupal. CorrectoEl practicante ágil debe facilitar al equipo información, para que el propio equipo se consciente, analice y tome decisiones al respecto. El practicante ágil no debe tomar las decisiones por el equipo, simplemente exponer las situaciones identificadas para que el equipo autorganizado y autogestionado sea capaz de resolver los conflictos por si mismo y crezca en su desarrollo grupal. 52 / 114 Durante el transcurso de un proyecto ágil hay un cambio de patrocinador por parte del cliente. El nuevo patrocinador nunca ha trabajado con frameworks agiles y está constantemente pidiendo al equipo de desarrollo detalles del proyecto y métricas de estado. Tú eres el Scrum Master del proyecto y el equipo viene a quejarse del compartimiento del patrocinador porque les está retrasando en su trabajo y ven peligrar el objetivo del sprint en curso. ¿Como actuarias ante esta situación? Hablar con el Product Owner del proyecto para que él se encargue del trato directo con el patrocinador y descargar al equipo de trabajo extra. Decirle al equipo que el patrocinador está en su derecho de pedirles detalle del proyecto ya que es quien lo financia y que le han de proporcionar la información que les pida. Llegar a un acuerdo con el equipo para que sea solo una persona del equipo quien interactúe con el patrocinador y así poder liberar al resto de personas. Hablar con el patrocinador para decirle que te trasmita todas las dudas únicamente a ti (Scrum Master) y que tú le darás respuesta. IncorrectoEl líder ágil debe proteger al equipo de interrupciones para que este centrado en completar su trabajo en las iteraciones, actuando como un líder servicial. CorrectoEl líder ágil debe proteger al equipo de interrupciones para que este centrado en completar su trabajo en las iteraciones, actuando como un líder servicial. 53 / 114 CEOLEVEL.INC está realizando un proyecto ágil con Scrum. El equipo está cumpliendo satisfactoriamente con las planificaciones de los sprints, el resultado el proyecto hasta el momento es bueno y el cliente e interesados del proyecto están muy satisfechos con las entregas. En el sprint 14 del proyecto el equipo ha planificado entregar veintidós puntos de historia siguiendo su predicción de velocidad obtenida de los anteriores sprints, estos veintidós puntos de historia provienen de 6 historias de usuario que se han seleccionado en la planificación del sprint y se han dividido en cincuenta y dos tareas que forman el sprint blacklog y que debe desarrollar el equipo de desarrollo. Al llegar al final del sprint solo se han podido finalizar treinta y cuatro tareas que son cuatro historias de usuario de las seis seleccionadas, la quinta historia de usuario esta sin testear y la sexta aún no se ha empezado. ¿Qué deberíamos hacer? Presentar a los interesados (stakeholders) las cuatro historias de usuario finalizadas en la reunión de revisión del sprint y devolver la quinta y sexta historia de usuario al product backlog para replanificarlas. Viendo que el equipo no iba a llegar a realizar todas las historias de usuario al fin del sprint el Product Owner debería haber cancelado el sprint previamente. Presentar a los interesados (stakeholders) las cinco historias de usuario que se han hecho, en la reunión de revisión del sprint, aunque la quinta no esté testeada y devolver la sexta historia de usuario al product backlog para replanificarla. Pedir al dueño del producto (producto owner) alargar la iteración para poder acabar el trabajo y así presentar finalizadas todas las historias de usuario en la revisión del sprint. IncorrectoSolo podemos presentar a los stakeholders el trabajo completado, si no ha sido testeado no está completado por lo que no lo podemos mostrar en la revisión del producto. Deberíamos presentar las 4 historias de usuario finalizadas y testeadas que han pasado los criterios de aceptación y devolver al product backlog las historias no finalizadas para replanificarlas. Nunca se puede alargar la duración de un sprint y solo se puede cancelar un sprint en el caso de que el objetivo del sprint ya no tenga sentido, se haya quedado obsoleto y no vaya a formar parte del producto final para evitar desperdicio de tiempo, en ningún otro caso se puede cancelar. CorrectoSolo podemos presentar a los stakeholders el trabajo completado, si no ha sido testeado no está completado por lo que no lo podemos mostrar en la revisión del producto. Deberíamos presentar las 4 historias de usuario finalizadas y testeadas que han pasado los criterios de aceptación y devolver al product backlog las historias no finalizadas para replanificarlas. Nunca se puede alargar la duración de un sprint y solo se puede cancelar un sprint en el caso de que el objetivo del sprint ya no tenga sentido, se haya quedado obsoleto y no vaya a formar parte del producto final para evitar desperdicio de tiempo, en ningún otro caso se puede cancelar. 54 / 114 Empezamos un nuevo proyecto ágil y nos encontramos haciendo la reunión de planificación de la iteración. Al ser la primera iteración del proyecto no disponemos de la métrica de velocidad que es resultado de la suma de puntos de historia finalizados en una iteración. ¿Cómo deberíamos calcular la velocidad del equipo en esta primera iteración? Utilizar un flujo de trabajo Kanban para identificar pasos y calcular la velocidad inicial. La decide el producto owner del equipo inicialmente ya que no podemos obtenerla de otra manera. Usar la velocidad que se obtuvo en proyectos similares pasados o hace una suposición calculada. Involucrar a interesados del proyecto para ver sus expectativas de la primera iteración y ajustar la velocidad a ello. IncorrectoLa velocidad es una medida de la tasa de progreso de un equipo utilizada para estimar compromisos / capacidad futuros.Es el promedio de puntos entregados por el equipo en la última iteración. Y se utiliza para ayudar al equipo a decidir cuántos puntos se comprometerá a entregar en la próxima iteraciónNormalmente se utiliza la media de las ultimas 3,4 o 5 velocidades del equipo para que sea más realista, ya que en una iteración en concreto podemos haber tenido algún problema que desvirtúe el valor general de la misma.Ya que no disponemos de este dato en la primera iteración del proyecto deberemos basarnos es la velocidad obtenida en proyectos similares ejecutados en el pasado o hacer una suposición basada en la experiencia del equipo y capacidad. CorrectoLa velocidad es una medida de la tasa de progreso de un equipo utilizada para estimar compromisos / capacidad futuros.Es el promedio de puntos entregados por el equipo en la última iteración. Y se utiliza para ayudar al equipo a decidir cuántos puntos se comprometerá a entregar en la próxima iteraciónNormalmente se utiliza la media de las ultimas 3,4 o 5 velocidades del equipo para que sea más realista, ya que en una iteración en concreto podemos haber tenido algún problema que desvirtúe el valor general de la misma.Ya que no disponemos de este dato en la primera iteración del proyecto deberemos basarnos es la velocidad obtenida en proyectos similares ejecutados en el pasado o hacer una suposición basada en la experiencia del equipo y capacidad. 55 / 114 Te encuentras en la mitad de tu proyecto y el cliente está muy satisfecho con el trabajo realizado por el equipo ágil. En la última revisión del producto un stakeholder (interesado del proyecto) nos ha pedido una nueva característica para el producto que considera muy importante y que no estaba contemplada en la planificación. ¿Cómo debería actuar el dueño del producto (producto owner) del equipo ante esta situación? Los cambios se aceptan en cualquier momento del proyecto. Dependiendo del valor que aporte el cambio el product owner, conocedor del negocio, decidirá si introducirlo en el proyecto o no y la prioridad que tiene. EL Product Owner debería elevar el cambio al CCB (Change Control Board) para que lo aprueben o rechacen ya que impacta en el alcance del proyecto. El producto owner debería hablar con el stakeholder para decirle que los cambios se aceptan solo durante el primer sprint/iteración. Si el cambio se identifica después debe posponerse para una versión futura. El cambio es bienvenido y siempre se tiene que aceptar. IncorrectoEl cambio es bienvenido, es uno de los principios ágiles y los frameworks así lo respaldan. En última instancia es el product owner, quien decide la prioridad del cambio y si se introduce o no en el proyecto ya que es el conocedor del negocio y quien debe asegurar la entrega de valor al producto. CorrectoEl cambio es bienvenido, es uno de los principios ágiles y los frameworks así lo respaldan. En última instancia es el product owner, quien decide la prioridad del cambio y si se introduce o no en el proyecto ya que es el conocedor del negocio y quien debe asegurar la entrega de valor al producto. 56 / 114 Empezamos un proyecto ágil y durante la primera iteración el equipo realiza una reunión para identificar riesgos del proyecto y definir acciones de mitigación para los mismos (una spike basada en riesgos). ¿Cómo resultado de este trabajo que espera obtener el equipo ágil? Una matriz de riesgos. El plan de gestión de riesgos. Un product backlog ajustado al riesgo. Un prototipo del proyecto. IncorrectoComo resultado obtendremos un product backlog ajustado al riesgo, con las acciones de mitigación identificadas introducidas en el mismo. Las dos características que tenemos que tener en cuenta para priorizar un product backlog son atacar primero los ítems de mayor valor para el cliente y también los ítems de mayor riesgo. De tal manera que debemos compensar entrega de valor para el cliente con también mitigación de riesgos en las planificaciones de iteraciones. CorrectoComo resultado obtendremos un product backlog ajustado al riesgo, con las acciones de mitigación identificadas introducidas en el mismo. Las dos características que tenemos que tener en cuenta para priorizar un product backlog son atacar primero los ítems de mayor valor para el cliente y también los ítems de mayor riesgo. De tal manera que debemos compensar entrega de valor para el cliente con también mitigación de riesgos en las planificaciones de iteraciones. 57 / 114 Nos encontramos en la iteración número doce de un proyecto estimado en 30 iteraciones. Un miembro del equipo directivo de la organización se reúne con el practicante ágil del proyecto porque quiere ver como se está desarrollando, el miembro del equipo de dirección no tiene muchos conocimientos de agilidad y el practicante ágil empieza explicándole de forma resumida cómo funciona el equipo y gestiona el framework. El miembro de dirección se sorprende al escuchar que cada día realizan una reunión con el equipo de 15 min. para poner en común el trabajo del equipo e identificar problemas e impedimentos que le trasladan al practicante ágil para su resolución. Cree que es una pérdida de tiempo y que deberían hacer esa reunión semanal o mensualmente, como una reunión de seguimiento del modelo tradicional y que eso les permitirá entregar más características en cada iteración. No solo lo cree, sino que trata de imponer su forma de pensar. ¿Cómo debería actuar el practicante ágil ante esta situación? Como en toda negociación debe buscar un punto en común, un win-win, intentando llegar a un acuerdo satisfactorio para ambas partes, realizar la reunión dos veces por semana podría ser un buen acuerdo. Debe ignorar la petición del miembro de dirección, ya que no conoce el framework. Debe proteger el framework, haciéndole ver al miembro de dirección que la reunión diaria es de vital importancia en las practicas ágiles para la inspección del equipo y detección de problemas de forma temprana sin ceder a su petición de cancelarla. Debe respetar la jerarquía de mando dentro de la organización y dejar de hacer la reunión diaria y pasarla a semanal o mensual como indica el miembro de dirección, es verdad que de esta forma podrán aumentar la capacidad de trabajo del equipo. IncorrectoEs obligatorio realizar la reunión diaria, ya que en proyectos complejos donde el alcance no está totalmente fijado desde el principio y el cambio es bienvenido, se necesita tener mucha inspección, transparencia y adaptación para que el proyecto sea exitoso. Así mismo debería hacer algún workshop con dirección para que entiendan los beneficios de esta forma de trabajar y por qué se hacer. Por eso es de vital importancia antes de empezar proyecto con frameworks agiles que las capas de dirección estén involucradas en el cambio cultural lo entiendan y lo respeten para el buen funcionamiento después de los proyectos. Parte de las responsabilidades del scrum master, coach, practicante ágil es promover el uso de la agilidad dentro de la organización, explicando por qué y defendiendo su buen uso. CorrectoEs obligatorio realizar la reunión diaria, ya que en proyectos complejos donde el alcance no está totalmente fijado desde el principio y el cambio es bienvenido, se necesita tener mucha inspección, transparencia y adaptación para que el proyecto sea exitoso. Así mismo debería hacer algún workshop con dirección para que entiendan los beneficios de esta forma de trabajar y por qué se hacer. Por eso es de vital importancia antes de empezar proyecto con frameworks agiles que las capas de dirección estén involucradas en el cambio cultural lo entiendan y lo respeten para el buen funcionamiento después de los proyectos. Parte de las responsabilidades del scrum master, coach, practicante ágil es promover el uso de la agilidad dentro de la organización, explicando por qué y defendiendo su buen uso. 58 / 114 Estamos trabajando en un proyecto ágil y nuestro dueño del producto hace una sesión donde involucra a partes de negocio de la organización y usuarios para gestionar expectativas y entender las prioridades de cada uno de ellos para ayudarle en su priorización del product backlog, Durante la sesión se realizan diferentes técnicas como Kano Analysis, Monopoly money, Esquemas sencillos, etc. ¿Qué pretende conseguir el PO con estas actividades? Priorizar el valor del cliente Dejar claro el alcance del proyecto. Conseguir estimaciones de las características del proyecto. Reducir los riesgos del proyecto. IncorrectoTécnicas como Kano Analisys, Monopoly Money y Esquemas Sencillos son practicas realizadas para la gestión de los stakeholders, que ayudan al PO del proyecto a identificar las necesidades de los mismos y obliga a negociar entre ellos para ponerse de acuerdo en las priorizaciones, de tal forma que se llegué un consenso de que es lo prioritario para ellos y gestionar sus expectativas, además de ayudar al propio PO a priorizar el product backlog según el valor que tienen las características para los stakeholders. En última instancia el PO siempre tiene la última palabra. Escuchará y intentará adecuar las necesidades de los stakeholders según se identifiquen, pero el PO como responsable del producto puede priorizar según su propio criterio si fuera necesario. CorrectoTécnicas como Kano Analisys, Monopoly Money y Esquemas Sencillos son practicas realizadas para la gestión de los stakeholders, que ayudan al PO del proyecto a identificar las necesidades de los mismos y obliga a negociar entre ellos para ponerse de acuerdo en las priorizaciones, de tal forma que se llegué un consenso de que es lo prioritario para ellos y gestionar sus expectativas, además de ayudar al propio PO a priorizar el product backlog según el valor que tienen las características para los stakeholders. En última instancia el PO siempre tiene la última palabra. Escuchará y intentará adecuar las necesidades de los stakeholders según se identifiquen, pero el PO como responsable del producto puede priorizar según su propio criterio si fuera necesario. 59 / 114 Dentro de la cartera de proyectos de nuestra empresa CEOLEVEL.INC se ha seleccionado un proyecto para iniciar en las próximas semanas, la PMO Ágil de CEOLEVEL.INC está seleccionando personas para formar parte del equipo en función de sus habilidades para crear un equipo multi-funcional capaz de cumplir con las necesidades del proyecto. El equipo se compone de 8 personas y ya han seleccionado a 6 personas con las que cumplen las habilidades necesarias para poder abordar el proyecto, cada persona especializada en un área en concreto. Para seleccionar los dos últimos integrantes del equipo tienen a cuatro candidatos, los dos primeros tienen conocimiento de varias áreas “en T” sin ser muy especialistas en ninguna y los dos siguientes candidatos son especialistas únicamente en sus respectivas áreas. ¿Qué candidatos serían más idóneos para acabar de componer el equipo ágil? Los candidatos expertos en una única área, ya que pueden aportar más valor al producto. El equipo ágil ha de estar compuesto por expertos de sus áreas, líderes que trabajen en silos funcionales. Un candidato con varias áreas de conocimiento y el otro experto, para que sea balanceado. Los dos candidatos con habilidades en varias áreas, ya que pueden apoyar al resto de miembros en sus áreas de conocimiento también. IncorrectoUna de las características de los equipos ágiles es que no trabajan en silos funcionales como a veces pasaba en los modelos tradicionales. Debemos tener con la suma de personas del equipo las habilidades necesarias para poder construir el producto, pero es importante y se prioriza en los equipos tener miembros con conocimiento en T, con una habilidad técnica principal pero que tenga conocimientos en otras áreas, ya que esto puedo ayudar al equipo en resolución de tareas críticas en menor tiempo, solución de errores o aportar otros puntos de vista a la hora de construir el producto. CorrectoUna de las características de los equipos ágiles es que no trabajan en silos funcionales como a veces pasaba en los modelos tradicionales. Debemos tener con la suma de personas del equipo las habilidades necesarias para poder construir el producto, pero es importante y se prioriza en los equipos tener miembros con conocimiento en T, con una habilidad técnica principal pero que tenga conocimientos en otras áreas, ya que esto puedo ayudar al equipo en resolución de tareas críticas en menor tiempo, solución de errores o aportar otros puntos de vista a la hora de construir el producto. 60 / 114 El manifiesto ágil se firmón en el 2001 por los principales accionistas de la agilidad en la época. En este manifiesto ágil se llego a un acuerdo entre los miembros para formar las bases de la agilidad creando unos valores principios y practicas que sustentan su uso. ¿De acuerdo con este manifiesto ágil cual de las siguientes combinaciones sería más correcta? Incrementos funcionales, colaboración con el cliente, seguir el plan e individuos e interacciones. Incrementos funcionales, individuos e iteraciones, responder al cambio y documentación exhaustiva. Individuos e interacciones, incrementos funcionales, colaboración con el cliente y responder al cambio. Responder al cambio, individuos e interacciones, procesos y herramientas y colaboración con el cliente. IncorrectoEn las demás respuestas hay conceptos que no forman parte de los valores, principios agiles, como seguir el plan, documentación exhaustiva o procesos y herramientas. CorrectoEn las demás respuestas hay conceptos que no forman parte de los valores, principios agiles, como seguir el plan, documentación exhaustiva o procesos y herramientas. 61 / 114 Durante la ejecución de la iteración siete de nuestro proyecto un interesado del proyecto pide incluir una serie de características al producto. El dueño del producto las analiza y cree que aportaran mucho valor a nuestro producto por lo que decide incluirlas al producto. ¿Dónde representamos de mejor manera el trabajo pendiente de nuestro proyecto? En el roadmap. En el backlog de la iteración. En el gráfico de velocidad del equipo. En el product backlog. IncorrectoEl product backlog es donde tenemos todo el trabajo a pendiente en el proyecto. CorrectoEl product backlog es donde tenemos todo el trabajo a pendiente en el proyecto. 62 / 114 Viendo que tu organización cada vez está realizando más proyectos con frameworks agiles, la mayoría con Scrum, un gerente de proyectos del modelo tradicional pide a un Scrum Master que le deje ver como lidera a los equipos en sus proyectos para aprender más sobre la agilidad. El gerente de proyectos tradicional se da cuenta muy rápido de que muchas de las decisiones del proyecto son tomadas por el propio equipo de desarrollo y que el scrum master más facilitador que autoritativo, su trabajo es asegurar que el equipo está centrado en el trabajo, compartir la visión del proyecto, hacer crecer al equipo y eliminar impedimentos para que puedan cumplir con el trabajo seleccionado. ¿Qué tipo de liderazgo está usando el scrum master? Liderazgo de mando. Liderazgo servicial. Liderazgo transformacional. Liderazgo Laissez-Faire. IncorrectoEl líder servicial reconoce que son los miembros del equipo los que hacen el trabajo y consiguen el valor para el negocio. El rol de leader (Scrum master, coach, PM) es un “facilitador. Y debe:Proteger al equipo al equipo de interrupciones.Eliminar impedimentos al equipo para que pueda progresar.(Re) comunicar la visión del proyecto.Y dar soporte para maximizar la productividad del equipo, proporcionar lo que el equipo necesita. CorrectoEl líder servicial reconoce que son los miembros del equipo los que hacen el trabajo y consiguen el valor para el negocio. El rol de leader (Scrum master, coach, PM) es un “facilitador. Y debe:Proteger al equipo al equipo de interrupciones.Eliminar impedimentos al equipo para que pueda progresar.(Re) comunicar la visión del proyecto.Y dar soporte para maximizar la productividad del equipo, proporcionar lo que el equipo necesita. 63 / 114 El producto Owner de nuestro proyecto ágil se encuentra reunido con el patrocinador del proyecto y algunos stakeholders, quieren saber fechas de entrega del producto y que incluirán estas entregas a alto nivel según la planificación actual del proyecto. ¿Cuál sería la herramienta más adecuada de comunicación que debería usar el PO (Product Owner, dueño del producto) para responder a estas dudas? Una demo del producto. Release Plan. El product backlog. Product Roadmap. IncorrectoEl producto roadmap permite a las organizaciones expresar dónde quieren llevar su producto y usarlo como una herramienta de comunicación que brinda a las partes interesadas una vista rápida de los puntos de lanzamiento principales y las funcionalidades deseadas. La planificación de entrega (reléase plan) únicamente muestra que contendrá una entrega en detalle. Solo la hoja de ruta (roadmap) muestra múltiples entregas. CorrectoEl producto roadmap permite a las organizaciones expresar dónde quieren llevar su producto y usarlo como una herramienta de comunicación que brinda a las partes interesadas una vista rápida de los puntos de lanzamiento principales y las funcionalidades deseadas. La planificación de entrega (reléase plan) únicamente muestra que contendrá una entrega en detalle. Solo la hoja de ruta (roadmap) muestra múltiples entregas. 64 / 114 En los proyectos ágiles se define una Definición de Terminado (Definitio of Done, DoD) que aclara cuando un elemento de trabajo se puede marcar como terminado. ¿Cuándo utiliza el equipo por primera vez esta definición de terminado (DoD) durante el proyecto? Cuando finaliza el primer elemento de trabajo. Cuando se testea por primera vez. Cuando estima los elementos. En la primera revisión del producto. IncorrectoAl estimar el elemento de trabajo, el equipo debe saber lo que se necesita hacer/cumplir para dar por bueno el trabajo. La DoD debe contemplarse al hacer la estimación ya que puede añadir más o menos complejidad al elemento de trabajo y esto ha de tenerse en cuenta en el valor que otorguemos de estimación.Los criterios de aceptación de un elemento son particulares a ese elemento, mientras que la DoD es para todos los elementos, como por ejemplo cumplir con los estándares de calidad impuestos por la organización, o que todos los elementos tengan que ser validados por dos personas del equipo antes de darlos por finalizados, etc. La DoD es definida por la organización o en su defecto si esta no lo hiciera por el equipo de desarrollo. CorrectoAl estimar el elemento de trabajo, el equipo debe saber lo que se necesita hacer/cumplir para dar por bueno el trabajo. La DoD debe contemplarse al hacer la estimación ya que puede añadir más o menos complejidad al elemento de trabajo y esto ha de tenerse en cuenta en el valor que otorguemos de estimación.Los criterios de aceptación de un elemento son particulares a ese elemento, mientras que la DoD es para todos los elementos, como por ejemplo cumplir con los estándares de calidad impuestos por la organización, o que todos los elementos tengan que ser validados por dos personas del equipo antes de darlos por finalizados, etc. La DoD es definida por la organización o en su defecto si esta no lo hiciera por el equipo de desarrollo. 65 / 114 En un proyecto ágil que estamos apunto de empezar ¿Cuáles serían los tres procesos básicos para poder iniciar el proyecto? Visión del producto, planificación del roadmap y burn down chart Iteraciones, planificación del roadmap y numero de sprints Acta de constitución, Project management plan, definición del product backlog incial Visión del producto, planificación del roadmap y definición del product backlog inicial IncorrectoVisión del producto, planificación del roadmap y definición del product backlog inicial. CorrectoVisión del producto, planificación del roadmap y definición del product backlog inicial. 66 / 114 El equipo de desarrollo está focalizado en finalizar las tareas pendientes de la iteración para llegar a tiempo a la revisión del producto con todo el trabajo finalizado cuando reciben la llama de un usuario final pidiéndoles que introduzcan más cantidad de trabajo en la iteración. ¿Qué deberíamos hacer? El líder ágil debe hablar con el usuario final y explicarle como se planifican las iteraciones. El equipo de desarrollo debe explicarle al usuario final como se planifican las iteraciones. Se debe pedir al usuario final que se una al equipo. Se debe elevar lo ocurrido para que se tomen medidas y no vuelva a ocurrir durante el proyecto. IncorrectoEl líder ágil debe proteger al equipo de desarrollo y hacer que este centrado en cumplir con los objetivos de la iteración liberándolo de “distracciones”. Por lo que debería ir a hablar con el usuario final y explicarle como planifican las iteraciones en los proyectos ágiles. CorrectoEl líder ágil debe proteger al equipo de desarrollo y hacer que este centrado en cumplir con los objetivos de la iteración liberándolo de “distracciones”. Por lo que debería ir a hablar con el usuario final y explicarle como planifican las iteraciones en los proyectos ágiles. 67 / 114 El product owner del proyecto se reúne con los interesados del proyecto para identificar la prioridad de las características según el valor del cliente. ¿Qué técnica sería adecuada para usar en esta reunión? Tallas de camiseta Wide Band Delphi Planning Poker MoSCoW IncorrectoLa única respuesta que es una técnica de priorización y por lo tanto la respuesta correcta es MoSCoW. Planning Poker y Wide Band Delphi son técnicas para la estimación de historias de usuario y las tallas de camiseta sería una medida de estimación. CorrectoLa única respuesta que es una técnica de priorización y por lo tanto la respuesta correcta es MoSCoW. Planning Poker y Wide Band Delphi son técnicas para la estimación de historias de usuario y las tallas de camiseta sería una medida de estimación. 68 / 114 En los proyectos agiles ¿Cuándo convertimos las historias de usuario en tareas para implementar por el equipo de desarrollo? En el refinamiento del product backlog. En la reunión diaria En cualquier momento. Durante la planificación de la iteración. IncorrectoDurante la reunión de planificación de la iteración seleccionamos las historias de usuario que se realizaran durante esa iteración, cuando las vamos seleccionando el equipo de desarrollo debe descomponer la historia de usuario en tareas técnicas, que pasaran a formar el backlog de la iteración, en el caso de scrum se llama sprint backlog. Es el único momento en el que se hace, ya que el product backlog no puede/debe contener tareas. CorrectoDurante la reunión de planificación de la iteración seleccionamos las historias de usuario que se realizaran durante esa iteración, cuando las vamos seleccionando el equipo de desarrollo debe descomponer la historia de usuario en tareas técnicas, que pasaran a formar el backlog de la iteración, en el caso de scrum se llama sprint backlog. Es el único momento en el que se hace, ya que el product backlog no puede/debe contener tareas. 69 / 114 En nuestro proyecto ágil tenemos cincuenta y tres historias de usuario en el product backlog. Las historias de usuarios son una excelente manera de representar el elemento de la cartera de producto (product backlog) y son una o más oraciones en el lenguaje cotidiano o comercial del usuario o cliente que captura lo que el usuario o cliente desea lograr. ¿Las historias de usuario son relevantes hasta? Que el equipo las completa. La finalización de la iteración. Que se realiza la entrega. La finalización del proyecto. IncorrectoLas historias de usuario es la manera de representar el elemento en el product backlog y el producto owner se encarga de priorizarlas en el product backlog para irlas introducciones en las planificaciones de las iteraciones del proyecto. Una vez la historia de usuario es seleccionada para realizarse en una iteración y es finalizada se retiran del product backlog porque ya ha sido implementada (nos quedara el registro en aplicaciones digitales tipo Jira de gestión, pero desaparecen del product backlog). CorrectoLas historias de usuario es la manera de representar el elemento en el product backlog y el producto owner se encarga de priorizarlas en el product backlog para irlas introducciones en las planificaciones de las iteraciones del proyecto. Una vez la historia de usuario es seleccionada para realizarse en una iteración y es finalizada se retiran del product backlog porque ya ha sido implementada (nos quedara el registro en aplicaciones digitales tipo Jira de gestión, pero desaparecen del product backlog). 70 / 114 Empiezas un nuevo proyecto como practicante ágil y en anteriores proyectos has identificado que el equipo tenía poca comunicación osmótica por estar distribuido en diferentes plantas del edificio, quieres mejorar este punto para obtener mejores resultados. ¿Cuál sería la mejor manera de potenciar este tipo de comunicación? Invitar a los usuarios finales a las reuniones diarias Usar herramientas de videollamada y de presencia para facilitar la interacción entre ellos. Usar la metodología de agile modeling para hacer estándares de documentación y publicarlos. Sentar al equipo junto en una misma ubicación para facilitar la comunicación cara a cara. IncorrectoLa comunicación más eficiente es la comunicación cara a cara y así consta en los principios y valores ágiles, por lo que lo ideal es tener al equipo en una misma ubicación física y proporcionarles un espacio de trabajo donde se pueda llevar a cabo este tipo de comunicación en su día a día. CorrectoLa comunicación más eficiente es la comunicación cara a cara y así consta en los principios y valores ágiles, por lo que lo ideal es tener al equipo en una misma ubicación física y proporcionarles un espacio de trabajo donde se pueda llevar a cabo este tipo de comunicación en su día a día. 71 / 114 El equipo ágil de nuestro proyecto se encuentra estimando historias de usuario del product backlog que se han introducido nuevas tras la ultima revisión del producto y que han sido sugeridas por los interesados del proyecto. El equipo esta realizando la estimación utilizando la técnica de planning poker y utilizando puntos de historia como medida en las estimaciones. ¿Qué representamos con los puntos de historia? El valor que aporta la historia de usuario La prioridad de la historia de usuario en el product backlog Duración que se necesita para completar una historia de usuario. Medida relativa del tamaño/complejidad de una historia de usuario. IncorrectoLos puntos de historia (Story Points) son la unidad de medida más común para los equipos ágiles que practican el tamaño relativo. Son una medida abstracta del esfuerzo requerido para implementar una historia de usuario. Los factores que se valoran para asignar estos puntos de historia son:Esfuerzo / TamañoRiesgo / Complejidad CorrectoLos puntos de historia (Story Points) son la unidad de medida más común para los equipos ágiles que practican el tamaño relativo. Son una medida abstracta del esfuerzo requerido para implementar una historia de usuario. Los factores que se valoran para asignar estos puntos de historia son:Esfuerzo / TamañoRiesgo / Complejidad 72 / 114 Después de unos cuantos meses de proyecto, tu equipo ágil ha llegado a la etapa de desarrollo grupal “performing” definida por Tuckman en su escala. ¿Qué implicaciones tiene esto a nivel del liderazgo que debe hacer el líder ágil del equipo? Necesitará hacer un liderazgo alto en dirección y apoyo para mantener el rendimiento del equipo alto, de lo contrario volverán a la etapa anterior de “norming”. Necesitará hacer un comportamiento más alto en dirección del equipo, ya que necesitará menos apoyo porque serán autosuficientes. En este punto el equipo no necesitará dirección y necesitara poco apoyo, el equipo ha llegado a ser autosuficiente y autogestionado. Un líder ágil deja que el equipo aprenda de sus errores, no debe dirigir ni apoyar en ninguna etapa de desarrollo. IncorrectoEn la etapa de performing (actuación) definida por Tuckman que es la última (más alta) el equipo es funcional por sí solo, autosuficiente y autogestionado, trabajan juntos con fluidez y son capaces de resolver problemas y conflictos por sí solos. Por lo que el liderazgo del líder ágil se diluye y pasa a estar pausado, actuando únicamente como líder servicial para el equipo. CorrectoEn la etapa de performing (actuación) definida por Tuckman que es la última (más alta) el equipo es funcional por sí solo, autosuficiente y autogestionado, trabajan juntos con fluidez y son capaces de resolver problemas y conflictos por sí solos. Por lo que el liderazgo del líder ágil se diluye y pasa a estar pausado, actuando únicamente como líder servicial para el equipo. 73 / 114 El framework ágil de Scrum se basa en la teoría de control de procesos empíricos. El empirismo afirma que el conocimiento proviene de la experiencia y la toma de decisiones basadas en lo que se conoce. ¿Cómo ayudan estos procesos empíricos de control a la agilidad? Mediante el test de requerimientos y realizando cambios. Dando visibilidad, revisando el producto y testeándolo. Mediante el test de requerimientos y adaptando según las necesidades. Dando visibilidad para poder inspeccionar el producto y adaptándolo según las necesidades. IncorrectoLos procesos empíricos de control hacen visible (transparencia) el estado del producto a las personas interesadas y al equipo para tener un entendimiento común, la inspección frecuente de los artefactos (product backlog, backlog de la iteración, incremento) y del progreso (burn down charts, burn up charts, velocity, etc..) para detectar variaciones indeseadas y permitir entonces la adaptación cuando un proceso se desvíe de los límites aceptables se deberá ajustar. CorrectoLos procesos empíricos de control hacen visible (transparencia) el estado del producto a las personas interesadas y al equipo para tener un entendimiento común, la inspección frecuente de los artefactos (product backlog, backlog de la iteración, incremento) y del progreso (burn down charts, burn up charts, velocity, etc..) para detectar variaciones indeseadas y permitir entonces la adaptación cuando un proceso se desvíe de los límites aceptables se deberá ajustar. 74 / 114 ¿Durante qué actividad en un proyecto ágil utilizaremos la secuencia de números 0,1,2,3,5,8,13,21…(Fibonacci)? Estimando horas de desarrollo. Estimando puntos de historia para las historias de usuario Priorizando el product backlog. Durante la retrospectiva IncorrectoUtilizamos la escala Fibonacci para estimar los puntos de historia relativos a una historia de usuario. Normalmente con la técnica de planning poker para hacer la estimación de las historias de usuario. CorrectoUtilizamos la escala Fibonacci para estimar los puntos de historia relativos a una historia de usuario. Normalmente con la técnica de planning poker para hacer la estimación de las historias de usuario. 75 / 114 En nuestro proyecto ágil tenemos identificados ochenta PBIs (Product Backlog ítems) algunos de ellos están en modo “borrador” no están estimados detalladamente y falta información. ¿Dónde es más normal que encontremos estos PBIs colocados en el product backlog? En la parte alta del product backlog. En la parte baja del product backlog. No deben haber items sin detalle en el product backlog. En cualquier lugar. IncorrectoLos PBIs que tienen menos detalle suelen estar en la parte baja del product backlog, son ítems no prioritarios por el momento en el proyecto, de lo contrario necesitamos detallarlos, restimarlos y subirlos en prioridad en el product backlog para que el equipo cuando tenga que trabajar con ellos no tenga ninguna duda al respecto. CorrectoLos PBIs que tienen menos detalle suelen estar en la parte baja del product backlog, son ítems no prioritarios por el momento en el proyecto, de lo contrario necesitamos detallarlos, restimarlos y subirlos en prioridad en el product backlog para que el equipo cuando tenga que trabajar con ellos no tenga ninguna duda al respecto. 76 / 114 En nuestro proyecto ágil se determina que necesitamos más personas en el equipo para poder finalizar a tiempo trabajo añadido por los interesados en el proyecto ya que el cliente no quiere modificar la fecha de final de proyecto, pero acepta incrementar el presupuesto para tener más capacidad en el equipo e incluir las características identificadas por los interesados del proyecto. Nuestro equipo pasa de tener seis miembros a catorce. Como resultado el espacio de trabajo del equipo esta abarrotado e incómodo. Tras el incremento de personas en el equipo la reunión diaria está excediendo los quince minutos ideales. ¿Qué debería hacer el practicante ágil frente a esta situación? Mover al equipo a una ubicación de trabajo con más espacio para ellos. Limitar las actuaciones de los miembros del equipo en las reuniones diarias a 1 minuto por persona. Dividir el equipo de catorce personas en dos equipos. Incrementar la duración máxima de la reunión diaria y actualizar el calendario. IncorrectoLas practicas ágiles recomiendan encarecidamente trabajar con equipos “pequeños” el equipo de catorce personas es demasiado grande y esta generando problemas de ubicación física del equipo, y en la duración de reuniones como la diaria i otras tomas de decisiones conjuntas que se verán afectas al tener que hacer consenso con más miembros, los tiempos de eventos del framework en que participa todo el equipo se verán afectados aumentando y restando eficiencia al equipo. La opción más recomendable en este caso sería dividir el equipo grande en dos equipos más pequeños. Idealmente ponerlos a trabajar en características que no tengan relación entre equipos para evitar dependencias y cuellos de botella. Cada equipo trabajará sobre su propio backlog de iteración y mantendrá reuniones diarias separadas eliminando el incremento de tiempo en ella y asegurando la correcta inspección. CorrectoLas practicas ágiles recomiendan encarecidamente trabajar con equipos “pequeños” el equipo de catorce personas es demasiado grande y esta generando problemas de ubicación física del equipo, y en la duración de reuniones como la diaria i otras tomas de decisiones conjuntas que se verán afectas al tener que hacer consenso con más miembros, los tiempos de eventos del framework en que participa todo el equipo se verán afectados aumentando y restando eficiencia al equipo. La opción más recomendable en este caso sería dividir el equipo grande en dos equipos más pequeños. Idealmente ponerlos a trabajar en características que no tengan relación entre equipos para evitar dependencias y cuellos de botella. Cada equipo trabajará sobre su propio backlog de iteración y mantendrá reuniones diarias separadas eliminando el incremento de tiempo en ella y asegurando la correcta inspección. 77 / 114 El equipo ágil se encuentra realizando una reunión de refinamiento del product backlog para ajustar las estimaciones, y dividir historias de usuario muy grandes (épicas) en historias de usuario más pequeñas. Además, el producto owner se ayuda del conocimiento del equipo para repriorizar el product backlog. ¿Cuál de las siguientes características es más importante de cara a realizar la priorización? El coste relativo. El valor para el cliente Dependencias entre historias de usuario El esfuerzo de desarrollo. IncorrectoLa principal medida que debe contemplar el product owner para priorizar el product backlog es el valor que aporta el item al cliente. Los dos factores críticos para priorizar son valor al cliente y reducción de riesgos. Los artículos de mayor valor son atacados primero ylos artículos de mayor riesgo también son atacados temprano. CorrectoLa principal medida que debe contemplar el product owner para priorizar el product backlog es el valor que aporta el item al cliente. Los dos factores críticos para priorizar son valor al cliente y reducción de riesgos. Los artículos de mayor valor son atacados primero ylos artículos de mayor riesgo también son atacados temprano. 78 / 114 Un equipo ágil que está desarrollando un producto de software para CEOLEVEL.INC trabaja con el marco de trabajo de Extreme Programming (XP o programación extrema) orientado únicamente a software y su forma de implementar las historias de usuario en la iteraciones del proyecto pasa por primero diseñar el test que ha de pasar la historia de usuario, luego implementar el código para pasar el test y por ultimo refactorizar el código escrito de la historia de usuario para dejarlo limpio, optimizado, sin duplicaciones de código y cumpliendo con los estándares de programación acordados al inicio del proyecto. ¿Qué practica está utilizando el equipo ágil en el proyecto? Diseño incremental Test-Driven Development (TTD) o Test First Development (TFD) Integración continua Prototipos IncorrectoTTD o TFD se basan en el mismo principio y es que las pruebas guíen el desarrollo, es decir que antes de empezar a implementar el código de la historia de usuario primero escribimos los test y con esto cerramos “alcance” de la historia de usuario, porque implementaremos el código únicamente necesario para pasar la prueba y dar por buena la historia de usuario, el código a de ser simple, siguiendo la practica de simplicidad de extreme programming y que iremos evolucionando únicamente si los requerimientos del software a construir así lo solicitan. Una vez escrito el test se ejecuta para ver que falle, porque no hemos implementado el código aún, una vez validado que falla implementamos el código simple para pasar el test y volvemos a ejecutar el test para validar que ahora si lo pasamos, cuando pasamos el test refactorizamos el código “borrador” para cumplir con los estándares de programación que hayamos definido, como código con comentarios, tabulaciones, optimizado, entendible para todos, etc. y damos por cerrada la historia de usuario que se presentara en la reunión de revisión al final de la iteración junto a las demás generando el incremento de esa iteración. CorrectoTTD o TFD se basan en el mismo principio y es que las pruebas guíen el desarrollo, es decir que antes de empezar a implementar el código de la historia de usuario primero escribimos los test y con esto cerramos “alcance” de la historia de usuario, porque implementaremos el código únicamente necesario para pasar la prueba y dar por buena la historia de usuario, el código a de ser simple, siguiendo la practica de simplicidad de extreme programming y que iremos evolucionando únicamente si los requerimientos del software a construir así lo solicitan. Una vez escrito el test se ejecuta para ver que falle, porque no hemos implementado el código aún, una vez validado que falla implementamos el código simple para pasar el test y volvemos a ejecutar el test para validar que ahora si lo pasamos, cuando pasamos el test refactorizamos el código “borrador” para cumplir con los estándares de programación que hayamos definido, como código con comentarios, tabulaciones, optimizado, entendible para todos, etc. y damos por cerrada la historia de usuario que se presentara en la reunión de revisión al final de la iteración junto a las demás generando el incremento de esa iteración. 79 / 114 Estamos analizando varios proyectos para su priorización en el portfolio de la organización. Tenemos el proyecto X con un IRR (Internal Rate of Return, tasa de retorno interna) del 14% y un proyecto Y con un IRR del 9%. ¿Cuál sería el proyecto que deberíamos priorizar según los datos? Depende del ROI El proyecto X El proyecto Y Depende del NPV IncorrectoSiempre que comparemos dos valores iguales, ya sea, ROI, NPV, o IRR, el que tenga mayor valor es el más beneficioso, por lo tanto, en este caso priorizaríamos el proyecto X. CorrectoSiempre que comparemos dos valores iguales, ya sea, ROI, NPV, o IRR, el que tenga mayor valor es el más beneficioso, por lo tanto, en este caso priorizaríamos el proyecto X. 80 / 114 Empezamos un proyecto ágil con un equipo nuevo sin experiencia en practicas ágiles, se ha realizado la planificación de la iteración y los miembros del equipo de desarrollo se encuentran trabajando en sus respectivas historias de usuario. El líder ágil se percata que en la reunión diaria del equipo cada miembro expone en que esta trabajando y dice los impedimentos que se encuentra, pero cuando esto sucede otras personas del equipo participan y buscan soluciones a los problemas que dicen los compañeros. ¿Esto es una buena practica en las reuniones diarias? Sí, porque es el propósito de la reunión diaria en si mismo, saber en qué están trabajando los compañeros y solucionar los problemas/impedimentos que se estén encontrando para tener un buen ritmo de trabajo y aumentar la velocidad del equipo al desbloquear conflictos. Los 15 minutos de duración de la reunión es una estimación, puede durar más si es necesario. No, el objetivo de la reunión es aumentar la visibilidad del trabajo de cada persona del equipo de desarrollo y asegurar que el trabajo este integrado para cumplir con los objetivos de la iteración, los problemas impedimentos se deben tratar fuera de esta reunión para no exceder los 15 minutos de duración. Sí, porque esto hace tener una foto precisa de en qué punto de la iteración nos encontramos y que usa después el líder del proyecto ágil para reportar el progreso a los interesados del proyecto. No, el objetivo principal de la reunión es informar al producto owner del progreso en la iteración, al producto owner no le interesan los detalles que se deben resolver a posteriori entre el equipo, además si todos intentan resolver los problemas en la reunión esta se alarga de los 15 minutos máximo de duración que tiene fijado. IncorrectoLa reunión diaria no puede durar más de 15 minutos porque si no el equipo perdería capacidad de trabajo, por lo que la importancia de la reunión es hacer visible en que está trabajando cada persona para tener una foto global del avance e identificar problemas o impedimentos para tratar a posteriori con las personas necesarias. CorrectoLa reunión diaria no puede durar más de 15 minutos porque si no el equipo perdería capacidad de trabajo, por lo que la importancia de la reunión es hacer visible en que está trabajando cada persona para tener una foto global del avance e identificar problemas o impedimentos para tratar a posteriori con las personas necesarias. 81 / 114 En nuestro Proyecto en CEOLEVEL.INC estamos desarrollando una aplicación a medida para el cliente SOLOSTOCKING proveedor de alimentos para otras empresas de alimentación. Necesitan una aplicación para gestionar sus productos y realizamos un proyecto ágil para conseguir una aplicación interna para SOLOSTOCKING que cumpla con sus necesidades. En nuestro equipo ágil de proyecto solo tenemos una persona experta en base de datos y el Project manager del proyecto esta preocupado por si está persona se pone enferma o casusa baja por cualquier causa ya que esto afectaría drásticamente el rendimiento del equipo. ¿Qué debería hacer? Mantener y transferir el conocimiento dentro del equipo, creando un repositorio de conocimiento accesible para todo el equipo con las tareas críticas que realiza. Es un riego del proyecto que debemos contemplar y seguir, pero no debemos realizar ninguna acción porque puede no suceder y sería desperdicio de trabajo. Empezar el proceso de búsqueda de una persona con conocimientos en bases de datos parecidas para tenerlo como repuesto. Mover al experto en base de datos a orto equipo para que los miembros de nuestro equipo se vean obligados a aprender las tareas que estaba realizando. IncorrectoMantener y transferir el conocimiento dentro del equipo es una tarea importante en cualquier proyecto para asegurar su éxito. Por lo que en este caso lo más adecuado sería crear un repositorio de conocimiento para que se puedan seguir realizando las tareas críticas del experto en base de dato y esto no impacte en una bajada de rendimiento del equipo o parada de trabajo. Además, podríamos realizar “spikes de conocimiento”, introducir tareas de en el product backlog acotadas en tiempo (estimadas) y asignadas a un miembro del equipo en las iteraciones para coger conocimientos básicos en gestión de bbdd y así tener una persona con conocimientos en T en varias áreas y que pueda llegar a cubrir, llegado el caso, la baja/enfermedad del experto de base de datos. CorrectoMantener y transferir el conocimiento dentro del equipo es una tarea importante en cualquier proyecto para asegurar su éxito. Por lo que en este caso lo más adecuado sería crear un repositorio de conocimiento para que se puedan seguir realizando las tareas críticas del experto en base de dato y esto no impacte en una bajada de rendimiento del equipo o parada de trabajo. Además, podríamos realizar “spikes de conocimiento”, introducir tareas de en el product backlog acotadas en tiempo (estimadas) y asignadas a un miembro del equipo en las iteraciones para coger conocimientos básicos en gestión de bbdd y así tener una persona con conocimientos en T en varias áreas y que pueda llegar a cubrir, llegado el caso, la baja/enfermedad del experto de base de datos. 82 / 114 Durante la iteración once del proyecto, el producto owner reúne a los interesados del proyecto y les entrega dinero falso para “comprar” características de producto que estamos generando. ¿Qué nombre recibe este practica? Análisis económico MoSCoW Análisis del mercado Monopoly Money IncorrectoEn la práctica de monopoly money se reparte dinero ficticio a los sponsors / stakeholders por el valor del presupuesto del proyecto y se les dice que lo repartan a través de las características a desarrollar del proyecto. Ayuda al producto owner a ver la importancia que tienen las características para los stakeholders y poder priorizar en función de ello. CorrectoEn la práctica de monopoly money se reparte dinero ficticio a los sponsors / stakeholders por el valor del presupuesto del proyecto y se les dice que lo repartan a través de las características a desarrollar del proyecto. Ayuda al producto owner a ver la importancia que tienen las características para los stakeholders y poder priorizar en función de ello. 83 / 114 La comunicación y colaboración del equipo ágil es básica para obtener buenos resultados durante el proyecto. Para facilitar que el conocimiento circule por el equipo y facilitar la comunicación osmótica que técnica tendría más valor: Sentar a los miembros del equipo juntos en una misma área de trabajo. Invitar a todos los interesados (aunque el incremento generado no les afecte) a las reuniones de revisión del producto. Invitar a expertos que no sean miembros del equipo a las reuniones de planificación. Revisa frecuentemente los requerimientos (historias de usuario) con el propietario del producto. IncorrectoLa comunicación cara a cara es uno de los principios ágiles que siempre que podamos tenemos que potenciar, por ello, la mejor manera de facilitar este tipo de comunicación y a su vez facilitar la comunicación osmótica del equipo sería que trabajara junto en un mismo espacio de trabajo. La comunicación osmótica del equipo significa que la información fluye en el fondo auditivo (conversaciones que tienen unas personas con otras, que no quedan documentadas en ningún sitio, pero que es conocimiento) de los miembros del equipo, de tal forma que ellos captan la información relevante, como si fuera por ósmosis. Esto se realiza normalmente por estar en la misma habitación. CorrectoLa comunicación cara a cara es uno de los principios ágiles que siempre que podamos tenemos que potenciar, por ello, la mejor manera de facilitar este tipo de comunicación y a su vez facilitar la comunicación osmótica del equipo sería que trabajara junto en un mismo espacio de trabajo. La comunicación osmótica del equipo significa que la información fluye en el fondo auditivo (conversaciones que tienen unas personas con otras, que no quedan documentadas en ningún sitio, pero que es conocimiento) de los miembros del equipo, de tal forma que ellos captan la información relevante, como si fuera por ósmosis. Esto se realiza normalmente por estar en la misma habitación. 84 / 114 Para el correcto funcionamiento de los frameworks ágiles la colaboración con el cliente es un valor que debemos seguir durante todo el proyecto. ¿Cómo ayuda el cliente en el desarrollo del producto? Diciendo sus prioridades e identificando nuevas características del producto. Poniendo las fechas de entrega y de iteraciones. Seleccionando a los miembros del equipo ágil. Aprobando las planificaciones de las iteraciones. IncorrectoEl cliente está presente en las revisiones de producto donde una vez visto el incremento generado por el equipo en la iteración se comentan siguientes pasos, nuevas características que consideran importantes o dando feedback de las prioridades. Para ello también el producto owner puede hacer reuniones con los interesados para validar sus prioridades de proyecto con técnicas como MoSCoW, Plannig Poker, etc. El cliente no aprueba las planificaciones ya que eso lo realiza el PO con el equipo de desarrollo y tampoco fija las fechas de entrega ya que es tarea del Product Owner ayudado del equipo y a veces también ayudado por los interesados, pero, no las fijan ellos. El producto owner muchas veces es parte del cliente ya que debe conocer el negocio para poder realizar las priorizaciones correctamente y asegurar la entrega de valor al cliente y el retorno de inversión en el proyecto. Pero el PO aunque sea parte del cliente es considerado parte del equipo ágil, no cliente o interesado como tal. CorrectoEl cliente está presente en las revisiones de producto donde una vez visto el incremento generado por el equipo en la iteración se comentan siguientes pasos, nuevas características que consideran importantes o dando feedback de las prioridades. Para ello también el producto owner puede hacer reuniones con los interesados para validar sus prioridades de proyecto con técnicas como MoSCoW, Plannig Poker, etc. El cliente no aprueba las planificaciones ya que eso lo realiza el PO con el equipo de desarrollo y tampoco fija las fechas de entrega ya que es tarea del Product Owner ayudado del equipo y a veces también ayudado por los interesados, pero, no las fijan ellos. El producto owner muchas veces es parte del cliente ya que debe conocer el negocio para poder realizar las priorizaciones correctamente y asegurar la entrega de valor al cliente y el retorno de inversión en el proyecto. Pero el PO aunque sea parte del cliente es considerado parte del equipo ágil, no cliente o interesado como tal. 85 / 114 Nos encontramos en una reunión de refinamiento del product backlog y concretamente estamos estimando una tarea historia de usuario de la parte baja del product backlog, la historia de usuario aun no está del todo detallada porque no es prioritaria y no entrará en las próximas iteraciones, aun así, para tener una buena predictibilidad el producto owner nos pide al equipo de desarrollo que la estimemos, ¿Qué tenemos que tener en cuenta en la estimación? Debemos decirle al producto owner que no debemos estimar esa historia de usuario hasta que no tenga más detalla porque es desperdicio. En las estimaciones se tiene que tener en cuenta la incertidumbre, si tiene mayor incertidumbre también ha de tener una mayor estimación. Las historias de usuario que no tienen detalle y en las que hay incertidumbre se les otorga un valor estándar de ocho puntos de historia. Debemos estimar lo que conocemos de la historia de usuario, cuando se detalle más se reestimará con otro valor si cambia. IncorrectoEn las estimaciones se tiene que tener en cuenta la incertidumbre de la misma, no es desperdicio estimar una historia de usuario que después se tendrá que reestimar cuando tenga más detalle, porque ayuda al PO a poder dar predictibilidad al Product Backlog. Por ejemplo, si suma todas las estimaciones de las historias de usuario restantes del Product Backlog puede saber cuantas iteraciones necesita para terminar todo el trabajo, por lo que tener el product backlog estimado es importante para poder hacer pronósticos, estimaciones de fecha fin, etc. CorrectoEn las estimaciones se tiene que tener en cuenta la incertidumbre de la misma, no es desperdicio estimar una historia de usuario que después se tendrá que reestimar cuando tenga más detalle, porque ayuda al PO a poder dar predictibilidad al Product Backlog. Por ejemplo, si suma todas las estimaciones de las historias de usuario restantes del Product Backlog puede saber cuantas iteraciones necesita para terminar todo el trabajo, por lo que tener el product backlog estimado es importante para poder hacer pronósticos, estimaciones de fecha fin, etc. 86 / 114 Durante la retrospectiva de la iteración 4 de tu proyecto os encontráis analizando por qué no habéis podido completar todas las historias de usuario que habíais planificado para la iteración. Tras utilizar el diagrama de espinas (fishbone diagram) para analizar la causa raíz que ha provocado esto llegáis a la conclusión de que el equipo ha tenido muchas interrupciones por llamadas, mails y reuniones. Los miembros del equipo se encuentran disgustados con los resultados porque han trabajado duro, pero por factores externos no han podido finalizar todo el trabajo seleccionado. ¿Por qué se ha producido esto? El equipo se ha relajado porque de lo contrario habrían finalizado todas las historias de usuario como se acordó en la planificación de la iteración con ellos. El producto owner ha introducido demasiadas historias de usuario para la iteración. Se han usado días ideales en la estimación de las historias de usuario. Las estimaciones de las historias de usuario seleccionadas para esta iteración no eran correctas. IncorrectoSi se usan días ideales en las estimaciones tenemos que contemplar que durante la ejecución de la iteración tendremos reuniones, llamadas, descansos, mails u otro tipo de distracciones/imprevistos que nos quitaran tiempo de implementación de las tareas. Por lo que en la reunión de planificación de la iteración no podemos coger las horas que tenemos en una iteración y rellenarla con las estimaciones de horas ideales, sino que debemos guarda holguras en la iteración que contemplen todos esos factores mencionados anteriormente. Por eso estimar con puntos de historia (story points) y obtener la velocidad al final de la iteración es una forma más efectiva de estimar las historias de usuario, porque la métrica de la velocidad nos indica lo que finalizó el equipo en las iteraciones anteriores y ahí ya se contempla el tiempo de reuniones, mails, llamadas, etc. CorrectoSi se usan días ideales en las estimaciones tenemos que contemplar que durante la ejecución de la iteración tendremos reuniones, llamadas, descansos, mails u otro tipo de distracciones/imprevistos que nos quitaran tiempo de implementación de las tareas. Por lo que en la reunión de planificación de la iteración no podemos coger las horas que tenemos en una iteración y rellenarla con las estimaciones de horas ideales, sino que debemos guarda holguras en la iteración que contemplen todos esos factores mencionados anteriormente. Por eso estimar con puntos de historia (story points) y obtener la velocidad al final de la iteración es una forma más efectiva de estimar las historias de usuario, porque la métrica de la velocidad nos indica lo que finalizó el equipo en las iteraciones anteriores y ahí ya se contempla el tiempo de reuniones, mails, llamadas, etc. 87 / 114 El producto owner en los proyectos agiles es la persona responsable de maximizar el retorno de la inversión del proyecto planificando con el equipo entregas de incrementos del producto funcional que aporten valor al cliente. Para poder realizar este trabajo, ¿Qué artefacto usa el producto owner para conseguirlo? Matriz de riesgos Gráficos de quemado Análisis de coste / beneficio El product backlog IncorrectoEl producto owner es propietario del product backlog, él es el encargado de escribir las historias de usuario/requisitos que lo componen y de su priorización. Por lo que en la parte alta del product backlog están las historias de usuario con mayor valor para el cliente y mayor riesgo asociado, porque nos interesa eliminar o mitigar el riesgo de forma temprana también. En la planificación de las iteraciones el equipo ágil discute el objetivo de la iteración seleccionando las historias de usuario de la parte alta del product backlog según su capacidad (velocidad) para asegurar la entrega de valor al cliente. CorrectoEl producto owner es propietario del product backlog, él es el encargado de escribir las historias de usuario/requisitos que lo componen y de su priorización. Por lo que en la parte alta del product backlog están las historias de usuario con mayor valor para el cliente y mayor riesgo asociado, porque nos interesa eliminar o mitigar el riesgo de forma temprana también. En la planificación de las iteraciones el equipo ágil discute el objetivo de la iteración seleccionando las historias de usuario de la parte alta del product backlog según su capacidad (velocidad) para asegurar la entrega de valor al cliente. 88 / 114 Estamos en la segunda iteración de nuestro proyecto ágil, hemos sido contratados para desarrollar una plataforma de compra online para el cliente CEOLEVEL.INC que hasta el momento solo tenían tiendas físicas a nivel nacional. En el roadmap de proyecto (hoja de ruta) tenemos una entrega al final de iteración 6 donde entregaremos el MVP. ¿Qué debería contener este MVP? Es cuando generamos una característica de nuestro producto en su totalidad, en este caso podría ser el motor de búsqueda de nuestra página web donde hubiéramos llenado la base de datos de todos nuestros productos, pudiéramos hacer búsquedas por nombres, categorías, nos mostrará productos relacionados y recomendaciones. Las características críticas de nuestro producto en un estado sencillo y funcional, casi a modo prototipo, sin evolucionar las funcionalidades, para obtener un feedback temprano del producto y poder adaptar cambios a las necesidades que identifiquen los usuarios/stakeholders. Debería ser un prototipo, sin funcionabilidad, únicamente para obtener feedback y ver si es viable la idea. La arquitectura total del producto, aunque no sea funcional, ya que son los cimientos para poder desarrollar las funcionalidades requeridas en las siguientes iteraciones y poder aportar valor al cliente. IncorrectoUn producto mínimo viable MVP es un producto con suficientes características para satisfacer a los clientes iniciales, y proporcionar retroalimentación para el desarrollo futuro.Le permite probar una idea exponiendo una versión temprana de su producto a los usuarios y clientes objetivo, para recopilar la información relevante y aprender de ella. Evita la creación de productos que los clientes no desean y es más cercano a los prototipos que a la versión real del producto final. CorrectoUn producto mínimo viable MVP es un producto con suficientes características para satisfacer a los clientes iniciales, y proporcionar retroalimentación para el desarrollo futuro.Le permite probar una idea exponiendo una versión temprana de su producto a los usuarios y clientes objetivo, para recopilar la información relevante y aprender de ella. Evita la creación de productos que los clientes no desean y es más cercano a los prototipos que a la versión real del producto final. 89 / 114 Un Scrum Master mantiene Scrums diarios y los mantiene en 15 minutos o menos. El Scrum Master trae una lista de tareas asignadas y verifica el estado de cada tarea con los miembros relevantes del equipo. El Scrum Master luego asigna nuevas tareas para el día y finaliza la reunión. ¿Es este un enfoque apropiado para ejecutar en los scrums diarios? Sí, el Scrum Master debería recibir actualizaciones de estado y distribuir nuevas tareas al equipo No, el Scrum Master debe actuar como facilitador de la reunión para fomentar la autoorganización del equipo. No, el Scrum Master también debe actualizar métricas en la reunión. Sí, El Scrum Master debe mantener Scrums diariamente y mantener el tiempo en 15 minutos o menos. IncorrectoEl scrum master no debe participar en la reunión, únicamente debe asegurarse de facilitarla y de que se produzca. Puede estar en la reunión pero no participar. CorrectoEl scrum master no debe participar en la reunión, únicamente debe asegurarse de facilitarla y de que se produzca. Puede estar en la reunión pero no participar. 90 / 114 Durante una reunión de refinamiento del product backlog el producto owner explica al equipo ágil el principio de Pareto o regla 80/20 y lo aplica en la priorización del product backlog. ¿Qué quiere decir con ello? Que las peticiones de los interesados del proyecto suelen ser las más importantes para el producto. Que un pequeño porcentaje de trabajo proporcionará un gran porcentaje de valor en el producto. Que los riesgos del proyecto no son siempre negativos Que una característica de un producto no tiene valor hasta que no está implementada. IncorrectoEl propósito de aplicar el Principio de Pareto al product backlog es que se necesitas principalmente enfocarte en ese 20 por ciento crítico para alcanzar el 80 por ciento de la satisfacción del cliente. CorrectoEl propósito de aplicar el Principio de Pareto al product backlog es que se necesitas principalmente enfocarte en ese 20 por ciento crítico para alcanzar el 80 por ciento de la satisfacción del cliente. 91 / 114 Un patrocinador está tratando de determinar qué proyecto tiene el mayor valor comercial. Un proyecto devuelve cinco millones de euros en 3 años y otro proyecto devuelve seis millones de euros en cuatro años. El coste de pedir prestado capital para financiar el proyecto es del cuatro por ciento. ¿Cuál de los siguientes es el mejor enfoque para determinar el proyecto con mayor valor? Calcular el NPV (Net Present Value, Valor Actual Neto) de los proyectos y elegir el proyecto con el menor coste. Calcular el NPV (Net Present Value, Valor Actual Neto) de los proyectos y elegir el proyecto de mayor valor. Seleccionar el proyecto que devuelve seis millones de euros en cuatro años, ya que devuelve la cantidad más alta. Seleccionar el proyecto que devuelve cinco millones de euros en tres años, ya que tiene el período de recuperación más corto. IncorrectaComo el enunciado nos está diciendo que hemos pedido un crédito con el coste del 4% no podemos calcular directamente el ROI (retorno de la inversión) por lo que debemos calcular el NPV (valor actual neto) y la premisa es que mientras más alto sea el NPV más beneficioso es. CorrectoComo el enunciado nos está diciendo que hemos pedido un crédito con el coste del 4% no podemos calcular directamente el ROI (retorno de la inversión) por lo que debemos calcular el NPV (valor actual neto) y la premisa es que mientras más alto sea el NPV más beneficioso es. 92 / 114 Tu equipo ágil está comenzando una nueva versión del producto final. El equipo avanza un poco más lento de lo que se esperaba con las predicciones de velocidad del equipo. El manager ágil está adoptando un enfoque de liderazgo servicial. ¿Cuál de las siguientes acciones es más probable que realice el manager ágil? Controlar al equipo para que cumplan con lo que se han comprometido. Reportar la bajada de rendimiento a los managers funcionales de cada miembro del equipo. Trabajar con el equipo en el desarrollo del producto. Realizar actividades administrativas para el equipo. IncorrectoEl líder ágil debe proteger al equipo de interrupciones y realizará tareas administrativas para el equipo en caso de necesidad para liberarlo y enfocarlo a entregar valor durante la iteración. CorrectoEl líder ágil debe proteger al equipo de interrupciones y realizará tareas administrativas para el equipo en caso de necesidad para liberarlo y enfocarlo a entregar valor durante la iteración. 93 / 114 Durante la hora de comer, te juntas con compañeros de otro equipo de proyecto ágil de tu organización y te comentan que ellos antes de empezar a desarrollar las funcionabilidades del producto diseñan los test y luego implementan el código, te explican los beneficios de está practica y por qué lo realizan de esta manera. ¿Qué técnica están utilizando? Test-Driven Development Extreme Programming Pair Programming Feature-Driven Development IncorrectoTTD o TFD se basan en el mismo principio y es que las pruebas guíen el desarrollo, es decir que antes de empezar a implementar el código de la historia de usuario primero escribimos los test y con esto cerramos “alcance” de la historia de usuario, porque implementaremos el código únicamente necesario para pasar la prueba y dar por buena la historia de usuario, el código a de ser simple, siguiendo la practica de simplicidad de extreme programming y que iremos evolucionando únicamente si los requerimientos del software a construir así lo solicitan. Una vez escrito el test se ejecuta para ver que falle, porque no hemos implementado el código aún, una vez validado que falla implementamos el código simple para pasar el test y volvemos a ejecutar el test para validar que ahora si lo pasamos, cuando pasamos el test refactorizamos el código “borrador” para cumplir con los estándares de programación que hayamos definido, como código con comentarios, tabulaciones, optimizado, entendible para todos, etc. y damos por cerrada la historia de usuario que se presentara en la reunión de revisión al final de la iteración junto a las demás generando el incremento de esa iteración. CorrectoTTD o TFD se basan en el mismo principio y es que las pruebas guíen el desarrollo, es decir que antes de empezar a implementar el código de la historia de usuario primero escribimos los test y con esto cerramos “alcance” de la historia de usuario, porque implementaremos el código únicamente necesario para pasar la prueba y dar por buena la historia de usuario, el código a de ser simple, siguiendo la practica de simplicidad de extreme programming y que iremos evolucionando únicamente si los requerimientos del software a construir así lo solicitan. Una vez escrito el test se ejecuta para ver que falle, porque no hemos implementado el código aún, una vez validado que falla implementamos el código simple para pasar el test y volvemos a ejecutar el test para validar que ahora si lo pasamos, cuando pasamos el test refactorizamos el código “borrador” para cumplir con los estándares de programación que hayamos definido, como código con comentarios, tabulaciones, optimizado, entendible para todos, etc. y damos por cerrada la historia de usuario que se presentara en la reunión de revisión al final de la iteración junto a las demás generando el incremento de esa iteración. 94 / 114 Trabajamos en un proyecto ágil con entregas iterativas e incrementales y el equipo empieza a identificar advertencias, problemas en el rendimiento frente a la planificación que habían realizado. ¿Dónde identificaremos en la mayoría de casos estos problemas por primera vez? En la reunión diaria. En las entregas del producto. En la retrospectiva. En las revisiones del producto. IncorrectoEn la reunión diaria que dura 15 min máximo, cada miembro del equipo expone con que ha estado trabajando el día anterior, con que trabajará hoy y que problemas se ha encontrado o sabe que se va a encontrar. La reunión diaria (daily meeting, stand-up meeting, daily) suele ser donde saltan las alarmas por primera vez al identificar bloqueos, problemas no identificados anteriormente, riesgo asociados, etc. CorrectoEn la reunión diaria que dura 15 min máximo, cada miembro del equipo expone con que ha estado trabajando el día anterior, con que trabajará hoy y que problemas se ha encontrado o sabe que se va a encontrar. La reunión diaria (daily meeting, stand-up meeting, daily) suele ser donde saltan las alarmas por primera vez al identificar bloqueos, problemas no identificados anteriormente, riesgo asociados, etc. 95 / 114 Un miembro del equipo de dirección se interesa por el proyecto en el que estás trabajando como practicante ágil ya que es uno de los primeros en la organización que se realiza con este framework. No pide que le expliquemos que quiere decir que trabajamos con ciclos de entrega incrementales. ¿Cuál sería la respuesta más adecuada que le deberíamos dar? Significa que hacemos una panificación adaptativa e incremental para hacer una mejor entrega de valor en cada iteración. Significa que hacemos una planificación simple, primero entregamos lo más sencillo y luego añadimos detalle al producto. Es lo mismo que el modelo tradicional (waterfall) pero con entregas más frecuentes. Quiere decir que hacemos una planificación progresiva de menos a más. IncorrectoLos ciclos de entrega incrementales son básicos para asegurar transparencia, inspección y adaptación en los proyectos ágiles, asegurando que los incrementos cumplen las necesidades de los interesados de forma temprana y permitiéndonos ajustar la entrega de valor al feedback de los mismo. Además nos proporciona un ROI más temprano en el proyecto, ya que nos permite generar incrementos funcionales más pequeños. CorrectoLos ciclos de entrega incrementales son básicos para asegurar transparencia, inspección y adaptación en los proyectos ágiles, asegurando que los incrementos cumplen las necesidades de los interesados de forma temprana y permitiéndonos ajustar la entrega de valor al feedback de los mismo. Además nos proporciona un ROI más temprano en el proyecto, ya que nos permite generar incrementos funcionales más pequeños. 96 / 114 Durante la ejecución de un proyecto, un equipo nuevo en prácticas agiles, su primer proyecto, pregunta al líder porque se sigue midiendo la velocidad del equipo una vez estabilizada. El equipo entiende que en las primeras iteraciones hay variaciones importantes en esta métrica debidas a la incertidumbre de los inicios de proyecto y del funcionamiento del equipo que se está conociendo y aprendiendo a trabajar conjuntamente y que esto afecta a la capacidad de trabajo que pueden planificar para las siguientes iteraciones, pero una vez estabilizada cree que no es necesario seguir midiéndola. ¿Cómo debería responder el líder ágil del equipo? La métrica de la velocidad de equipo además de ayudar en la capacitación de trabajo en las planificaciones de iteración también sirve de línea base para ver como la mejora continua del equipo se refleja en ella y validar que las acciones de mejora están funcionando. Esta métrica sirve para comparar el rendimiento de los equipos en proyectos de la organización con características similares. La métrica de la velocidad de equipo sirve a los gerentes funcionales para medir el rendimiento de los miembros del equipo, y se añaden como objetivos de carrera de cada persona, asegurando de esta manera la implicación de cada uno de ellos en el proyecto. La métrica de la velocidad del equipo además de ayudar en la capacitación de trabajo en las planificaciones de iteración también se usa para que los interesados del proyecto sean conscientes del trabajo realizado por el equipo, es la forma de ver el valor entregado al cliente. IncorrectaEn los proyectos ágiles la mejora continua es una norma, ciclos cortos de trabajo, inspección y adaptación en función de lo aprendido para mejorar. Por lo que la métrica de la velocidad además de ayudar a afinar la capacitación el equipo a comprometerse con el trabajo de la iteración ayuda a observar la mejora en esta mejora continua. Ayuda a ver que acciones de mejora resultado de las retrospectivas han ayudado a mejorar al equipo y cuales no, las que ayudan a mejorar se mantienen a lo largo del proyecto y las que penalizan se eliminan al observar los resultados. El encargado de analizar y rastrear esta velocidad de equipo en busca de mejoras es el líder ágil, coach, scrum master, el nombre cambiará dependiendo del framework que estemos usando. CorrectoEn los proyectos ágiles la mejora continua es una norma, ciclos cortos de trabajo, inspección y adaptación en función de lo aprendido para mejorar. Por lo que la métrica de la velocidad además de ayudar a afinar la capacitación el equipo a comprometerse con el trabajo de la iteración ayuda a observar la mejora en esta mejora continua. Ayuda a ver que acciones de mejora resultado de las retrospectivas han ayudado a mejorar al equipo y cuales no, las que ayudan a mejorar se mantienen a lo largo del proyecto y las que penalizan se eliminan al observar los resultados. El encargado de analizar y rastrear esta velocidad de equipo en busca de mejoras es el líder ágil, coach, scrum master, el nombre cambiará dependiendo del framework que estemos usando. 97 / 114 Nuestro equipo de desarrollo ágil está teniendo problemas para tomar decisiones conjuntamente y llegar acuerdos. Esto está generando crispación en alguna de las personas del equipo. El rendimiento del equipo sigue siendo bueno y estable. ¿Cómo debería actuar el practicante ágil ante esta situación? No debería hacer nada ya que los resultados siguen siendo buenos en el proyecto. Debería informar a los managers funcionales de las personas que entran en conflicto para que tomen acciones correctivas. Debería observar las disputas desde una posición “alejada” y dejar que el equipo resuelva el conflicto por sí solo. Debería actuar en los conflictos de inmediato para que no generen un problema, tomando decisiones drásticas. IncorrectoEl equipo de desarrollo debe ser autogestionado y autosuficiente, por lo que debe ser capaz de resolver sus conflictos por si solos sin la mediación de nadie. Si el practicante ágil identificara que el conflicto no se resuelve y se escala llegando a un punto crítico debería actuar, pero hacerlo antes sería contraproducente para el equipo ya que esto les sirve para crecer. Si el practicante ágil resuelve todas las disputas el equipo no sabrá cómo solucionarlas por sí solos y retrasará su desarrollo grupal restándoles autonomía en su día a día. CorrectoEl equipo de desarrollo debe ser autogestionado y autosuficiente, por lo que debe ser capaz de resolver sus conflictos por si solos sin la mediación de nadie. Si el practicante ágil identificara que el conflicto no se resuelve y se escala llegando a un punto crítico debería actuar, pero hacerlo antes sería contraproducente para el equipo ya que esto les sirve para crecer. Si el practicante ágil resuelve todas las disputas el equipo no sabrá cómo solucionarlas por sí solos y retrasará su desarrollo grupal restándoles autonomía en su día a día. 98 / 114 Estas en una reunión con todo el equipo ágil estimando historias de usuario (requisitos) que se han introducido nuevas en el product backlog. La sesión está transcurriendo con normalidad, pero en este punto estáis estimando una historia de usuario compleja y el equipo de desarrollo llega a consenso de que su valor en estimación relativa es de trece puntos de historia. El producto owner quiere incluir esa historia de usuario en la próxima iteración y viendo la capacidad del equipo de desarrollo y que tiene otras historias de usuario prioritarias le pide al equipo que rebaje la estimación de la historia de usuario a cinco puntos ya que así podrán incluirla en la iteración siguiente y el incremento tendrá más valor para el cliente. ¿Debería aceptar el equipo de desarrollo? No, porque el único que podría cambiar la estimación sería el manager. Sí, porque prima la entrega de valor al cliente de forma temprana y el equipo tiende a poner colchones en las estimaciones. Sí, porque como indica el nombre es una estimación relativa y el producto owner puede ajustarla en última instancia. No, porque el equipo de desarrollo es el único que puede estimar el trabajo y deben ser estimaciones realistas y consensuadas entre todos los miembros. IncorrectoNadie más que el equipo de desarrollo puede estimar las historias de usuario. Ellos son las personas que la han de implementar y los que tienen los conocimientos técnicos para poderla realizar por lo tanto solo ellos pueden estimar trabajo y el resto del equipo (product owner, líder ágil) han de respectarlo. CorrectoNadie más que el equipo de desarrollo puede estimar las historias de usuario. Ellos son las personas que la han de implementar y los que tienen los conocimientos técnicos para poderla realizar por lo tanto solo ellos pueden estimar trabajo y el resto del equipo (product owner, líder ágil) han de respectarlo. 99 / 114 Durante la retrospectiva de la iteración ocho de nuestro proyecto el practicante ágil identifica analizando los resultados de la iteración, que una de las mejoras de proceso propuesta por un miembro del equipo (aprobada por el resto en la retrospectiva anterior) y que se aplicó en la iteración en curso no ha dado resultado y ha empeorado el rendimiento del equipo. ¿Cómo deberíamos actuar? Felicitar al equipo por poner en practica la idea y dejar más tiempo para ver si los resultados mejoran en siguientes iteraciones. Revertir el proceso de mejora que se implementó de la retrospectiva anterior y alentar al equipo a seguir buscando mejoras para el proyecto. Informar al responsable de carrera de la persona que tuvo la idea y dejar constancia en su evaluación personal del problema de rendimiento que ha ocasionado. Revertir el proceso de mejora que se implementó y vetar a la persona que propuso la idea en esta retrospectiva. IncorrectoParte de la mejora continua es buscar áreas de mejora en las restrospectivas y aplicar acciones en las siguientes iteraciones. El practicante ágil, líder, debe ser inspirador para los miembros del equipo y incitarlo a innovar y probar mejoras creando un entorno donde se puedan tomar riesgos controlados para mejorar y eso no penalice, se aprender de la experiencia. La agilidad nos brinda la oportunidad de poder introducir mejoras que medimos en periodos cortos, viendo si son útiles para el equipo o por lo contrario penalizan, el beneficio de encontrar mejoras que mantendremos durante todo el proyecto a mejoras que empeoran el rendimiento en una única iteración y que descartamos tras analizar los resultados es muy grande. Por lo que el líder ágil debe inspirar al equipo a seguir probando mejoras y protegerlo cuando estas no funcionen de retractores, ya que es parte del aprendizaje y de la mejora continua. En las retrospectivas descubriremos decisiones y acciones que nos gustaría poder hacer. Esto es sabiduría y se debería celebrar, no ser usado para avergonzar a nadie. CorrectoParte de la mejora continua es buscar áreas de mejora en las restrospectivas y aplicar acciones en las siguientes iteraciones. El practicante ágil, líder, debe ser inspirador para los miembros del equipo y incitarlo a innovar y probar mejoras creando un entorno donde se puedan tomar riesgos controlados para mejorar y eso no penalice, se aprender de la experiencia. La agilidad nos brinda la oportunidad de poder introducir mejoras que medimos en periodos cortos, viendo si son útiles para el equipo o por lo contrario penalizan, el beneficio de encontrar mejoras que mantendremos durante todo el proyecto a mejoras que empeoran el rendimiento en una única iteración y que descartamos tras analizar los resultados es muy grande. Por lo que el líder ágil debe inspirar al equipo a seguir probando mejoras y protegerlo cuando estas no funcionen de retractores, ya que es parte del aprendizaje y de la mejora continua. En las retrospectivas descubriremos decisiones y acciones que nos gustaría poder hacer. Esto es sabiduría y se debería celebrar, no ser usado para avergonzar a nadie. 100 / 114 En tu empresa se gestionan proyectos de forma tradicional y ágil dependiendo de las características del propio proyecto. Se forma un equipo ágil de desarrollo que hasta ahora solo había trabajado con el modelo tradicional para trabajar con un enfoque adaptativo. El equipo cuenta contigo, un practicante ágil con experiencia que les guiará en el proyecto. Cuando el nuevo equipo de desarrollo ágil es informado de que el alcance del proyecto no está cerrado desde el inicio empiezan a tener dudas de cómo se medirá el progreso. ¿Cómo practicante ágil que deberías decirles al equipo? El progreso se mide con el número de historias de usuario finalizadas en cada iteración. El incremento generado al final de la iteración (potencialmente entregable) de valor demostrable al cliente es la mejor medida. Con la métrica de velocidad del equipo. Que el equipo de desarrollo tiene que autogestionarse y esta empoderado para tomar sus propias decisiones, por lo que no existen métricas de progreso. IncorrectoLos valores ágiles nos dicen que la mejor medida de progreso de un proyecto es el producto funcionando, por lo que mejor que cualquier métrica de estado o reporte, ya que trabajamos con iteraciones cortas que promueven la entrega de incrementos funcionales del producto al final de las mimas, esta es la mejor medida. CorrectoLos valores ágiles nos dicen que la mejor medida de progreso de un proyecto es el producto funcionando, por lo que mejor que cualquier métrica de estado o reporte, ya que trabajamos con iteraciones cortas que promueven la entrega de incrementos funcionales del producto al final de las mimas, esta es la mejor medida. 101 / 114 Nos encontramos en la fase inicial de un proyecto que realizaremos con un framework ágil debido a la incertidumbre inicial. Se está generando el acta de constitución del proyecto en este punto, el cliente está entrando en mucho detalle de las características del proyecto y el cómo se realizarán haciendo crecer este documento a varias páginas. ¿Cómo practicante ágil que consideraciones deberíamos hacer? Los enfoques agiles se centran en colaboración de ambas partes para saber que construir y aportar el máximo valor al producto de forma temprana antes que en debatir muchos detalles del contrato. En los enfoques agiles no se firma un contrato En los enfoques agiles debe detallarse claramente el alcance del proyecto en el acta de constitución, ya que al ser un modelo adaptativo y poder introducir cambios debe quedar muy claro el alcance desde el inicio. Los enfoques ágiles recomiendan no centrarse demasiado en la negociación de contratos, ya que la mayoría de los clientes se preocupan por sí mismos de todos modos. IncorrectoDebido a la incertidumbre inicial de los proyectos ágiles bajar al detalle todo el producto es imposible, además los frameworks ágiles están construidos para tener una inspección y adaptación continua según las necesidades que vayamos identificando durante el proyecto. Detallar en el contrato el alcance requeriría una fase inicial de análisis que retardaría la entrega de valor y no aseguraría que las características de negocio que definiéramos en el fueran realmente las necesidades de negocio requeridas realmente para los interesados y usuarios finales debido a la complejidad del proyecto en sí. La mejor forma de abordar los proyectos complejos es de una forma colaborativa para tener el máximo feedback en iteraciones cortas que nos aseguren poder inspeccionar y adaptar nuestro producto a las necesidades reales del mercado, negocio de forma rápida y eliminando desperdicio o rework. CorrectoDebido a la incertidumbre inicial de los proyectos ágiles bajar al detalle todo el producto es imposible, además los frameworks ágiles están construidos para tener una inspección y adaptación continua según las necesidades que vayamos identificando durante el proyecto. Detallar en el contrato el alcance requeriría una fase inicial de análisis que retardaría la entrega de valor y no aseguraría que las características de negocio que definiéramos en el fueran realmente las necesidades de negocio requeridas realmente para los interesados y usuarios finales debido a la complejidad del proyecto en sí. La mejor forma de abordar los proyectos complejos es de una forma colaborativa para tener el máximo feedback en iteraciones cortas que nos aseguren poder inspeccionar y adaptar nuestro producto a las necesidades reales del mercado, negocio de forma rápida y eliminando desperdicio o rework. 102 / 114 Durante la iteración un miembro del equipo no es capaz de llegar a un acuerdo con un interesado del proyecto sobre el diseño de la interfaz web de una aplicación interna. ¿Qué sería lo más adecuado usar en esta situación? Votación Diagrama Ishikawa Brainstorming Prototipos IncorrectoLos prototipos (wireframes) son la herramienta más adecuada para este tipo de conflictos, ya que nos ahorra tiempo de construcción y nos ayuda a valida la idea. CorrectoLos prototipos (wireframes) son la herramienta más adecuada para este tipo de conflictos, ya que nos ahorra tiempo de construcción y nos ayuda a valida la idea. 103 / 114 Estamos trabajando en proyecto grande, donde construiremos un producto para una gran multinacional. Para cumplir con lo acordado se estima que se necesitan cinco equipos ágiles trabajando en paralelo sobre el mismo producto. ¿Cuántos product backlogs necesito para este generar este producto? Depende del tamaño de los equipos. Por cada 8 miembros deben tener su propio product backlog. Dividiremos el trabajo en X product backlogs en función de las habilidades del equipo. Uno. El product backlog es común para todos los equipos del proyecto. Cinco. Cada equipo ha de trabajar con un product backlog. IncorrectoSolo puede haber un product backlog por producto. Luego cada equipo en la planificación de su iteración formará su backlog de iteración (sprint backlog), con el que trabajaran durante la propia iteración. CorrectoSolo puede haber un product backlog por producto. Luego cada equipo en la planificación de su iteración formará su backlog de iteración (sprint backlog), con el que trabajaran durante la propia iteración. 104 / 114 Estamos empezando nuestro proyecto, se ha firmado el acta de constitución del proyecto, se ha realizado una reunión de inicio de proyecto con el equipo ágil y empezamos la primera iteración. Hemos realizado la planificación de la primera iteración con el equipo y el product owner ha priorizado los PBIs (Product Backlog Items) para la segunda y tercera iteración del proyecto en función del valor y mitigación de riesgos. Durante el transcurso de la primera iteración las condiciones de mercado han cambiado y necesitamos ajustar las características del producto. ¿Cómo deberíamos actuar? El PO debe comunicar al resto del equipo ágil la importancia de adaptar las necesidades de negocio al cambio de las condiciones de mercado y realizar una reunión para refinar el product backlog ajustándolo a los cambios. Se debe reunir el PO y el líder del equipo ágil para volver a priorizar los requisitos del proyecto. Debemos abrir una petición de cambio ya que las nuevas características del producto por el cambio en las condiciones de mercado ya que esto afectará al alcance inicialmente definido en el acta de constitución del proyecto. Si se aprueba el cambio deberemos repriorizar el product backlog con las nuevas características. Debemos seguir la planificación de las tres primeras iteraciones y después ajustar las características del producto a las necesidades actuales del mercado. IncorrectoAdaptar el cambio a las necesidades del mercado o a nuevas características identificadas en las revisiones del producto por los interesados de forma temprana es una característica de la agilidad asegurando la entrega de valor al cliente y eliminando el desperdicio para que no afecte de manera negativa en el proyecto. El PO es responsable de priorizar el product backlog pero debe informar a todo el equipo de los cambios que se vayan realizado en el mismo ya que ellos serán quien implementaran los cambios en el producto, decidirán como hacerlos y cuanto les costará hacerlo. Por lo que en este tipo de cambios de prioridades debemos involucrar a todo el equipo idealmente. CorrectoAdaptar el cambio a las necesidades del mercado o a nuevas características identificadas en las revisiones del producto por los interesados de forma temprana es una característica de la agilidad asegurando la entrega de valor al cliente y eliminando el desperdicio para que no afecte de manera negativa en el proyecto. El PO es responsable de priorizar el product backlog pero debe informar a todo el equipo de los cambios que se vayan realizado en el mismo ya que ellos serán quien implementaran los cambios en el producto, decidirán como hacerlos y cuanto les costará hacerlo. Por lo que en este tipo de cambios de prioridades debemos involucrar a todo el equipo idealmente. 105 / 114 Al final de la iteración tres de nuestro proyecto ágil el equipo ha finalizado veintitrés puntos de historia. ¿Qué representan estos veintitrés puntos de historia? Que él equipo ha tenido problemas en la iteración porque realizar menos de treinta puntos de historia por iteración indica bajo rendimiento y el líder ágil debe revisar que ha pasado. Cycle Time Velocidad del equipo Time to Market IncorrectoLa velocidad del equipo es el resultado de las historias de usuario finalizadas durante la iteración. CorrectoLa velocidad del equipo es el resultado de las historias de usuario finalizadas durante la iteración. 106 / 114 Te encuentras en una fase avanzada de tu proyecto de creación de software. Tu equipo tiene un promedio de 40 puntos de historia por iteración de dos semanas. Os quedan 200 puntos historia de funcionalidad en el product backlog para finalizar el proyecto. ¿Cuántas semanas esperas que pasen hasta que se complete el desarrollo? 20 5 2.5 10 IncorrectoLa respuesta correcta son 10 semanas. Las iteraciones en el proyecto, según el enunciado de la pregunta, son cada dos semanas y realizamos 40 puntos de historia cada dos semanas, si dividimos 40/2 para saber cuantos puntos generamos en una semana, el resultado son 20. Por lo tanto debemos dividir los 200 puntos de historia restantes que quedan en el product backlog entre los 20 puntos que realizamos a la semana (de forma estimada). 200/20 = 10. Si mantenemos la velocidad de equipo en 10 semanas acabaremos el trabajo estimado del product backlog. Que a su vez sería 5 iteraciones del proyecto al ser de dos semanas. CorrectoLa respuesta correcta son 10 semanas. Las iteraciones en el proyecto, según el enunciado de la pregunta, son cada dos semanas y realizamos 40 puntos de historia cada dos semanas, si dividimos 40/2 para saber cuantos puntos generamos en una semana, el resultado son 20. Por lo tanto debemos dividir los 200 puntos de historia restantes que quedan en el product backlog entre los 20 puntos que realizamos a la semana (de forma estimada). 200/20 = 10. Si mantenemos la velocidad de equipo en 10 semanas acabaremos el trabajo estimado del product backlog. Que a su vez sería 5 iteraciones del proyecto al ser de dos semanas. 107 / 114 Nuestra organización empieza un proyecto ágil y está formando el equipo que desarrollara el producto. ¿Cuál sería el planteamiento ideal a la hora de formar el equipo en referencia a personas asignadas a tiempo parcial al proyecto? Permitir tener personas asignadas a un porcentaje en el proyecto siempre y cuando no sean recursos críticos del proyecto. Intentar evitar las asignaciones a porcentaje en el proyecto, asignar recursos a un solo proyecto. No importa que una persona esta asignada a un porcentaje al proyecto porque no penalizad en el rendimiento del equipo. No permitir que los miembros del equipo sean asignados a más de dos proyectos a la vez. IncorrectoNos preguntan el planteamiento ideal por lo que la respuesta correcta sería intentar evitar asignaciones a porcentajes. Los equipos ágiles son altamente colaborativos y tener personas a porcentajes puede ser fuente de futuros problemas. Además, la multitarea, hacer cambios de proyecto reducen el rendimiento de esa persona según los estudios significativamente, hasta un 40% del trabajo puede ser en cambios de proyecto, urgencias criticas del otro proyecto, lag de información, etc. Por lo que idealmente intentaremos evitarlo, aunque no siempre será posible. CorrectoNos preguntan el planteamiento ideal por lo que la respuesta correcta sería intentar evitar asignaciones a porcentajes. Los equipos ágiles son altamente colaborativos y tener personas a porcentajes puede ser fuente de futuros problemas. Además, la multitarea, hacer cambios de proyecto reducen el rendimiento de esa persona según los estudios significativamente, hasta un 40% del trabajo puede ser en cambios de proyecto, urgencias criticas del otro proyecto, lag de información, etc. Por lo que idealmente intentaremos evitarlo, aunque no siempre será posible. 108 / 114 Estamos trabajando en un proyecto ágil utilizando el framework de Scrum y hay discrepancias en cuanto a la priorización del product backlog, los interesados del proyecto no se ponen de acuerdo en cuales son las características prioritarias ya que cada uno defiende que las que afectan a su área son las más importantes y por tanto las que se tendrían que desarrollar primero y no consiguen llegar a consenso. En el propio equipo scrum también surgen discrepancias en cuanto a cuáles serían las características prioritarias para asegurar el éxito del proyecto. ¿En estos casos como se debería actuar? EL dueño del producto (PO, Product Owner) siempre tiene la responsabilidad de hacer la priorización del product backlog. La PMO (oficina de proyecto) del proyecto debería tomar parte y decidir cuales sería la correcta priorización de las características en el product backlog. El jefe de equipo/arquitecto debe ser quien tome la decisión en base a su experiencia. El equipo de desarrollo es quien decide la priorización del product backlog ya que son ellos quien realizarán el trabajo y deciden el que, cuando y el cómo hacerlo. IncorrectoEl Product Owner es el conocedor del negocio y una de sus responsabilidades principales es priorizar el product backlog en función del valor que aporta al producto teniendo en cuenta valor aportado y la reducción de riesgos en el proyecto. Puede ayudarse de expertos, stakeholders, etc. pero la última palabra y la decisión final de como priorizarlo es suya. CorrectoEl Product Owner es el conocedor del negocio y una de sus responsabilidades principales es priorizar el product backlog en función del valor que aporta al producto teniendo en cuenta valor aportado y la reducción de riesgos en el proyecto. Puede ayudarse de expertos, stakeholders, etc. pero la última palabra y la decisión final de como priorizarlo es suya. 109 / 114 Durante la reunión diaria de un equipo ágil compuesto por seis personas un miembro del equipo dice que no puede empezar sus tareas del sprint hasta que no finalice unas tareas que tiene en curso de otro proyecto al que también está asignado. Viendo del rendimiento del equipo y haciendo una predicción del mismo consideran que no van a poder finalizar el objetivo del sprint a tiempo. ¿Qué se debería haber hecho diferente para evitar esta situación? El equipo debería haber trabajado más rápido para compensar esta situación. El equipo debería haber tenido en cuenta en la planificación del sprint la disponibilidad de las personas. Tendrían que tener un equipo más grande para poder compensar este tipo de situaciones. Se debería haber hablado con el producto owner del proyecto para incluir una persona más en el equipo en esa iteración. IncorrectoCuando el equipo ágil realiza la planificación de la iteración ha de tener en cuenta, disponibilidad de las personas, %de asignación, festivos, etc. para poder hacer una planificación realista y poder cumplir con el objetivo marcado al final de esta reunión. CorrectoCuando el equipo ágil realiza la planificación de la iteración ha de tener en cuenta, disponibilidad de las personas, %de asignación, festivos, etc. para poder hacer una planificación realista y poder cumplir con el objetivo marcado al final de esta reunión. 110 / 114 Cuando comparamos estilos de comunicación, ¿Cuál de las siguientes sentencias es cierta? La comunicación cara a cara tiene la mayor eficiencia y la menor riqueza. La comunicación basada en papel tiene la mayor eficiencia y la menor riqueza. La comunicación basada en papel tiene la menor eficiencia y la mayor riqueza. La comunicación cara a cara tiene la mayor eficiencia y la mayor riqueza. IncorrectoLa comunicación cara a cara tiene la mayor eficiencia y la mayor riqueza y en los frameworks ágiles es de gran importancia como se indica en los principios ágiles recogidos en el agile manifesto. CorrectoLa comunicación cara a cara tiene la mayor eficiencia y la mayor riqueza y en los frameworks ágiles es de gran importancia como se indica en los principios ágiles recogidos en el agile manifesto. 111 / 114 Los proyectos ágiles son altamente colaborativos, donde la comunicación entre equipo y cliente es básica para obtener buenos resultados en el proyecto, al partir de un alcance no definido en su totalidad y siempre que se pueda manteniendo conversaciones cara a cara (F2F communication). Por ello la comunicación ágil es importante porque: En las comunicaciones agiles intervienen de forma clave los radiadores de comunicación, como graficas de quemado, matriz de riesgos, etc. para que todas las personas interesadas estén informadas en cualquier momento y esto elimina los cambios en los requerimientos del proyecto. La planificación de versiones e iteraciones mantiene a las personas del equipo alineadas, la reunión diaria elimina la confusión, las revisiones/demostraciones de iteraciones mantienen al equipo enfocado en los entregables y las retrospectivas nos permiten realizar una mejora continua en el proyecto. La planificación de la iteración diaria permite gestionar el cambio y las reuniones semanales garantizan que los impedimentos se identifiquen rápidamente y se gestionen o eliminen de forma eficaz, eliminando el desperdicio y favoreciendo la entrega de valor constante. Los métodos de comunicación ágiles se centran en requisitos y especificaciones detallados y escritos que son más completos y permiten al equipo gestionar el cambio de forma más eficaz. IncorrectoLa comunicación en los proyectos agiles es de vital importancia y está respaldada por los eventos (reuniones) del propio framework para asegurar las inspección, transparencia y adaptación en el proyecto para identificar de forma temprana, impedimentos, desperdicio y nuevas funcionalidades para asegurar la entrega de valor al cliente que nos guía con su feedback. CorrectoLa comunicación en los proyectos agiles es de vital importancia y está respaldada por los eventos (reuniones) del propio framework para asegurar las inspección, transparencia y adaptación en el proyecto para identificar de forma temprana, impedimentos, desperdicio y nuevas funcionalidades para asegurar la entrega de valor al cliente que nos guía con su feedback. 112 / 114 Estamos realizando un proyecto con el framework de Srcum, ¿Cuál de los siguientes roles no sería un rol del framework? Scrum Master Product Owner Development Team Project Manager IncorrectoEn scrum los roles del equipo ágil son Product Owner, Scrum Master y Development Team. El Project Manager no forma parte de los roles promovidos por Scrum. CorrectoEn scrum los roles del equipo ágil son Product Owner, Scrum Master y Development Team. El Project Manager no forma parte de los roles promovidos por Scrum. 113 / 114 Estamos trabajando en proyecto ágil con el framework de Kanban. Nuestro equipo trabaja en la cadena de montaje donde se generan las planchas de carrocería del nuevo modelo de coche de 2021. Se utiliza un tablero Kanban para ver en que punto están las tareas y se han definido políticas explicitas y un WIP (Work In Progress) para las columnas del tablero. ¿Qué tipo de trabajo está realizando el equipo en el proyecto? Trabajo incremental por iteraciones. Trabajo funcional. Flujo de valor. Trabajo secuencial. IncorrectoKanban es un método para gestionar el trabajo que surgió en Toyota Production System. A finales de los años 40, Toyota implementó en su producción el sistema “just in time” (justo a tiempo”) que en realidad representa un sistema de arrastre, basado en el flujo de valor continuo. Esto significa que la producción se basa en la demanda de los clientes y no en la práctica tradicional de fabricar productos e intentar venderlos en el mercado. CorrectoKanban es un método para gestionar el trabajo que surgió en Toyota Production System. A finales de los años 40, Toyota implementó en su producción el sistema “just in time” (justo a tiempo”) que en realidad representa un sistema de arrastre, basado en el flujo de valor continuo. Esto significa que la producción se basa en la demanda de los clientes y no en la práctica tradicional de fabricar productos e intentar venderlos en el mercado. 114 / 114 Estamos en la iteración número 16 de nuestro proyecto y nuestro líder ágil facilita la reunión diaria al equipo de desarrollo para su realización. Nuestro líder ágil informa al equipo que estará de baja 4 días. ¿Qué debe hacer el equipo ágil en ausencia del líder con respecto a reunión diaria? La reunión diaria no se producirá hasta que no se reincorpore al proyecto el líder ágil. El producto owner debe facilitar la reunión durante la ausencia del líder ágil en el proyecto. El equipo de desarrollo documentará los impedimentos y el progreso de cada persona del equipo y no realizará la reunión diaria hasta que se reincorpore el líder ágil donde se retomaran las reuniones diarias. El equipo de desarrollo seguirá realizando la reunión diaria independientemente de que el líder ágil esté presente o no. IncorrectoLa reunión diaria es de y para el equipo de desarrollo y el líder ágil únicamente debe asegurarse de que se produzca. No es obligatorio que este presente. Por lo que el equipo debe seguir realizando la reunión diaria con normalidad durante la ausencia del líder ágil. CorrectoLa reunión diaria es de y para el equipo de desarrollo y el líder ágil únicamente debe asegurarse de que se produzca. No es obligatorio que este presente. Por lo que el equipo debe seguir realizando la reunión diaria con normalidad durante la ausencia del líder ágil. Tu puntación es 0% Restaurar