Una historia avanza por el tablero. El desarrollo está completo. Las pruebas son exitosas. El código se fusiona. El equipo la marca como completada y pasa al siguiente elemento. Dos días después, alguien descubre que la función falla bajo carga, expone datos del usuario o falla cuando las entradas están mal formadas. La historia se marcó como completada, pero en realidad no estaba terminada. Y ahora el equipo está solucionando problemas que deberían haberse evitado, mientras espera el nuevo trabajo.
Este patrón es tan común que la mayoría de los equipos han aprendido a vivir con él. Las historias marcadas como terminadas no siempre se pueden entregar. Los problemas de calidad surgen después. El equipo sabe que esto sucede, pero el mecanismo que lo evitaría (una Definición de Terminado clara, compartida y obligatoria) no existe o solo existe en teoría y se ignora en la práctica porque cumplirla ralentizaría al equipo.
La ironía es que ignorar la calidad para mantener la velocidad no hace que los equipos sean más rápidos. Los hace sentir más rápidos a corto plazo, mientras que acumula deuda que los ralentizará más adelante. Una Definición de Terminado que evolucione para elevar el nivel de calidad no limita la productividad. Es un mecanismo que hace visible la velocidad insostenible y obliga al equipo a abordar las prácticas que les impiden avanzar con rapidez de forma sostenible.
Cuando “Terminado” significa cosas diferentes
El primer síntoma de una definición de “Terminado” incorrecta es la falta de alineación. Diferentes miembros del equipo utilizan estándares diferentes. Un desarrollador marca una historia como terminada porque el código funciona en su entorno. El ingeniero de control de calidad la marca como terminada porque supera las pruebas funcionales. El propietario del producto la marca como terminada porque cumple los criterios de aceptación. Y luego alguien descubre que nunca se probó para detectar vulnerabilidades de seguridad, que no tiene gestión de errores, o que funciona aceptablemente con diez usuarios, pero colapsa bajo la carga de producción.
Cada persona creía estar haciendo su trabajo correctamente. El problema es que “terminado” nunca se definió con la suficiente claridad como para que todos trabajaran hacia el mismo estándar. Y a falta de claridad, las personas optan por el estándar que consideran alcanzable dentro de las limitaciones que enfrentan. Si el sprint está por terminar y es necesario mantener la velocidad, “terminado” empieza a significar “funcionalmente completo” y todo lo demás se pospone.
Ese aplazamiento es invisible al principio. El gráfico de velocidad parece saludable. El equipo entrega puntos de historia de forma constante. Pero, en el fondo, se acumulan defectos. Se ignoran requisitos no funcionales. La deuda técnica se acumula. Y para cuando el coste se hace visible, es mucho más costoso abordarlo que prevenirlo.
El trinquete de calidad
Utilizo la Definición de Terminado de forma diferente a la mayoría de los equipos. No como una lista de verificación estática que el equipo intenta cumplir, sino como un mecanismo de calidad progresivo que eleva el nivel con el tiempo. El mecanismo es simple: se establece una Definición de Terminado base que el equipo puede cumplir de forma consistente. Luego, una vez que han demostrado que pueden cumplirla, se eleva el nivel.
Por ejemplo, un equipo con dificultades para gestionar defectos podría empezar con una Definición de Terminado que indique «no se dejan defectos de alta prioridad pendientes para el siguiente sprint». Esto es factible. El equipo se centra en abordar los problemas más críticos antes de marcar el trabajo como finalizado. Con el tiempo, mejoran en la prevención de defectos de alta prioridad desde el principio: mejores pruebas unitarias, mejor revisión de código, mayor atención a los casos extremos. Una vez que cumplen este estándar de forma consistente, la Definición de Terminado evoluciona: «no se dejan defectos de prioridad media pendientes para el siguiente sprint».
El mismo mecanismo funciona para requisitos no funcionales. Un equipo que trabaja en una aplicación web podría comenzar con «programación defensiva y casos de prueba unitaria para inyección SQL». Una vez que esto se vuelve rutinario, el estándar se expande: «Vulnerabilidades de inyección SQL y exposición de datos abordadas». Luego, «Inyección, exposición de datos y fallos de autenticación». La progresión sigue un patrón similar al Top 10 de OWASP, elevando el nivel gradualmente a medida que el equipo desarrolla la capacidad para cumplir con estándares más altos.
La crisis artificial
Al aumentar la Definición de Finalizado, la velocidad suele verse afectada. Historias que se habrían marcado como finalizadas con el estándar anterior ahora siguen en curso porque no cumplen con los nuevos requisitos. El rendimiento del equipo disminuye. Esa caída parece una crisis, pero no lo es.
Lo que la caída revela es que la velocidad anterior no era sostenible. El equipo avanzaba rápido al posponer el trabajo de calidad. Marcaban como terminadas historias que no se podían entregar, y el costo de ese aplazamiento era invisible en el gráfico de velocidad. Aumentar la Definición de Terminado hace visible la compensación. La velocidad que se alcanzaba era una ilusión. La velocidad que se puede alcanzar con el nuevo estándar es la realidad.
Esa realidad genera incomodidad productiva. El equipo no puede cumplir con su compromiso de sprint bajo la nueva Definición de Terminado con sus prácticas actuales. Algo tiene que cambiar. Mejoran sus procesos previos: mejores pruebas, programación en parejas, revisión de código más rigurosa y verificaciones automatizadas. Con el tiempo, la velocidad se recupera. Pero ahora el equipo está cumpliendo con el nuevo nivel de calidad. Son sosteniblemente más rápidos y de mayor calidad, no solo más rápidos.
La crisis artificial es el mecanismo que impulsa la mejora. Sin ella, los equipos carecen de la fuerza necesaria para abordar las prácticas que les impiden avanzar con rapidez de forma sostenible. Se sienten ocupados, se sienten productivos y se estancan en un nivel de calidad que, con el tiempo, se volverá insostenible.
¿Qué pertenece a una definición de “Terminado”?
Una Definición de Finalizado funcional especifica qué debe cumplirse para que una historia pueda considerarse completa. Esto incluye lo obvio (escribir el código, aprobar las pruebas, cumplir los criterios de aceptación), pero también incluye lo que los equipos suelen postergar: requisitos no funcionales, documentación, preparación para la implementación y resolución de defectos.
Los componentes específicos variarán según el contexto del equipo. Un equipo que desarrolla una aplicación web orientada al consumidor tendrá requisitos no funcionales diferentes a los de un equipo que desarrolla una infraestructura backend. Un equipo en un sector altamente regulado tendrá requisitos de cumplimiento que otros no tienen. La Definición de Finalizado no es una plantilla para copiar. Es un acuerdo que el equipo establece sobre el estándar al que se someterá.
Ese acuerdo es responsabilidad del equipo, no una imposición externa. Como ocurre con todas las decisiones de ingeniería, quienes realizan el trabajo son quienes mejor pueden definir qué significa “terminado” en su contexto. Sin embargo, la responsabilidad no implica que el estándar sea estático. La definición de “terminado” debe evolucionar a medida que mejora la capacidad del equipo. Lo que era un desafío hace seis meses debería ser rutinario ahora. Y si lo es, el listón debería subir.
Las conversaciones que permite
Una definición clara de “Terminado” cambia el carácter de las conversaciones que mantienen los equipos. Cuando una historia se marca como terminada, pero posteriormente se descubre que presenta problemas, la conversación suele volverse conflictiva. El desarrollador afirma que funcionó en su entorno. El ingeniero de control de calidad afirma que no se probó correctamente. El propietario del producto afirma que no cumple con las expectativas. Todos defienden su parte del proceso y nadie se responsabiliza de la deficiencia.
Cuando la Definición de Terminado es clara y se aplica, esa conversación cambia. Si una historia se marca como terminada y posteriormente presenta problemas, la pregunta no es “¿de quién es la culpa?”. La pregunta es “¿por qué nuestra Definición de Terminado no detectó esto?”. Esta es una pregunta de sistemas, no de culpa. Impulsa al equipo a examinar si su estándar es lo suficientemente riguroso, si se aplica de forma consistente y si cuentan con los procesos necesarios para cumplirlo.
Ese cambio —de la culpa al pensamiento sistémico— es uno de los resultados más valiosos de una Definición de Terminado bien mantenida. Centra la energía del equipo en mejorar el proceso en lugar de defender decisiones individuales. Y convierte la calidad en una responsabilidad compartida, en lugar de algo que se delega al control de calidad o se pospone.
Con la mirada en el largo plazo
Una Definición de Terminado en constante evolución no es una restricción. Es una función forzada. Crea las condiciones para la mejora al visibilizar las prácticas insostenibles y dar al equipo un objetivo claro hacia el cual trabajar. La velocidad puede disminuir a corto plazo. Esa disminución no es un fracaso. Es honestidad.
Con el tiempo, a medida que las prácticas del equipo mejoran y el nuevo estándar se vuelve rutinario, la velocidad se recupera. Pero ahora el equipo entrega un trabajo realmente realizado: entregable, sostenible y resiliente en condiciones reales. No solo son más rápidos, sino sosteniblemente más rápidos. Y esa sostenibilidad es lo que distingue a los equipos que mejoran con el tiempo de los que se estancan en un nivel de calidad del que nunca podrán escapar.
La definición de “Terminado” no es el objetivo final. Es el mecanismo que lo hace alcanzable. Y como todo buen mecanismo, funciona mejor cuando evoluciona en respuesta a la creciente capacidad del equipo. Los estándares estáticos producen resultados estáticos. Los estándares en evolución producen mejoras. La diferencia no está en las palabras escritas. Está en el compromiso de elevar el listón cuando el equipo esté listo y luego apoyarlo a medida que avanza para alcanzarlo.
Establecer y desarrollar una Definición de Terminado que impulse una mejora genuina requiere identificar dónde están las brechas de calidad y desarrollar la capacidad para subsanarlas. Exploremos cómo hacer que la definición de terminado tenga sentido para su equipo. Reserve una consulta gratuita para hablar sobre sus estándares actuales y cómo podrían evolucionar.
Discover more from The Software Coach
Subscribe to get the latest posts sent to your email.
