Categoría: opinion

Reflexiones sobre el programa de Agiles 2015

La conferencia ha terminado y en mi opinión ha estado muy bien. Al igual que en los últimos años, el programa estuvo compuesto por 3 tipos de sesiones: keynotes (sesiones plenarias), sesiones de open space y sesiones seleccionadas del call for papers. Es en estas últimas que voy a centrar este artículo.

Desde el punto de vista del contenido de las sesiones creo que hemos tenido una mejora de calidad respecto a años anteriores. Obviamente esto es una opinión completamente subjetiva basada en mi percepción personal y en comentarios de personas con las que hablé (tener presente que mi subjetividad puede ser muy alta pues yo mismo estuve involucrado en la selección de sesiones ;-)). 

Al mismo tiempo ocurre que el proceso de selección de sesiones utilizado en esta ocasión requirió mucho más esfuerzo que en años anteriores. La duda que aún tengo es si ese esfuerzo adicional efectivamente se tradujo en un mejora proporcional de la calidad de las sesiones. Me pregunto: ¿hay alguna forma de mejorar la calidad de las sesiones sin invertir tanto esfuerzo en proceso de selección?

Mi sensación es que no hay garantías sobre la calidad de las sesiones y al mismo tiempo creo que cualquier proceso de selección siempre tendrá una carga de subjetividad que terminará generando algunas disconformidades. En este sentido el gran desafío radica en maximizar la calidad disminuyendo las disconformidades. Y no olvidemos que la calidad también es una propiedad subjetiva, ¡ja!.

Durante la conferencia hubo algunos espacios de discusión sobre esta cuestión en los que Alan insistió en ir hacia un formato de conferencia completamente Open Space. Esta idea me gusta por el hecho de que disminuye drásticamente el esfuerzo que debe hacer el equipo organizador en la selección de sesiones (pues todas las propuestas son automáticamente aceptadas), pero al mismo tiempo me parece que aún nos falta cierta maduración en el uso del formato Open Space, o sea, como comunidad hemos realizado muchas conferencias con formato Open Space pero a pesar de ello muchas de las sesiones presentadas en nuestros Open Spaces parecen muy improvisadas y carentes de preparación, dos cuestiones que en la mayoría de los casos perjudican la calidad. Hablamos también sobre posibles estrategias para evitar la improvisación extrema/general. El camino parece ser que las sesiones sean propuestas de forma previa y que la propia comunidad pueda dar feedback de forma temprana. Esto es algo que se ha probado en algunos casos y ha reportado buenos resultados. Pero curiosamente lo probamos en Argentina y a mi parecer no funcionó pues hubo propuestas presentadas sobre las que nadie dio feedback y también propuestas presentadas cuyo autor ni siquiera asistió a la conferencia. De todas formas creo que tenemos que experimentar. La duda que me surge es si ese lugar de experimentación debe ser la conferencia latinoamericana o alguna otra conferencia local.

Continuará…

El fenómeno JavaScript

Si bien JavaScript tiene unos cuantos años, desde el auge de la web 2.0 su popularidad ha ido constantemente en ascenso. En los últimos años han aparecido diversas herramientas y frameworks que permitieron a JavaScript ir más allá de los navegadores web.

Como efecto colateral, ya no importa si uno se consideraba programador Java, C# o Ruby, hoy por hoy todo el mundo debe tener cierto manejo de JavaScript.

Personalmente nunca me gustó JavaScript pero a pesar de eso no dudo en usarlo cuando creo que es la opción apropiada para una determinada solución. Eso me llevo a trabajar con jQuery y Node.js.

Recuerdo que hace dos o tres años, mientras que en el mundo JavaScript empezaban a surgir diversos frameworks y herramientas, en el mundo de los Sysadmins empezaban a popularizarse herramientas de automatización de infraestructura. Justamente en el aquel momento me encontré en un contexto en el que tuve que elegir trabajar como desarrollador FrontEnd con JavaScript o bien tomar un rol de SysAdmin/DevOp y meterme con las herramientas de automatización. Precisamente fue esta última opción la que elegí. Creo que profesionalmente aquella fue una elección muy acertada pues el manejo de herramientas de automatización me permitió participar en diversos proyectos muy interesante. Pero hace un par de meses me rendí, siendo consciente que ya no es posible escapar de la marea JavaScript me puse a aprender AngularJS y agregué a mi backlog Meteor y React.

 

Mis notas sobre AOC 2015

El fin de semana pasado participé del Agile Open Camp 2015. Como ya había mencionado, el evento se llevó a cabo en la Estancia del Carmen ubicada en las afueras de Bariloche.

Sin duda en varios aspectos este evento fue el mejor evento que participé en mi vida. Paisaje, logística, contenido, emotividad, actividades sociales y recreativas son algunos de las aspectos destacados del evento.

Creo que fue clave el hecho de que los participantes estuviéramos alojamos en el mismo lugar de la conferencia y al mismo tiempo que el lugar estuviera reservado (casi) exclusivamente para el evento. Esto permitió realizar diversas actividades «extra programa» luego de finalizadas las sesiones «formales» como ser juegos, espacios de meditación y guitarreadas hasta bien entrada la noche. Una de esas actividades extra formales fue la escritura de un libro (tema que compartiré en otro post).

Entre los momentos que más me impactaron están:

  • La visita al Invap, una empresa del estado dedicada a desarrollos de alta tecnología: radares, satélites, reactores nucleares, etc.
  • La charla Héctor Otheguy gerente general del Invap
  • El espíritu colaborativo que se vivió a la largo del todo el evento incluso en cuestiones casi domésticas como poniendo y levantando la mesa, preparando la comida y sirviéndola cuando estuvo lista
  • El exquisito cordero que comimos el sábado a la noche seguido de un fogón que incluyó guitarra, armónica, canciones y payadas.
  • La charla de Alan a la orilla del lago Gutiérrez con los cerros y el bosque de fondo
  • El cierre del evento con palabras emotivas de los organizadores y el entusiasmo de todos los participantes

Más allá de todas estas estas cuestiones también hubo un sesiones de open space que tuvieron muy buena repercusión como ser: el dojo de retrospectivas facilitado por Thomas Wallet, la sesión sobre trabajo remoto facilitada por Mariano Szklanny, la sesión de juegos facilitada por David Canteros, el elefante Agile de los muchachos de Invap, el taller de organizaciones de Martín Salías, la sesión de organizaciones horizontales de los muchachos de Grupo Esfera, el taller de identidad de Pablitux y Rodrigo Monelos y podría seguir un rato más.

Analizando el evento desde una perspectiva comunitaria creo que definitivamente ha marcado un hito:

  • Por un lado (hasta donde tengo registro) fue el primer evento «inmersivo»  y organizado en forma abierta por la comunidad ágil de Argentina . Me refiero al hecho de estar todos juntos, todo el día, por 3 días (en mi caso me levanté siempre alrededor de las 8 y siempre me acosté después de la 1)
  • Por otro lado fue un evento grande (3 días con fuertes implicancias de logística y unos 70 participantes) y fue auto organizado por los propios participantes con el liderazgo de un grupo de entusiastas locales que fueron los que tuvieron la idea del evento.

Mis felicitaciones para el core del grupo de organizadores: 

Les dejo aquí algunas fotos memorables:

aoc_summary_1 aoc_summary_2 aoc_summary_3 aoc_summary_4

El Configuration Manager: habilidades y conocimientos

Una empresa con la estoy trabajando actualmente tomó la decision de tener dentro de cada equipo una persona con el rol de configuration manager. Inicialmente me generó ciertas sospechas, la única persona que conocí ocupando formalmente un rol así realizaba tareas que restaban mucho más de lo que sumaban y por ello los equipos terminaban ignorándola. Al mismo tiempo los proyectos exitosos que conozco deben parte de su éxito al hecho de que el equipo maneja las tareas de configuration management de forma integral en el día a día del proyecto.

Pero luego de pensarlo más detenidamente y analizando las particularidades del contexto, me autoconvencí que tener un configuration management por proyecto podía ser una buena idea  ya que en términos generales los equipos no tenían un buen control de la configuración debido en gran parte a falta de conocimiento. Entonces la idea era que estos CM se encarguen de ayudar a los equipos a incorporar prácticas de control de la configuración.
Ya convencido de la idea me puse a pensar que habilidades y conocimientos debería tener una persona para ocupar el rol de CM tal como lo estaba planteando esta organización. Más allá de conocimientos generales de Configuration Management, que se mencionan en cualquier libro de Ingeniería de Software identifiqué los siguientes puntos:
  • Background de desarrollo / perfil técnico
  • Sólidos conocimientos del sistema de control de versiones de la organización (Git en este caso)
  • Sólidos conocimientos de la herramienta de build de la organización (Maven en este caso)
  • Conocimiento de Build Server (Jenkins en este caso)
  • Conocimiento de bash
  • Disciplina
  • Capacidad de aprendizaje
  • Capacidad de liderazgo

 

 

Cuando un libro te toca: #MasProductivos

Hace unos días tuve un intercambio de mails con un colega que ya al tercer mail empezó a levantar temperatura. Escribí el quinto mail del intercambio, lo releí y de repente me acordé algunas cosas que había leído en el libro #MasProductivos de @martinalaimo. Le di vueltas en mi cabeza por un par de minutos y finalmente terminé escribiendo:

«Creo que entiendo tu punto y me parece que hay algunas cosas que no comparto, pero no considero que el mail sea el medio más apropiado para intentar ponernos de acuerdo. A menos que tengas una propuesta diferente, te propongo hablar este tema mañana cuando nos veamos físicamente»

Recibí una respuesta corta y positiva. Al día siguiente, tuve la charla presencial con mi colega y rápidamente pudimos llegar a un acuerdo win-win sin ningún tipo de rispideces 😉

Emoción: avance de ingeniería en el CBC

Hoy desayuné con una noticia que me emocionó: la última inscripción del Ciclo Básico Común (curso de ingreso) de Universidad de Buenos Aires indica que habrá más ingresantes 2015 en carreras de ingeniería que en carreras de ciencias sociales, una situación casi inédita.

Claro está que la UBA no es la única casa de altos estudios en el país, pero sin duda es una institución de referencia y es posible que esta tendencia sea un reflejo general de la sociedad. Parece que los esfuerzos de promoción de las carreras técnicas hechos por las diversas organizaciones relacionadas a la industria han dado frutos.

La noticia me llegó por medio de este artículo del diario Clarín, lo que me resulta curioso es que la información provista en el mismo artículo indica que el título de la nota es incorrecto, ¡ja!

 

DevOps, una nueva idea no tan nueva

El término DevOps fue acuñado por Patrick Debois quien allá por 2009 organizó una serie de conferencias bajo el título DevOpsDays. El objetivo de estos eventos era incentivar una visión holística de la entrega de software derribando las barreras de la visión tradicional que separaban el desarrollo del software de su operación. A pesar que el término fue acuñando hace ya más de 5 años, creo que fue en los último 3 que tuvo un salto de popularidad potenciado entre otras cosas por herramientas como Chef, Puppet, Docker, y Vagrant y por prácticas como Infraestructura as Code, Test-Driven Infraestructure y Self-Service Provisioning.

Si bien la idea de DevOps aún hoy puede parecer novedosa para algunas organizaciones, para algunas otras siempre ha sido moneda corriente. Hablando más en concreto creo que DevOps suele resultar novedoso o incluso revolucionario para grandes organizaciones de tipo «tradicional» como bancos, telcos e incluso organismos gubernamentales. Al mismo tiempo me parece que es moneda común en organizaciones surgidas en la era de internet como .coms y startups.

Personalmente desde 2012 soy parte del equipo de Tipit, una empresa dedicada a brindar soluciones web y que adicionalmente cuenta con un conjunto de aplicaciones ofrecidas como servicio.
Tipit es una empresa chica pero que tiene bien claro que sus clientes pagan por el valor aportado al negocio y que en este contexto se traduce en software funcionando en manos del usuario. Dicho de otra forma, en términos de valor no existe la diferencia entre desarrollo y operación, la cuestión es blanco o negro: ¿está la funcionalidad lista para ser usada en un ambiente productivo o no?

Al igual que la mayoría de mis colegas en Tipit, yo trabajo tanto en tareas de desarrollo como en tareas de operaciones. Esto no implica que todos hagamos todo, todo el tiempo, sino que cada uno tiene un rol en cada proyecto pero más allá de ese rol particular que cada uno desempeña, todos somos responsables de que el software este disponible en manos del usuario cuando este lo necesite. Entre otras cosas esto requiere no dejar las cuestiones de operaciones para la última milla, sino tenerlas presentes en forma temprana, ya desde el momento del diseño de cada funcionalidad.

DevOps ¿es un realmente un rol?

Érase una época en que las organizaciones operaban como silos, con un área de desarrollo por un lado y una área de operaciones/infraestructura por otro. Estas dos áreas no sólo hablaban poco entre ellas sino que incluso en algunos casos guardaban cierto rencor entre sí. Programadores y Sysadmins enfrentados mutuamente como Vampiros y Hombres-Lobo, porque obviamente más allá de las diferencias que ellos percibían, para todo el resto de la organización eran más o menos lo mismo: gente rara del área de TI.

La adopción de métodos ágiles en las áreas de desarrollo ayudó que los desarrolladores se acercarán más al negocio y al resto de las áreas de la organización. Agile fue algo así como la sustancia que permite a Blade exponerse la luz solar y vivir más como humano que como Vampiro. Pero en la gran mayoría de los casos la fórmula de Blade no tuvo efecto en los Hombres-Lobo, quienes quedaron aún más aislados del resto de la organización.

En varias organziaciones la cuestión se puso aún más interesante cuando los equipos usando agile pretendieron salir a producción en forma frecuente. Tradicionalmente los pasajes a producción ocurrian cada un par de meses y era entonces cuando la relación entre Programadores y Sysadmins alcanzaba los picos máximos de tensión. Ahora los programadores agile pretendián ir a producción cada 2 semanas y encima contaban con el apoyo (y el entusiasmo) de la gente de negocio. Para los Hombres-Lobo esto era demasiado: ahora los Vampiros tenian el apoyo de Blade y los humanos.

Y como suele ocurrir en todas las guerras, el mayor perjudicado con todo esto era el pueblo (que en este caso era la organización). Fue en este contexto donde surgió el la iniciativa de DevOps como una propuesta para acercar a los programadores y los sysadmins y lograr que cada uno trabajé consciente de la existencia y responsabilidades del otro. Es aquí donde las implementaciones de DevOps divergen en dos estrategias.

Por un lado algunas organzaciones generan un nuevo rol al que denominan DevOp con el objetivo de mediar entre programadores y sysadmins. Si bien creo que inicialmente esta estrategia puede ayudar mejorar la situación, creo que no es más que un remiendo. Estos DevOps cuentan generalmente con habilidades técnicas mixtas, o sea son una especie de Hombre-Lobo-Vampiro y en última instancia son un bicho raro más a los ojos del resto de la organización.

Por otro lado, algunas otras organizaciones ven DevOps como una transformación en la organización mediante la cual programadores y sysadmins dejan de lado su egoísmo para trabajar colaborativamente unos con otros (al mejor estilo Saga Crepúsculo parte 3) de cara a lograr una feliz convivencia con los humanos y el resto de la organización.

Personalmente me inclino por esta segunda estrategia de DevOps aunque reconozco que en ciertos casos la primera estrategia puede resultar beneficiosa siempre y cuando quienes ocupen el rol de DevOps cuenten con habilidades blandas (gestión, facilitación, etc) más allá de las habilidades técnicas.

Nobleza obliga: la analogía con Vampiros y Hombres-Lobo está tomada de un artículo publicado por Jeff Atwood en su blog CodingHorror.com.

La calidad no es inyectable

No puedes construir un producto y luego inyectarle calidad, por una simple razón: la calidad no es inyectable.

Si quieres un producto de calidad, debes construirlo con calidad desde el vamos. Esto implica que la calidad de tu producto está directamente relacionada al proceso de construcción del mismo. Por ello tu proceso de construcción debe incluir actividades y prácticas de calidad. Y nada de esto es particular de la construcción de software.

Curiosa y contrariamente a esto, durante mucho tiempo muchas organizaciones de la industria del software han insistido (y algunas lo siguen haciendo)  en separar las actividades de construcción de las actividades de calidad, delegándolas incluso en distintos equipos que trabajan sobre el producto en distintos momentos, generalmente en forma secuencial. Un equipo de técnicos construye el producto y una vez terminado lo entrega al equipo de calidad, como si este pudiera inyectarle calidad, pero realidad ese equipo en el mejor de los casos solo mide la calidad del producto haciendo pruebas. Dependiendo del resultado de esas pruebas, el equipo de construcción vuelve a tomar el producto para «mejorar» su calidad. Esta dinámica de ida y vuelta se repite hasta que el producto alcanza el nivel de calidad deseado (o hasta que se acaba el presupuesto o hasta que se llega a una fecha límite).

¿Es posible generar un producto de calidad de esta forma ? Si, es posible. Pero no es la única forma y posiblemente tampoco sea la mejor para todos los casos. Entonces, ¿cómo seria una mejor forma de hacer esto? ja!, eso es tema del próximo post 😉

 

Integración continua, principio #3: el principio del tio Ben

Cuando el tío Ben está apunto de morir en los brazos de su sobrino Peter Parker (spiderman) le dice una frase que lo marcará para siempre:

Grandes poderes conllevan grandes responsabilidades

Amo esta frase, creo que aplica a todos los ámbitos de la vida y también al desarrollo de software. En este sentido Tobias Meyer en su libro People Scrum la utiliza para describir la situación de un equipo autoorganizado: el equipo tiene el poder de autoorganizarse y eso automáticamente aumenta su responsabilidad. Analicemos esta situación por el contrario: si a un equipo se le imponen compromisos ¿cuán responsable será ese equipo por esos compromisos impuestos?. Si en lugar de eso fuera el propio equipo el que asumiera los compromisos ¿no se sentiría ese equipo automáticamente más responsable por el cumplimiento de esos compromisos que el propio equipo eligió? Mi experiencia me ha demostrado que efectivamente es de esta forma, lo cual confirma la frase del tío Ben.

Llevando esto al contexto de integración continua creo que la frase puede incluso aplicarse a la inversa, grandes responsabilidades requieren grandes poderes. O sea, si se pretende que un equipo asuma la responsabilidad de mantener un build sano, debe entonces darse a ese equipo las herramientas (poderes) para poder tomar esa responsabilidad. En concreto ello implica, entre otras cosas, que el equipo debe tener acceso total al ambiente de integración continua. Sin excepción puedo decir que todas las implementaciones fallidas que he visto de esta práctica tenían en común que el equipo no tenía acceso completo al ambiente de integración continua.