A la hora de definir cuando algo está "listo" o "hecho" (DoD =definition of done) siempre debemos tomar en cuenta que cada lista de cosas por hacer es diferente de proyecto en proyecto, el equipo humano tampoco es el mismo en todo los proyectos y las circunstancias que rodean al proyecto igualmente son variables. Por lo tanto no existe una Definición de Listo exactamente igual para todos los proyectos.
Hay que dejar claro también que pueden existir varias DoD en un proyecto: la DoD de una funcionalidad, la DoD de un Sprint, la DoD de una tarea, la DoD de una Historia de Usuario, etc. En este caso nos enfocaremos solamente en la DoD de una Historia de Usuario, como parte del cumplimiento de un set de requerimientos de un usuario.
Existen muchos ejemplos de DoD, pero la mayoría de las cosas que solemos encontrar en internet o en la literatura son genéricas y no toman en cuenta entornos reales de proyectos. Lo que queremos compartir en este post es como el entorno de un proyecto de implementación de un ERP como Odoo (aunque es válido a casi cualquier proyecto de tecnología) deja en evidencia que a dichas DoD le falta contextualizar algunos aspectos.
Lo que no te dicen que tomes en cuenta
La cantidad de variables que la literatura formal no menciona que tomes en cuenta es importante. Las DoD son confusas o diferentes en cada proyectos. La experiencia nos dice que hay algunos aspectos vitales a tomar en cuenta:
Los requerimientos
¿Están bien definidos?
¿Están las historias de usuarios (H.U) bien definidas?. En otros post hablaremos de cómo establecer el criterio de "bien definidas". Lo importante a resaltar aquí es que la precisión de los criterios de aceptación, las asunciones y las conclusiones finales son en parte fundamental para tener una DoD adecuada al proyecto. Si una H.U tiene criterios de aceptación vagos, el cliente no podrá considerar "lista" ninguna de las asignaciones asociadas a dicha H.U.
Es bueno recordar que los criterios de aceptación por sí solos no indican la Definición de Listo de una funcionalidad o H.U. Solamente indican aquello que espera el cliente que suceda con el software en unas circunstancias dadas.
Nivel del compromiso del cliente
¿Cuán cerca estamos de saberlo?
El desempeño del equipo humano es vital para establecer una clara DoD, lo que nos lleva a hacernos la siguiente pregunta ¿En qué momento del proyecto tenemos una DoD correcta? Básicamente va a depender, en parte, de cuán bien se conozcan los actores involucrados en términos de desempeño. De nuestra experiencia la respuesta a esa pregunta pasa por lo siguiente:
No te quedes con lo que te prometen, haz que te cumplan
El nivel de compromiso "verdadero” y no el profesado por parte del Product Owner/Gerente de proyecto del lado del cliente se conoce cuando estamos en la ejecución del proceso de desarrollo e implementación de las funcionalidades de software. Muchas veces contamos con que el cliente nos va a dar 5 horas diarias de un gerente de proyecto para validar nuestras entregas, entre otras cosas, y cuando estamos en plena faena nos damos cuenta que la dedicación no es tal y existe una brecha importante en su dedicación.
¿Que hacer?
Primeramente, antes de comenzar el proyecto vamos a suponer que tenemos de ese gerente o product owner del cliente la más alta dedicación posible. Con eso en mente, planteamos nuestra DoD.
Seguidamente evaluar la brecha entre lo que esperábamos en término de tiempo y dedicación del lado del cliente para con nosotros cuando el proyecto esté andando.
Es típico que si el gerente de proyecto o product owner tiene otra ocupaciones dentro del cliente, la dedicación no sea la prometida. Esto puede ser normal y DEBE ser previsto en caso que no sea una persona exclusiva y dedicada a nuestro proyecto.
Ahora bien, toda esta situación genera sin lugar a duda una afectación a la economía del proyecto, porque menos dedicación por parte del cliente afecta de seguro actividades que la DoD tiene definidas. Acto seguido vienen retrasos en tiempo y aumento de presupuestos.
Ejemplos de actividades definidas en algunas DoD que incluya participación directa del cliente pueden ser:
Revisión y aprobación del feature por el product owner en el servidor de testing.
Documentación en vídeo del feature por parte del usuario clave.
Generación del reporte X por parte del cliente para la validación de resultados, entre otros.
Como se ve, si el cliente se retrasa, mi DoD nunca se cumple y de eso comienzan a surgir los inconvenientes de tiempo y dinero.
En conclusión cualquier DoD que se haya realizado antes de iniciar el proyecto tomando en cuenta la participación del cliente debe revisarse en pro de la salud económica del proyecto.
Infraestructura de hardware
Cuando no es nuestra responsabilidad pero si nos afecta
El acuerdo que defina cuál va a ser la plataforma de Testing y Producción, y cómo va a funcionar la misma, es otro aspecto importante en cuanto a la DoD de funcionalidades de software.
Algunas veces nos hemos encontrado con que comenzamos proyectos (incluso los terminamos) y aún el despliegue de los servidores de producción por parte del cliente no se ha ejecutado, por lo que todas las funcionalidades desarrolladas quedan implementadas en un entorno de Testing o pre-producción, que en teoría debería ser una de las etapas intermedias del despliegue de la funcionalidad, pero en este caso termina siendo la final.
Por lo tanto si al comienzo del proyecto ya sabemos que el entorno de producción no es una realidad, ni lo será a mediano plazo, debemos especificar claramente en la DoD donde dejaremos culminado el trabajo: ¿entorno de prueba del cliente? ¿servidor en la nube de algún tercero? ¿entornos locales?, etc.
Recordemos que del cumplimiento de "Listo" depende el cierre técnico/administrativo de la funcionalidad y no puede éste estar atado a retrasos de despliegue de infraestructura no estipulados en el proyecto.
La DoD no es una lista inexpugnable
Siempre esta sujeta a revisión
Aún cuando logre definirse una lista de actividades para una DoD tomando en cuenta la variabilidad comentada en las secciones anteriores, hay que tener presente que una misma DoD muchas veces no aplica igual para todas las funcionalidades. La definición natural de "Listo" tiene ciertas limitaciones si lo vemos como un cheklist obligatorio para todas las funcionalidades que se desarrollen. El equipo de desarrollo debe estar consciente de ello y entender que algunas actividades deben ser aplicadas para cumplir el checklist y otras no, dependiendo de lo que se esté implementando.
Ejemplo de una DoD de Historia de Usuario
Todas las tareas asociadas están terminadas
Las pruebas unitarias están aprobadas
La verificación de los estándares del código están OK
Propuesta de merge revisada y aprobada
No hay defectos “por revisar”
Se cumplieron los requerimientos no funcionales
Se cumplieron los criterios de aceptación
El dueño del producto validó los criterios de aceptación en el entorno de pre-producción con data real.
El dueño del producto validó que lo que recibió en pre-producción se encuentra en producción.
