« Back to blog homepage

Extreme Programming, cómo aplicarlo en tu empresa

Álvaro Maleno, programador en prácticas de TravelgateX nos cuenta su experiencia en primera persona aplicando Extreme Programming en el equipoX. Esperamos que os sirva y que también vosotros, nos podáis compartir si os ha pasado algo similar.

El Extreme Programming surge de la mano de Kent Beck, un reputado ingeniero de software que buscaba una forma de desarrollo más efectiva.

Mi experiencia personal

En mayo de este año, en TravelgateX decidimos probar el Extreme Programming mediante un experimento con el cual medir el impacto que la metodología podía tener entre nuestras filas… Y en este punto entro yo.

Mi experiencia como programador era de menos diez, apenas he cursado un año completo del Grado Superior de Desarrollo de Aplicaciones Multiplataforma. Eso sí, ganas de crecer, todas las del mundo, que a la falta de habilidad hay que ponerle corazón.

Por suerte el compañero con quien me colocarían para trabajar mano a mano, codo con codo, espalda con espalda, me aventajaba en poco… sólo era un senior con más de quince años de experiencia, que es como decir que no le había “quedado ninguna para septiembre”.

Por delante, un proyecto interesante para un novato como yo, en el que para nada había que meter mano a ningún componente crítico del sistema de la empresa. Bajo ningún concepto, repito, estaba permitido manipular ningún componente crítico de la estructura del sistema de la empresa. Bien, continúo, el proyecto debía entrar en un componente crítico del sistema y, causando el menor impacto posible, rescatar una serie de información que debería de ser almacenada en base de datos.

Mi reto consistía, primero, en no morir en el intento; segundo, en conseguir que el programador senior no se hartase demasiado rápido de mí; y tercero, no ser despedido como consecuencia de lo segundo. Aún así, confiaba en que el proyecto saldría adelante por sí mismo.

La etapa de las diferencias

No hizo falta mucho tiempo para que las diferencias entre un inicio tradicional dentro de una empresa tecnológica y un comienzo siguiendo la metodología Extreme Programming se dejasen sentir en mi cuerpo. No, no pasé una tediosa semana dedicada a leer documentación exclusivamente durante la cual mi cerebro se vería obligado a descifrar el terrible enigma que habría de darme la respuesta a la pregunta: ¿a qué demonios se dedica la empresa? Por el contrario, tanto el proyecto como los conocimientos necesarios para afrontarlo me fueron transmitidos de la mano de un experto observando directamente la materia prima: el proyecto. Esto hizo que mi aterrizaje en el puesto de trabajo fuese muy suave, lo que consiguió que me sintiese parte de un proyecto desde el primer día.

Así se me presentó un mundo de posibilidades fuera de mi alcance hasta el momento. Al trabajo iba a aprender no sólo desde el punto de vista laboral, sino también personal. La manera en la que un programador experto afronta los proyectos que le son encargados, en nada se parece a la forma en la que un junior lo hace.

Los “seniors” han asimilado tan profundamente su profesión que parecen contener en su propia forma de ser, en sus hábitos, en sus razonamientos, un manual de buenas prácticas tan necesario como difícil de transmitir. Por ello, colocar a dos personas con semejante desnivel no ha sido la mejor forma de aplicar la metodología Extreme Programming, lo que supuso el motivo fundamental que propició el fracaso. Aún así, no han dejado de obtenerse resultados positivos.

El efecto “espejo”

Al situar a dos personas durante tanto tiempo en un mismo lugar y condenarlas a realizar cada actividad juntos, se crea un “efecto espejo” mediante el cual, una buena parte de las prácticas adquiridas con la experiencia, se transmiten y son asimiladas vía directa.

Aplicar Extreme Programming tal como lo hemos hecho, nos da como conclusión que un programador novato siempre tendrá dificultades para medir la magnitud de la importancia que tienen determinadas formas de afrontar un programa. Por ejemplo, dedicar el tiempo necesario para pensar qué se va a hacer y cuál es la manera que más le conviene al conjunto del sistema es algo que para un junior, más enfocado en encontrar una primera solución y transcribirla a código lo más rápidamente posible, suele pasar por alto.

No con poco esfuerzo conseguimos establecer unas rutinas de trabajo que asegurasen el buen resultado del proyecto y comprobamos que la metodología tenía una serie de fortalezas muy interesantes.

Garantizar una formación excelente, y como iniciación en el mundo laboral es estupenda, ya que asegura que el programador que empieza se habitúe a seguir unas buenas prácticas a la hora de programar. Además, se detectan errores en tiempo de codificación, lo que ahorra búsquedas eternas para solventar los bugs.

Como conclusión

El Extreme Programming funciona para situaciones críticas, ya que dos cerebros pensando suelen encontrar antes una solución y, el hecho de estar intercambiando ideas contínuamente favorece el proceso creativo, tan requerido para la labor.

Sin embargo, todo en la vida tiene su contrapartida y esta metodología no iba a ser menos. Hablar también agota, pero como resorte disparador del fracaso encontramos, fundamentalmente, dos hechos importantes: es imposible avanzar en un proyecto que no sea el común, ya que la pérdida del hilo de uno de los dos programadores lo dificulta. Esto imposibilita la efectiva resolución de incidencias, por ejemplo. El otro hecho se refiere a la dificultad para mantener a dos personas en el mismo lugar al mismo tiempo, ya que por ejemplo, ambas tendrían que irse de vacaciones en las mismas fechas para no dejar “huérfano” al compañero que trabaja en el mismo proyecto.

Tras un primer experimento “fallido”, podríamos decir, se ha puesto en marcha otro con dos programadores junior, confiando en que los problemas referentes al desnivel quedasen solucionados. Como conclusión importante de este segundo intento he podido extraer un aforismo tan simple como efectivo: “dos programadores junior no son un senior, pero no lo hacen nada mal”.

Agradecemos a Álvaro Maleno por contarnos su experiencia personal y también a Carlos Acedo por aportarnos su tiempo para también explicarnos cómo ha ido este proyecto. Continuará…

Learn More About TravelgateX