Definición de terminado en Jira: acuerda qué significa «terminado»

Un ingeniero termina un cambio y hace avanzar la incidencia de Jira. Una persona de pruebas descubre que la nueva pantalla funciona, pero un flujo existente se ha roto. Atención al cliente se entera del cambio por un cliente confundido. Todos usaron la palabra terminado, pero cada uno quería decir algo diferente.

Una definición de terminado proporciona al equipo un estándar compartido de finalización. Hace visibles las comprobaciones de calidad esperadas antes de comenzar el trabajo, de modo que la revisión dependa menos de quién recuerde hacer la pregunta adecuada.

En esta guía desarrollaremos un ejemplo para un equipo ficticio de un portal de clientes, distinguiremos las comprobaciones de calidad compartidas de los criterios de aceptación específicos de una funcionalidad y pondremos ambos junto a una incidencia de Jira mediante Definition of Done & AC de Power Pack.

¿Qué es una definición de terminado?

La Guía Scrum describe la definición de terminado como el estándar de calidad que debe cumplir un Incremento. Proporciona una comprensión compartida del trabajo completado. Cuando una organización ha establecido un estándar, este constituye el mínimo para sus equipos Scrum. Consulta la Guía Scrum oficial.

Para nuestro ejemplo práctico, piensa en un pequeño conjunto de preguntas que el equipo plantea sobre cada cambio pertinente. ¿Se ha revisado la implementación? ¿Han superado las comprobaciones de verificación acordadas? ¿Está disponible la información que las personas necesitan para dar soporte al cambio?

Las preguntas concretas dependen del producto y sus riesgos. Un portal público de clientes, un informe interno y un sistema crítico para la seguridad necesitan estándares diferentes. Copiar la lista de otro equipo sin debatirla puede dejar lagunas importantes y añadir trabajo sin utilidad.

Un estándar útil describe un resultado observable. «Alta calidad» expresa una aspiración. «Se han superado las comprobaciones de regresión acordadas y sus resultados están enlazados desde la incidencia de Jira» describe algo que un revisor puede examinar.

Separa la calidad compartida del comportamiento de la funcionalidad

Nuestro equipo ficticio añade preferencias de notificaciones. Los clientes podrán activar o desactivar un correo de resumen semanal. Los mensajes importantes de la cuenta quedan fuera de esa preferencia.

La funcionalidad necesita sus propios criterios de aceptación. Por ejemplo, una elección guardada debe seguir apareciendo cuando el cliente cierre sesión y vuelva a entrar. Ese requisito pertenece a esta funcionalidad porque describe lo que debe experimentar el cliente.

La definición de terminado abarca el estándar más amplio de finalización. Revisar la implementación, comprobar el comportamiento existente afectado y actualizar la documentación de soporte puede aplicarse a muchos cambios diferentes.

Ambas listas importan. Una funcionalidad puede comportarse como se solicitó y carecer de trabajo esencial de calidad. Del mismo modo, un código revisado y unas comprobaciones de regresión superadas no demuestran que la funcionalidad solicitada se comporte correctamente.

Empieza por las carencias que tu equipo observa realmente

Reúne brevemente a las personas que construyen, verifican y dan soporte al producto. Utiliza un ejemplo reciente de trabajo que parecía completo, pero necesitó seguimiento inesperado.

Nuestro equipo del portal identifica tres problemas recurrentes. A veces quedan comentarios de revisión sin resolver. La configuración existente de la cuenta recibe poca cobertura de regresión. Las instrucciones de soporte llegan después de que la funcionalidad esté disponible.

Esos problemas sugieren comprobaciones útiles. También dan al equipo un motivo para mantener breve el estándar: cada entrada debe evitar un fallo reconocible o establecer una condición de calidad necesaria.

Pregunta cómo verificará alguien cada entrada propuesta. Si nadie puede describir las pruebas, mejora la redacción antes de adoptarla. «Documentación completa» podría referirse a notas de versión, notas internas de diseño o un artículo de ayuda al cliente. Acordad qué información se necesita y dónde debe estar.

Acordad también quién realiza normalmente las comprobaciones. Esa conversación puede tener lugar en el proceso habitual de planificación. Una lista por sí sola no asigna un revisor ni reserva tiempo en su calendario.

Redacta una lista compartida y práctica

Este es el primer borrador del equipo del portal. Es un acuerdo de trabajo ilustrativo, no un estándar universal.

• La revisión de la implementación está completa y los comentarios de revisión obligatorios están resueltos.
• Se han verificado los criterios de aceptación acordados para la incidencia.
• Se han superado las comprobaciones de regresión acordadas para los flujos de cuenta afectados.
• Se han superado las comprobaciones de accesibilidad acordadas para las pantallas modificadas.
• La documentación de soporte refleja el cambio de comportamiento para el cliente.
• Los resultados de verificación y los enlaces de revisión pertinentes están registrados en la incidencia de Jira.

Antes de utilizar esta lista, el equipo documenta qué incluyen sus comprobaciones de regresión y accesibilidad. De lo contrario, dos personas podrían marcar la misma frase después de hacer trabajos diferentes.

Para el portal, el conjunto de regresión acordado incluye iniciar sesión, abrir la configuración de la cuenta y actualizar un campo de perfil existente. La revisión de accesibilidad de los controles modificados incluye manejo con teclado, foco visible y etiquetas comprensibles. Son ejemplos de las comprobaciones elegidas por este equipo, no un estándar completo de accesibilidad.

La entrada de soporte también necesita una interpretación práctica. Si un cambio no afecta al cliente, el equipo debe establecer de antemano un estándar adecuado para ese tipo de trabajo. Evita que los revisores improvisen excepciones solo para poner una lista en verde.

Añade el estándar a una incidencia de Jira

Abre la incidencia de Jira correspondiente y localiza la tarjeta Definition of Done & AC de Power Pack. Contiene las pestañas separadas Acceptance Criteria y Definition of Done. Selecciona Definition of Done antes de añadir las comprobaciones compartidas.

Para una lista pequeña, escribe el título de una comprobación y selecciona Add o pulsa Intro. Centra cada título en una condición revisable. Una frase larga con tres comprobaciones no relacionadas dificulta representar una finalización parcial.

También puedes seleccionar Bulk Import y pegar una lista Markdown. Por ejemplo, pega las seis entradas anteriores con un guion y un espacio al principio de cada línea. También se admiten las casillas de verificación habituales de Markdown.

La importación añade entradas a la pestaña seleccionada. Comprueba la pestaña antes de confirmar e inspecciona después la lista resultante. Importar de nuevo el mismo contenido puede añadir entradas que ya existen, así que úsala deliberadamente, no como una acción de actualización.

Utiliza entradas sin marcar para trabajo todavía no verificado. Las casillas Markdown marcadas se importan como completadas; las marcas copiadas de una incidencia anterior no deben sustituir a revisar el cambio actual.

El estándar acordado debe colocarse manualmente en cada incidencia pertinente. Conserva una copia de referencia en la documentación habitual del equipo y pega las comprobaciones adecuadas en las incidencias nuevas. Este proceso es una práctica del equipo, no una conexión automática entre un estándar central y cada incidencia.

Recorre una revisión real

Supongamos que la funcionalidad de preferencias de notificaciones está lista para revisar. Maya comprueba los resultados para el cliente mientras Priya verifica el conjunto de regresión acordado. Leo resuelve los comentarios pendientes de revisión de la implementación y enlaza el registro de revisión.

La primera revisión revela que la preferencia se guarda correctamente, pero el foco del teclado desaparece después de seleccionar Save. El equipo deja incompleta la comprobación de accesibilidad, registra el problema en su conversación habitual de Jira y lo corrige antes de repetir la comprobación correspondiente.

La documentación de soporte también está sin terminar. Eso sigue visible aunque los criterios de aceptación específicos de la funcionalidad estén completos. Las listas separadas ayudan a explicar por qué el equipo todavía tiene trabajo pendiente.

Cuando una comprobación se haya superado realmente, selecciona su botón Done. Vuelve a seleccionarlo si nueva información implica que el elemento debe volver a pendiente. Registra resultados de pruebas, enlaces de revisión y decisiones importantes mediante el proceso habitual de Jira o documentación del equipo.

Un elemento completado registra el criterio del equipo. No ejecuta la comprobación, recopila sus pruebas ni determina quién realizó la verificación. Si importa la identidad del revisor o el momento de revisión, registra explícitamente esa información en tu proceso habitual.

Lee con atención el indicador de preparación

La herramienta muestra los recuentos de elementos completados y totales de cada pestaña. Su indicador de preparación muestra Ready for Release solo cuando ambas listas contienen al menos un elemento y todos los elementos de ambas están completados. En cualquier otro caso, muestra In Verification.

Esa regla hace útil el indicador para detectar entradas sin terminar. También explica por qué una lista Definition of Done completa no produce el estado de finalización total mientras Acceptance Criteria permanezca vacía.

Interpreta el texto como un resumen del estado de la lista. No demuestra que las comprobaciones fueran suficientes, las pruebas convincentes o el producto seguro para su lanzamiento. Un equipo puede marcar como completada una comprobación mal redactada con la misma facilidad que una útil.

La lista tampoco bloquea una transición de Jira ni la integración de una solicitud de cambios. Sigue utilizando el proceso habitual de entrega y lanzamiento del equipo para tomar esas decisiones.

Mantén útil el estándar a medida que cambia el trabajo

Revisa el estándar cuando un defecto repetido revele una comprobación ausente, cuando el producto cambie de forma importante o cuando una comprobación existente deje de aportar información útil.

Por ejemplo, el equipo del portal podría descubrir que los cambios de preferencias funcionan inmediatamente, pero fallan después de una sincronización diferida. Ese hallazgo podría dar lugar a una regla de verificación más amplia para funcionalidades que dependen de procesamiento diferido. El equipo debe decidir primero a qué cambios se aplica y qué pruebas demostrarán el éxito.

Actualiza el estándar de referencia y debate cómo aplicar el cambio al trabajo ya iniciado. Las listas existentes de las incidencias no heredan automáticamente esa revisión. Inspecciona las incidencias afectadas y añade manualmente las nuevas comprobaciones acordadas cuando corresponda.

Evita ampliar la lista tras cada error aislado. A veces conviene más añadir un criterio de aceptación específico, aclarar una tarea de implementación o cambiar el proceso de revisión. El estándar compartido debe seguir siendo algo que el equipo pueda entender y aplicar de verdad.

Pruébalo en una incidencia actual

Elige una incidencia próxima a revisión. Acuerda un estándar breve y compartido de calidad, colócalo en Definition of Done y añade los resultados específicos para el cliente de esa incidencia en Acceptance Criteria.

Recorred juntos las comprobaciones y enlazad las pruebas donde vuestro equipo las registra normalmente. Marca las entradas como completadas solo después de verificarlas y revisa después el trabajo restante mediante tu proceso habitual de entrega.

El resultado útil es una conversación más clara. Cuando alguien diga que el cambio de preferencias de notificaciones está terminado, el equipo podrá explicar qué resultados funcionan, qué comprobaciones de calidad se superaron y de dónde procede esa conclusión.

• La Guía Scrum — Definición de terminado