Desarrollo Ágil Tema 4.2

Las GASPs son partes claves de la guía de Scrum. Verdadero. Falso.

Las GASPs son prácticas no pertenecientes a Scrum, pero muy usadas como tales. Verdadero. Falso.

Las GASPs son prácticas oficiales de Scrum. Verdadero. Falso.

Las historias de usuario no son GAPSs. Verdadero. Falso.

¿Cuánntos tipos de GASPs hay?. 2. 3. 4. 5.

¿Cuáles son los tipos de GASPs que hay?. Estimación y seguimiento. Gestión y control. Organización y división. Planificación y desarrollo.

Una historia de usuario es... Una descripción corta de un requisito. Una exposición de una funcionalidad. Una explicación de una tareas. Un conjunto de Puntos de Historia.

Una historia de usuario debe poder entenderse por... El Scrum Master y el equipo de desarrollo. El equipo Scrum. El equipo de desarrollo. El Product Owner y Scrum Master.

¿Cuáles de las siguientes prácticas no son oficiales de Scrum?. Historias de usuario. Puntos de historia. Eventos. Sprint Backlog.

¿Cuáles de las siguientes prácticas son oficiales de Scrum?. Sprint Retrospective. Planning póker. Eventos. Product Backlog.

Describe el formato que debe tener una historia de usuario. Como. Quiero. Para.

¿La siguiente historia de usuario es correcta? Como usuario, quiero reservar una habitación de hotel. Verdadero. Falso.

¿La siguiente historia de usuario es correcta? Como viajero en vacaciones, quiero ver fotos de los hoteles. Verdadero. Falso.

¿La siguiente historia de usuario es correcta? Como usuario, quiero cancelar una reserva. Verdadero. Falso.

¿La siguiente historia de usuario es correcta? Como pasajero frecuente, quiero volver a reservar un vuelo anterior para ahorrar tiempo en los vuelos frecuentes. Verdadero. Falso.

Descripción escrita en lenguaje de negocio que sirve como identificación y recordatorio del requerimiento y ayuda para la planificación mediante la priorización. Targeta. Conversación. Confirmación.

Intercambio de datos que ocurre entre los miembros del equipo y el propietario para aclarar los detalles y dudas. Es la parte más importante. Targeta. Conversación. Confirmación.

Pruebas a llevar a cabo para poder decir que la HU se ha completado con éxito. Targeta. Conversación. Confirmación.

¿Cuál es la parte más importante de las Historias de Usuario?. Targeta. Conversación. Confirmación.

¿Cuáles son las partes fundamentales en la creación de una Historia de Usuario?. Tarjeta, conversación y confirmación. Descripción, explicación, desarrollo. División, asignación, ejecución.

Relaciona cada práctica no oficial de Scrum con el tipo al que corresponda. Estimación. Seguimiento.

Relaciona cada práctica no oficial de Scrum con el tipo al que corresponda. Estimación. Seguimiento.

¿A qué se refiere la I del modelo INVEST que siguen muchas historias de usuario?.

¿A qué se refiere la N del modelo INVEST que siguen muchas historias de usuario?.

¿A qué se refiere la V del modelo INVEST que siguen muchas historias de usuario?.

¿A qué se refiere la E del modelo INVEST que siguen muchas historias de usuario?.

¿A qué se refiere la S del modelo INVEST que siguen muchas historias de usuario? (escribe la palabra es Español).

¿A qué se refiere la T del modelo INVEST que siguen muchas historias de usuario?.

Las HU de un mismo Sprint deben ser dependientes entre sí. Verdadero. Falso.

Todos los detalles de la HU deben estar recogidos en la targeta. Verdadero. Falso.

Los detalles de la HU se añaden mediante la conversación. Verdadero. Falso.

Una HU no puede durar más de 1 semana en realizarse. Verdadero. Falso.

Una HU no puede durar más de 1 sprint en realizarse. Verdadero. Falso.

Todas las pruebas de usuario deben tener test. Verdadero. Falso.

El Scrum Master redacta las historias de usuario. Verdadero. Falso.

El Product Owner redacta las historias de usuario. Verdadero. Falso.

La conversación para obtener una buena Historia de Usuario se da entre. El equipo y el Product Owner. El Product Owner y el Scrum Master. El Scrum Master y el equipo. El cliente y el Product Owner.

La estimación de una historia de usuario se obtiene en: La tarjeta. La conversación. La confirmación.

¿Cuál es el orden del flujo de trabajo de una historia de usuario?. Tarjeta -> Conversación -> Confirmación. Tarjeta -> Confirmación -> Conversación. Conversación -> Tarjeta -> Confirmación. Conversación -> Confirmación -> Confirmación. Confirmación -> Tarjeta -> Conversación. Confirmación -> Conversación -> Tarjeta.

¿Quién se encarga de la confirmación de una Historia de usuario?. El cliente. El equipo de desarrollo. El Scrum Master. El Product Owner.

¿Cómo determinados la esfuerzo necesario para realizar una Historia de Usuario?. Mediante Puntos de Historia. Mediante horas estimadas para dedicarle. Mediante su coste monetarios estimado. Mediante la cantidad de tareas que contenga.

La velocidad de un Sprint de mide dividiendo la cantidad de puntos de historia terminados entre los totales. Verdadero. Falso.

La velocidad ideal de un Sprint es de 1. Verdadero. Falso.

La velocidad de un Sprint se obtiene sumando todos sus puntos de Historia. Verdadero. Falso.

La velocidad de un Sprint se obtiene sumando todos los puntos de Historia terminados. Verdadero. Falso.

¿En qué evento se realiza el Planning Póker?. Sprint Planning. Daily Scrum. Sprint Review. Sprint Retrospective. Refinement.

El Planning Póker se realiza en la Sprint Review. Verdadero. Falso.

El Planning Póker se realiza en la Sprint Planning. Verdadero. Falso.

El Planning Póker se realiza al comienzo del proyecto. Verdadero. Falso.

En el Planning Póker los puntos de una HU los determinan los miembros del equipo que vayan a trabajar en ella. Verdadero. Falso.

La primera HU seleccionada en el Planning Póker se determina al azar. Verdadero. Falso.

La primera HU seleccionada en el Planning Póker debe ser una ya realizada en el Sprint anterior. Verdadero. Falso.

La primera HU seleccionada en el Planning Póker debe ser una ya realizada en el Sprint anterior y con una dificultad media. Verdadero. Falso.

La puntuación de las HU en el Planning Póker se determinan comparando con la primera. Verdadero. Falso.

La primera HU seleccionada en el Planning Póker debe ser seleccionada entre todos. Verdadero. Falso.

La primera HU seleccionada en el Planning Póker debe ser considerada por el equipo con una dificultad media. Verdadero. Falso.

Al utilizar las historias de usuario en Scrum debemos añadir. Puntos de historia. Test para verificarla.

Una historia de usuario no debería ser dependiente de otra historia, pero a veces es inevitable. Verdadero. Falso.

La prioridad de una HU se determina mediante los Puntos de Historia. Verdadero. Falso.

En el Planning Póker los PH de una HU se determinan según la votación de la mayoría. Verdadero. Falso.

En el Planning Póker los PH de una HU se determinan por consenso entre todos. Verdadero. Falso.

La técnica MoSCoW se utiliza para determinar los PH de una HU. Verdadero. Falso.

La técnica MoSCoW se utiliza para determinar la duración de una HU. Verdadero. Falso.

La técnica MoSCoW se utiliza para determinar la prioridad de una HU. Verdadero. Falso.

La técnica MoSCoW divide a las HU en 5 tipos. Verdadero. Falso.

La técnica MoSCoW divide a las HU en 4 tipos. Verdadero. Falso.

En la técnica MoSCoW una HU "Must" significa... Que debe estar terminada en el primer Sprint. Que debe estar terminada como máximo al finalizar el proyecto. Que debe ser la primera en desarrollarse. No existe esta categoría en la técnica MoSCoW.

En la técnica MoSCoW una HU "Should" significa... Que debe estar terminada como máximo al finalizar el proyecto. Que depende de la HU "Must". Que debería estar terminada como máximo al finalizar el proyecto. No existe esta categoría en la técnica MoSCoW.

Puede haber más de una HU "Must" en un proyecto. Verdadero. Falso.

Puede haber más de una HU "Must" en un Sprint. Verdadero. Falso.

Puede haber más de una HU "Must" en un proyecto pero no en un Sprint. Verdadero. Falso.

No puede haber dos Historias de usuario "Should" y "Must" en el mismo Sprint, excepto si este dura 3 semanas o más. Verdadero. Falso.

En el último Sprint nos damos cuenta no vamos a poder terminar todas las HU, ¿cuál no realizamos según la técnica MoSCoW ?. Must. Should. Could. Will not have. No podemos determinarlo sin más datos.

En cada incremento debería haber mínimo una HU "Must". Verdadero. Falso.

En la técnica MoSCoW una HU "Will not have" significa... Que debería estar terminada como máximo al finalizar el proyecto. Que debe haber al menos 1 por Sprint. Que es de "relleno". No existe esta categoría en la técnica MoSCoW.

En los criterios de aceptación se añaden las pruebas que deberá pasar la HU. Verdadero. Falso.

¿Qué deberían incluir los criterios de aceptación de una HU?. La documentación necesaria. Los desarrolladores que la realizaron. Los Puntos de Historia. El PBR.

Existen 4 tipos de Historias de Usuario según sus PH. Verdadero. Falso.

Grandes proyectos, peticiones globales sin más análisis ni detalles. Temas. Épicas. Historias de usuario. Tareas.

"Super" historias de usuario, algo más concretas. Temas. Épicas. Historias de usuario. Tareas.

Descripción de una funcionalidad simple y concisa que aporta valor. Temas. Épicas. Historias de usuario. Tareas.

Las HU se pueden dividir en tareas por necesidades técnicas. Temas. Épicas. Historias de usuario. Tareas.

Clasifica la siguiente Descripción de una Historia de Usuario: "Buscador de ofertas de trabajo”. Temas. Épicas. Historias de usuario. Tareas.

Clasifica la siguiente Descripción de una Historia de Usuario: "Backoffice para agregar ofertas de trabajo”. Temas. Épicas. Historias de usuario. Tareas.

Clasifica la siguiente Descripción de una Historia de Usuario: "Filtros que aplicar a la búsqueda”. Temas. Épicas. Historias de usuario. Tareas.

Clasifica la siguiente Descripción de una Historia de Usuario: "Presentación listado-detalle de los resultados de búsqueda”. Temas. Épicas. Historias de usuario. Tareas.

Clasifica la siguiente Descripción de una Historia de Usuario: "Como candidato quiero buscar en las ofertas de trabajo para ver cuales me interesan”. Temas. Épicas. Historias de usuario. Tareas.

Clasifica la siguiente Descripción de una Historia de Usuario: "Como candidato quiero poder encontrar ofertas filtradas para obtener solo las de mi zona, mi profesión y la remuneración que yo quiera”. Temas. Épicas. Historias de usuario. Tareas.

Clasifica la siguiente Descripción de una Historia de Usuario: "Crear los métodos de consulta a BBDD para que retornen resultados". Temas. Épicas. Historias de usuario. Tareas.

Clasifica la siguiente Descripción de una Historia de Usuario: "Mostrar mensaje si no se encuentran resultados con los criterios de búsqueda”. Temas. Épicas. Historias de usuario. Tareas.

En los tableros de tareas las tareas son divisiones de las Historia de usuario. Vedadero. Falso.

En los tableros de tareas las Historia de usuario son divisiones de las tareas. Vedadero. Falso.

En la Sprint Planning se determinan las tareas del tablero de tareas para todo el Sprint. Vedadero. Falso.

En la Sprint Planning se determinan las tareas del tablero de tareas para los primeros días. Vedadero. Falso.

Definimos la velocidad de desarrollo como: Esfuerzo realizado a lo largo de un Sprint. ¿Qué puede ser el esfuerzo?. Vedadero. Falso.

Definimos la velocidad de desarrollo como: Esfuerzo realizado a lo largo de un Sprint. ¿Qué puede ser el esfuerzo?. Puntos de historia. Tareas. Horas. Días.

Una gráfica en la que representamos el esfuerzo que nos queda por hacer. burndown chart. burn-up chart.

Una gráfica en la que representamos el esfuerzo que ya hemos hecho. burndown chart. burn-up chart.

¿Cuá es esa gráfica?. burndown chart. burn-up chart.

¿Cuá es esa gráfica?. burndown chart. burn-up chart.

¿Cuá es esa gráfica?. burndown chart. burn-up chart.

El Product Backlog Refinement se hace al principio de cada Sprint. Verdadero. Falso.

El Product Backlog Refinement se hace al final de cada Sprint. Verdadero. Falso.

¿Cuándo se hace el Product Backlog Refinement?. Al final del proyecto. A la mitad de un Sprint largo. Al final de cada Sprint. Al comienzo de cada Sprint.

El mapa de Historias de Usuario se centra en el proyecto. Verdadero. Falso.

El mapa de Historias de Usuario se centra en el Sprint. Verdadero. Falso.

La función principal de un mapa de historias es dividir el trabajo. Verdadero. Falso.

La función principal de un mapa de historias es darnos una visión general que nos permite organizar mejor. Verdadero. Falso.

¿Qué hace el mapa de historias?. Distribuir historias gráficamente. Nos permite organizar mejor.

¿Para qué sirve el mapa de historias?. Distribuir historias gráficamente. Nos permite organizar mejor.

Debe haber al menos un mapas de historias por Sprint. Verdadero. Falso.

Debe haber un mapa de historias por proyecto. Verdadero. Falso.

Es el resultado de agrupar HU en lo más fundamental. Backbone. Walking skeleton.

Es el conjunto de historias de usuario que conforman una versión básica: release. Backbone. Walking skeleton.

Para obtener feedback debemos usar el backbone. Verdadero. Falso.

Para obtener feedback debemos usar el walking skeleton. Verdadero. Falso.

El backbone está contenido en el walking skeleton. Verdadero. Falso.

El walking skeletons está contenido en el backbone. Verdadero. Falso.

¿Cuántas historias de usuario representamos en el mapa de historias?. Las finalizadas. Las del Sprint al que corresponda. Todas. Las que están en proceso o no empezadas.

¿Qué son las Historias de Usuario naranjas?. Backbone. Walking skeleton. Parte del Walking skeleton. Parte del Backbone.

¿Qué son las Historias de Usuario azules?. Backbone. Walking skeleton. Parte del Backbone. Parte del Walking skeleton.

¿Cuándo obtenemos el walking Skeleton al completo?. En la primera release. En la segunda release. En la tercera release. No lo obtenemos.

Podemos completar el backbone sin haber finalizado todas las HU del walking Skeleton. Verdadero. Falso.

Podemos completar el walking Skeleton sin haber finalizado todas las HU del backbone. Verdadero. Falso.