En Scrum, es importante que todo el equipo esté alineado en lo que se considera « terminado ». Para ello, el equipo definirá su Definition of Done (Definición de « Hecho »). También se le llama DOD, que es simplemente un acrónimo. La definición de « hecho » es una práctica impuesta por Scrum a través de su guía Scrum. Aprovecharemos este artículo para comprender bien este concepto y asimilar la importancia de no subestimarlo.
La Definición de « Hecho » (DOD)
El equipo Scrum va a definir juntos los criterios que permitirán afirmar que un ítem (por ejemplo, una historia de usuario) puede considerarse « hecho ». Estos criterios tienen como objetivo imponer una calidad técnica en todos los elementos entregados. A menudo mal entendido, en Scrum, todo el equipo es 100% responsable de la calidad final de las entregas, y esto se aplica hasta la puesta en producción de los elementos. El propietario del producto no es un validador del trabajo de este equipo. Así, el equipo Scrum debe establecer criterios que definirán el mínimo necesario para permitirse entregar los elementos en producción. Y este equipo lo hace de manera autónoma. Si el propietario del producto forma parte de esta Definition of Done (Definición de « Hecho »), no tiene ninguna responsabilidad específica en comparación con el Scrum Master y los desarrolladores. No puede tratar de imponer sus ideas al equipo Scrum. Es esencial que la organización entienda que el equipo Scrum es 100% autónomo en la realización, la calidad de la misma y esto en su totalidad. En los tableros visuales, a menudo se representa mediante el movimiento de las tarjetas adhesivas a la columna « hecho ».
En algunos equipos Scrum, vemos a un miembro con habilidades de pruebas (u homologación) que tendrá la tarea de verificar que el ítem cumple al 100% con esta Definition of Done. Sin embargo, recordemos que todo el equipo Scrum sigue siendo responsable de llevar a cabo la « hecho » de cada elemento. Tener un miembro del equipo con experiencia en pruebas no exime a todo el equipo Scrum de su responsabilidad; este último confía en él. Una frase interesante de la guía Scrum para mostrar la importancia de esta práctica:
« El objetivo de cada Sprint es proporcionar incrementos de características potencialmente publicables que se adhieren a la definición actual de ‘hecho’ del equipo Scrum ».
¿Incluye la puesta en producción?
El equipo es responsable de la realización de los ítems hasta su entrega. Sin embargo, esta entrega debe hacerse al menos en un entorno estable, que a menudo se llama entorno de prueba. La Definition of Done no puede incluir la puesta en producción si el propietario del producto valida la estrategia de entrega o despliegue continuo. Esto no impide incluir conceptos de activación/desactivación de funciones en producción. Si el propietario del producto define una estrategia de entrega por lotes, entonces la Definition of Done no puede incluir la puesta en producción.
¿Es la misma Definition of Done para todas las tareas?
El equipo Scrum no escribirá una Definition of Done para cada ítem. Esto sería demasiado engorroso. Sin embargo, algunos ítems pueden tener criterios de calidad adicionales. De hecho, si cada ítem requiere que se cumplan al 100% todos los criterios definidos por la Definition of Done, no hay nada que impida al equipo Scrum agregar a veces criterios adicionales a algunos ítems.
¿El propietario del producto participa en la Definition of Done (DOD)?
Desde la última versión de la guía Scrum, el propietario del producto debe participar en la creación de la Definition of Done. Él es un actor en su creación al igual que cualquier otro miembro del equipo Scrum; no tiene más ni menos peso en las decisiones. Sin embargo, en algunos criterios que corresponden más a las habilidades del Propietario del Producto y/o a sus responsabilidades, es lógico que se le escuche más; esto es un concepto de inteligencia colectiva que confía en las habilidades de cada uno.
La Definition of Done de varios equipos
Si varios equipos trabajan en un producto común (o una oferta común), se recomienda encarecidamente que sea la misma para todos los equipos. De hecho, la guía Scrum exige que haya una misma Definition of Done para todos los equipos Scrum que trabajen en un mismo producto. No hacerlo traerá complicaciones adicionales innecesarias e incluso a veces generará conflictos entre los equipos. Si un equipo no puede aplicar la misma definición de « hecho » porque la versión estándar no se ajusta en absoluto a sus actividades, entonces tendrá que personalizarla para tener una Definition of Done coherente.
¿Cómo se implementa?
El equipo de desarrollo definirá la Definition of Done (DOD) en varias formas en un taller:
- acciones a realizar
- criterios de calidad
- conformidad esperada (de manera concreta)
Por ejemplo, el equipo podría definir una DOD de este tipo:
Le recomiendo encarecidamente mostrar su Definition of Done en su tablero visual de gestión o hacerla visible en el software que utilice (en caso de equipos dispersos).
La Definition of Done debe evolucionar
Al comienzo de un producto, no es fácil ser estricto con la Definition of Done. Entonces, será necesario agregar criterios a medida que avance para hacer de la « hecho » un criterio de calidad cada vez más estricto. Sin embargo, al comienzo de un producto, la DOD no debe ser irrealista, ya que esto podría impedir al equipo proporcionar valor a los clientes/usuarios.
Conclusión de la Definition of Done (DOD)
El concepto de la Definition of Done es relativamente simple de entender. Sin embargo, será más difícil implementarlo, especialmente al comienzo de los productos. Los equipos Scrum deben aceptar no ser demasiado exigentes al comienzo del producto; de hecho, esto permitirá al equipo Scrum tener una fase de aprendizaje. Lo mejorarán a lo largo del avance del producto. Sin embargo, no debemos olvidar que la DOD es una práctica del equipo Scrum y no de uno o algunos miembros de ese equipo; cada miembro está involucrado en ella.
Soyez le premier à commenter