option
Cuestiones
ayuda
daypo
buscar.php
TEST BORRADO, QUIZÁS LE INTERESE: Desarrollo Ágil Tema 4.2
COMENTARIOS ESTADÍSTICAS RÉCORDS
REALIZAR TEST
Título del Test:
Desarrollo Ágil Tema 4.2

Descripción:
Ing. Informática UJA (las preguntas son propias, no de exámenes ni test)

Autor:
AVATAR
Elena Gómez Padilla
OTROS TESTS DEL AUTOR

Fecha de Creación: 20/05/2023

Categoría: Informática

Número Preguntas: 124
COMPARTE EL TEST
COMENTARNuevo Comentario
No hay ningún comentario sobre este test.
Temario:
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.
Denunciar Test