Definición de «terminado» (DoD): lista de comprobación y ejemplos
La definición de «terminado» (DoD) es una lista de comprobación que cada historia debe superar antes de su entrega. Ejemplos de listas de comprobación, cómo redactar la suya propia y la diferencia entre la DoD y los criterios de aceptación.
La definición de «terminado» (DoD) es la breve lista de comprobación que el equipo acuerda y que toda historia debe cumplir antes de que se considere completada: revisada, probada, fusionada, implementada y aceptada. Se trata de una norma única para todo el equipo. Los criterios de aceptación se establecen por cada historia; la definición de «terminado» es global. Al confundir ambos conceptos, «terminado» acaba significando, de forma imperceptible, «funciona en mi equipo».
Todos los equipos han experimentado la diferencia entre «el desarrollador dice que está terminado» y «realmente está listo para su lanzamiento». La definición de «terminado» acorta esa distancia. Se acuerda una vez y se aplica en cada sprint, independientemente de lo que implique cada historia en concreto. Sin ella, «terminado» es una opinión subjetiva de cada persona, y la diferencia sale a la luz en la demostración o, lo que es peor, en producción.
Qué significa la «definición de «hecho»» en Scrum
La Guía de Scrum lo define como «una descripción formal del estado del incremento cuando cumple con los criterios de calidad exigidos para el producto». En términos sencillos, la definición de «terminado» es el compromiso asociado al incremento, uno de los tres artefactos de Scrum. El trabajo que cumple con dicha definición pasa a formar parte del incremento. El trabajo que no lo cumple no puede publicarse ni mostrarse en la revisión del sprint; vuelve al backlog del producto.
Si su organización ya ha establecido una definición de «terminado», todos los equipos la utilizan como requisito mínimo y pueden ampliarla. Si no es así, el equipo elabora la suya propia. La idea no se limita a Scrum: los equipos de Kanban suelen elaborar la misma lista como norma para trasladar el trabajo a su columna final.
Ejemplos de la definición de «hecho»
Ejemplo de lista de verificación de «tareas completadas»: un equipo de desarrollo de software
Un punto de partida viable para un equipo que se dedica al desarrollo de una aplicación web:
- Se han cumplido y verificado los criterios de aceptación.
- Se ha revisado el código y se ha fusionado con la rama principal.
- Se han escrito pruebas automatizadas que se han superado; no hay nuevas pruebas inestables.
- No se conocen regresiones ni errores críticos pendientes relacionados con esta tarea.
- Se han actualizado la documentación y el registro de cambios en los casos en que el cambio afecta a los usuarios.
- Se ha implementado en el entorno de prueba y se han realizado pruebas de verificación.
- El responsable del producto lo ha aceptado.
Adopte esta definición y, a continuación, adáptela a lo que su equipo vaya a aplicar realmente. Una definición de «terminado» con un criterio que nadie comprueba es peor que una breve. Esto hace que el equipo acabe considerando toda la lista como algo meramente decorativo. Asegúrese de que quepa en una sola pantalla y de que cada punto sea verificable.
Ejemplo de la definición de «terminado»: un equipo que no publica código
Esta misma idea es aplicable a un equipo de marketing, de contenidos o de diseño. La definición de «terminado» de un equipo de contenidos podría ser la siguiente:
- Se cumplen los criterios de aceptación del pliego de condiciones.
- Ha sido editado por una persona distinta del autor.
- Se han comprobado los datos, las cifras y los enlaces.
- Se han cumplido los requisitos básicos de accesibilidad: texto alternativo, orden de los encabezados y contraste legible.
- Aprobado por quien lo haya solicitado.
- Publicado o entregado, y registrado en un lugar donde el equipo pueda consultarlo.
Niveles de historia, sprint y lanzamiento
Scrum exige una única definición de «terminado» para el incremento. En la práctica, muchos equipos agrupan las comprobaciones según el lugar en el que se producen de forma natural:
| Nivel | Se aplica a | Artículos habituales |
|---|---|---|
| Historia | Cada elemento de la lista de tareas pendientes | Se ha revisado el código, las pruebas han superado con éxito, se han cumplido los criterios de aceptación y el responsable de producto lo ha aceptado |
| Sprint | El Incremento en su conjunto | Integrado en la rama principal, conjunto de pruebas de regresión con resultado satisfactorio, implementado en el entorno de prueba |
| Comunicado | Lo que llega a los clientes | Se han redactado las notas de la versión, se han realizado las comprobaciones de seguridad y rendimiento, y se ha informado al servicio de asistencia |
Mantenga la historia como referencia principal. Si una comprobación solo puede realizarse en el momento del lanzamiento, indíquelo también en la lista, para que nadie marque una historia como completada dando por hecho que otra persona detectará el error más adelante.
Cómo redactar una definición de «terminado»
- Empiece por lo que se le sigue escapando. Fíjese en los últimos sprints: los errores detectados tras dar por «terminado» el trabajo, las historias que han tenido que volver a tramitarse, las tareas aplazadas. Cada uno de ellos apunta a una línea que falta.
- Redáctelo junto con todo el equipo. Las personas que realizan el trabajo deben llegar a un acuerdo al respecto en una sola sesión, con el scrum master actuando como moderador y el product owner presente en la sala. Una lista impuesta desde fuera es una que el equipo no defenderá bajo la presión de los plazos.
- Asegúrese de que cada línea sea verificable. «Probado» es una impresión; «pruebas automatizadas escritas y superadas en la integración continua» es una verificación. Si dos personas pudieran discrepar sobre si se cumple una línea, reescríbala.
- Limítese a lo que vaya a hacer cumplir ahora mismo. Empezaríamos con entre cinco y ocho líneas. Añada las metas ambiciosas cuando el equipo pueda realmente alcanzarlas.
- Colóquelo allí donde se realiza el trabajo. Una lista de comprobación incluida en la plantilla del ticket o en la columna «Hecho» del tablero se utiliza. Una página del wiki acaba cayendo en el olvido.
- Revíselo en la revisión retrospectiva. Cuando se pase por alto el mismo fallo dos veces, añada una línea. Cuando se marque una línea sin que nadie la haya comprobado, pregúntese si sigue estando justificada.
Definición de «terminado» frente a criterios de aceptación
Esta es la distinción con la que los equipos suelen tropezar con mayor frecuencia. Los criterios de aceptación de una historia de inicio de sesión son específicos de dicho proceso: unas credenciales correctas le llevan al panel de control, mientras que tres intentos fallidos bloquean la cuenta. La definición de «terminado» (revisado, probado, implementado) es idéntica para la historia de inicio de sesión, la historia de búsqueda y la historia de facturación. Los criterios son locales y responden a la pregunta «¿hemos creado lo correcto?». La definición de «terminado» es global y responde a la pregunta «¿alguna parte de nuestro trabajo está lista para su entrega?». Una historia no se considera terminada hasta que supera ambas etapas.
Definición de «listo» frente a definición de «terminado»
Son como dos soportes para libros, no gemelos simétricos. La definición de «listo» da paso a una historia dentro del sprint: lo suficientemente pequeña, lo suficientemente clara y estimada. La definición de «terminado» da paso al trabajo finalizado fuera del sprint. «Listo» se refiere a la historia; «terminado», al trabajo. Los equipos que solo cuentan con una de ellas suelen centrarse en «listo» (porque las historias que no están listas llaman mucho la atención) y dejan que «terminado» pase desapercibido, y así es como se acumulan las historias pendientes y las que están «al 90 % completas».
Las tres listas de comprobación dejan de confundirse entre sí en cuanto se comprenda qué es lo que controla cada una de ellas:
| Definición de «listo» | Criterios de aceptación | Definición de «hecho» | |
|---|---|---|---|
| Ámbito de aplicación | A nivel mundial, cada historia | Noticias locales: esta noticia | A nivel mundial, cada historia |
| Gates | Inicio del sprint | El desenlace de la propia historia | Salida del sprint |
| Respuestas | «¿Podemos empezar ya?» | «¿Hemos creado lo adecuado?» | «¿Se puede enviar?» |
| Propiedad de | El equipo, junto con el responsable del producto | Responsable de producto, junto con el equipo | El equipo |
¿Quién es el responsable de definir qué se considera «terminado»?
El equipo lo redacta; el equipo se encarga de su cumplimiento. El scrum master actúa como facilitador y el product owner aporta su opinión sobre el umbral de aceptación, pero son los ingenieros quienes deciden qué implica técnicamente que algo esté «terminado», ya que un «terminado» mal definido supone una deuda que ellos deben saldar, no la dirección. Vuelva a analizarlo en una retrospectiva cuando la misma deficiencia siga repitiéndose; esa es la señal de que falta algún elemento.
Cómo influye la definición de «terminado» en sus estimaciones
Los puntos de historia cuantifican el trabajo hasta su finalización, no hasta que se haya «terminado de programar». Por lo tanto, la definición de «finalizado» está implícita en cada estimación. Si añade una línea del tipo «rendimiento comprobado», cada historia se vuelve un poco más extensa. Cuando la lista cambie, vuelva a revisar sus historias de referencia en la siguiente sesión de planificación; de lo contrario, la velocidad descenderá por una razón que nadie podrá explicar.
¿Qué es lo que falla?
La definición de «terminado» se convierte en un cartel. Se cuelga en la wiki del equipo, se recita durante la incorporación de nuevos miembros y se ignora ante la presión de los plazos: «Escribiremos las pruebas en el próximo sprint». Dos sprints más tarde, la deuda de pruebas es estructural y la definición se ha convertido en una ficción. Cuando el concepto de «terminado» es difuso, la velocidad se infla: el equipo acumula puntos por un trabajo que en realidad no está listo para su entrega, y la previsión deja de tener sentido sin que nadie se dé cuenta.
La solución no consiste en una lista más larga, sino en una más corta en la que el equipo se mantenga firme. Una definición de «terminado» solo es real en la medida en que haya una tarea que esté dispuesto a no marcar como terminada porque no cumple con uno de sus criterios.
Los criterios de aceptación determinan el avance de la historia. La definición de «terminado» determina el avance del equipo. Asegúrese de que sean lo suficientemente breves como para que realmente pueda hacerlos cumplir. Un criterio que no se hace cumplir no es más que papeleo.
Preguntas frecuentes
¿Cuál es la definición de «terminado» en el método ágil?
La definición de «terminado» (DoD) es una única lista de comprobación que cada historia debe cumplir antes de que se considere completada: por lo general, debe haber sido sometida a pruebas, revisada, fusionada, documentada e implementada en el entorno de pruebas. Se trata de una norma común para todo el equipo, no de una lista específica para cada historia, y su finalidad es que «terminado» signifique lo mismo cada vez que alguien lo diga.
¿Cuál es la diferencia entre la definición de «terminado» y los criterios de aceptación?
La definición de «terminado» es global; se aplica el mismo criterio de aceptación a todas las historias. Los criterios de aceptación son locales, es decir, específicos de cada historia. Los criterios de aceptación indican lo que debe hacer esta funcionalidad; la definición de «terminado» indica qué significa que un trabajo sea «listo para su entrega» en cualquier caso que el equipo produzca. Una historia debe cumplir ambos requisitos.
¿En qué consiste una lista de verificación de «definición de «hecho»»?
Una lista breve y explícita de los requisitos que deben cumplirse en cada historia: código revisado e integrado, pruebas escritas y superadas, ausencia de regresiones conocidas, documentación actualizada, implementación en un entorno de pruebas y aceptación por parte del responsable de producto. Los elementos concretos varían según el equipo, pero la lista debe caber en una sola pantalla y cada línea debe poder verificarse.
¿Cuál es la diferencia entre la definición de «listo» y la definición de «terminado»?
Las etapas de «listo» marcan el inicio del sprint; son el umbral que debe superar una historia antes de que el equipo se comprometa con ella. Las etapas de «terminado» marcan la salida del sprint; son el umbral que debe superar el trabajo finalizado antes de su entrega. «Listo» se refiere a que la historia esté bien definida; «terminado» se refiere a que el trabajo esté listo para su entrega.
¿Cómo se redacta una definición de «terminado»?
Empiece por lo que siempre se le escapa: los errores, el trabajo de corrección y las tareas pendientes de los últimos sprints. Acuerde la lista con todo el equipo, redacte cada punto de modo que pueda responderse con un «sí» o un «no», redúzcala a lo que realmente vaya a aplicar y colóquela donde se realiza el trabajo, como por ejemplo en la plantilla de tickets. A continuación, revísela en la retrospectiva cada vez que se le pase algo por alto.
¿Quién establece la definición de «terminado»?
El equipo de desarrollo es el responsable, normalmente con la ayuda del scrum master. El product owner aporta su opinión sobre los criterios de aceptación, pero son las personas que realizan el trabajo quienes deciden qué implica técnicamente que algo esté «terminado», ya que son ellas las que pagan las consecuencias cuando dicho concepto se define de forma imprecisa.
Lecturas relacionadas
- Estimación ágil: la guía completa: aquí encontrará toda la información al respecto.
- Criterios de aceptación: la prueba por historia con la que a menudo se confunde la definición de «terminado».
- Definición de «listo»: la puerta de entrada situada en el extremo opuesto del sprint.
- Errores en el Planning Poker: cómo un «hecho» poco riguroso inflan la velocidad.