Es mortal la sensación de que vamos quemando semanas a un ritmo vertiginoso. Tercera semana del bootcamp finiquitada, y con una sensación de victoria total.

Ha sido una semana de cosas variadas, que sin un objetivo claro al final ha cristalizado en una lección bastante interesante: Los lenguajes no importan tanto. Para eso siempre está la documentación y el ingenio necesario para utilizarla para encontrar la solución al problema.

¿Otra vez la misma historia? En realidad la conclusión de la primera semana semana fue muy parecida a la de esta. Digamos que he ampliado el abanico de cosas que van por delante de saber un lenguaje de programación.

En aquella ocasión se trataba de las buenas prácticas (código limpio, encapsulado...). Al final son cosas propias de este mundillo. Pero la lección aprendida esta semana es más universal. Y si ya de donde vengo era algo fundamental, cuando se trata de construir software se convierte en algo totalmente necesario.

Estoy hablando de la comunicación.

El experimento del viernes

La semana fue avanzando entre las clases de HTML y CSS de un maestro del diseño de UIs como es Emilio para luego pasar al tan particular mundo de Javascript de la mano de otro grande, Carlos Blé.

La gracia del asunto fue cuando llegamos al viernes, día en el que siempre nos toca hacer un ejercicio de dimensiones mayores a las habituales(bicharraco para los amigos). Y Carlos nos hizo una propuesta que simplemente no podiamos rechazar:

Poner a 12 proyectos de programadores que ni siquiera se pueden considerar juniors a hacer una versión web cutre del Tabú en un solo día. Con una API reconocedora de voz que no había por dónde meterle mano. Y todos juntos y al mismo tiempo. This is madness!

Eso iba a ser un infierno. ¡Solo llevamos tres semanas de clase! Pero nos lanzamos a ello. ¿Quién dijo miedo? Al fin y al cabo no había nada en juego y teniamos mucho que aprender.

Nos dividimos en 3 pequeños equipos de desarrollo, cada uno centrado en una parte del software. A mi me tocó en el equipo de integración. O lo que es lo mismo, en asegurarse de que todas las piezas al final acabaran encajando y que el resto de equipos no la liaran sobreescribiendo lo que hacía el resto.

El primer problema con el que nos topamos fue entender qué demonios estábamos haciendo. Ponernos todos en la misma onda porque, como quedó claro en el primero de unos cuantos daily standup meetings (o reuniones cada media hora de todos de pie contando nuestros avances o tribulaciones) cada uno tenía en su cerebro una visión distinta del problema.

Tras un rato de diálogo y un par de ejemplos de casos de uso bien descritos, por fin pudimos ponermos manos a la obra... Hasta que volvieron a aparecer los problemas.

Surfeando en un mar de contratiempos

Problema nº1: Liándola con git. El control de versiones es una parte muy importante en proyectos con tanta gente. Y por ahora no lo dominamos en absoluto. Lo gracioso fue cuando tuvimos que darle un cambio de estructura radical al proyecto, y en mitad del proceso se me fue la cabeza, di por hecho que el cambio ya se había terminado y subí una versión diferente y se lió. Se nos fue una hora para solucionar el follón. Y todo por no preguntar si ya estaba listo.

Problema nº2: Asignación de tareas repetida. Llegada la tarde, hicimos una especie de kanban con las tareas que estaban en marcha y las asignaciones. Yo me hice cargo de organizar un poco la situación y repartir tareas. ¿Pero qué pasa cuando alguien ya ha hecho algo y nadie te lo ha dicho y coges y se lo asignas a otro?

Problema nº3: Sirocos y faltas de respeto. Esto no se dio mucho, aunque en los momentos finales en los que estaba a punto de llegar el deadline más de uno aporreaba como loco el teclado mientras su navegante le gritaba para que le hiciera caso.

Problema nº4: Unir todas las piezas. ¿Pero qué nos llevó al caos y la confusión? Parecía que lo teníamos todo manos o menos claro. Pero llegado el momento en que teniamos que juntarlo todo, nos dimos cuenta de que faltaban unas cuantas cosas. ¿Por qué? Porque a pesar de nuestro intento inicial de establecer qué había que hacer, se nos habían pasado un par de detalles.

Problema nº5: Ponerse de acuerdo. Y uno de esos pequeños detalles no era precisamente pequeño. Era la maldita mecánica que controlaba el funcionamiento completo de la aplicación y que en ningún momento nos había dado por fijar. Y cada uno de los pocos que teniamos valor para darle vueltas al tema lo veíamos de una manera diferente y no eramos capaces de llegar a un acuerdo.

Conclusiones

Pero oye, a pesar de todo conseguimos que funcionara nada más que veinte minutos pasado el deadline. Mínimamente, pero funcionar al fin y al cabo.

Subidón aparte (ninguno dábamos dos duros por nosotros), lo realmente importante fue lo que plasmamos en la siguiente pizarra:

No esta mal ¿no? Fue un día intenso, pero en el que aprendimos muchísimo.

Pero si con algo me quedo, y sobre todo analizando los problemas que tuvimos que sortear para lograr nuestro pequeño éxito, fue la importancia que tiene la comunicación.

Todos y cada uno de ellos están relacionados de alguna manera con este tema.

Hubo una idea que comentó Carlos que me pareció maravillosa, a la vez que un poco utópica. Lo ideal en un entorno de trabajo sería que existiera una comunión total entre los miembros del equipo de desarrollo que no hiciera necesaria una jerarquía. Ese tipo de relaciones que hace que la comunicación entre los miembros fluya de forma natural.

Pero lo dificil de conseguirlo no quita que sea algo a lo que aspirar siempre. Para conseguir el éxito lo más importante no es escribir código. Es la comunicación entre las distintas partes, el estar en la misma onda todo el mundo. Hace falta saber hacia dónde estamos yendo y cómo vamos a llegar allí.