Prepara el Sprint

Tras el uso de la metodología Scrum en varios proyectos te das cuenta de que el equipo de desarrollo nunca va a ser responsable del desarrollo. El equipo, por lo general, esta formado por personas que solo quieren programar. No quieren tener una visión global del proyecto y no quieren hacerse responsable del trabajo de los demas.

Esto implica que al final se tenga un jefe de proyecto o un Scrum master o product owner mas parecido a un jefe de proyecto que al puesto que Scrum indica que debe tener. Si al final te decantas por usar Scrum pero con responsables entonces ten en cuenta varias cosas:

- Antes de la reunion de cierre de Sprint recuerda a la gente que lleven el estado de las tareas y el estado de lo que le quede sin finalizar preparado.

- Ve con el Sprint preparado a la reunión de definición del Sprint. Es decir, ya ten preparadas las tareas que tiene asignado cada miembro del equipo para el siguiente Sprint. En la reunión habla con los miembros del equipo de las tareas. En función de lo que se diga entonces se puede modificar. Pero llevalo preparado. 

Si estas ocioso propon un proyecto.

A todas las personas que hemos programado nos ha pasado que en algún momento de nuestra carrera hemos pasado periodos de estar ociosos completamente o casi completamente. Y estos periodos pueden durar meses.

Por lo general, el motivo es coyuntural: el proyecto entra en un periodo en el que se decide el rumbo que debe tomar, la empresa no tiene muy claro donde encaja mas tu perfil, el proyecto esta sobredimensionado, etc.. Pero sea cual sea el motivo, el animo del programador empieza a descender ya que aparecen sentimientos deprimentes: quieren que me vaya de la empresa, estoy perdiendo el tiempo, etc..

Puedes empezar a estudiar y a hacer cursos como loco de cualquier cosa y/o tecnología. No es mala solución pero si la situación se alarga entonces las energias que tenias para estudiar desaparecerán.

La mejor solución es que enfoques la situación como si tu jefe te hubiese mandado hacer una propuesta de una mejora completa del proyecto en el que estes. Por ejemplo, si trabajas en un proyecto que esta implementado en Java Structs entonces propon implementarlo con Spring Boot. Y no te quedes en un documento, implementa código.

Como abordar un problema concreto

Cuando se tiene se tiene que abordar un problema concreto (por ejemplo te piden que hagas una aplicación en Java o uses Docker para desplegar tu aplicación), se tiene que afrontar como una serie de tareas no ordenadas. Estas tareas se pueden dividir en dos:


- Tareas informativas: Son las tareas en las que adquieres conocimientos para formarte pero no da una productividad directa.

- Tareas creativas: Son las tareas que van a dar como fruto la solución al problemas que se esta abordando. Son las tareas que dan una productividad directa.

Por nuestra naturaleza humana, las tareas informativas son mas divertidas y enriquecedoras que las tareas creativas por lo que estamos mas predispuestos a abordar tareas informativas. Para que te estresen las tareas te recomiendo:

1º Haz la división del problema en tareas.
2º Identifica cuales son las creativas y cuales son las informativas.
3º A por las tareas:
3.a Un las horas de trabajo que estes en mejor forma o estes mas predispuesto aborda las tareas creativas.
3.b Cuando te sientas mas bloqueado o con menos ganas aborda las tareas informativas.

Casos:

1º El problema no tiene tareas informativas porque ya soy un experto: Es dificil de creer que no te quede nada por aprender (y mas en el mundo del software) pero lo que si que puedes hacer es (en la hora de las tareas informativas) abordar tareas informativas de otros problemas.


2º No tengo suficiente con mi horario laboral y sigo en la oficina despues de la hora o trabajo desde casa: Este tiempo debe ser completamente de tareas informativas.

3º Me quiero especializar en tareas informativas. No quiero hacer tareas creativas: Esta bien especializarse pero hay que ser franco, si solo te mueven las tareas informativas y no quieres hacer nada de creativas (o un numero muy bajo de tareas creativas) entonces existe un problema porque ninguna empresa te va a pagar para que solo te formes. La formación tiene siempre un fin productivo. Lo mejor que puedes hacer es buscar otras orientaciones como ser formador de otros profesionales.     

Vértigo técnico

Cuando en proyecto de desarrollo de software se ofrece formación tecnológica, tanto si va a usar dicha tecnología en el proyecto como si no se va a usar, el técnico siempre mostrará predispuesto a realizar dicha formación. Es normal, es bueno para el técnico y para el proyecto en general. Pero es muy diferente aprender que producir. Es decir, se puede producir un efecto en la respuesta del técnico que confunda y parezca extraño desde la gestión ya que el técnico puede estar muy dispuesto a formarse pero puede puede mostrar muchas pegas a la hora de desarrollar tareas productivas con lo que ha aprendido. Esto puede parecer contradictorio pero tiene mas sentido de lo que parece.

Desarrollar una tarea productiva tiene asociadas una serie de características que no son técnicas como son:

• Se le pedirá al técnico una fecha fin.
• Se le pedirá al técnico una calidad.
• Se le pedirá al técnico que explique que es la mejor solución.

 y por supuesto es mas fácil para técnico (y para cualquiera) garantizar estos puntos usando la tecnología con la que trabaja siempre que una tecnología que acaba de aprender.

A este efecto lo llamo vertigo técnico.

Como solucionarlo:

• Mas formación del técnico: para que adquiera mas conocimiento y pueda garantizar todos los puntos anteriores.
• Selección del técnico: puede que el mismo técnico no quiera moverse de su zona de confort. Si este es el caso se debe considerar la opción de no pedir al técnico que aprenda algo nuevo y seleccionar a otro técnico en su lugar.
• Comprensión en la gestión: Por parte del gestor hay que entender que una nueva tecnología convierte a un técnico senior en uno junior y no se le puede pedir resultados tan rápido como se hacia antes.     

Documentación Util

Este es un punto donde hay mucha discusión ya que tenemos en el enfoque básico que indica que cuanto mas documentación se haga y cuanto mas detalle tenga esa documentación mejor. Pero este planteamiento es el claro ejemplo de cosas que suenan bien pero en la practica son un fracaso. Por que? vamos a ver los factores que SI hay que tener en cuenta:

• Tiempo de elaboración: Cuanto mas extensa y mas en detalle sea la documentación mas va a costar redactarla.
• Mantenimiento: No existe (al menos en el mundo del software) documentación que este bien desde el principio. Ni los pliegos. Cuanto mas extensa y mas en detalle sea la documentación mas va a costar las modificaciones y las ampliaciones.
• Capacidad de comprensión: la documentación tiene que ser un punto de referencia, debe ser la "CONSTITUCIÓN" del reino del proyecto. Cuanto mas extensa y mas en detalle sea sera mas posibilidad exista de que en algún punto diga una cosa y en otro diga completamente lo contrario (que existan contradicciones).

La documentación de software debe seguir la siguientes reglas:

• Del axioma "Cuanto mas extensa y mas en detalle sea ..." del punto anterior tampoco saquemos la conclusión de que la documentación debe ser escasa. La documentación en un proyecto de desarrollo de software debe ser precisa y completamente determinista.
• Debe tener el mayor número de dibujos que expliquen gráficamente lo que se esta explicando con palabras.  
•  Debe tener un formato fácilmente accesible por todo el mundo. Sea técnico, gestión, cliente, etc.. Olvida los words, excel, etc... Tiene que ser un formato web tipo wiki, blog, etc..

La clave es que cuando algún miembro del equipo pregunte por cualquier cosa se le pueda solucionar "enviandolo" a una url donde esta la documentación precisa que le solucione el problema. 

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.