Definiciones ante de empezar el primer Sprint (DOR y DOD)

En los proyectos tradicionales es común que se utilice una robusta documentación para transmitir la necesidades del negocio al equipo de desarrollo causando que se pase de mano en mano generando que se distorsione en el camino los objetivos iniciales.

En los proyectos ágiles cambiamos la forma de transmitir las necesidades debido a que nos enfocamos en cambiar alguna documentación por conversaciones y como lo dice el manifiesto ágil :

 El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

Comúnmente existen interrogantes como :

  • ¿Como voy a transmitir todas mis necesidades en una tarjeta?
  • ¿Donde se adjuntan los prototipos de interfaz gráfica?
  • ¿Donde se muestran las reglas de negocios?
  • ¿Los flujos de operaciones?
    Y algunas mas…

Es verdad que algunas veces técnicas como Historias de Usuario no contienen toda la información necesarios para el desarrollo de un producto en una organización, por lo que da una apertura para adaptar la técnica a diferentes forma de trabajo. Es hay donde juega un papel importante las definiciones antes de iniciar (DOR y DOD), que son checklist que deben contener los ítem del producto para que tanto negocio y equipo tengan un entendimiento mutuo de lo que se va a desarrollar y como se va a verificar.

Definition of Ready (Definición de Preparado)

Lista de elementos que debe contener cada ítem del Product Backlog para que el equipo pueda comprometerse a desarrollar en el Sprint.

Definition of Done (Definición de Terminado)

Lista de elementos que deben contener cada ítem del Product Backlog para que el negocio pueda aprobar su entrega.

Estas definiciones son un buen complemento para nuestro Product Backlog, ya que da transparencia sobre la construcción del producto, por ello presento una pequeña guía de como facilitar una sesión para acordar las definiciones.

Como facilitar la sesión

Antes de:

Materiales :

  • Posibles ítem DOR y DOD.
  • Post it.
  • Marcadores
  • Un ambiente adecuado .

Recomiendo dedicar entre 60 – 120 minutos para su ejecución.

Durante:

Iniciamos realizando una presentación de la actividad, resaltando la importancia y el valor que genera realizarla.

Antes de entra en materia, se realiza el juego de “Vacaciones Perfectas”, donde se arman equipos y los participantes deben crear una lista sobre cuáles serían los criterios que deben cumplir sus vacaciones perfectas :

Ejemplo :

  • Playa
  • Bufet
  • Aventura
  • Económico
  • Fuera del país

Ayuda a generar un poco de esparcimiento antes de la actividad y entender la importancia de definir acuerdos.

Primero seleccionamos cual de las definiciones vamos a comenzar a armar DOR o DOD.

La idea es comenzar a leer cada una de las propuestas de elementos que podría contener las definiciones y se ubica en alguno de los siguientes cuadros:

EntraMas adelanteNo Entra
 

Entra: va a ser parte de la definición.

Mas adelante: mas adelante se conversara si ingresa a la definiciones

No entra : no va a ser parte de la definición.

Luego se continua con la segunda definición y el resultado sera nuestras definición de preparado y terminado.

Después de :

Es buena idea compartir los resultados ya sea por correo , documentarlo en un repositorio o ponerlos cerca al tablero del equipo en Post It.

TIPS:

  • Importante investigar como es el proceso de desarrollo , ya que pueden haber prerrequisitos para cada organización que sean necesarios tales como , reglamentos, políticas, procesos , auditorías y demás, por lo que serán insumos para nuestras propuestas de ítems.
  • Refinar los acuerdos ya que muchas veces los procesos cambian y la forma de hacer las cosas también.
  • Empoderar al Negocio sobre la importancia de entregar cada ítem de Product Backlog con lo insumo necesarios para que el equipo se pueda comprometer, ya que muchos retrasos en los proyectos son porque los ítems no están preparados.
  • Acompañar al equipo en tener presente la definición de terminado , para que cada ítem cumpla todo lo necesario para su aprobación.
  • Los ítems para mas adelante pueden ser ingresados para cuando el equipo haya alcanzado un grado de madurez, un claro ejemplo de ello son las buenas practicas de ingeniería de software como , Integración continua, despliegue de código.