Mes: enero 2018

Proyecto fallido (porque no solo de los éxitos se aprende)

Hacia fines del año pasado una empresa con la que estaba trabajando me pedió que me encargara de automatizar los tests de una aplicación. Como yo ya estaba comprometido en otro proyecto con otro cliente, solo tenía disponible una dedicación reducida de 1 día por semana. A pesar de esto, el cliente quiso que yo me encarga de esa tarea y así lo hice.

La aplicación en cuestión ya estaba productiva y recibía actualizaciones frecuentemente. La idea era que yo avanzara con la automatización de tests trabajando de forma desacoplada del equipo de desarrollo. Y creo que ese fue precisamente uno de los errores. La aplicación no había sido diseñada considerando la testeabilidad lo cual llevó a que me cruzara con una importante cantidad de trabas al intentar automatizar.  Algunas de esas trabas eran esperables, pero al estar trabajando 1 día por semana y sin una dedicación explícita del equipo de desarrollo para darme soporte, el grado de avance semanal fue muy lento, a punto tal que fui yo mismo quien le propuso al cliente terminar el proyecto. A mi entender esta iniciativa requería: una persona full-time (o al menos con una dedicación de 20 horas semanales) y un tiempo explícitamente reservado del equipo de desarrollo.

Haciendo un análisis de lo ocurrido he podido identificar una situación en común con otro proyecto fallido en que participé tiempo atrás: iniciativa técnica con un baja dedicación mía y sin involucramiento explícito del equipo de desarrollo. La lección aprendida es: no involucrarme en proyectos donde no haya una dedicación explícita del equipo de desarrollo y donde yo no pueda dedicar un mínimo de 15 horas semanales.

Primer tema de investigación (casi) completo

En 2016 me uní al Grupo de Investigación en Prácticas y Procesos de UNTreF. Hubo varias cuestiones que me motivaron a unirme al grupo. Por un lado quería hacer una experiencia formal en investigación, por otro lado me pareció una buena oportunidad para estudiar un tema que me venía dando vueltas desde hacía un tiempo. Dicho tema tenía que ver con la gran popularidad de los métodos ágiles y mi sensación de abundancia de individuos y organizaciones «vende humo». Con esto me refiero a gente más preocupada por decir que «es ágil» que por «realmente serlo», gente implementado agile en forma incompleta (o flácida en términos de Fowler), mucha daily, mucho post-it y poco código decente. Con esta sensación en mente inauguramos una nueva línea de investigación dentro del grupo: Prácticas Agiles. Formalizamos la sensación con la siguiente hipótesis:

«Dentro del desarrollo de software existen distintos tipos de prácticas: las técnicas y las organizacionales. A partir de esto nuestra hipótesis es que las prácticas técnicas son mucho menos utilizadas que las prácticas organizacionales»

Para validar esta hipótesis realizamos un estudio empírico estructurado en 3 etapas dentro de la dentro de la comunidad ágil de America Latina.  Los resultados parciales de las etapas 1 y 2 los publicamos oportunamente en las ediciones 2016 y 2017 del CONAIISI. Los resultados finales surgidos de la tercer etapa y elaborados a partir de la encuesta que hicimos en Agiles 2017, los volcamos en un artículo que terminamos de escribir esta semana. Lo único que nos está faltando para cerrar esta tercer etapa de este primer estudio es la publicación de este artículo. La publicación resulta relevante por dos cuestiones: por una lado la validación formal de pares (fundamental en el ámbito científico/académico) y por otro la difusión del conocimiento generado. Ayer enviamos el artículo a una conferencia y ahora nos queda esperar el feedback que llegará dentro de un mes aproximadamente.

 

¿Queres aprender sobre escalabilidad de Software?

La gente Auth0 ha comenzado una iniciativa que ha dado en llamar Engineering BootCamp de la cual estoy siendo parte. En términos concretos esta iniciativa consiste en una serie de entrenamientos de entre 20 y 30 horas con un enfoque «hands-on» (algo así como 20% de teoría y 80% de práctica).

El primer entrenamiento será sobre escalabilidad y se llevará a cabo a comienzos de Febrero en las oficinas de Auth0 en Buenos Aires. La participación es totalmente gratuita pero como los cupos son limitados, los interesados deben completar un formulario de postulación y a continuación resolver un pequeño ejercicio de programación. La idea es que este ejercicio nos ayude a asegurar cierto nivel mínimo de conocimiento en los participantes.

Los interesados pueden encontrar más información y completar su postulación aquí. No se dejen estar que la postulación termina hoy (viernes 12).

 

Finalmente JavaScript

Como la mayoría de quienes hemos hecho desarrollo web, en algún momento tuve que tirar algunas líneas de JavaScript y sinceramente lo hice sin preocuparme demasiado por aprender seriamente el lenguaje. Hace un par de años, impulsado por NodeJS, JavaScript pegó un salto de popularidad que ameritó que uno  aprendiera JavaScript seriamente. Pero en aquel momento yo me encontraba trabajando en cuestiones de configuration management e infraestructura como código.

Finalmente hace un par de semanas empecé a trabajar en un nuevo proyecto con la gente de Auth0 y eso me llevó a que me ponga a aprender JavaScript seriamente. Es por esto que en futuros post iré compartiendo capítulos de mi camino de aprendizaje JavaScript.

Continuará…

Sobre las prácticas técnicas y «las otras»

Hace un par de días circuló por la red una frase de Ivar Jacobson: «Kill All Methods — Free the Practices«. Esto nos resonó mucho dentro de nuestro equipo de investigación en UNTreF porque nuestra temática de trabajo está enfocada en  prácticas de desarrollo de software.

En términos generales entendemos que en el desarrollo de software hay dos grandes grupos de prácticas cuyos nombres aún no terminamos de cerrar pero que por el momento venimos denominando practicas técnicas y prácticas organizacionales. Esta clasificación/agrupamiento de prácticas no es algo necesariamente novedoso, de hecho Bertrand Meyer en su libro Agile! habla de prácticas técnicas y organizacionales. Por otro lado, en el reporte anual de Agile de Version One se habla «técnicas ágiles» y «prácticas de ingeniería».

En el contexto de nuestra investigación las prácticas organizacionales son aquellas practicas aplicables en diversas disciplinas porque no requieren conocimiento específico de la disciplina porque tratan sobre la forma en que el equipo de organiza para realizar su trabajo.  Un ejemplo de este grupo de prácticas son las de gestión de proyectos, las cuales pueden aplicarse tanto en un proyecto de desarrollo de software como un proyecto de construcción civil.

Las prácticas técnicas son prácticas particulares de la disciplina y que generalmente no aplican (o pierden sentido) en el contexto de otra disciplina. Un ejemplo de esto podrían ser las prácticas de versionado de código en desarrollo de software.

Continuará…