Simulador PMI-ACP

Incorrecto

El 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.

Incorrecto

Una 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.

Incorrecto

En 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»

Incorrecto

Los 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.

Incorrecto

El 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).

Incorrecto

El dueño del producto (Product Owner) es la única persona en el proyecto que puede cancelar una iteración en curso.

Incorrecto

Las 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.

Incorrecto

El 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.

Incorrecto

Siguiendo 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.

Incorrecto

Que 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.

Incorrecto

El 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.

Incorrecto

De 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.

Incorrecto

La 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.

Incorrecto

La ú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.

Incorrecto

Al 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.

Incorrecto

Mientras 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.

Incorrecto

La 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.

Incorrecto

Las 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.

Incorrecto

El 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.

Incorrecto

Introducir 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.

Incorrecto

Uno 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.

Incorrecto

Los 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).

Incorrecto

El 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

Incorrecto

El 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.

Incorrecto

Idealmente 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.

Incorrecto

Los 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.

Incorrecto

Están utilizando el método MoSCoW para la priorización. Ayuda al equipo a comprender la perspectiva empresarial de las funciones del product backlog.

Incorrecto

Siempre 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.

Incorrecto

Los 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).

Incorrecto

La 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.

Incorrecto

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.

Incorrecto

Los 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.

Incorrecto

Los 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.

Incorrecto

El 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.

Incorrecto

El 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.

Incorrecto

En 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.

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.

Incorrecto

La escucha activa es una de las softskills requeridas para un buen líder servicial.

Incorrecto

En 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.)

Incorrecto

En 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.

Incorrecto

La 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.

Incorrecto

La 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.

Incorrecto

Un 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 entregar

Quien trabaja en qué

Las características seleccionadas para la iteración

Metricas de Velocity y de defectos

Recomendaciones de las retrospectivas

Registros de riesgo, etc.

Incorrecto

Uno 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.

Incorrecto

El 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.

Incorrecto

El equipo de desarrollo debe tomar la decisión, ya que son autogestionados. Deben ser capaces de tomar decisiones conjuntamente.

Incorrecto

El 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.

Incorrecto

Bajar 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.

Incorrecto

El 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.

Incorrecto

Como 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.

Incorrecto

El 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.

Incorrecto

El 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.

Incorrecto

Solo 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.

Incorrecto

La 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ón

Normalmente 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.

Incorrecto

El 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.

Incorrecto

Como 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.

Incorrecto

Es 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.

Incorrecto

Té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.

Incorrecto

Una 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.

Incorrecto

En 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.

Incorrecto

El product backlog es donde tenemos todo el trabajo a pendiente en el proyecto.

Incorrecto

El 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.

Incorrecto

El 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.

Incorrecto

Al 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.

Incorrecto

Visión del producto, planificación del roadmap y definición del product backlog inicial.

Incorrecto

El 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.

Incorrecto

La ú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.

Incorrecto

Durante 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.

Incorrecto

Las 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).

Incorrecto

La 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.

Incorrecto

Los 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ño
Riesgo / Complejidad

Incorrecto

En 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.

Incorrecto

Los 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.

Incorrecto

Utilizamos 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.

Incorrecto

Los 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.

Incorrecto

Las 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.

Incorrecto

La 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 y
los artículos de mayor riesgo también son atacados temprano.

Incorrecto

TTD 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.

Incorrecto

Siempre 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.

Incorrecto

La 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.

Incorrecto

Mantener 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.

Incorrecto

En 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.

Incorrecto

La 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.

Incorrecto

El 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.

Incorrecto

En 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.

Incorrecto

Si 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.

Incorrecto

El 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.

Incorrecto

Un 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.

Incorrecto

El 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.

Incorrecto

El 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.

Incorrecta

Como 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.

Incorrecto

El 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.

Incorrecto

TTD 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.

Incorrecto

En 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.

Incorrecto

Los 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.

Incorrecta

En 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.

Incorrecto

El 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.

Incorrecto

Nadie 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.

Incorrecto

Parte 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.

Incorrecto

Los 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.

Incorrecto

Debido 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.

Incorrecto

Los 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.

Incorrecto

Solo 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.

Incorrecto

Adaptar 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.

Incorrecto

La velocidad del equipo es el resultado de las historias de usuario finalizadas durante la iteración.

Incorrecto

La 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.

Incorrecto

Nos 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.

Incorrecto

El 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.

Incorrecto

Cuando 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.

Incorrecto

La 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.

Incorrecto

La 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.

Incorrecto

En 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.

Incorrecto

Kanban 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.

Incorrecto

La 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.