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.

“Ser tú mismo en un mundo que intenta constantemente convertirte en otra cosa es el mayor de los logros.” Ralph Waldo Emerson.

Realmente lo importante no es ni tener un cargo, ni tener el poder que este puede otorgar. Lo importante de verdad es el trabajo que tu hagas, estar a gusto con él, que te divierta y guste, para poder dar tu máximo cada día. Así realmente serás importante en la empresa.

Todos nosotros tenemos el poder de ir cada día al trabajo y dar lo mejor de nosotros mismos. Y para eso no hace falta tener un cargo. Tenemos el poder de inspirar, influir y ensalzar a todas las personas con las que nos encontremos mediante el don del buen ejemplo. Y para eso no hace falta tener un cargo. Todos nosotros podemos crear cambios positivos ante unas condiciones negativas. Todos tenemos el poder de tratar a todos los implicados en una organización con respeto, aprecio y bondad, y al hacerlo, elevar la cultura de la organización a lo mejor de lo mejor.. Y para eso no hace falta en absoluto, tener un cargo.

“El dinero, la influencia y la posición no son nada comparados con la mente, los principios, la energía y la perseverancia” Orison Swett Marden

La definición de enciclopedia de Poder sería “Estar capacitado, reunir las condiciones, para hacer lo que se expresa.” con lo que cada uno de nosotros tenemos el poder en el día a día.

Todos los días, antes de entrar al trabajo, tendríamos que dejar nuestro ego en la puerta. En lugar de obsesionarnos con los objetivos que la sociedad quiere que rijan nuestra vida, con un despacho más grande y un sueldo más alto, deberíamos dedicar toda nuestra concentración y nuestras capacidades a realizar nuestro trabajo de la mejor manera posible. Todo lo demás vendrá dado. De ese modo, podemos dejar una huella en las vidas de nuestros compañeros y de nuestros clientes, y crear una organización mejor. No definir nuestro éxito por lo que conseguimos o el puesto en el que estamos, sino por lo que damos y podemos aportar. Esto, además de hacernos especiales a los ojos de todo el mundo, nos llenará de una sensación de plenitud y felicidad, por que sabríamos que estaríamos utilizando nuestra vida a una causa con sentido. Y para lograr todo esto, ya sabéis…. no hace falta tener un cargo

Muchas veces nos toca hacer tareas repetitivas una y otra vez que nos quitan mucho tiempo. Normalmente no las damos la mayor importancia, ya que estamos acostumbrados a hacerlas y nos salen casi sin pensar. Desde un simple ssh o una copia de backup, hasta un despliegue de la aplicación a producción.

Este tipo de tarea son subceptibles a fallos, ya que estamos tan habituados a ellas, que las hacemos sin pensar. ¿Cuántas veces has cometido fallos al hacerlas? ¿cuántas veces has puesto mal el nombre de la máquina a la que te vas a conectar, has metido mal la password, o incluso hasta te has cargado algo por un error tonto? Yo multitud de ellas.

Una de las mejores cosas que tiene la informática, es que podemos automatizar las tareas para ahorrarnos un tiempo valiosísimo y evitar esta serie de errores tontos, pero que pueden ser garrafales.

Hoy voy a intentan enseñaros una herramienta simple para automatizar estas tareas, llamada Expect.

Me diréis, “¿por qué nos cuentas esto? create un programa en bash o en cualquier lenguaje y ala!” Pero hay muchas veces que tenemos que pegarnos contra una interfaz interactiva, a la cual tenemos que contestar y esperar a que nos conteste, por eso solemos hacer estas tareas a mano. Bien, pues con Expect podemos interactuar con la terminal de turno y de una manera realmente fácil

Expect es una herramienta basada en el lenguaje Tcl, utilizada para automatizar aplicaciones interactivas como ssh, telnet, scp, ftp, etc, y todo esto de una manera rápida y sencilla.

Bien, pues empecemos con un ejemplo de una simple conexión por ssh:

Bueno, como veis es bastante sencillito, no hace falta controlar mucho del lenguaje para manejar este tipo de scripts. Ahora simplemente modificando las variables tenéis un script que se conecta por ssh a la máquina que le digáis, de una manera muy rápida. Hasta podéis configurar el prompt sin necesidad de modificarlo en el .bashrc del servidor.
Yo concretamente uso este tipo de script para conectarme a mis máquinas en el trabajo, y nunca me equivoco en la ip ni en el usuario ni en el password

Ahora, podemos comprimir un directorio del que queramos hacer un backup (por ejemplo) una vez conectados a él con el script anterior y quitando el comando interact:

Para más ayuda, tenemos el comando autoexpect. Este comando graba todo lo que hagamos en una terminal y lo va guardando en un archivo en formato expect, y una vez hayamos terminado podemos ejecutarlo. Esto, repetirá fiel y exactamente los mismo pasos que habíamos hecho. Esto ya es el colmo!

Imaginaros que cantidad de cosas podemos automatizar de una forma sencillita y cuanto tiempo y errores podemos ahorrarnos. Ahora piensa que cosas repites una y otra vez de forma repetitiva todos los días y podrías automatizar…. y hazlo!!

En mi opinión, la clave de todos los negocios son las personas. Al final, una empresa, no es más que una iniciativa humana en la que se unen varias personas en torno a algún sueño para poder llegar a expresar sus talentos y conocimientos, para ir dando y aportando valor a sus clientes.

Con el actual avance de la tecnología, la cantidad de altibajos, tanta competencia y tanto cambio en el mundo empresarial, la mayoría de gente ha olvidado que la clave de todo esto está en las relaciones humanas. Al ritmo actual al que estamos sometidos, es fácil sacrificar las relaciones en favor de los resultados. Pero la realidad es que cuanto más fuerte sean los lazos entre tus compañeros y tú, así como las relaciones con los clientes para los que trabajas, mejores serán tus resultados, o al menos esa es mi experiencia.

La sociedad ha creado un nuevo universo empresarial. Y estoy totalmente de acuerdo, cuando leo en algunos sitios, que hay que desechar las viejas técnicas y tácticas utilizadas hasta ahora y adaptarse a un mundo totalmente nuevo. Si seguimos haciendo lo mismo que hacíamos en los 80 y 90 e incluso en los 2000, seguiremos obteniendo esas altísimas tasas de fracaso en los proyectos. Todos hemos escuchado alguna vez la famosa frase de Einstein “Si buscas resultados distintos, no hagas siempre lo mismo.” e incluso hemos leído el líbro de Winnie de Pooh donde pone:

“Aquí está el oso Edward, bajando las escaleras, golpeándose en la cabeza, detrás de Christopher Robin. Es, por lo que él sabe, la única forma de bajar las escaleras, pero a veces siente que hay otra manera, si sólo pudiera parar de golpearse un momento y pensar en ello. Y entonces sintió que quizás…”

 

Los que se resisten a cambiar y se aferran temerosos a las mismas costumbres y hábitos, acabarán extinguiéndose, como los dinosaurios. ¡No vivas en el pleistoceno como los dinosaurios!!

En fin, lo que quiero decir es que, si de verdad se quiere alcanzar el más alto potencial en los negocios, se debe tratar a la gente excepcionalmente bien. Desvivete por tus clientes y ayuda a desarrollar las capacidades de tus compañeros. No necesitamos ser managers para despertar lo mejor en nuestros compañeros ni para ejercer una magnífica influencia en nuestra organización. No necesitamos ser ejecutivos para tener unas relaciones estupendas con nuestros clientes, de manera que alaben nuestros productos y el servicio que ofrecemos. Al final casi siempre son nuestros clientes los que más venden nuestros servicios y nuestros productos. Solo necesitamos dedicarnos cada día a expresar lo mejor de nosotros mismos y dejar una huella fantástica en otras personas.

Las mejores compañías cuentan no solo con equipos de personas que rinden al máximo, sino con equipos de personas con las que mantienen inmejorables relaciones. Y es que en realidad un negocio no es más que unas especie de conversación. Y si la empresa en la que trabajas olvida avivar esa conversación y las relaciones humanas entre los implicados, la conversación acabará pronto y el negocio fracasará.

Si de verdad quieres que tu empresa esté a la cabeza de tu sector, todo el mundo que esté en ella importa. Todo el mundo que trabaje en la empresa, es importante. Todas las personas de la empresa tienen que estar comprometidas y conectadas, porque la calidad de una empresa depende de la calidad de sus trabajadores.

Las buenas relaciones te darán una buena empresa. Las relaciones extraordinarias te darán una empresa extraordinaria.

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