Jump to content

Definición de hecho: Difference between revisions

From Scrum Manager BoK
← Older edit
Mberne (talk | contribs)
Bureaucrats, Interface administrators
2,053 edits
No edit summary
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
La '''definición de hecho''' (''DoD'' o ''Definition of Done'' en inglés) es la descripción de las condiciones que debe tener un trabajo para considerarlo terminado.
{{Meta-bok|min=5}}
La '''definición de hecho''' (''Definition of Done'' o ''DoD'' en inglés) es el conjunto de condiciones acordadas que debe cumplir un trabajo para poder considerarse terminado. Es el compromiso asociado al [[incremento]] en el marco estándar de Scrum: garantiza que lo entregado tiene la calidad suficiente para integrarse en el producto o sistema y, si procede, ser puesto en producción.


==Descripción y características==
A diferencia de los [[criterios de aceptación]], que son específicos de cada historia de usuario, la definición de hecho aplica a todos los incrementos por igual. Es explícita, conocida por todo el equipo y evoluciona con el tiempo: a medida que el equipo aprende y el producto madura, la barra de calidad sube.
*'''La determinan''' los [[desarrolladores]] y el [[propietario del producto]].
*Se suele plasmar en una '''lista de criterios''' al que se someterá la [[historia de usuario|historia]] o el [[sprint]] para confirmar si se puede considerar "terminado".  
*'''Es explícita y conocida por todo el equipo.''' Dependerá del ámbito del negocio, pero algunos de los aspectos más habituales que se incluyen son funcionalidad, calidad, pruebas, documentación y retroalimentación del cliente. Es decir:
**Todas las tareas o historias implementan la funcionalidad requerida de manera correcta.
**Todas se han implementado con alta calidad técnica, cumpliendo con los estándares necesarios.
**Todas se han probado y los errores encontrados se han resuelto.
**Todo ha quedado documentado adecuadamente para su fácil comprensión y mantenimiento.
**Y el cliente ha revisado y aprobado el incremento.
**También es habitual, en empresas de software, que la Definición de Hecho incluya criterios de seguridad, privacidad, y compatibilidad. Es importante que el código cumpla con los estilos y directrices del proyecto.


==Función==
Sin una definición de hecho clara, el equipo puede producir una nube de trabajo aparentemente terminado pero en un estado incierto, que complica las planificaciones y genera riesgos ocultos en la fecha de entrega.
*Incluye criterios y acciones que agregan valor demostrable, y puede ir evolucionando conforme se aprende, para mejorar tanto los entregables como la forma de trabajar.
*Ayuda a mantener un nivel de calidad que beneficia al cliente y a los usuarios.
*Ayuda a controlar el avance del proyecto.


'''«Hecho» debe significar que está listo para usarse:''' para integrarse en el producto o sistema. Eso no sólo requiere que el incremento funcione, sino que esté probado, que sea seguro, etcétera.
== Quién la determina ==


Sin una buena Definición de Hecho podemos producir una nube de trabajo no del todo terminado o en un estado incierto, que complica las planificaciones, y genera riesgos ocultos que pueden poner en compromiso la fecha de entrega y la calidad del producto.
La definen conjuntamente los [[desarrollador|desarrolladores]] y el [[propietario del producto]]. El equipo de desarrollo aporta los criterios técnicos de calidad; el propietario del producto aporta los criterios de entregabilidad desde la perspectiva del cliente.
==Diferencias con los criterios de aceptación==
===Nivel de concreción===
Los '''[[criterios de aceptación]]''' se centran en cada elemento del ''backlog'' por separado.  
*Están conectados a las historias de usuario.
*Son algo con lo que están familiarizados los product owners.
*Suelen expresarse en forma de lista, como un flujo o una serie de criterios.
*El propietario del producto los explica durante la reunión de [[planificación del sprint]], y cubren lo que el cliente espera de la historia.


La '''[[definición de hecho]]''' atañe a los incrementos, en general. Una historia puede estar completada, pero eso no constituye un incremento. Por supuesto, las historias incluidas en el sprint deben ser funcionales, y lo que define si lo son o no son los criterios de aceptación. Pero eso no es suficiente para entregárselo al cliente.
== Niveles de aplicación ==
*Se asegura de que los incrementos están «hechos» de verdad. Un incremento «hecho» es una entrega que se puede dejar cerrada con tranquilidad.


===Formato===
La definición de hecho puede aplicarse a distintos niveles de granularidad:
No existe un modelo estándar para escribir ni los criterios de aceptación ni la Definición de Hecho. Pueden apuntarse utilizando lenguaje natural, tal y como el [[product owner]] o la persona del equipo se exprese, o acordar entre todos un formato cómodo y que sirva a las necesidades del equipo. Lo que sí es importante es hacer un esfuerzo por ser concisos y descriptivos al sintetizar lo que se ha acordado durante las conversaciones.
 
==Véase también==
=== Tarea ===
*[[Criterios de aceptación]].
* Implementada.
*[[Desarrolladores]].
* El código escrito cumple estilos y directrices del proyecto.
*[[Propietario del producto]].
* Pruebas unitarias realizadas.
*[[Historia de usuario]].
* Integrada en el repositorio.
*[[Sprint]].
* Integra correctamente con el resto del sistema en el ''build''.
*[https://open.spotify.com/episode/0GjNQprSs7wbQ8s6G0lGXu?si=f6b4006adcd24e1f Scrum Manager Podcast | Episodio 6: Definition of Done].
* Gestor de tareas actualizado.
*[https://www.scrummanager.com/blog/2023/03/definition-of-done-o-definicion-de-hecho/ Scrum Manager Blog: Transcripción Scrum Manager Podcast | Episodio 6: Definition of Done].
* Satisfechas las métricas acordadas: cobertura, análisis estático, etc.
* Aprobada por el tester.
 
=== Historia de usuario ===
* Todas las tareas asociadas están hechas.
* Incidencias detectadas en fase de desarrollo resueltas.
* Código documentado con comentarios relevantes donde aporten claridad.
* Documentación y otros requisitos del proyecto completados.
* Satisface los [[criterios de aceptación]] acordados.
* Pruebas de integración realizadas.
* Pruebas unitarias acumuladas y de aceptación superadas (manual o automáticamente).
 
=== Sprint ===
* Todas las historias planificadas están hechas.
* Revisión del sprint realizada y feedback de los interesados obtenido.
* Retrospectiva realizada e identificada al menos una acción de mejora.
* Aprobado por el propietario del producto.
 
== Diferencias con los criterios de aceptación ==
 
Los '''criterios de aceptación''' se centran en cada elemento del ''backlog'' de forma individual: los define el propietario del producto para explicar qué espera de una historia concreta. La '''definición de hecho''' atañe a los incrementos en general: define el estándar de calidad mínimo que debe cumplir cualquier trabajo entregado.
 
Una historia puede satisfacer sus criterios de aceptación y aun así no cumplir la definición de hecho si, por ejemplo, el código no pasa el análisis estático o no está integrado correctamente.
 
== DoD reforzada en equipos con IA ==
Cuando parte del código se genera con herramientas de IA, la definición de hecho estándar no es suficiente. Los equipos que trabajan con asistentes de código o agentes de IA necesitan añadir criterios específicos —lo que la guía ''Scrum en equipos con IA'' de Scrum Manager denomina '''DoD reforzada''':
* '''Análisis estático:''' el código generado por IA pasa herramientas de análisis estático sin errores críticos antes de integrarse.
* '''No-duplicación:''' verificado que la IA no ha introducido código duplicado. La duplicación tiende a aumentar de forma significativa en proyectos asistidos por IA; el umbral recomendado es inferior al 5%.
* '''Seguridad:''' revisión de vulnerabilidades específica para código generado por IA.
* '''IA supervisando IA:''' utilización de agentes de IA como revisores automáticos del output de otros agentes, con semáforos y alertas.
* '''Revisión humana:''' un ''product builder'' (desarrollador) revisa y valida el código antes de que se integre, con especial atención a los errores sutiles que la IA introduce con apariencia de corrección.
<div class="bok-aviso">
Los prototipos generados con ''vibe coding'' o generación conversacional rápida '''no se consideran incrementos liberables''': son artefactos de aprendizaje para validar hipótesis. Incluirlos en la definición de hecho sin pasar la DoD reforzada es una de las formas más habituales en que el código generado por IA se convierte en deuda técnica acumulada.
</div>
== Error frecuente ==
<div class="bok-aviso">
'''Tener una definición de hecho que nadie consulta.''' Es habitual que los equipos acuerden una DoD en las primeras semanas y luego no la revisen ni la apliquen con consistencia. El resultado es que cada miembro del equipo aplica implícitamente su propia definición de "terminado", lo que produce calidad inconsistente entre historias e incrementos. La DoD no es un documento de inicio de proyecto: es un estándar vivo que debe estar visible y revisarse en cada retrospectiva.
</div>
== Recursos ==
<div class="bok-recurso">
🎙️ [https://open.spotify.com/episode/0GjNQprSs7wbQ8s6G0lGXu '''Podcast Ep. 6: Definition of Done''']<span class="detalle">Scrum Manager Podcast · Spotify</span>
</div>
<div class="bok-recurso">
📄 [https://www.scrummanager.com/blog/2023/03/definition-of-done-o-definicion-de-hecho/ '''Definition of Done o definición de hecho''']<span class="detalle">Scrum Manager Blog · mar 2023</span>
</div>
<div class="bok-recurso">
📄 [https://www.scrummanager.com/files/scrum_master.pdf '''Scrum Master v.4.0''']<span class="detalle">Descarga gratuita · Scrum Manager</span>
</div>
 
== Véase también ==
<div class="bok-tags">
[[Criterios de aceptación]] [[Incremento]] [[A punto]] [[Desarrollador]] [[Propietario del producto]] [[Artefactos]] [[Deuda técnica]] [[Agilidad técnica]]
</div>
<div class="bok-ecosistema">
<div class="texto">
<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span>
<span class="sub">Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span>
</div>
<div class="botones">
<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div>
<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div>
</div>
</div>
[[Category:Glosario de términos]]
[[Category:Glosario de términos]]
[[Category:Scrum]]
[[Category:Scrum_estandar]]

Latest revision as of 14:50, 14 May 2026

⏱ 5 min de lectura  ·  📅 Actualizado en 2026

La definición de hecho (Definition of Done o DoD en inglés) es el conjunto de condiciones acordadas que debe cumplir un trabajo para poder considerarse terminado. Es el compromiso asociado al incremento en el marco estándar de Scrum: garantiza que lo entregado tiene la calidad suficiente para integrarse en el producto o sistema y, si procede, ser puesto en producción.

A diferencia de los criterios de aceptación, que son específicos de cada historia de usuario, la definición de hecho aplica a todos los incrementos por igual. Es explícita, conocida por todo el equipo y evoluciona con el tiempo: a medida que el equipo aprende y el producto madura, la barra de calidad sube.

Sin una definición de hecho clara, el equipo puede producir una nube de trabajo aparentemente terminado pero en un estado incierto, que complica las planificaciones y genera riesgos ocultos en la fecha de entrega.

Quién la determina

La definen conjuntamente los desarrolladores y el propietario del producto. El equipo de desarrollo aporta los criterios técnicos de calidad; el propietario del producto aporta los criterios de entregabilidad desde la perspectiva del cliente.

Niveles de aplicación

La definición de hecho puede aplicarse a distintos niveles de granularidad:

Tarea

  • Implementada.
  • El código escrito cumple estilos y directrices del proyecto.
  • Pruebas unitarias realizadas.
  • Integrada en el repositorio.
  • Integra correctamente con el resto del sistema en el build.
  • Gestor de tareas actualizado.
  • Satisfechas las métricas acordadas: cobertura, análisis estático, etc.
  • Aprobada por el tester.

Historia de usuario

  • Todas las tareas asociadas están hechas.
  • Incidencias detectadas en fase de desarrollo resueltas.
  • Código documentado con comentarios relevantes donde aporten claridad.
  • Documentación y otros requisitos del proyecto completados.
  • Satisface los criterios de aceptación acordados.
  • Pruebas de integración realizadas.
  • Pruebas unitarias acumuladas y de aceptación superadas (manual o automáticamente).

Sprint

  • Todas las historias planificadas están hechas.
  • Revisión del sprint realizada y feedback de los interesados obtenido.
  • Retrospectiva realizada e identificada al menos una acción de mejora.
  • Aprobado por el propietario del producto.

Diferencias con los criterios de aceptación

Los criterios de aceptación se centran en cada elemento del backlog de forma individual: los define el propietario del producto para explicar qué espera de una historia concreta. La definición de hecho atañe a los incrementos en general: define el estándar de calidad mínimo que debe cumplir cualquier trabajo entregado.

Una historia puede satisfacer sus criterios de aceptación y aun así no cumplir la definición de hecho si, por ejemplo, el código no pasa el análisis estático o no está integrado correctamente.

DoD reforzada en equipos con IA

Cuando parte del código se genera con herramientas de IA, la definición de hecho estándar no es suficiente. Los equipos que trabajan con asistentes de código o agentes de IA necesitan añadir criterios específicos —lo que la guía Scrum en equipos con IA de Scrum Manager denomina DoD reforzada:

  • Análisis estático: el código generado por IA pasa herramientas de análisis estático sin errores críticos antes de integrarse.
  • No-duplicación: verificado que la IA no ha introducido código duplicado. La duplicación tiende a aumentar de forma significativa en proyectos asistidos por IA; el umbral recomendado es inferior al 5%.
  • Seguridad: revisión de vulnerabilidades específica para código generado por IA.
  • IA supervisando IA: utilización de agentes de IA como revisores automáticos del output de otros agentes, con semáforos y alertas.
  • Revisión humana: un product builder (desarrollador) revisa y valida el código antes de que se integre, con especial atención a los errores sutiles que la IA introduce con apariencia de corrección.

Los prototipos generados con vibe coding o generación conversacional rápida no se consideran incrementos liberables: son artefactos de aprendizaje para validar hipótesis. Incluirlos en la definición de hecho sin pasar la DoD reforzada es una de las formas más habituales en que el código generado por IA se convierte en deuda técnica acumulada.

Error frecuente

Tener una definición de hecho que nadie consulta. Es habitual que los equipos acuerden una DoD en las primeras semanas y luego no la revisen ni la apliquen con consistencia. El resultado es que cada miembro del equipo aplica implícitamente su propia definición de "terminado", lo que produce calidad inconsistente entre historias e incrementos. La DoD no es un documento de inicio de proyecto: es un estándar vivo que debe estar visible y revisarse en cada retrospectiva.

Recursos

🎙️ Podcast Ep. 6: Definition of DoneScrum Manager Podcast · Spotify

📄 Definition of Done o definición de hechoScrum Manager Blog · mar 2023

📄 Scrum Master v.4.0Descarga gratuita · Scrum Manager

Véase también

Criterios de aceptación Incremento A punto Desarrollador Propietario del producto Artefactos Deuda técnica Agilidad técnica

¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.

Buscar convocatorias
Club Agile
Retrieved from "https://www.scrummanager.com/bok/index.php?title=Definición_de_hecho&oldid=3717"