Maximizando la distancia entre el DoR y DoD

El objetivo de un equipo ágil es aportar valor continua y eficazmente. Para esto se asegura de trabajar en lo más prioritario y entender cómo aporta valor (no simplemente ser un eslabón más de la cadena de valor/ siendo la cadena de valor). La forma de maximizar esa aportación de valor es teniendo un equipo que integre y participe en las actividades de toda la cadena de valor del producto o en la mayor parte posible. Esto hará que sea un equipo alineado y enfocado al valor de negocio, que entienda las necesidades del usuario y negocio, y además que vea el propósito de su trabajo y cómo su este aporta valor a la organización y/o a los clientes. De esta forma, al crear soluciones de negocio de una forma colaborativa entre miembros de un equipo cross-funcional se logra tener una alineación máxima donde todos los integrantes de la cadena de valor trabajan juntos con un objetivo común.  La cadena de valor queda auto contenida en el equipo

¿Y qué tiene todo esto que ver con el DoR y el DoD?

En un equipo ágil una de las cosas que definen en qué parte de la cadena de valor está involucrado el equipo son el DoR y DoD. Son como la puerta de entrada y salida del trabajo que hace el equipo. O por lo menos definen que alcance (de inicio a fin) tiene el trabajo que el equipo hace durante una iteración y/o ciclo de trabajo. Hay cierto trabajo que se hace antes de la iteración para llegar al “Ready” donde el equipo también está involucrado.

Por esto es que creo que analizando el DoR y DoD de un equipo podemos ver fácilmente cuánto ese equipo abarca en la cadena de valor y a partir de ahí trabajar para ampliar su alcance y lograr tener un equipo más cross-funcional aún y centrado en aportar valor de extremo a extremo (end-to-end).

Si nos imagináramos al “equipo más ágil del mundo” probablemente sería un equipo que cuando hay una idea la entiende, define, construye y pone en producción de una forma fluida, participando de todas las tareas y que hace todo eso dentro de su iteración (o incluso que la iteración viene definida por ese desarrollo e2e).  En este equipo el DoR estaría casi vacío y el DoD incluiría todo lo necesario para llegar a producción.   

En el otro extremo tendríamos a un equipo que tiene un DoR muy extenso donde gran parte del análisis probablemente ya tenga que estar hecho y un DoD que ni siquiera incluye las pruebas funcionales o de aceptación. Cuando se presenta un caso como este, lo que estamos teniendo son fases que se desarrollan iterativamente (waterfall iterativo). En este caso el gap (o la distancia) entre el DoR y el DoD es muy chica y muestra que el equipo solo está enfocado en el desarrollo.

Con esto no estoy diciendo que el DoR tiene que tender a cero o desaparecer ni tampoco que el DoD siempre tiene que incluir el ir a producción (esto va a depender de cada proyecto, producto, empresa y/o contexto). Pero si creo que el DoR y el DoD, además de ser acuerdos de trabajo que ayudan mucho a conseguir un producto de calidad en un desarrollo ágil, nos pueden servir como indicadores o barómetros de la agilidad de un equipo y por lo tanto son una gran herramienta para la mejora continua del equipo.  

img_2118

Consideraciones del DoR

Este post de Mike Cohn habla del peligro de tener un DoR que fuerce a tener cosas 100% terminadas, que creen fases en el ciclo de desarrollo. El DoR tiene que ayudar al equipo a minimizar los riesgos de cara a la ejecución del Sprint, pero teniendo cuidado de no convertirlo en un “firewall” que cree fases y que además rompa la colaboración en el trabajo necesario para llegar al “Ready”. Otra disfuncionalidad que podría crear un DoR muy estricto, es la creación de un “mini-contrato” en cada ítem del product backlog. Ya que, si muchas cosas tienen que estar 100% detalladas o definidas, queda poco lugar para la colaboración y negociación dentro del Sprint.   

Consideraciones del DoD

Para el DoD es bueno tener como objetivo ideal el llegar a la entrega continua (Continuous Delivery), ya que así siempre vas a tener en cuenta todos los aspectos (de calidad y de procesos) que necesites para ir a producción y a la vez cómo automatizar lo más posible ese camino hacia producción para poder hacerlo con el menor esfuerzo posible y la mayor calidad (aquí es donde las habilidades de DevOps del equipo van a ser fundamentales). Aunque no se llegue a la entrega continua, tenerlo como objetivo ayuda a pensar en TODO lo que tiene que hacerse para que una funcionalidad este realmente HECHA.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s