Definition of Done: Simple y sin embargo compleja

La Definition of Done (DoD) es una herramienta ágil importante que ayuda a los equipos a planificar y ejecutar el trabajo. En principio, la Definition of Done es solo una serie de criterios que el producto debe cumplir para considerarse terminado. Sin embargo, aunque el concepto es tan sencillo, la implementación en la realidad no es tan simple. El contexto y las posibilidades de interpretación forman una zona gris.

Contexto y criterios de aceptación

El primer nivel de complejidad consiste en que la Definition of Done siempre debe verse en el contexto del entorno, lo que se refiere a la completitud técnica y funcional y a la aceptación por parte del Product Owner. El hecho de que el Product Owner acepte el producto representa el valor del producto. Los criterios de aceptación – o como quiera que se llamen – reflejan si el código puede resolver un problema de negocio específico definido por la User Story o un requisito. Los criterios de aceptación deben confirmar que la historia realmente hace aquello para lo que fue concebida, y pueden utilizarse para la creación de pruebas de aceptación.

Desde un punto de vista formal, la Definition of Done suele ser un reflejo de los estándares técnicos y de proceso de una organización. Por ejemplo, las organizaciones suelen tener estándares para la escritura de código y pruebas unitarias, por lo que la Definition of Done puede contener requisitos para la estructura del código, la documentación y las pruebas. También puede incluir componentes relacionados con la funcionalidad. Sin embargo, la funcionalidad está básicamente incluida en la definición a través de los criterios de aceptación, etc. En algunos casos, he visto declaraciones en la Definition of Done que indican que los criterios de aceptación deben cumplirse. Después de superar la doble barrera de la Definition of Done y los criterios de aceptación, el Product Owner debe evaluar el valor entregado de la solución. Luego se realiza la evaluación final, en la que acepta o rechaza la solución. El resultado de este proceso también se describe como done-done o incluso done-done-done.

Obstáculos y preguntas importantes sobre la DoD

Para implementar el concepto de "Done" de manera sólida, hay que superar tres obstáculos: los criterios de la Definition of Done, los criterios de aceptación (como parte de una User Story) y la aceptación por parte del Product Owner. Además, hay que sopesar algunas preguntas que hacen el proceso, por lo demás relativamente simple, algo más difícil. Estas incluyen:

1. ¿Quién decide qué significa Done?
   En muchas organizaciones, los criterios de Done a menudo se dejan a los equipos individuales. Esto suele ocurrir dentro de los límites de los estándares técnicos y de proceso definidos por la organización. Hace unos años, por ejemplo, un equipo de desarrollo con estándares estrictos de codificación y pruebas unitarias me preguntó si podían omitir los requisitos de pruebas unitarias para su código. Las pruebas unitarias eran un criterio en su Definition of Done. Su justificación era que los testers descubrirían más tarde en el proceso si funcionaba, y que al Product Owner no le gustaban las pruebas de los programadores. Sin embargo, el equipo tenía que cumplir con los estándares establecidos por la organización y no estaba en discusión simplemente omitir los requisitos de las pruebas unitarias.

2. ¿Es aceptable que los criterios no se cumplan completamente?
   Todos los equipos con los que he trabajado se han preguntado tarde o temprano si estaría bien interpretar la Definition of Done de manera diferente y así eludirla. A menudo la respuesta es "Sí". Sin embargo, esto generalmente implica una discusión sobre la zona gris, la aceptación de deuda técnica y cuándo debe saldarse esa deuda.

3. ¿Pueden las necesidades de la organización ser más importantes que las del Product Owner?
   Este es el alter ego de la pregunta anterior. Todos en el equipo, incluido el Product Owner, deben saber cuándo y dónde los estándares y/o necesidades de la organización son más importantes que la aceptación por parte del Product Owner. La presión por entregar puede tentar a los equipos y Product Owners a impulsar el código para luego revisarlo en Sprints posteriores, lo que lleva los estándares y la arquitectura a sus límites. La mayoría de las organizaciones más maduras establecen límites claros para que todos sepan cuándo deben respetarse las necesidades y estándares de la organización.

Conclusión sobre la Definition of Done (DoD)

Todas las definiciones de la palabra "Done" implican un cierto grado de finalidad y completitud. En el desarrollo, mejora y mantenimiento de software, el concepto de Done puede ser muy complejo. Cada una de estas capas puede tener sus propios matices técnicos, funcionales y relacionados con el valor. Los equipos aprenden rápidamente que un trabajo debe estar realmente done, done y done para estar verdaderamente terminado.

Este texto proviene del blog de SPaMCAST y fue traducido al alemán por nosotros.