Agile a izquierda y derecha

Continuando con la inquietud que traje hace un par de días comparto algunas ideas más surgidas de mi intercambio con mi querido colega @Pablitux.

Dada la relevancia del factor humano, la consciencia del otro, el espíritu de co-creación y colaboración, uno podría pensar que Agile tiene cierto aire de “izquierda”.

Del mismo modo si pensamos en el foco en la entrega de valor, la eliminación de desperdicios y la optimización del flujo, uno podría pensar que es un enfoque resultadista, algo que suena más de “derecha”.

Más allá de esto pensamientos algunos hechos que podrían aportar a esta reflexión.

  • Toda la movida de Scrum at Scale tiene una onda muy corporativa
  • El libro de Tobias Mayer & Alan sobre Scrum se llama Por un Scrum Popular
  • En Ágiles 2017 no hubo sponsors, lo que podría interpretarse como una postura “anti mercado”
  • El Ágiles 2014 se hizo en un hotel de categoría, la organización estuvo a cargo de una empresa de eventos, el precio de la entrada fue record y los sponsors estuvieron muy presentes en el evento

Estudio sobre enseñanza de métodos ágiles (pedido de ayuda)

El principal foco de mi trabajo de investigación este año es la enseñanza de métodos ágiles en carreras universitarias de grado en Argentina. En ese sentido llevo publicados dos trabajos:

  • Introducing Agile Methods in Undergraduate Curricula, a Systematic Mapping Study, publicado en CACIC 2019
  • Initial Assessment of Agile Development in the Undergraduate Curricula, publicado en WBMA@AgileBrazil 2019

El primero es una revisión de sistemática de publicaciones. El segundo es un trabajo basado en una encuesta realizada a estudiantes de carreras de informática. El tercer paso de este trabajo de investigación es estudiar el tema desde las perspectiva docente y en ese sentido estoy contactando docentes de ingeniería de software y afines para revelar qué enseñan y cómo lo enseñan.

Hasta el momento he logrado contactar docentes de 22 universidades, no pretendo contactar docentes de todas las universidades de país, pero hay algunas que particularmente me gustaría poder contactar:

  • Universidad de Mendoza
  • Universidad Nacional de Córdoba
  • Universidad Nacional de Rosario
  • Universidad Nacional de Entre Ríos
  • Universidad Nacional de Formosa
  • Universidad Nacional de La Pampa
  • Universidad Nacional de Río Cuarto
  • Universidad Nacional de Santiago del Estero

Si algún lector puede darme una mano para contactar docentes de ingeniería de software de estas instituciones le estaré muy agradecido.

Nuevos talleres para fin de año

De aquí a fin de año tengo agendados dos talleres y en paralelo estoy empezando a diseñar algunos nuevos para el año próximo.

El próximo lunes 11 de Noviembre voy a estar dictando una nueva edición actualizada mi taller de DevOps (más info aquí)

Durante diciembre estaré haciendo una nueva edición de mi taller online de Introducción a Docker & Kubernetes (detalles del temario aquí)

Por otro lado, a partir de algunas charlas y consultas que escuché en conferencias y meetups en los últimos meses, se me ocurrió armar algunos nuevos talleres.

Los nombres al igual que la estrategia de delivery aún la tengo que pulir, pero las ideas las tengo bastante claras:

  • Dev para Ops: unas de las cosas que viene de la mano de las iniciativas de DevOps es el manejo de Infraestructura como Código y junto con ello viene todo un conjunto de prácticas del mundo de desarrollo y de ingeniería de software que muchas veces son desconocidas para la gente que trabaja en cuestiones de Operaciones / Infraestructura / IT. Cuestiones como programación, modularización, abstracción, planificación, versionado, documentación, testing, etc. La idea de esta taller es cubrir estos temas desde una enfoque hands-on teniendo como audiencia a gente de Operaciones / Infraestructura / IT.
  • Git Internals: hoy en día el uso de Git es moneda corriente, pero me parece que la mayoría de los usuarios no sabe cómo funciona Git en detalle, ya sea porque utilizan Git desde algún IDE que oculta los detalles o porque solo utiliza las operaciones básicas. Este taller sería como una continuación de mi Taller de Git que armé hace unos 7 años.
  • Integración y Entrega continua 2.0: estas son dos prácticas de las más populares en la actualidad pero no son prácticas nuevas. Asimismo en los últimos años ha habido una explosión de herramientas de soporte a estas prácticas que se suman al clásico Jenkins. En este taller vamos a explorar los fundamentos conceptuales de estas prácticas junto con diversos criterios para elegir una herramienta y los patrones de implementación más populares.
  • Patrones de desarrollo de microservicios: microservicios es un tema picante y popular y como suele ocurrir con estos temas siempre gente intrigada y confundida. A esto se suma el hecho que un par de clientes me han consultado por capacitaciones en esta temática

Interesados en participar o conocer más de estos talleres me puede escribir por este medio.

Agile, Economía, Tradicionalistas e Innovadores

El clima político que se ha vivido en Argentina desde el comienzo de las campañas electorales me llevo reflexionar sobre las posibles relaciones entre Agilismo y los tan mencionados modelos económicos que tanto han sido nombrados en estos últimos tiempos. Antes de adentrarme más en el tema quiero aclarar que no soy experto en estos temas, sino un simple ciudadano de a pie, cuyas ideas pueden implicar razonamientos erróneos. Hecha la advertencia, avanzo.

Dentro de lo que ha dado en llamarse “Agile” o “Agilismo” hay a mi entender dos corrientes que yo personalmente denomino “los tradicionalistas” y “los innovadores”.
Los tradicionalistas son lo que ven los métodos ágiles como literalmente los describe el manifiesto: “…formas mejores de desarrollar software…” y por consiguiente lo aplica puntual y concretamente al desarrollo de software.
Los innovadores son los que tienen una conexión más profunda con el Agilismo y lo aplican en diversos contextos de su vida, excediendo por mucho el desarrollo de software e incluso el ámbito laboral. Yo personalmente me considero tradicionalista pero tengo varios amigos y colegas que sin duda se ubicarían en el grupo de los innovadores.

Para los tradicionalista me parece que no hay conexión entre agile y los modelos económicos.

Pero en el caso de los innovadores sospecho que puede llegar a haber cierta conexión. Los innovadores “van con agile a todos lados” y eso hace que agile se filtre indefectiblemente en la discusión de modelos económicos. Y cuando hablo de modelos económicos no me refiero necesariamente a cuestiones de macroeconomía sino también a cuestiones más del día a día como la forma en que nos organizamos dentro de una organización. Un dato en este sentido: en el meetup de Agiles Argentina suele hablarse con bastante frecuencia de organizaciones horizontales. En contraposición a eso, mientras escribo estas líneas me viene a la memoria una conversación con un colega que me cuenta que está trabajando en un corporación internacional y que están implementado SAFe lo cual me hace pensar que estoy escribiendo boludeces (perdón el término, puede que no suene elegante pero es muy gráfico).

En fin, me cuesta articular argumentos, tal vez porque soy un tradicionalista. Voy a cortar aquí y voy a intentar validar algunas ideas con colegas innovadores a ver opinan.

Continuará….

Un caso de Infra as Code

El manejo de infrastructura como código es relativamente simple cuando la infraestructura es Kubenernetes, pero cuando no es así la cuestión se puede tornar más compleja.

El proyecto en el que estoy trabajando actualmente no utiliza Kubernetes, sino servidores (VMs) con CentOS 7. El front (ember.js) es servido desde un Web Server Apache y el back (java) corre en un Wildfly (jboss). Por otro lado tenemos un SQL Server (el setup de la instancia está fuera de nuestro alcance, pero nosotros nos encargamos de manejar el esquema de datos)

Para manejar todo esto tenemos:

  • Scripts para levantar la VM en la plataforma de VMWare
  • Scripts Ansible para aprovisionar las VMs instalando y configurando Apache, Wildfly, Java, etc
  • Scripts flyway para evolucionar el esquema de base de datos

Estos scripts los utilizamos para administrar 4 ambientes:

  • Desarrollo / Integración
  • Demo
  • Test / Homologación
  • Producción

Adicionalmente a estos ambientes compartidos cada developer tiene una VM (vagrant) local en su máquina de desarrollo, que también es aprovisionada con los mencionados scritps. Este me parece que es un punto central en un esquema de infraestructura mutable: cada developer tiene en su máquina un ambiente para probar que tiene el mismo runtime que el ambiente productivo. Esto no es menor ni tampoco muy común, ya que en general el ambiente del developer tiene un sistema operativo desktop mientras que el resto de los ambientes tiene un sistema operativo server.

De esta forma, más allá de tener versionada la infraestructura, tenemos ambientes uniformes.

Más notas de nerdear.la

A pesar de que la agenda de charlas y workshops del segundo día me resultaba super interesante, estuve en menos charlas y más en el co-working. Sin embargo pude ver la charla de Dr. TDD de Nico Papagna, excelente.

Más allá del charlas creo que el evento estuvo excelente, la organización fluyó muy bien, me parece que se respetaron los tiempos de las sesiones y la conexión a internet me pareció estable y con velocidad apropiada para trabajar. Por cuestiones familiares no pude asistir al día 3, una lástima porque el programa también pintaba de diez.

Quiero felicitar a la gente sysarmy que son los organizadores de nerdearla porque la conferencia se viene superando año a año y a pesar de aumentar la cantidad de participantes, el nivel de conferencia sigue subiendo. Adicionalmente quiero agradecer a @emaraschio que fue mi anfitrión el día que tuve que dar mi charla.

Notas de nerdear.la día #1

A pesar de la copiosa lluvia la asistencia fue impresionante, no tengo idea del número pero había mucha gente. Al momento de finalizar las palabras de apertura el auditorio principal estaba llenísimo. Como orador me sentí muy cómodo, casi un rockstart: acceso al secto vip, escenario elevado y un auditorio con mucha gente para escuchar mi charla. Si bien estoy acostumbrado a dar charlas, el hecho de que el escenario estuviera elevado y que el auditorio fuera tan grande, me generó cierta dificultad para interactuar con la audiencia. De hecho, no tuve interacción hasta el final de la charla cuando le acercaron micrófonos a la audiencia. Una de las preguntas que recibí fue:

“[…] ¿crees que hay alguna componente cultural por la cual no tenemos (en Argentina) la disciplina/orden/coinciencia para hacer test automatizados? […]”

Mi respuesta fue:

Me parece que es una cuestión que tiene más que ver con la mentalidad de los empresarios que con los que desarrollamos software. En Argentina hay algunas empresas que contratan ingenieros para hacer tests pero también hay empresas que contratan psicólogos para hacer tests”

Me parece importante hacer un par de aclaraciones sobre mi respuesta. En primer lugar no tengo nada contra los psicólogos, dije psicólogos en forma genérica para representar gente que típicamente no tiene formación ingenieril. No es que crea que todo el testing deba ser hecho por ingenieros, pero si pretendemos automatizar tests es necesario que parte del grupo de personas que se encargarán del trabajos de testing deben formación técnica/ingenieril.

Aquí están disponibles para descarga los slides que utilicé.

Todas las charlas que vi me parecieron muy buenas pero la que me resultó más interesante fue la de Juan Pablo Borna quien conto varias experiencias de trabajo como Production Engineering en LogDevice/FaceBook.

Más allá de las charlas, dediqué un buen rato al networking, me reencontré con varios colegas que hacía tiempo que no veía.

Para cerrar este post dejo una hermosa postal que vi cuando me estaba retirando de la conferencia.