I delivery this tutorial yesterday morning. Seven people participated on it: 2 from Austria, 2 from Spain, 2 from Finland and 1 from Germany.
The tutorial flowed as expected but I would have like to have 30 extra minutes to cover the Continuous Delivery part with a hands-on exercise.
Participants evaluated the tutorial with 5 points out of 5 🙂
Here is the formal summary of the tutorial.
Este fue el título de la charla que estuve dando el lunes pasado en el meetup de Software Crafters Barcelona. La charla estuvo basada en el material de mi charla «No contrates Ingenieros DevOps», pero decidí darle una dinámica distinta. Inicialmente hice una introducción al mindset DevOps y luego debatimos sobre el rol del Ingeniero DevOps usando una dinámica de Fishbowl. Finalmente cerramos revisando algunas prácticas para intentar acercar y mejorar el flujo de la gente de Dev y gente de Ops.
Me gustó mucho la forma en que fluyó la actividad. Luego de la charla nos quedamos compartiendo unos tragos con los participantes. Agradezco a la comunidad de Crafters, a la gente de Voxel Group y a Adrián Perreau porque hicieron posible el meetup.
Comparto aquí algunos recursos que mencioné durante la charla:
Hace unos dos meses comenzamos, con el grupo de Prácticas y Procesos de UNTreF, a trabajar en un estudio sobre Test-Driven Development (TDD).
TDD es un de las prácticas ágiles más populares pero comparativamente con otras prácticas ágiles es muy poco utilizada. Cuando digo que es popular me refiero a que es muy conocida (se sabe de que se trata) pero curiosamente hay varios estudios que muestran que su uso es mucho menor al de otras prácticas ágiles como las Restrospectivas e Integración continua. Dos fuentes que confirman esto son el reporte anual de VersionOne y nuestro propio estudio sobre Prácticas Agiles en Latam.
Con mi colega @dfontde tenemos la sospecha de que esta baja adopción de TDD puede deberse a issues de usabilidad de la práctica. Esto es precisamente lo que vamos a intentar probar (o descartar) en este estudio. Para ello utilizaremos el Modelo de Usabilidad de Práctica y Procesos que @dfontde está desarrollando como parte de su doctorado.
Para realizar esta investigación vamos a necesitar la colaboración de practicantes con al menos 5 años de experiencia en el uso de TDD. Los interesados pueden contactarme dejando un mensaje aquí.
Next week I will deliver my DevOps Tutorial at the International Conference on Product-Focused Software Process Improvement, Profes 2019. This will be my second time delivering this tutorial in Europe, but this time I have updated the tutorial to include Kubernetes-related content and of course I had to remove some other content that was not so relevant.
The conference will be held in the North Campus of the Technical University of Barcelona. The tutorial is scheduled for November 27 morning.
For those that plan to participate ensure to install the following software on your notebooks: an Ssh client, Git and Docker Desktop (or docker-engine for those running on Linux).
Desde 2009, cuando descubrí el formato Open Space, hasta hoy creo que este formato ha tenido muchísimo uso y difusión. Pero lamentablemente mis experiencias en Open Spaces en los últimos años no han sido muy positivas y finalmente me cansé. Me cansé de asistir a eventos/encuentros sin saber a ciencia cierta qué temas concretos se tratarán, me casé de ver sesiones extremadamente improvisadas que no salen bien, me cansé de ver siempre a los mismo oradores exponiendo.
El martes pasado estuve participando de un Meetup en formato Open Space y una vez más experimente la misma historia: fui sin saber qué temas concretos se tratarían, me encontré con los mismo oradores y con sesiones improvisadas.
Insisto, es una cuestión de gustos. A mi personalmente me gusta más tener una agenda predefinida.
Creo que un punto intermedio podría ser tener una agenda mixta, algunas sesiones previamente definidas y luego un espacio para sesiones espontáneas que surjan durante el encuentro.
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.
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:
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:
Si algún lector puede darme una mano para contactar docentes de ingeniería de software de estas instituciones le estaré muy agradecido.
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:
Interesados en participar o conocer más de estos talleres me puede escribir por este medio.
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á….
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:
Estos scripts los utilizamos para administrar 4 ambientes:
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.
Blog de NicoPaez 