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.

Integración continua, principio #2: build everywhere

Particularmente la tarea de Build debe poder ejecutarse tanto en el servidor de integración continua como en la máquina del programador. Esto es fundamental para que en caso de falla del build, los programadores sean capaces de reproducir la falla en sus ambientes locales ejecutando la misma tarea que ejecutó el servidor.

Al mismo tiempo esto reduce la dependencia con el servidor de integración continua, ya que el mismo solo agrega un paso previo y uno posterior al build. En concreto:

  • El servidor de IC monitorea al repositorio de código y dispara nuevas ejecuciones en caso de detectar cambios
  • Una vez disparado el build y descargado el código fuente, el servidor de IC ejecutará la tarea de build que es justamente la que debe poder ejecutarse en la máquina de los programadores
  • Finalmente el paso adicional que ejecuta el servidor de IC es la notificación del resultado del build

Integración continua, principio #1: Independencia de IDE

Desde el punto de vista conceptual esta práctica está muy bien descripta en el artículo de Martin Fowler (#lecturaObligatoria), pero a la hora de intentar implementar la práctica, no suele alcanzar con la teoría. En este sentido un libro que me parece muy útil es Jenkins: The definitive guide de John Ferguson.

Luego de la lectura de los mencionados recursos y de haber recorrido un largo camino con esta práctica he identificado algunos principios fundamentales para la efectiva implementación de esta práctica. A partir de hoy y durante los próximos días voy a compartir una serie de post explicando cada uno de dichos principios. Si bien los principios los voy a ir numerando, su numeración no tiene correlación alguna con su importancia. Aquí va el primero.

Independencia del IDE

La generación del build no puede depender de un IDE. Es sorprendente la cantidad de programadores que no son capaces siquiera de compilar su aplicación sin usar un IDE. Esta es una situación que veo en muchos ambiente Java (alta dependencia de Eclipse) y .Net (alta dependencia de Visual Studio). En la actualidad todos los lenguaje de programación cuentan con alguna herramienta de build e incluso si no existe una herramienta específica para algún lenguaje, siempre es posible utilizar alguna herramienta genérica como el noble make.