Es un mapa en el visualizamos todas las historias de usuario que contamos sobre un sistema de información. Story Map Visual Map Historia de Usuario Map Goal.
¿Cómo se hace un Story Mapping? Encuadrar, Mapear la “big picture”, Explorar y Rebanar tus “releases” Mapear la “big picture”, Encuadrar, Explorar las “releases” Mapear la “big picture”, Explorar y Encuadrar el modelo Ninguna.
¿Qué estrategias podría aplicarse para “Encuadrar” el proyecto(qué/para quién y porqué)? Cualquiera de las anteriores Entrevistar a cliente y definir las necesidades Evaluar el alcance del proyecto Evaluar el valor del producto.
Nos centramos en la historia global o el proceso global, el “big picture”. Solo backbone. Podemos elegir un usuario crítico. Mapear la “Big picture” Explorar Encuadrar Rebanar tus "releases".
Completamos el cuerpo de nuestro mapa rompiendo las grandes historias del backbone en historias más pequeñas. Mapear la “Big picture” Explorar Encuadrar Rebanar tus "releases".
Trabajamos con clientes y usuarios para definir qué versiones se pueden hacer y qué funcionalidad contendrían Mapear la “Big picture” Explorar Encuadrar Rebanar tus "releases".
¿Cuándo se escriben historias de usuario? Ninguna Solo en los talleres de usuario Solo cuando se revisan resultados de una iteración Solo cuando se refina el product backlog.
En los proyectos largos, no suele ser necesario planificar más allá de… 6 meses 1 mes 3 meses 1 año.
El número de historias adecuado es… El que podamos gestionar sin que suponga carga de trabajo excesiva 100 60 30.
Un story workshop es un taller de historias de usuario donde se trabaja en definir historias de usuario Verdadero Falso.
¿Cuál de las siguientes actividades NO se realiza en un story workshop? Ninguna Presentación del objetivo Presentación de roles de usuario Generación de ideas para HU (Historias de Usuario).
Una HU es el resultado (o recordatorio) de una conversación que hayamos tenido o vayamos a hacer Verdadero Falso.
¿Cuál es el ciclo que sigue una HU? 1.Card, 2.Conversation, 3.Confirmation, 4.Construction, 5.Consequences 1.Card, 2.Conversation, 3.Construction, 4.Confirmation, 5.Consequences 1.Confirmation, 2.Consequences, 3.Conversation, 4.Construction Ninguna de las anteriores.
Dada la siguiente HU,¿Qué representa el “trabajador”? Rol Beneficio Acción Ninguna.
Dada la siguiente HU, ¿Qué representa “solicitar un anticipo de mi nómina”? Rol Beneficio Acción Ninguna.
Dada la siguiente HU, ¿Qué representa “tener ese dinero en mi cuenta”? Rol Beneficio Acción Ninguna.
Son criterios que el sistema debe realizar para considerar que la HU está correctamente implementada Criterios de aceptación DoD (Definition Of Done) RF´s RNF´s.
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 Épica(Epic)? Meses Semanas Años Días.
En términos de tiempo, ¿Qué tamaño tendría una Feature? Meses Semanas Años Días.
En términos de tiempo, ¿Qué tamaño tendría una HU? Meses Semanas Años Días.
De acuerdo a los criterios INVEST,¿Son independientes las siguientes HUs? Falso Verdadero.
De acuerdo a los criterios INVEST,¿Cuando podemos decir que una Historia de Usuario no es “estimable”? Todas son correctas Cuando no es independiente Cuando no es testeable Cuando no es escalable.
De acuerdo a los criterios INVEST. A medidia que una HU se hace más “pequeña”, va aumentando su “valor” Falso Verdadero.
De acuerdo a los criterios INVEST.¿Diría que las siguientes HUs son “probables” (Testeables)? Falso Verdadero.
La mayoría de los criterios para tener buenas HUs también pueden aplicarse a Requisitos No Funcionales (RNFs) Verdadero Falso.
Los atributos internos son percibidos por usuarios y son de interés a stakeholders y product owners Verdadero Falso.
¿Qué técnica podemos aplicar para añadir detalles a una HU? Todas Criterios de aceptación Escenarios de historias Descomponer historias.
SPIDR es un conjunto de 5 reglas o criterios para dividir historias de usuario en tareas técnicas Falso Verdadero.
Aprender más sobre aspectos técnicos, de arquitectura o de herramientas para HU. Spike Interface Path Data.
Identificar si una HU puede tener distintas interfaces si se usa en dispositivos distintos o bajo condiciones especiales. Spike Interface Path Rule.
Extraer varias HU para detallar cada uno de los caminos alternativos que pueden originarse de una HU Spike Interface Path Rule.
Identificar subconjuntos de reglas de negocio de una HU. Si podemos implementar esos subconjuntos es un criterio. Rule Interface Path Spike.
Identificar subconjuntos de datos de una HU. Si podemos implementar cada subconjunto de forma separada, es un criterio Data Interface Path Spike.
El siguiente ejemplo representa un SPIKE Verdadero Falso.
El siguiente ejemplo representa una división con criterios DATA Falso Verdadero.
El siguiente ejemplo representa una división con criterios INTERFACE Falso Verdadero.
El siguiente ejemplo representa una división con criterios RULE Falso Verdadero.
El siguiente ejemplo representa una división con criterios PATH Falso Verdadero.
Los escenarios son aún más detallados que los criterios de aceptación de historias… Falso Verdadero.
BDD no está enfocado a conseguir una especificación ejecutable. Los ejemplos no son especificaciones ni requisitos Falso Verdadero.
Podemos usar escenarios sin BDD(Behaviour-Driven Development) Falso Verdadero.
Un fichero Gherkin siempre empieza definiendo una “Feature”... Falso Verdadero.
Cuando se describen escenarios de Gherkin, ¿Cuál de las siguientes palabras NO es una palabra reservada del lenguaje? Can When Then But.
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? Definir cuantas más acciones por paso mejor (usar “y” y no tantos “And”) Escribe escenarios desde la prespectiva de usuario en lugar de la técnica Intentar tener un único "When" ¡¡¡No hagas copypaste!!!.
En el lenguaje Gherkin, la sentencia “Scenario outline” permite… Ejecutar el mismo escenario múltiples veces Indica que el escenario es único Ejecutar el escenario el último Marcar el escenario como "importante" para los usuarios.
|
