Durante mucho tiempo he defendido que el Product Backlog es la herramienta de trabajo del Product Owner y aunque creo que es la más importante, no es la única, sin duda. ¿Cómo articulamos esas cosas que sabemos, que no deberíamos olvidar y que suelen ser genéricas para nuestros desarrollos? Desde que empecé a trabajar como Product Owner, había cosas que veía siempre y no me parecía que tuviera sentido tener que escribir en cada historia de usuario. Para eso, otra de las herramientas que pueden estar muy bien es la definición de hecho.
Igual que en mi entrada anterior sobre cómo empoderar al Product Owner, decía que es importante que se conozcan las métricas fundamentales de una empresa, las del balance y la cuenta de resultados, también comentaba que estas se deben expandir los puntos que sean más necesarios. A instancia de lo que se vaya a desarrollar, es interesante saber cómo podemos construir una base de conocimiento de nuestro producto.
¿Cómo lo enfocamos?
Si la definición de hecho para un incremento forma parte de los estándares de la organización, todos los equipos de Scrum deben seguirla como mínimo. Si no es un estándar organizativo, el equipo de Scrum debe crear una definición de hecho adecuada para el producto.
Guía Scrum 2020
No es rentable servir a todos
Comenzamos por un ejemplo que me ocurrió una vez. ¿Cómo articulamos hasta qué versión de algo debemos sacar nuestro SW? Se me ha dado el caso en el que se hereda un bug en producción que lleva bastante tiempo reportado que dice que no estamos funcionando correctamente en una versión antigua de Internet Explorer en la web. ¿Qué hacemos? ¿Ampliamos el servicio que se da a más versiones?
En ese caso, hicimos lo siguiente: Los desarrollos se seguían, tal cual. No íbamos a parar la maquinaria. Nos basamos de primeras un poco en la intuición, se dijo, vamos a llegar hasta X versión de cada explorador. La misma vino dada sobre todo por la visión técnica. El equipo sabía cuales eran los puntos más complicados a cubrir y esos los descartamos por el momento.
Se lanzó un estudio a través de Google Analytics. Cruzamos la versión del explorador y sistema operativo (Con eso podíamos ver si teníamos que tener en cuenta versiones mobile) con los ingresos por cada uno de ellos. Quedó algo así:
Pusimos una línea roja, es decir, por debajo de cierta versión de cada versión de navegador, no íbamos a trabajar. No merecía la pena. Si lo vemos mirando el ratio coste/sprint, un equipo medio puede costar entre 8.000 y 15.000 €. Hay que tenerlo en cuenta a la hora de complicar los desarrollos para no tirar dinero a la basura desarrollando cosas que nadie necesita.
Eso, sin contar con el coste de oportunidad (Lo que pierdes por no haber desarrollado otra cosa que es más valiosa).
Bien. ¿Y ahora qué? Puedes estar poniendo esta información a través de criterios de aceptación en todas las Historias de Usuario que impliquen desarrollo relacionados con la web o puedes articularlo a través de criterios dentro de la definición de hecho («Definition of Done»):
- Los desarrollos sólo estarán disponibles para la versiones de los exploradores superiores a…
Puedes, además, adjuntar un enlace al estudio que se ha hecho. Este, debe estar vivo para ir actualizando sobre qué se debe desarrollar. Y lo puedes compartir con todo el mundo, hacer público ese documento, no sólo con el equipo de desarrollo.
Esto sólo es un ejemplo, al igual que desde la parte técnica se pueden dejar claras las reglas del juego para subir a producción, desde la gestión de producto podemos marcar ciertas normas.
Reduce la cantidad de desarrollos
Y podemos controlarlo también desde la definición de hecho. Cuando sacas una historia de usuario tienes que pensar en que esta es independiente y suficiente como para aportar valor al usuario. Si esto implica que hay que hacer desarrollos en el back-Office para que desde alguno de los departamentos de la compañía puedan gestionar el producto, es clave que esta parte se incluya en la misma.
De nada vale que que hagamos cambios en una web pública que no podamos controlar o medir. Muchas veces con que dejemos disponible la parametrización en base de datos es suficiente. No es la mejor opción pero es el camino más rápido para empezar a trabajar. Me explico: Imagina que quieres controlar qué productos están disponibles para la venta en tu web. Podrías hacer un panel maravilloso desde el cual el equipo correspondiente pueda activar o desactivar productos, pero a lo mejor, para poder salir, en una primera iteración, con que se pueda controlar haciendo cambios en base de datos vale. Y esto también lo puedes articular a través de DoD:
- Todos los desarrollos deberán ser parametrizables sin necesidad de hacer subidas a producción.
Está claro que es un criterio de aceptación más abierto que el anterior, pero con una frase a priori tan tontorrona ya estás plantando una semilla dentro del equipo para que se piense en esto, que también tiene sus efectos directos en el delivery. Porque si cada vez que hay que hacer cambios en la parametrización debemos hacer subidas a PROD, tenemos un problema y mucho tiempo consumido de nuestro equipo en sucesivos sprints.
Sin datos estás vendido
Por supuesto y siguiendo la línea del end-to-end, no se debería salir a producción sin mecanismos de inspección del producto, haciendo que quede directamente monitorizado.
Durante un tiempo estuve haciendo prácticas en el sector de la construcción naval. Allí, uno de los mensajes que se me quedaron grabados fue:
Un barco puede salir a la mar sin muchas cosas, pero es obligatorio que sus sistemas de comunicaciones estén 100% funcionales.
Con los sistemas informáticos debería pasar algo igual. No son pocos los casos en los que desarrollo y Business Intelligence van por separado, pero si articulamos a través de la definición de hecho introducimos este concepto de base.
Por ejemplo:
- Se deben poder medir las consecuencias de cualquier cambio en el producto.
Este es más abierto si cabe, pero después puedes incluir cómo quieres medirlo si el negocio lo tiene claro, a través de criterios de aceptación. Con eso, estás forzando a que siempre haya una métrica detrás de una Historia de usuario y que esta esté disponible siempre para analizar el avance del negocio o del producto.
Configura tu DoD para exprimir el valor
Cada casa es un mundo y tiene sus propias necesidades, pero hablando de desarrollos hay varias formas de poner límites y exigencias al desarrollo. La definición de hecho es una herramienta magnifica para decir cómo queremos trabajar, generar conversaciones hacia esos puntos y lanzar investigaciones para mejorar el ROI.
Como opinión personal, puede estar bien que no sea de las primeras cosas que ves cuando empiezas en un equipo nuevo. Es importante que el mismo empiece a trabajar, tomarse el pulso y entregar valor, pero que con el tiempo empiece a aparecer como un documento escueto que vaya mejorándose con el tiempo para reflejar mejor la realidad del equipo y la empresa. Menos es más muchas veces.
¿Cómo veis vosotros la DoD? ¿La habéis trabajado alguna vez?
