Dentro de Scrum tenemos muchas tareas rutinarias. Unas de ellas pueden ser las reuniones de planificación o inicio del Sprint y otra las reuniones de sincronización o Daily meeting. También tenemos las reuniones de Demo, las retrospectivas y finalmente el propio Sprint.

Estas fases rutinarias se repiten una y otra vez hasta la finalización del proyecto o pueden ser indefinidas si se trabaja en un producto, como es mi caso. Las repeticiones de estas fases, son una muy buena forma de afianzar la metodología y hacer que las personas del equipo la interioricen completamente sin esfuerzo alguno, ya que es a base de repeticiones sucesivas establecidas con un orden concreto. Esta forma de aprender la metodología aporta unas verdaderas mejoras al saber en todo momento y todas las personas del equipo, en que fase están ahora mismo y cual y cuando es la siguiente. Esto, unido a unas iteraciones cortas hace que todo el equipo esté en movimiento continuo sin detenerse.

 

 

Scrum intenta conseguir un equipo de alto rendimiento continuo. Con esta forma de trabajo casi sin descanso se consiguen fácilmente si el equipo ayuda. Ahora teniendo un equipo altamente productivo a pleno rendimiento, podemos avanzar rápidamente hacia nuestros objetivos de entrega, mejorar continuamente nuestros procedimientos, conocimientos  y técnicas, y finalmente trabajar con todo el mundo motivado y contento.

Cuando estas en esta fase de alto rendimiento continuo unido a iteraciones y repeticiones, puede darse el caso de que el equipo se empiece a cansar y ver este método de trabajo como monótono. Todo el mundo se cansa de las cosas por muy bien que estén si son repetitivas hasta el infinito. Sobre todo si el desarrollo es de un producto y nunca terminan las iteraciones.

Tenemos que evitar este decaimiento del equipo a toda costa. Para ello una solución muy fácil es romper los Sprints. Con romper los Sprint me refiero a hacer un parón de estas iteraciones continuas durante un tiempo, 10, 20 días, un mes, ahí como cada uno vea mas conveniente y que se adapta mejor a su equipo. Con esto, conseguiremos romper la rutina y que el equipo desconecte durante un tiempo de las repeticiones.

 

 

Cuando digo romper, no me refiero a parar de trabajar, sino simplemente pasar a otro modo durante este tiempo. Podemos cambiar por ejemplo a Kanban o hacer una gestión clásica de proyectos en desarrollo. Lo más cómodo sería conseguir que el cliente nos diera este tiempo para corregir la deuda técnica que haya en el proyecto hasta ese momento. Este caso con un producto y un cliente interno, puede resultar más fácil de conseguir, aunque con un cliente normal que paga cada entrega será mucho más duro y tendremos que buscarnos las habichuelas.

Un buen período para realizar este parón es durante verano. Esta época es perfecta para romper con la rutina, ya que la gente normalmente se coge vacaciones y no podremos hacer los Sprint con el equipo al completo durante todos los días. Si a esto le unimos la desconexión de por si que ya son las propias vacaciones, tenemos una rotura completa de la rutina.

Puede parecer que el parón del equipo en pleno rendimiento y totalmente metido en los Sprints, nos colapse ese rendimiento, pero realmente lo que conseguiremos será un período de desconexión, que no parón del desarrollo.

Al terminar este período, volveremos a retomar las iteraciones con más ganas y más energía. Volviendo a establecer los períodos y volviendo a la normalidad que todos necesitamos después de un tiempo desconectados. Todo el equipo se sentirá como si empezara un periodo estable, que conoce muy bien, controlado y con el que se siente a gusto, aportando motivación y entusiasmo.

 

 

Finalmente entraremos en la dinámica muy rápidamente, como cuando cogemos una bicicleta después de un tiempo sin utilizarla. Con la que al principio tenemos una toma de contacto para recordar nuestras habilidades y a continuación ya estamos montados pedaleando sin ningún problema.

Esta técnica finalmente lo que pretende es no quemar al equipo de trabajo con un trabajo continuo y repetitivo en metodología. Seguramente haya muchas otras forma de hacerlo, pero esta desde mi experiencia, es bastante efectiva

 

 

La mayoría de gente con la que he trabajado programando, cuando tenían que hacer alguna aplicación, una parte, API, clase o lo que fuera, lo escribían y ya está. Incluso yo hasta hace no mucho tiempo, escribía el código que mejor me salía a la primera y ahí lo dejaba, a veces orgulloso de él y todo :S . Por suerte, después de unos años de experiencia he aprendido que esto no debe ser así. 

No nos deberíamos limitar a  escribir un programa de principio a fin a la primera. Más importante aún, no deberíamos esperar ser capaces de escribir programas limpios y elegantes a la primera. Si algo he aprendido durante todo el periplo que ha supuesto mi carrera estudiantil y profesional, es que la programación es un arte más que una ciencia. Para escribir un código limpio, primero debemos escribir código sucio y luego limpiarlo.

Esto no debería ser una sorpresa para nadie. Escribir código limpio, es una cuestión de refinamientos sucesivos. Primero debemos escribir una primera versión, después revisarla, corregir lo que creamos conveniente, a continuación, volver a revisar y volver a refinar, y así sucesivas veces. Tener un ciclo de refactorizaciones sucesivas.

Un símil muy bueno se puede hacer con los polinomios de álgebra, donde los descomponemos en factores y los factorizamos paso a paso para hacerlos más simples y comprensibles sin modificar su resultado para llegar a una solución. Bien, pues con el código debemos hacer lo mismo, llegar a una solución lo más comprensible y simple para todo el mundo que vaya a meter mano a ese código.

La mayoría de los programadores jóvenes (con pocos años de experiencia en este tema) no están de acuerdo con esta técnica y no sigue este consejo muy bien. Ellos creen que el objetivo principal es conseguir que el programa funcione, dando igual como esté escrito por dentro. Terminando así con un código ilegible, código espagueti, o como le queráis llamar. Solo preocupa que funcione lo requerido y poder pasar así rápidamente a la siguiente tarea. Parafraseando a Uncle Bob “Los programadores más experimentados saben que esto es un suicidio profesional”.

El principal problema de que un programador se acostumbre a hacer refactorizaciones sucesivas de su código y cuidarlo con mucho más mimo, es que supone un esfuerzo y este esfuerzo no se ve plasmado en funcionalidades para el proyecto. A pesar de ello, si utilizamos esta forma de programar refactorizando, como técnica de desarrollo a lo largo del proyecto, conseguiremos que nuestro código sea de calidad y mucho más legible, ya no solo para nosotros, sino también para el resto de programadores del equipo. La experiencia dice (y no solo la mía) que este tiempo empleado en cada refinamiento sucesivo, será recuperado repercutiendo con creces en el avance del proyecto en el futuro.

Desde mi punto de vista, lo ideal es que la calidad quede automatizada e integrada en el propio proceso. Si algo falla, que pasará, algún tipo de alarma o aviso debe de saltar para que pueda ser corregido por alguien. Si algo falla y no se detecta, ya no es solo un problema, sino que es un problema del proceso y habrá que modificarlo para solucionar ese fallo de detección. Si alguien tiene que estar supervisando un proceso para controlar la calidad, es que dicho proceso no produce calidad solamente, sino que también produce defectos o desperdicios. Teniendo en cuenta que en la actualidad esto llevado al extremo es casi imposible, lo que nos tendremos que quedar es algo intermedio. Para lograr una excelente calidad en un proyecto necesitamos automatización y supervisión humana, lo mínimo indispensable en este último punto.
En Japón esta filosofía se denomina “Jidoka”, que podríamos traducirla como medio-automatización o automatización con ayuda humana. 

Este termino, “Jidoka” viene de Toyota, en concreto del telar que desarrolló Sakichi Toyoda, fundador de la empresa “Toyota” (Como no :P), que permitía parar la máquina, cuando esta rompía el hilo que utilizaba y así no terminaba desencadenando todos los problemas que esto ocasionaba.

De aquí, transladándolo al desarrollo de software, un ejemplo de auto-calidad dentro del proceso podría ser, el utilizar una buena herramienta de gestión de tareas como Jira, junto a sus plugings Greenhoper, FishEye, Crucible y Bamboo. Habituando al equipo a utilizar este tipo de herramientas, podremos llegar a tener un sistema totalmente integrado, que nos proporcione un buen nivel de calidad.

Un ejemplo simple de su uso prodría ser el siguiente:

1º Alta de nueva funcionalidad a implementar en el proyecto dentro de Jira (Historia de usuario).
2º Implementación de la funcionalidad en el Sprint actual suponiendo que utilicemos Scrum (Greenhoper)
3º Trazabilidad desde los requisitos introducidos en la tarea de Jira hasta los cambios que estos han ocasionado en el repositorio de código en su desarrollo (FishEye)
4º Revisión del código de esta tarea (Crucible)
5º Auto-build del proyecto completo con estos cambios de código (Bamboo)
6º Auto ejecución de test (Bamboo)

Si podemos conseguir que todo el equipo implicado en el proyecto siga estos pasos, habremos conseguido tener un mínimo control semi-automatizado de calidad, que ya quisieran muchos proyectos.
También quiero dejar muy claro, que la calidad no es responsabilidad de un único grupo o departamento. La calidad es responsabilidad de todo el equipo, desde la persona encargada en la toma y redacción de requisitos, hasta el programador más junior que tiene que esforzarse por escribir un buen “Clean Code”.

Otro buen ejemplo de prácticas que nos aseguran un mínimo de calidad en el proyecto siguiendo el proceso, sería TDD. Pero no de una forma de inspección después de la codificación, ni una etapa final o intermedia. Sino, como una disciplina de trabajo, una disciplina compartida por todo el equipo y todos los equipos de desarrolladores. Cada uno, debe de responsabilizarse de crear, ejecutar y mantener un conjunto de pruebas unitarias de todo el código que escribe, y estas deben ser automatizadas y ejecutarse en un tiempo moderado. Además de las pruebas, TDD define una refactorización del código continua, en la que el programador debe buscar en su propio código la forma de mejorarlo, dejarlo limpio, mantenible y así ahorrar tiempo futuro en su comprensión, con un gran ahorro también en deuda técnica.

Aunque parezca mentira, aquí lo difícil de su implantación no es la técnica, ni los medios, ni si quiera el tiempo de desarrollo, sino el que cada miembro de cada equipo asuma esta forma de trabajo como su responsabilidad. Cada miembro debe asimilar y comprender que el resultado del proyecto depende en gran parte de él y que si utiliza estas técnicas, llegará a tener un gran control de calidad, un código realmente mantenible y será finalmente más productivo. Algo duro y difícil de conseguir en una empresa.

Por desgracia, la calidad ha acabado siendo víctima de su propio éxito. Ha sido convertida en un fetiche del marketing, donde no importa tanto mejorar la calidad del proceso productivo, como obtener y galardonarte con una certificación de tal o de cual organización de moda. La pena, es que esto está empezando a pasarle también a las Metodologías Ágiles. Así que entendamos bien los conceptos básicos de calidad para que esto no nos ocurra a nosotros

Es muy importante marcarse objetivos y dejarlos claros, apuntarlos y releerlos de vez en cuando. Nuestra mente tiene un montón de pensamientos al día, si la enseñamos a fijarse en lo que más nos aporta, como son nuestros objetivos, esto nos beneficiará bastante a la hora de seguirlos. 

La gente tiene claro que quiere sentirse mejor, tener más energía o vivir con mayor satisfacción. Pero cuando preguntas qué es exactamente lo que quieren, casi nadie sabe responder. Todos sabemos que queremos tener dinero, tener muy buena salud y ser reconocidos, pero no definimos ningún paso para llegar a ello, no hemos pensado en que dirección avanzar para adquirirlo.

Seguro que os ha pasado muchas veces empezar a ver algo en todos lados. Algo en lo que antes no te habías fijado pero que ahora parece que te persigue. A mi me pasó por ejemplo cuando me saqué el carnet de conducir, (hace ya mucho )  no me había fijado en la cantidad de señales de trafico que hay por todos lados. O cuando empecé a leer sobre la agilidad, que pasé de no conocerla a encontrarme las metodologías por todas las web que leía. Esto, desde el punto de vista Zen, se denomina “Joriki” que se refiere al poder que surge de nuestra concentración.

Cuando te concentras en tus objetivos y estos te absorben completamente, tu tiempo pasa sin darte cuenta, como cuando programamos, investigamos o estamos absortos por una tarea que nos interesa y nos entusiasma.

Con la focalización se desarrolla una profunda concentración, Joriki.

“El poder o fuerza que surge cuando la mente se ha unificado y ha llegado a la concentración en un solo punto. Esto es más que la capacidad de concentrarse, en sentido usual de la palabra.”.

Mediante la apertura se cultiva la no resistencia, el desapego, el no imponerse. Esto para mi se refiere “Joriki”, el poder de concentrar tu mente en algo que te gusta y en algo en lo que quieres avanzar. Al fin y al cabo poner atención.

Con la concentración desarrollamos estabilidad mental para afrontar los retos, en este caso emocionales. Cuando comenzamos a desarrollar la no oposición, la no resistencia, entonces se produce una claridad mental para verlos como son y como actúan estos retos, estos objetivos.

Wolfgang von Goethe dijo “Estamos hechos y moldeados por lo que amamos”, y si lo que amamos es conseguir nuestros objetivos para ser mejores personas y vivir con energía, nos moldearemos por ello si nos esforzamos en conseguirlo.

Hace poco, terminé un libro llamado “El líder que no tenía cargo” de Robin Sharma.

El libro es una novela, en la que a través del protagonista, nos va abriendo las puertas a la filosofía del profesional, del líder sin cargo. La cuál se podría resumir, así:

“No importa el lugar que ocupes en el organigrama empresarial o cuales sean tus circustancias personales. Lo fundamental es que tienes capacidad para demostrar que eres un líder. Estés donde estés en tu profesión o en tu vida, siempre debes dar el máximo.”

En el libro, Robin, intenta hacer ver la habilidad que todos tenemos para llegar a tener un gran liderazgo. Pero no un liderazgo en el sentido de tener mucha presión acompañado de una gran responsabilidad en una gran empresa. Sino un liderazgo diario, en la vida de cada uno, y haciéndonos ver como podemos influenciar a cada persona de nuestro alrededor positivamente, inspirando, dando ejemplo en nuestro trabajo y actitud diaria. El tipo de liderazgo que tiene que ver con la excelencia en el trabajo y en el comportamiento, dando igual el puesto en el que te encuentres.

Todos podemos tener un millón de razones para desanimarnos, para no estar satisfechos, para no implicarnos en nuestro trabajo. Podríamos quejarnos de que no somos más que un empleado y que lo único que hacemos no es más que trabajar para la gente con mucho dinero. Pero una de las más grandes libertades que tenemos como personas, es la libertad de elegir cómo vemos nuestro papel en el mundo y el poder que tenemos para tomar decisiones positivas en cualquier circunstancia en la que nos encontramos.

Este libro me ha hecho recordar y replantearme muchas cosas de mi vida reciente. Cuando empecé a entrar, a leer y meterme en el mundo de la agilidad, no me dí cuenta de que cada vez estaba más ilusionado. No tenía ni idea de lo que depararía, pero desde entonces he aprendido que la incerteza es un regalo precioso. A casi todos nos da miedo lo desconocido. No debería ser así. Lo desconocido no es más que el comienzo de una aventura, una nueva oportunidad de crecer. Y justamente por estas causas me decidí a empezar a escribir en este blog