Reflexiona sobre la complejidad del proceso

Hoy he ido a prepararme un vaso de leche con chocolate y mis pasos han sido lo siguientes ya que me parecieron los mas obvios:

1º He ido a la estantería de los vasos, he cogido un vaso y lo he dejado sobre la mesa que esta debajo de la estantería.

2º He ido a la estantería del chocolate, he cogido el chocolate y lo he dejado sobre la mesa que esta debajo de la estantería del chocolate (a unos dos metros de la estantería de los vasos).

3º He cogido una cuchara, he ido donde estaba el chocolate, he cogido una cucharada de chocolate y he ido a verterlo en la leche.

Cuando me lo estaba bebiendo se me ha pasado por la cabeza: QUE MAL LO HE HECHO!!! He recorrido dos metros con una cuchara llena de chocolate (se podría haber vertido) cuando si hubiese dejado el chocolate al lado del vaso verter el chocolate en el vaso habría sido inmediato (gano  tiempo y esfuerzo).

Es una tontería pero si analizamos cuantas veces lo haber hecho en un año te das cuenta la de tiempo y fiabilidad que he perdido.

Este ejemplo tan sencillo ilustra perfectamente lo que pasa en muchos desarrollos de software. Para establecer una dinámica en el proyecto, se empieza con procesos obvios  ya que son fáciles de entender y solucionan rápido un problema. Lo malo es que, con el tiempo, la costumbre se traduce en "para que cambiarlo si ya tenemos un procedimiento" y no vemos la posible gran perdida de tiempo y esfuerzo.

Merece la pena, cuando nos da la impresión de que estamos malgastando tiempo y esfuerzo, en analizar la complejidad de los procesos para ver si pequeños cambios suponen un ahorro.

Criterios de terminado. Definition of done

Existen grandes problemas de comunicación en un proyecto de desarrollo de software. Eso se hace evidente cuanto mas se va avanzando en el desarrollo. Un gran problema de comunicación es no especificar ciertos matices que cada uno de los actores que intervienen en el proyecto interpretan a su manera.

Para evitar los problemas de comunicación merece la pena definir ciertos conceptos que parecen obvios pero que en realidad son muy subjetivos. El primero que hay que definir es el "Definition of done". Cuando una tarea, requisito, desarrollo, etc.. cuando algo esta terminado y se puede pasar a otra tarea? cuando le digo a mi jefe "ya esta" y el entiende lo mismo que yo? etc...

Los criterios no deben ser muy exigentes, ni complejos pero si establecer una serie de pasos que indiquen al implicado en el desarrollo que puede dar una tarea por terminada.

Por ejemplo, se le puede indicar a un programador que una tarea esta terminado cuando:

1. Has terminado en tu equipo de desarrollo local
2. Has subido todo el codigo al repositorio
3. Has compilado la aplicación con tus cambios
4. Has ejecutado la aplicación con tus cambios
5. Compruebas que la aplicación funciona correctamente con tus cambios

Puede parecer una tonteria pero merece la pena dejarlo claro, incluso escribirlo en algun lado para que el equipo siempre lo tenga presente.