Certificado de Fundamentos de Historias de Usuario

Las historias de usuario no son requisitos de software.

• Verdadero.

• Falso.

Las historias de usuario se deben documentar detalladamente con el fin de que el desarrollo del producto (software) sea exitoso.

• Verdadero.

• Falso.

¿Cuál de estas es una característica de las historias de usuario?

• Difíciles de entender y aceptar por parte del usuario.

• Redundancia, repetición de información.

• Documentación excesiva, difíciles de recordar.

• Breves, descripción corta.

• Ninguna de las anteriores.

¿Cuál de las siguientes afirmaciones no es cierta?

• Las historias de usuario representan funcionalidades parciales, es decir, no indican funciones o procedimientos complejos y grandes que el sistema debe hacer.

• Las historias de usuario siempre se escriben usando la forma “como usuario... quiero característica... para propósito”.

• Las historias de usuario no se pueden agrupar por temas.

• Las historias de usuario sirven como insumo para la documentación del software.

• Todas son ciertas.

Si no hay una Definición de Preparado (DoR – Definition of Ready) establecida:

• Las historias de usuario no se pueden refinar.

• Las historias de usuario no se pueden escribir en el formato “Como...Quiero...Para”.

• Las historias de usuario no se deben empezar a desarrollar.

• Las historias de usuario no se pueden probar una vez que se han desarrollado.

• No hay ninguna relación entre la Definición de Preparado y las Historias de Usuario.

La Historia de usuario: Como Analista de cartera Quiero un informe de deudores morosos Para realizar análisis de cartera vencida

Es una historia de usuario inválida.

• Verdadero.

• Falso.

En un proyecto ágil, todas las historias de usuario se detallan al principio del proyecto. Esto:

• Evita que no se generen ambigüedades durante el desarrollo del producto.

• Permite que haya un inventario de requisitos actualizado.

• Demora el desarrollo del producto.

• Ayuda a que haya una definición acotada de la solución.

• No todas las historias de usuario se detallan al principio del proyecto, solo las que se desarrollarán en el primer Sprint.

Una historia de usuario puede tener muchos (más de 15) criterios de aceptación.

• Verdadero.

• Falso.

Una historia de usuario se puede desarrollar en un Sprint si:

• a) Fue solicitada por el Dueño de Producto.

• b) Es lo suficientemente pequeña como para que pueda completarse en el Sprint (Definición de Terminado).

• c) Se desarrolla junto a otras historias de usuario en el mismo Sprint.

• a, b y c son ciertas.

• a y c son ciertas.

Para ser desarrollada en un Sprint, una historia de usuario debe tener muchos (más de 15) criterios de aceptación.

• Verdadero.

• Falso.