Scrum DoD

Artículo

SCRUM DoD - Definición de Hecho

"El Incremento es la suma de todos los ítems del Product Backlog completados durante un Sprint y el valor de los incrementos de todos los Sprints anteriores.”, La Guía Scrum.

¿Podemos estar cayendo en una incongruencia al hablar de Definición de Hecho, cuando en un proceso iterativo estamos siempre construyendo un nuevo producto en cada iteración y todo es susceptible de ser mejorado?

Por otro lado, la Guía Scrum nos habla del significado de Hecho en varias ocasiones.

“El nuevo incremento debe ser “Hecho”, lo cual significa que debe estar en condiciones de ser usado …”, La Guía Scrum.

Parece que al menos el significado de Hecho lo podemos ir acotando a que lo producido sea usable.

Sin embargo, es desafortunado que esto haya llevado a muchos a creer que no se puede lanzar nada hasta el final del Sprint, hasta que el Product Owner decida. Esto no es del todo cierto. Las funcionalidades pueden ser liberadas durante el Sprint.

Según el Glosario de Scrum.org, la definición de Hecho es:

"… un entendimiento compartido de las expectativas que el incremento debe cumplir para poder ser liberado a la producción.", Glosario Scrum.

El equipo de desarrollo debe definir una definición de Hecho, que por supuesto debe estar negociada y acordada con el Product Owner y con la Organización de Desarrollo. Es habitual que las organizaciones dispongan de una base sobre la que negociar el grano fino que luego cada producto y equipo adoptan para su casuística concreta.

Una buena definición de Hecho debe ayudar al proceso Scrum aportando en sus tres pilares fundamentales: transparencia, inspección y adaptación.

Transparencia

Está claro que el disponer de unas reglas claras, entendibles, alineadas con el Product Owner y la Organización de Desarrollo, que además han sido negociadas entre todas las partes y son públicas, es un gran ejercicio de transparencia.

Inspección

En este caso, la inspección no se aplica directamente a la Definición de Hecho propiamente dicha, se aplica al incremento que se genera conforme a esta.

Si del hecho de inspeccionar el incremento surgen nuevos criterios a aplicar a la Definición de Hecho, tenemos mecanismos establecidos para realizarlo y así mejorar la entrega y la generación de siguientes incrementos.

Adaptación

"A medida que los equipos Scrum maduran, se espera que sus Definiciones de Hecho se amplíen para incluir criterios más estrictos y de mayor calidad". - La Guía Scrum.

Más claro no puede estar. La adaptación de la Definición de Hecho es un proceso iterativo que se produce mientras el devenir del producto va emergiendo. El equipo, conforme a las circunstancias particulares va adaptando, mediante la negociación, la Definición de Hecho para conseguir la mayor calidad en las iteraciones de los incrementos producidos.

Una de las derivadas más interesantes de esta adaptación, ya nos la revela la propia Guía Scrum:

"Nuevas definiciones pueden descubrir nuevo trabajo que haya que hacer en incrementos previos ya realizados." - La Guía Scrum.

Al ir adaptando los criterios de Hecho podemos generar deuda técnica en el producto. Deuda que tendrá que ser incluida en el Backlog de Producto y tratada consecuentemente.

Entonces, que debemos entender como Hecho

Por lo que hemos visto anteriormente, ya tenemos una idea de qué debe ser un Incremento para ser considerado como Hecho. Debe ser:

  • Potencialmente útil
  • Debe poder ser usado
  • Tiene que ser liberable a producción
  • Ha de estar probado a fondo
  • Se tiene que poder inspeccionar
  • Ha sido chequeado conforme a los estándares de producto y organización

De cara a los equipos la Definición de Hecho ayuda a:

  • Planificar de manera realista
  • Aprender y adaptarse con rapidez
  • Crear una atmosfera de transparencia
  • Generar alineación
  • Estimular el proceso de mejora
  • Mejora de la calidad

Desde un punto de vista más concreto en lo referente al software generado, un producto construido en torno a una correcta Definición de Hecho, nos encontraríamos por ejemplo con:

  • Código limpio y estandarizado
  • Código revisado
  • Pruebas unitarias completadas
  • Pruebas de estrés, rendimiento y seguridad pasadas
  • Pruebas de UAT superadas
  • Pruebas de usabilidad realizadas
  • Documentación suficiente
  • Lecciones aprendidas recopiladas
  • Revisiones tanto de negocio, como de arquitectura o gobierno de desarrollo hechas y conformes

Conclusión

En definitiva, contar con el recurso de la Definición de Hecho es una garantía de que, de manera transparente, todos los intervinientes en la construcción del producto, disponen de un marco común que atiende a los criterios de calidad, que permiten, desde los diferentes ángulos y puntos de vista, cubrir el espectro completo de lo que se requiere para que un producto sea entregable a cliente en producción.

A veces visualizamos la Definición de Hecho ( al igual que su hermana, la Definición de Preparado ) como una puerta que nos da paso a que, en este caso, un incremento sea considerado como conforme para ser puesto en producción.

Creedme, da igual cómo lo visualicemos, el hecho de disponer de este filtro con reglas conocidas de antemano por todos, que ha sido negociado y sobre el que tenemos la posibilidad de mejorarlo conforme nuestra experiencia aumenta, es una herramienta clave en la consecución de cualquier construcción de producto con Scrum. No hay manera, o al menos a mí no se me ocurre cómo, de llevar a buen puerto un proyecto ágil sin la cobertura de una buena Definición de Hecho.

Conoce a nuestro experto

Julio Roche

Julio Roche es Specialist Director del área de System Development&Integration, en la práctica de DxD de Deloitte. Profesional con más de 25 años de experiencia en el mundo del desarrollo de soluciones tecnológicas, su labor se encuentra actualmente focalizada en el terreno de la movilidad y la transformación digital, lo que le ha llevado a estar involucrado en procesos de implantación de metodologías ágiles desempeñando todos los roles que estas enumeran. Ha sido Agile Coach&Trainer, Scrum Master, Product Owner y parte del Development Team.