Desde la Visión hasta las Tareas a desarrollar en el Sprint

  • Home
  • Desde la Visión hasta las Tareas a desarrollar en el Sprint
Shape Image One
Desde la Visión hasta las Tareas a desarrollar en el Sprint

Desde la Visión hasta las Tareas a desarrollar en el Sprint

Visión

Todo proyecto necesita una visión para orientarse en la dirección adecuada. Una visión sirve como guía para elegir el curso de acción actual y futuro.

Ejemplo de declaración de visión

Visión de Oracle:

Nuestra visión es llegar a las bases de datos que se auto reparen

Elena Montoya
Business Development, Coretech and Big Data Director de Oracle

Una declaración de visión es para la organización y sus miembros, a diferencia de la declaración de misión que es para los clientes y una declaración de visión.

Gran cantidad del texto es extraído del material oficial de Scrum Manager.

Visión del producto

La visión del producto en Scrum es una breve declaración del estado futuro deseado que se lograría al desarrollar e implementar un producto. Un proyecto bien concebido proporciona un camino definitivo que puede cumplir mejor los objetivos o metas del proyecto. También proporciona una comprensión común de la dirección hacia la que quieren moverse.

Además de eso, la visión del producto también ayuda al propietario del producto a priorizar qué funciones crear primero, en qué orden y qué no crear para el producto.

Temas

A un nivel por encima de epics e historias de usuario se encuentran los temas.

Por ejemplo, en un sistema de software para gestión contable, el conjunto de epics: “Altas, bajas y mantenimiento de clientes”, “Facturaciones puntuales y recurrentes”, “Consultas de navegación y acciones de fidelización”, “Pedidos”, “Devoluciones” se podrían denominar como el tema de la gestión de clientes. 

Épica

Es una etiqueta que aplicamos a una historia grande, cuyo esfuerzo es demasiado grande para completarla de una sola vez o en un solo sprint.  tienen baja granularidad, los epics tienen una alta granularidad.

Los epics suelen tener un flujo asociado por el cual se puede dividir en historias de usuario, en otras palabras, las historias de usuario resultantes de la descomposición de un epic están íntimamente relacionadas entre sí. A medida que aumenta su prioridad y se acerca al momento de su implementación, el equipo la descompone en historias de usuario con un tamaño más adecuado para ser gestionada con los principios y técnicas ágiles: estimación y seguimiento cercano (normalmente diario).

Probablemente no encajará en un sprint y debería dividirse en historias

Historias de Usuario

Las historias de usuario son utilizadas en los métodos ágiles para la especificación de requisitos, son una descripción breve de una funcionalidad software tal y como la percibe el usuario (Mike Cohn, 2004).

Describen funcionalidades que dan solución a necesidades o problemas del cliente o del usuario, representan los “qués” a construir y se escriben en forma de historia con una o dos frases utilizando el lenguaje común del usuario.

Las historias de usuario son las unidades más pequeñas de funcionalidad de usuario en ágil que se pueden entregar en un sprint ágil. Por lo general, se estiman utilizando una historia apuntada y se definen utilizando los criterios INVEST.

Estas son una forma ágil de administrar los requisitos de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para administrarlos. Las historias de usuario forman parte de la fórmula de captura de funcionalidades definida en 2001 por Ron Jeffries de las tres C’s.

Cada historia de usuario debe ser limitada, esta debería poderse memorizar fácilmente y escribir sobre una tarjeta o post-it (card), ya que son una promesa de una conversación posterior. Poco antes de ser implementadas, en la reunión de refinamiento o en la de planificación de sprint, estas van acompañadas junto con los criterios de validación asociados de conversaciones entre el equipo de desarrollo y el propietario del producto. Como los cambios son bienvenidos en agilidad, no vale la pena profundizar antes, ya que en el momento de la implementación estas pueden haber cambiado desde que fueron escritas. Los criterios de validación, a veces transformados en escenarios de pruebas por el equipo de desarrollo, permiten al propietario del producto o usuario de negocio confirmar que el equipo ha entendido y recogido correctamente los requisitos.

Ventajas que aportan las historias de usuario:

  • Al ser muy cortas, estas representan requisitos del modelo de negocio que pueden implementarse rápidamente (días o semanas).
  • Necesitan poco mantenimiento.
  • Mantienen una relación cercana con el cliente.
  • Permiten dividir los proyectos en pequeñas entregas.
  • Permiten estimar fácilmente el esfuerzo de desarrollo.
  • Son ideales para proyectos con requisitos volátiles o no muy claros.

 

El origen de las historias de usuario viene de XP “eXtremeProgramming” o programación extrema, donde las historias de usuario deben ser escritas por los clientes. Esta metodología fue creada por Kent Beck y descrita por primera vez en 1999 en su libro eXtreme Programming Explained.

Las historias de usuario se aplican en la mayoría de los métodos ágiles, siendo así una herramienta muy importante también en scrum.

TAREAS

Estas son resultado de la descomposición por parte del equipo de las historias de usuario en unidades de trabajo adecuadas para gestionar y seguir el avance de su ejecución.

La granularidad es el nivel de detalle de cada elemento de la pila de producto, y este debe de ir en relación a la posición dentro de la misma. Recordemos que la posición va en relación a la prioridad. Al final de la lista, donde está lo menos prioritario, están los epics, historias de usuario de gran tamaño, y los temas que describen grandes cosas, de los que cada uno se descompondrá en elementos más pequeños a medida que avanza p

Las historias susceptibles de entrar en el próximo sprint son las que más detalle deben de tener para que en la reunión de planificación de sprint el equipo tenga toda la información necesaria para desglosarlas en tareas de la pila de sprint por tanto, las historias de usuario son los elementos que deben de encabezar la lista.