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, etc. En este caso nos enfocaremos solamente en la
DoD de una funcionalidad, como parte del cumplimiento de un set de
requerimientos de un usuario.
Algunas cosas que debemos tomar en
cuenta antes de establecer la Definición de Listo son las
siguientes:
1. El nivel de detalle de los
requerimientos levantados:
¿Están las historias de usuarios
(H.U) bien definidas?. En otros post hablaremos de como 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 nos pueden indicar un criterio bien
razonable para en conjunto llegar a una Definición de Listo adecuada
al proyecto.
Es bueno recordar que los criterios de
aceptación por si solos no indican la Definición de Listo de una
funcionalidad o H.U.
2. El equipo de proyecto del proveedor.
El equipo humano es vital para
establecer una clara Definición de Listo, lo que nos lleva a
hacernos la siguiente pregunta ¿En que momento del proyecto tenemos
una Definición de Listo correcta? Básicamente va a depender, en
parte, de cuan bien se conozcan los actores involucrados en términos
de desempeño. Alguna de las razones que llevan a esta conclusión
son las siguientes:
2.1 Nivel de compromiso del product
owner y su equipo
El nivel de compromiso "verdadero",
no el profesado, se conoce cuando se está en pleno en el proceso de
desarrollo e implementación de las funcionalidades de software. Esto
hace que cualquier Definición de Listo que dependa de los niveles de
respuesta del product owner y su equipo debe suponer el mas alto
nivel de compromiso con el proyecto, para luego poder evaluar bien
las brechas entre lo exigido y lo recibido por parte de dicho equipo.
Ahora bien, ¿que sucede si la brecha
entre lo Recibido vs lo Esperado es negativa y no se puede cerrar?
Evidentemente habrá razones de peso para justificar esto, pero no
deja de ser un escenario viable sobre todo en un proyecto de ERP
(enterprise resource planning system) en el cual la operación de la
empresa se lleva en paralelo con el desarrollo e implementación de
las funcionalidades, y muchas veces toca estar en la empresa cuando
hay situaciones tales como: cierre fiscal anual, corte trimestral de
inventario, rotación de personal, cierre de línea de negocio, entre
otras.
En conclusión, en el caso que los
niveles de compromiso esperados resultasen mucho mayor a los que
realmente demuestra el cliente, cualquier Definición de Listo que se
haya realizado debe revisarse en pro de la salud económica del
proyecto.
3. Infraestructura de hardware
El acuerdo que defina cual va a ser la
plataforma de Testing y Producción, y como va a funcionar la misma,
es otro aspecto importante en cuanto a la Definición de Listo de
funcionalidades de software.
Muchas veces se comienzan proyectos (y
se terminan) sin que el despliegue de los servidores de producción
tenga fecha fija de ejecución, 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 el iniciar un proyecto de
desarrollo /implementación de software a la par de un proceso de
procura, instalación o puesta a punto de servidores de producción
debe tomar muy en cuenta la Definición de Listo de una forma muy
precisa en cuanto a lo que se tenga HOY en día como infraestructura,
y no con lo que se va a tener a futuro cercano, mediano o lejano.
Recordando que del cumplimiento de "Listo" depende el
cierre técnico/administrativo de la funcionalidad, no puede éste
estar atado a retrasos de despliegue de infraestructura no
estipulados en el proyecto.
4. La DoD no es un Checklist
inexpugnable
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 este implementando.
No hay comentarios:
Publicar un comentario