SCPO

En un proyecto donde el alcance es claro desde el principio y estable a lo largo del tiempo, ¿qué enfoque es mejor?. Waterfall/por fases. Agile. Híbrido. ITIL.

¿Dónde se definen las reglas de Scrum?. En el Agile Manifesto. No existen reglas definidas. Es un estándar de la IEEE. En la Guía de Scrum.

¿Cuál es una ventaja del enfoque Agile frente a Waterfall?. Agile aumenta la productividad en tareas repetitivas. Agile permite conocer bien el alcance al principio. Agile permite adaptar el alcance a lo largo del tiempo mediante iteraciones cortas. Agile permite tener un mejor control y seguimiento con reportes a la dirección basados en muchos indicadores de proyecto.

¿Qué contenidos se declaran en el Manifesto Agile?. Una guía para hacer Scrum. La forma de crear equipos ágiles en organizaciones complejas. Una lista de casos de éxito de Agile. Un conjunto de 4 valores y 12 principios.

¿Cuál de los siguientes es un valor Agile?. No documentar. No planificar. No firmar contratos. Colaboración con el cliente.

¿Cuál de los siguientes es un principio Agile?. No documentar. No planificar. No firmar contratos. No crear soluciones complejas.

¿Cuál es la diferencia entre un Project Plan y un Roadmap?. Ninguna, son lo mismo. El project plan detalla actividades para corto plazo y el roadmap detalla actividades para el largo plazo. El project plan detalla los tiempos, y el roadmap detalla los costes. El project plan detalla todas las tareas del proyecto, y el roadmap describe objetivos a conseguir a lo largo de bloques de tiempo.

¿Cuál es la manera más adecuada de crea equipos Agile?. Especializados por departamento. Crossfuncionales organizados por producto. Pool de recursos matricial. Multiasignados a varios proyectos para aumentar la productividad.

¿Qué es un perfil T-Shaped?. Un perfil con conocimiento especialista. Un perfil con conocimiento generalista. Un perfil de gestión. Un perfil con conocimiento especialista en una materia y generalista en otras varias.

¿Cuáles son los pilares de Scrum?. Transparencia, Inspección y Adaptación. Transparencia, Ejecución y Seguimiento. Diseño, Inspección y Adaptación. Transparencia, Control y Adaptación.

¿Qué caracteriza al framework Scrum?. Se basa en el control empírico de procesos. Se basa en la gestión de proyectos por procesos. Es determinista y prescriptivo. Ninguna de las anteriores.

¿Cuáles de los siguientes son valores de Scrum?. Transparencia, Inspección y Adaptación. Foco, Coraje, Compromiso. Foco, control y seguimiento. Humildad, respeto e igualdad.

¿Cuáles de los siguientes son componentes de Scrum?. Transparencia, Inspección y Adaptación. Foco, Coraje, Compromiso. Roles, Artefactos y Eventos. Personas, Procesos, Productos.

¿Cuáles son los roles de Scrum?. Project Manager, Desarrollador, Tester. Product Owner, Scrum Master, Equipo de Desarrollo. Arquitecto, Analista, Desarrollador, Tester y Jefe de Proyecto. Jefe de Proyecto, Scrum Master y Product Owner.

¿Cuáles son los artefactos de Scrum?. Project Plan, Project Backlog, Project Increment. Project Plan, Sprint Plan, Tableros. Incremento de producto y burn down chart. Product Backlog, Sprint Backlog e Incremento de producto.

¿Cuáles son los eventosde Scrum?. Project planning, seguimiento, control y revisión. Requisitos, análisis, diseño, desarrollo y testing. Sprint Planning, Daily, Sprint Review, Sprin Retro. Sprint Planning, Control diario, seguimiento del sprint y testing.

En el ciclo de un sprint Scrum, ¿dónde interviene activamente el Product Owner?. Project planning y Sprint Retro. Sprint Planning, Sprint review y Sprint Retrospective. Dailys y review. El PO no participa durante el ciclo Scrum.

¿Qué relación existe entre Scrum y Agile?. Son lo mismo. Scrum es una forma de poner en práctica Agile. Scrum es un mindset y Agile es un framework. Scrum y Agile no tienen ninguna relación.

¿Cuáles de las siguientes son funciones del Product Owner?. Control y seguimiento del proyecto, definición y asignación de tareas. Gestionar el Product Backlog, asegurar que se comprendan los elementos del product backlog, decidir cuándo pasar a producción. Depende de si es un product owner técnico o de negocio. Ninguna de las anteriores.

¿En qué aspectos debería fijarse un Product Owner para definir valor?. Reducción de costes y productividad. Estabilidad y bloqueo ante cambios de alcance. Buscar un balance adecuado entre lo que desean los usuarios, lo que es viable técnicamente y lo que es posible en la organización. Debe entregar a los usuarios todo lo que pidan, ya que son la única voz autorizada.

¿Qué refleja el modelo estratégico ?Onion? (cebolla)?. La forma de planificar sprints. Es un mapa que permite definir releases. Es un modelo para gestionar a los interesados mediante la definición de distintas capas de jerarquía. Define los distintos planos que permiten gestionar un producto, incluyendo la estrategia y la táctica de construcción y entrega.

¿Por qué es útil definir un Impact Mapping?. Es una herramienta de uso prescrito por la guía de Scrum. Permite saber cómo mejoramos la vida del usuario gracias nuestro producto. Es crucial para mantener el margen de beneficios descrito en la oferta. Permite una mejor coordinación del proyecto.

¿Por qué es útil definir un Business Model Canvas?. Es una herramienta de uso prescrito por la guía de Scrum. Permite sintetizar los aspectos estratégicos del producto. Es crucial para mantener el margen de beneficios descrito en la oferta. Permite una mejor coordinación del proyecto.

¿Qué es el Product Roadmap?. Una visión de qué objetivos conseguir a lo largo del tiempo. Es una herramienta de uso prescrito por la guía de Scrum. Un Gantt para el seguimiento y coordinación del proyecto. Ninguna de las anteriores.

¿Qué implicaciones tiene una construcción en forma iterativa incremental?. Waterfall/por fases. Primero se itera y luego se incrementa. Híbrida. Refinar lo ya hecho y, a la par, añadir nuevas funciones.

La organización de un producto sujeto a construcción Agile?. Requiere de una EDT que defina paquetes de trabajo. Requiere de una definición formal de entregables. Requiere de una estructuración orientada a valor. Todas las anteriores.

Una historia de usuario?. Es la forma de definir requisitos en Agile. Es la forma recomendada en la guía de Scrum para definir los elementos del Product Backlog. Es el relato de la necesidad/objetivos de un usuario que sirve para establecer un diálogo continuo con dicho usuario. Es la forma que tiene un equipo Scrum de definir las tareas del Sprint Backlog.

Cuál de las 3 Cs de una historia de usuario es más importante: Card (tarjeta): sin ella, no se puede hacer el análisis de requisitos. Conversación: la capacidad de poder refinar con el usuario qué necesita y qué espera obtener. Confirmación: la validación de los requisitos por parte del usuario. Las 3 Cs son igualmente importantes.

¿Qué es un User Story Map?. Una representación de las tareas del equipo similar a un Gantt. Una estructura de producto alrededor de dos ejes: eje de interacción del usuario con el producto (narrativa) y eje temporal de entrega. Es la forma en la que el usuario expresa su satisfacción con el producto. Es el entregable final de un Sprint, que será validado en el Sprint Review y que sirve para realizar el seguimiento y el control del producto.

¿Qué significa que el producto debe ser construído mediante rebanadas verticales (vertical slicing)?. Que primero han de realizarse todos los sprints de backend antes de empezar con los de front-end. Que ha de realizarse la arquitectura antes del desarrollo. Que cada historia de usuario debe ser tecnológicamente implementada en su totalidad dentro de un mismo sprint. Que cada departamento de la organización ha de encargarse de su parte de la historia de usuario.

A la hora de crear el Product Backlog, ¿cuándo podemos dar por finalizada su definición?. Cuando todas las épicas han sido refinadas en historias. Cuando refleja todos los requerimientos. Nunca: un product backlog es un elemento vivo en constante definición. Ninguna de las anteriores.

¿En qué evento de Scrum ha de realizarse el refinameinto de producto?. En las Daily. En la Retrospectiva. Sólo en la Review y excepcionalmente en el planning. No existe evento específico para esta actividad.

Según el modelo Kano?. Todas las funcionalidades son igual de importantes para el usuario. Las funcionalidades esperadas por el usuario son prioritarias. Las funcionalidades no esperadas, pero que pueden sorprender positivamente al usuario son prioritarias. Las funcionalidades no esperadas, no deben realizarse.

A la hora de priorizar valor, un enfoque adecuado para reducir el time to market sería?. Ley 80/20 > Hay que entregar el 80 % del producto en el 20 % del tiempo estimado. Ley 20/80 > Hay que enfocarse en el 20 % del producto que cubre las necesidades del 80% de los usuarios. Ley del 100% > Agile nos ayuda a entregar antes todo el producto gracias al uso de Sprints. Ley de Bristol-Meyer: el usuario siempre tiene la razón.

¿Por qué deberíamos tener una Definición de hecho (DoD) en nuestros Sprints?. Porque lo exigen las auditorías. Porque permite tener una visión común de qué significa que algo esté realmente terminado. Porque es la forma de obtener una certificación de Scrum a nivel organizativo. Porque el Product Owner puede coordinar mejor los recursos.

¿Cuáles de los siguientes aspectos pueden incluirse en la definición de hecho?. Pruebas de rendimiento, Pruebas de escalabilidad, Pruebas de seguridad y Calidad de código. Refactoring y Pruebas de aceptación del usuario. Documentación requerida por la organización y Pruebas de regresión. Todas las anteriores.

Cuando un mismo producto ha de ser realizado por varios equipos de desarrollo... Hay un solo PO, con un solo Product Backlog a partir del cual cada equipo crea sus Sprint Backlogs. Hay un PO para cada equipo. Cada equipo tiene su Product Bakclog. Se establece una estructura matricial basada en el modelo Spotify.

Sobre el valor entregado en un Sprint?. Queda definido por lo que el equipo entrega. Los tests aseguran el valor entregado. Basta con que el PO apruebe la entrega. Todas las anteriores son incorrectas.

¿Qué problema plantean los KPIs clásicos?. Son cualitativos. Generan un comportamiento orientado a cumplir con la métrica. Sólo tienen sentido cuando se usa Big Data. Ninguna de las anteriores.

¿Qué es un OKR?. Son KPIs cualitativos. Una estructuración de medición de valor en forma de establecimiento de objetivos sustentados por indicadores clave. La forma de medir cuando se usa Big Data. Una evolución de SMART extendida al INVEST mediante el uso de las 3 Cs con modelos DEEP.

¿Qué es la gestión basada en evidencias?. Son KPIs cualitativos. Un algoritmo de inteligencia artificial que ha de incluirse en todos los productos para poder establecer si aporta valor. La forma de medir cuando se usa Big Data. Medir valor en base a las observaciones de cómo el producto está siendo usado y su impacto real.

¿Qué problemas plantea la estimación tradicional?. Estimaciones hechas por una sola persona. Influencia del jefe/experto. Demasiado tiempo y esfuerzo dedicado a estimar. Todas las anteriores.

Si el Product Owner impone una velocity creciente al equipo?. Logrará mayor productividad. Acabará antes el producto. Puede generar deuda técnica que perjudique la calidad e impacte en el rendimiento final. Mejorará la motivación del equipo y la satisfacción del usuario.

Sobre la Velocity?. Es una medida de productividad. Se puede ampliar un 10 % en cada Sprint. A y B son correctas. A y B son incorrectas.

¿Qué es un Story point?. La relación esfuerzo/tiempo de una user story. La unidad ISO/IEEE de estimación Agile. La equivalencia en días ideales de una estimación. Ninguna de las anteriores.

¿Qué es la Velocity?. La cantidad de Story Points que el equipo se compromete a entregar en un Sprint. La cantidad de Story Points que el Product Owner planifica para cada sprint. La cantidad de Story Points que un equipo logra entregar al final de un Sprint. El cociente entre el esfuerzo y el coste.

¿En qué parte del Sprint Planning es crucial la participación del Product Owner?. En la primera parte: dar a conocer el objetivo del sprint y explicar bien los items del Product Backlog inicialmente elegidos para ello. En la segunda parte: definir y estimar bien las tareas que ha de ejecutar el equipo. En ambas. El PO no participa en el Sprint Planning.

¿En qué parte de la Daily es crucial la participación del Product Owner?. En la primera parte: dar a conocer el objetivo del sprint y explicar bien los items del Product Backlog inicialmente elegidos para ello. En la segunda parte: definir y estimar bien las tareas que ha de ejecutar el equipo. En ambas. El PO no participa en el Daily.

El Product Owner en la Review?. Realiza el control y seguimiento del equipo. Define y estima las tareas que ha de ejecutar el equipo en el siguiente Sprint. El PO no participa en la Review. Ninguna de las anteriores.

La cancelación de un Sprint?. Sólo puede decidirla el PO bajo circunstancias muy excepcionales. La decide el Scrum Master cuando cambian las prioridades. La decide el equipo si se ve presionado. Un sprint nunca se puede cancelar.

El Product Owner en la Retrospectiva?. Realiza el control y seguimiento del equipo. Es uno más a a la hora de identificar puntos y acciones de mejora. El PO no participa en la Retrospectiva. Ninguna de las anteriores.