La semana pasada, en medio de la vorágine que esta suponiendo este mes de Agosto, escribí un post en el blog de Kabel Sistemas de Información donde hablaba sobre el concepto del trabajo terminado.
En el ámbito del desarrollo del software, vamos a encontrar que en función del rol que interectue con una tarea, normalmente el significado de terminado es diferente. Es muy importante, definir que se espera de una tarea y cual es el camino para conseguirlo. A continuación podéis leer el post, o podeís acceder al post que escribir originalmente en el blog de Kabel.
Acabado, cerrado o terminado, son palabras usadas comúnmente para referirnos a lo mismo: el momento en el que a una tarea no es necesario dedicarle más tiempo.
Probablemente el concepto de terminado, sea uno de los conceptos que más controversia levanta en el mundo del desarrollo de software, ya que es algo muy habitual que el concepto de terminado sea diferente para los diferentes roles que intervienen el ciclo de desarrollo y por lo tanto, cuando una persona del equipo de desarrollo dice esto esta terminado o cerrado, el jefe de proyecto, el arquitecto o el product owner esperan una resultado concreto que casi seguro es diferente al que espera alcanzar el desarrollador.
¿Que supone esto? tareas que se reabren / tareas que no se cierran, fricciones y en algunos casos frustración.
Evitar los problemas que surgen en relación al trabajo terminado es un propósito que tiene que perseguir la persona que esta liderando el desarrollo del proyecto y además, tenemos que entender la importancia que tiene ya este concepto esta directamente relacionado con otros de gran importancia, como la evolución del proyecto o el trabajo ideal.
Evitar los problemas que surgen en torno al trabajo terminado es algo asumible, simplemente, prueba lo siguiente:
Define cuando se encuentran las tareas terminadas.
Las tareas se encuentran terminadas cuando el responsable de hacer las pruebas dice que esta terminada.
Sencillo, contundente y sin dejar lugar a ningún tipo de duda. Una tarea estara acabada cuando la persona que prueba dice que esta acaba y que no es necesario dedicarle más tiempo.
Los hay que también defienden que una tarea esta acabada cuando una vez se ha desplegado la solución funciona en un entorno idéntico al que será el entorno de producción. Más o menos es lo mismo, ya que cuando decimos que el responsable de pruebas dice que esta acabada, esto implica que la solución ha tenido que desplegarse, que la solución ha de ser estable etc.
Una tarea estará terminada cuando el responsable de hacer las pruebas dice que esta terminada. En esta afirmación hay una parte muy importante que es “el responsable de hacer las pruebas”, es decir, damos por hecho que tendremos una persona implicada en el proyecto cuya labor sera probar y decir que es lo que esta y que no esta cerrado. Una persona que en definitiva se responsabiliza de lo que se va desarrollando y de que los acabados y niveles de calidad del producto son suficientes.
Define que significa terminado y que niveles de calidad esperas cuando algo esta terminado.
Comparte con el equipo de desarrollo que esperamos cuando algo esta terminado. La comunicación dentro del equipo es directamente proporcional al resultado del ciclo de desarrollo. En relación a las tareas que se encuentran hechas y las que no lo están, también. Como hemos dicho en la introducción normalmente nos encontramos que el concepto de terminado es diferente en base al role que desempeña cada uno de los miembros del equipos, así pues, unifica el concepto de terminado, deja claro cuando esta terminada una tarea y que es lo que implica.
Un buen ejercicio, es describir que es lo que se espera de cada una de las tareas y dejarlo escrito. Evidentemente esto tiene un coste en la gestión / creación de tareas, pero este sobre coste sera siempre inferior al coste que tiene sentarse con cada miembro del equipo que participa en el desarrollo de una tarea y contarle que esperas de ella o por supuesto, del coste que tiene esperar un resultado sin especificar cual es el resultado.
En un proyecto en el que participé, nos encontramos que el día que nos hicieron una demo del proyecto con las tareas terminadas, no se había realizado ningún trabajo en relación a la interfaz de usuario. Cuando nos hicieron la demo del supuesto trabajo terminado y preguntamos que pasaba con la solución ya que no tenía una hoja de estilos que plasmara la imagen corporativa del cliente ni ayudara a comprender lo que se le estaba exponiendo al usuario final, la respuesta fue:
El trabajo esta hecho, los estilos son interfaz.
Poco que decir al respecto la verdad. No obstante, ¿Que es lo que ha pasado para que un proyecto se considere terminado cuando falta por desarrollar una de las piezas más importantes del mismo?
No utilices el termino terminado.
Terminado es un concepto demasiado absoluto, muchas veces lo utilizamos pero no siempre es el mejor. Es decir, dado que vamos a tener en el equipo una persona que va a ser el responsable de definir que esta terminado, trata de que el termino terminado solo lo utilice él.
Desde el punto de vista del desarrollador, puedes utilizar otros términos, términos no tan absolutos que te dan margen para interactuar con las tareas, por ejemplo, en scrum, es un formalismo comúnmente aceptado utilizar los términos rojo y verde.
- Rojo cuando la tarea se encuentra en progreso.
- Verde cuando ya se ha realizado el trabajo y podemos considerarlo hecho.
Como conclusión, evitar los problemas que surgen en relación al trabajo terminado, es tan sencillo como hacerle ver al equipo cuando se puede dar una tarea por cerrada, quien dice que esta abierto y qué está cerrado y sobre todo que todas las personas que intervienen en el ciclo de desarrollo, tengan el mismo concepto de lo que supone que algo este terminado.
Y a tí, ¿que te parece? Espero comentarios.
A deshoras 