May 26, 2017

Definición de Terminado (Done)

Definición de Terminado

  • 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.

El trabajo no terminado puede considerarse deuda técnica. Algunas formas que se pueden encontrar de la deuda técnica.

  • Defectos
  • No se ha implementado compilaciones automatizadas
  • Alta complejidad del código de tal manera que hace difícil su mantenimiento
  • No se cuenta con despliegue automatizado
  • No se han desarrollado de pruebas unitarias
  • Alto acoplamiento del código
  • La lógica de negocio en los lugares equivocados
  • Muy pocas pruebas de aceptación realizadas
  • Falta de pruebas de regresión
  • Código duplicado
  • Nombres o algoritmos difíciles de leer y mantener.

¿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
  • Capacitación
  • Integración y despliegue continuo
  • Uso TDD
  • Pruebas de integración

¿Cómo elaborar los criterios de terminado?

  • Los criterios de terminado deberían incluir los estándares de la organización de desarrollo, si estos estándares no existen entonces el equipo de desarrollo puede elaborarlos.
  • Los criterios de terminado deberían cubrir todas las actividades del proceso de desarrollo, por ejemplo actividades de análisis, de diseño, de codificación, de pruebas y despliegue entre otros.
  • Los criterios de terminado deberían servir para que el equipo de desarrollo considere el esfuerzo de implementarlos durante la estimación del Product Backlog.

Ejemplos de criterio de terminado

  • Todos los criterios de aceptación de cada PBI han sido validado y aceptado por el PO.
  • Todos los "Unit Test" fueron ejecutados sin errores
  • Que la integración continua se haya ejecutado sin errores

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.

Los criterios de terminado se pueden ver como capas que son para todo el proceso de desarrollo y el producto y no solamente para el incremento del equipo de Scrum.

Preguntas que pueden ayudarnos a mejorar la definición de Terminado (Done)

  1. ¿Existe una definición de Done?
  2. ¿La DoD ha sido acordada con la organización de desarrollo?
  3. ¿La DoD ha sido acordada con el Product Owner?
  4. ¿La DoD cubre aspectos para todas las actividades que permiten producir un incremento usable de producto?
  5. ¿Es DoD visible y disponible por el equipo?
  6. ¿La DoD está siendo usada durante el transcurso del Sprint?
  7. ¿La DoD ha sido revisada y actualizada durante el Sprint Retrospective?
  8. ¿Los criterios de Done incluyen los estándares de desarrollo de la organización?
  9. ¿Los criterios de Done incluyen las prácticas de DevOps?
  10. ¿Los criterios de Done incluyen elementos requeridos por la organización como por ejemplo documentación?

Joel Francia es Trainer de Scrum.org en el Perú y Agile Coach.

https://www.facebook.com/joe.familia1