- Muchas veces sucede que la comunicación no es clara cuando se quiere definir que es terminado. Por ejemplo, cuándo un usuario especifica que requiere un reporte con cuatro columnas y que la última columna tenga un total parece algo sencillo. Pero si para probar ese reporte se requiere preparar datos históricos consolidados de varios meses y años entregados por un proveedor externo, además cuadrar los resultados con otros reportes y además que dichos reportes sean validados con datos de mínimo 6 meses, la cosa se complica bastante y los conflictos suelen aparecer con frecuencia más aún cuando el único punto de referencia es un documento de análisis donde no aparece si esto se encuentra dentro o fuera del alcance y por lo tanto el único entregable es el "Reporte terminado".
- También sucede que frecuentemente cuándo un miembro del equipo de desarrollo se refiere a que ha terminado una funcionalidad se refiere al término de la codificación y no al termino de dicha funcionalidad como un incremento de producto listo para ser usado para el usuario. Esto lleva muchas veces a conflictos porque se puede suponer que hay una mala intención del desarrollador al entregar un producto incompleto.
- En otras ocasiones supuestamente se ha terminado de desarrollar una aplicación con las pruebas del producto y revisado con los usuarios pero cuando se intenta pasar a producción los usuarios mencionan que requieren seguir probando con otros meses y además que hay otras integraciones que se requieren probar y que sin esas pruebas no pueden aprobar el producto, esto en realidad nunca estuvo en el plan de trabajo pero dado que el usuario siempre recalca que mientras no tenga el "producto terminado" no lo va aceptar no tenemos claro cuando hemos terminado, pero ¿Qué es terminado?
- La definición de "Terminado" es un entendimiento compartido de completado para el producto.
- Debe ser visible y universalmente entendido y acordado para fomentar la transparencia.
- Es el denominador común de la calidad del producto.
- Por ejemplo, un equipo de desarrollo que entrega una funcionalidad al Product Owner cree que ya ha terminado, el Product Owner cree que eso significa que junto con esa funcionalidad se ha elaborado la documentación asociada a la funcionalidad. El equipo de desarrollo no ha entregado esa documentación y no entiende porque se requería. Es un clásico problema de comunicación que podría ser resuelto por la definición de terminado.
La deuda técnica provoca una crisis en la profesión del desarrollo de Software.
- Una creencia de algunos clientes es que pueden pedir software y exigir fechas y alcances definidos y que ese software puede ser entregado en un estado terminado y con todos los requerimientos completados.
- Los desarrolladores para soportar esa creencia tienden a reducir la calidad para cumplir con las fechas y el alcance comprometido.
Entonces se producen resultados como los siguientes
- Software con errores, empresas que pierden dinero, clientes insatisfechos y que cada vez creen menos en la profesión del desarrollo de software.
- Los desarrolladores llegan a sentirse desgastados, desmotivados y con un sentimiento de resentimiento y disconformidad con la profesión del desarrollo de software. Pueden llegar hasta odiar el trabajo porqué a pesar de todo el esfuerzo no logran entregar productos de software “terminado”.
- Se produce un largo, tedioso y complejo proceso de estabilización que desgasta las relaciones entre el equipo de desarrollo y los usuarios.
Conforme el trabajo no terminado crece el trabajo terminado decrece creando un escenario en el cuál se invierte más tiempo en tratar de pagar la deuda técnica que en desarrollar más producto terminado. Se puede llegar a un momento en el cual la deuda técnica es tan grande que casi no se desarrolla nuevo producto y todo el tiempo se invierte en pagar esa deuda técnica.
¿Qué debería incluir la definición de terminado?
- Pruebas de rendimiento
- Pruebas de escalabilidad
- Pruebas de seguridad
- Calidad de código (Por ejemplo deuda técnica medida con SonarQube o usar NDepends)
- Refactoring
- Internacionalización a varias culturas
- Pruebas de aceptación del usuario
- Documentación requerida por la organización
- Pruebas de regresión
- Revisión de código
- Pruebas de integración
Los criterios de terminado en Scrum proveen transparencia
- Tener una definición de terminado completo para el desarrollo que sea similar al producto en producción
- Asegurarse que la definición de terminado optimice el mantenimiento y extensibilidad de la aplicación
- En cada Sprint cumplir los criterios de terminado y refinar estos criterios durante el Sprint Retrospective
- Cumplir los criterios de terminado por elemento del Sprint Backlog del Sprint para evitar sorpresas al finalizar.