El bloc de notas de un Agilista Jedi

Regresar Scrum

Scrum & Calidad: 5.1 tips para una poderosa Definición de Terminado

2 de junio de 2023

Scrum & Calidad: 5.1 tips para una poderosa Definición de Terminado

En Scrum, hablar de calidad del producto es hablar de la Definición de Terminado, la cuál es popularmente conocida como DoD, así a secas, DoD, un acrónimo debido a su nombre en inglés: Definition of Done.

Esta Definición de Terminado es una descripción formal de lo que debe de cumplirse para que el producto que se está entregando cuente con las medidas de calidad requeridas. Es decir, lo que debe de cumplirse y validarse para asegurar que el producto que se está construyendo pueda ser puesto en producción, que lo pueda utilizar directamente usuario final, y que sea un producto de calidad (que no tenga fallas o bugs, que cumpla con los lineamientos de la organización, que el programa no “se rompa”, etcétera).

No pretendo que este sea un artículo teórico, pero es necesario ver algo de teoría. Así que, partiendo de una “definición de libro”, veamos qué es la Definición de Terminado.

De acuerdo con el Glosario de Scrum.org, la Definición de Terminado es: “Un entendimiento compartido de las expectativas que el incremento debe cumplir para poder ser liberado a la producción.”

Aquí hay un par de ideas clave que es relevante enfatizar:
“Entendimiento compartido”:
Esto significa que es co-creada por todo el equipo Scrum, que todos la comprenden y están de acuerdo con ella. Es decir, que no es algo que definen solo los desarrolladores como área técnica, sino que negocio, a través del Product Owner, debe de compartir este entendimiento.

• “Las expectativas que el incremento debe cumplir”:
En Scrum buscamos entregar un incremento de producto en cada sprint, esto es un incremento funcional que puede utilizar el usuario final a partir de ese momento en caso de ser requerido. Por eso, al definir en la DoD lo que el producto debe de cumplir, se crea una línea base en términos de calidad, ya que cualquier incremento de producto cumple siempre con la DoD, lo que quiere decir que hay un nivel de calidad “mínimo” establecido para todos los incrementos.

• “Para ser liberado a producción”:
Como mencionaba en el punto anterior, cada incremento de producto que se entrega debe de ser un incremento completamente funcional, que puede utilizar el usuario final, a partir de ese momento en caso de ser requerido.

Al ser un entendimiento compartido, es claro y transparente para todo el equipo lo que “terminado” significa. No existe algo como “casi-casi-terminado”, está terminado o no lo está, por lo tanto, se puede entregar o no.

Aquí me gustaría compartir 5.1 puntos muy chéveres para que puedas co-crear con tu equipo una poderosa Definición de Terminado. Estas son algunas ideas que han funcionado después de colaborar con diversos equipos. Veamos una por una:

1. Co-creación:

Ya que se trata de un entendimiento compartido por el equipo, es mucho más enriquecedor que sea co-creado por todo el equipo. Parecerá obvio este punto, pero una vez colaboré con un equipo en el cual el líder técnico definía la DoD porque era quien “tiene más experiencia”, y el resto del equipo, por ser juniors, solo se apegaba a lo definido. Nos tomó un tiempo el que pudiéramos avanzar todos juntos hacia la co-creación, pero ya llegando a ese nivel, el crecimiento del equipo y de la calidad del producto fue innegable.
La co-creación fomenta la diversidad de ideas y perspectivas, además de que ayuda s que las personas sientan que formaron parte en el proceso de crear algo nuevo, por lo que el sentido de pertenencia y compromiso aumenta.

2. Evolutiva:

La DoD debe de inspeccionarse y adaptarse regularmente, no está escrita en piedra, y conforme el equipo va madurando, también la DoD debe de hacerlo. En un escenario real, ya que hablamos de responder al cambio, es necesario que la DoD se ajuste conforme el contexto técnico cambia, por ejemplo, ¿Se ha detectado un nuevo defecto o bug que no había ocurrido antes?, o ¿Qué tal cuando una actualización tecnológica hace necesaria una nueva validación? Si es el caso, agregar eso a la DoD.

3. Visión del futuro:

Ya que la DoD debe de ir madurando y evolucionado, es poderosísimo que el equipo tenga una visión compartida del estado futuro que pretende alcanzar, el nivel de calidad al cual el equipo aspira a llegar, quizá no este sprint ni el siguiente, pero sí como un estado hacia el cual el equipo va avanzando, paso a paso. Tal vez técnicamente el equipo aún no tiene los conocimientos y/o experiencia necesaria, pero está capacitándose, aprendiendo y eventualmente llegarán a ahí.

4. No es una receta de cocina:

La DoD no debe de ser prescriptiva. Indicar con puntos y comas lo que se debe de hacer como un procedimiento o receta, puede limitar la autogestión del equipo. Aquí no hay “mejores prácticas”, solo recordemos que no buscamos la documentación extensiva. Lo adecuado, como todo en la vida, es el balance. Documentar en la DoD lo justo y necesario para el equipo, no más, no menos.

5. Transparencia real:

La transparencia significa que la información debe de estar visible y disponible para las personas interesadas. En este caso, con transparencia “real” me refiero a que no solo visible y disponible es suficiente, sino que debe de ser entendible y comprensible para todos. Por ejemplo, ¿El Producto Owner sabe a qué se refiere que todo el código esté integrado?, la verdad es que no es necesario que sepa cómo hacerlo técnicamente, pero sí es importante que comprenda la esencia de lo que esto implica, y que comprenda su importancia, así como el impacto de no hacerlo.

5.1 Y aquí un Bonus: ¡Diversión!

Esto es fundamental. El cumplir con objetivos de calidad y código limpio no implica que debe de ser algo aburrido. Desde las dinámicas de facilitación para co-crear una DoD, inspeccionarla y adaptarla, hasta el aseguramiento de su cumplimiento, son oportunidades para que el equipo se divierta, se abra a lo lúdico, a nuevas ideas, fomentar las condiciones para que el equipo entre en estado de “Flow” y detone la creatividad. ¿Lo has experimentado con tu equipo?

Que el equipo cuente con una DoD es esencial, si no cuenta con una, el mejor momento para empezar a co-crearla fue el sprint pasado. El segundo mejor momento es hoy.

El hacer código limpio siempre evita problemas y dolores de cabeza, ayuda a no dejar trabajo pendiente para el final o “escondido debajo de la alfombra” que regresará al equipo después como problemas debido a mala calidad. El retrabajo es un tipo de desperdicio e impacta en la productividad.

Para cerrar, me gustaría reforzar que el objetivo de Scrum es entregar cada sprint un incremento de producto que sea funcional, que cumpla con el objetivo del sprint y que, en última instancia, sea un paso adelante hacia el objetivo del producto… y la Definición de Terminado, es piedra angular en esto. Recordemos que en el momento en que un elemento del Product Backlog cumple con la Definición de Terminado, nace un Incremento de producto.

Cuéntanos, ¿Qué te parecieron estos 5.1 puntos para una poderosa DoD? ¿Qué otro punto agregarías?
Me encatará leerte y que conversemos :)


autor

Leonel Zapien López
Apasionado del Agilismo y del Pensamiento Lean: Agile-Lean Coach, Consultor, Facilitador & Speaker.

Conoce más sobre mí

Comparte este articulo

Seguir leyendo sobre Scrum