Cuestiones
ayuda
option
Mi Daypo

TEST BORRADO, QUIZÁS LE INTERESETEMA 3 MARSI

COMENTARIOS ESTADÍSTICAS RÉCORDS
REALIZAR TEST
Título del test:
TEMA 3 MARSI

Descripción:
preguntas tipo test

Autor:
AVATAR

Fecha de Creación:
11/03/2024

Categoría:
Informática

Número preguntas: 49
Comparte el test:
Facebook
Twitter
Whatsapp
Comparte el test:
Facebook
Twitter
Whatsapp
Últimos Comentarios
No hay ningún comentario sobre este test.
Temario:
¿Cuál de las siguientes actividades NO se realiza en un story workshop? Ninguna Presentación del objetivo Generación ideas para HU(Historias de Usuario) Presentación de roles de usuario.
Un story workshop es un taller de historias de usuario donde se trabaja en definir historias de usuario verdadero falso.
El número de historias adecuado es... 100 60 30 El que podamos gestionar sin que suponga carga de trabajo excesiva.
¿Cuándo se escriben historias de usuario? Solo cuando se revisan resultados de una iteración Solo en los talleres de usuario Solo cuando se refina el product backlog Ninguna.
Trabajamos con clientes y usuarios para definir qué versiones se pueden hacer y qué funcionalidad contendrían... Encuadrar Explorar Mapear la "Big picture" Rebanar tus "releases".
¿Qué estrategias podría aplicarse para "Encuadrar" el proyecto (qué / para quién y porqué)? Solo Lean Inception Solo Elevator Pitch Solo Design Thinking Cualquiera de las anteriores.
En Ios proyectos largos, no suele ser necesario planificar más allá 1 mes 3 meses 6 meses 1 año.
¿Como se hace un Story Mapping? Encuadrar, Mapear la "big picture", Explorar y Rebanar tus "releases" Mapear la Sbig picture-, encuadrar y explorar las "releases" Mapear la "big picture-. Explorar y Encuadrar el modelo Ninguna.
Nos centraremos en la historia global o el proceso global, el "big picture". Solo backbone. Podemos elegir usuario crítico Encuadrar Explorar Mapear la "Big picture" Rebanar tus "releases".
Completamos el cuerpo de nuestro mapa rompiendo las grandes historias del backbone en historias más pequeñas Encuadrar Explorar Mapear la "big picrure" Rebanar tus "releases".
Los atributos internos son percibidos por usuarios y son de interés a stakeholders y product owners Verdadero Falso.
La mayoría de tos criterios para tener buenas HUs también pueden aplicarse a Requisitos NO Funcionales (RNFS) Verdadero Falso.
De acuerdo a los criterios INVEST. A medida que una HU se hace más "pequeña", va aumentando su "valor" Verdadero Falso.
De acuerdo a los criterios INVEST, ¿Cuándo podemos decir que una Historia de Usuario NO es "estimable"? Es demasiado grande Desconocimiento de la tecnología necesaria Desconocimiento del dominio del problema y la solución propuesta (HIJ) Todas son correctas.
De acuerdo a tos criterios INVEST, ¿Son independientes las siguientes HUs? Verdadero Falso.
De acuerdo a tos criterios INVEST. ¿Diría que las siguientes HUS son "probables' (Testeables) ? Verdadero Falso.
En términos de tiempo, ¿Qué tamaño tendría una Feature? años meses semanas días.
En términos de tiempo, ¿Qué tamaño tendría una Épica (Epic)? años meses semanas días.
Los criterios de aceptación deben definirse en la propia HU ya que también son parte del resumen de la conversación Verdadero Falso.
En términos de tiempo, ¿Qué tamaño tendría una HU? años meses semanas días.
Son criterios que el sistema debe realizar para considerar que la HU está correctamente implementada DoD (Definition of Done) RFs Criterios de aceptación RNFs.
Dada La siguiente HU, ¿Qué representa "tener ese dinero en mi cuenta"? Rol Beneficio Acción Ninguna.
Dada la siguiente HU, ¿Qué representa el ' 'trabajador"? Rol Acción Beneficio Ninguna.
¿Cuál es el ciclo que sigue una HU? Construction Consequences Confirmation Conversation Card.
Dada la siguiente HU, ¿Qué representa "solicitar un anticipo de mi nómina"? Rol Beneficio Acción Ninguna.
Una HU es el resultado (o recordatorio) de una conversación que hayamos tenido o vayamos a hacer Verdadero Falso.
¿Qué técnica podemos aplicar para añadir detalles a una HU? Criterios de aceptación Escenarios de historias Descomponer historias Todas.
SPIDR es un conjunto de 5 reglas o criterios para dividir historias de usuario en tareas técnicas Verdadero Falso.
Aprender más sobre aspectos técnicos, de arquitectura o de herramientas para una HU Spike Path Interface Data Rule.
Identificar si una HU puede tener distintas interfaces si se usa en dispositivos distintos o bajo condiciones especiales Spike Path Interface Data Rule.
Extraer varias HU para detallar cada uno de los caminos alternativos que pueden originarse de una HU Spike Path Interface Data Rules.
Identificar subconjuntos de reglas de negocio de una HU. Si podemos implementar esos subconjuntos es un criterio Spike Rule Data Interface Path.
Identificar subconjuntos de datos de una HU. Si podemos implementar cada de forma separada, es un criterio Spike Path Interface Data Rule.
El siguiente ejemplo representa una Spike Verdadero Falso.
El siguiente ejemplo representa una división con criterios DATA Verdadero Falso.
El Siguiente ejemplo representa una división con criterios INTERFACE Verdadero Falso.
El siguiente ejemplo representa una división con criterios RULE Verdadero Falso.
El siguiente ejemplo representa una división con criterios PATH Verdadero Falso.
Los escenarios son aún más detallados que los criterios de aceptación de historias... Verdadero Falso.
BDD no está enfocado a conseguir una especificación ejecutable. Los ejemplos no son especificaciones ni requisitos Verdadero Falso.
Podemos usar escenarios sin BDD (Behaviour-Driven Development) Verdadero Falso.
Un fichero Gherkin siempre empieza definiendo una "Feature". Verdadero Falso.
Cuando se describen escenarios de Gherkin, ¿Cuál de las siguientes palabras NO es una palabra reservada del lenguaje? When But Then Can.
Cuando se describen escenarios de una "Feature", el "Background" es algo común para todos los escenarios Verdadero Falso.
En un escenario de Gherkin, un paso "Given" es una postcondición Verdadero Falso.
Un paso "When" es una acción externa, probablemente de un usuario Verdadero Falso.
Un paso "Then" es el resultado de la acción del usuario Verdadero Falso.
¿Cuál de las siguientes recomendaciones NO es una buena recomendación para escribir buenos escenarios? Intenta tener un único "When" Escribe escenarios desde la de usuario en lugar de la técnica iii No hagas copy&paste !!! Definir cuantas más acciones por paso mejor (usar "y" y no tantos "And").
En el lenguaje Gherkin, ta sentencia "Scenario outline" permite... Indica que el escenario es único Ejecutar el mismo escenario múltiples veces Ejecutar el escenario el último Marcar el escenario como "importante" para Ios usuarios.
Denunciar test Consentimiento Condiciones de uso