Cierre de cuatrimestre @ UNTreF

La semana pasada completamos un nuevo curso de la materia Ingeniería de Software en UNTreF. Tuvimos 6 alumnos, todos completaron la cursada y 5 de ellos promocionaron la materia.

Debido al cambio de plan de estudio, este cuatrimestre fue el último en la modalidad actual pero a pesar de eso también hicimos algunas innovaciones en esta edición. Resulta que a partir del próximo año la materia se dicta en el contexto del nuevo plan de estudio en el cual es un materia de tercer año y no de quinto año como fue hasta el momento.

En lo personal creo que fue uno de los mejores cuatrimestres que tuvimos y creo que en gran medida fue por el grupo de alumnos. A diferencia de otros cuatrimestres creo que se generó una muy buena onda tanto en la relación entre los alumnos como también en la relación docente-alumno.

Como de costumbre trabajamos sobre el JobVacancy pero agregamos una innovación creando una capa de presentación complementaria representada por un Bot de Telegram. La introducción de este componente trajo un conjunto nuevo de complejidades que nos permitieron aplicar algunas prácticas más allá de las habituales (logs centralizados, monitoreo, gestión multipipeline, etc.)

En la retrospectiva de cierre los alumnos destacaron 3 cuestiones:

  1. Didáctica de la materia 🙂
  2. Contenidos de la materia 🙂
  3. Alta carga de trabajo (y agrego yo, carga continua de trabajo) 😐

Podcast: Agilidad Técnica

Hace un par de días salió publicado un episodio del podcast La Revolución Ágil en el que estuve participando. El episodio fue grabado hace un par de meses y es básicamente una charla uno a uno con Camilo Velasquez, host del del podcast.

Previo a esta publicación tuvimos cierto desencuentro respecto del título con el que saldría publicado el episodio. El título original que había puesto Camilo me generaba cierta incomodidad pues a mi parecer transmitia una idea de «rivalidad» entre técnicos y agilistas. El título final, «Agilidad Técnica», me parece mas apropiado pero igualmente a mi parecer tiene cierta redundancia ya la verdadera agilidad implica el uso de ciertas prácticas técnicas (test-automation, CI/CD, etc).

Más allá de la cuestión del título, creo que la charla estuvo muy buena y creo que trae muchas cuestiones interesantes para aquellos agilistas que trabajan con equipos de entrega de software y que no tienen formación técnica.

Varias de las cuestiones que menciono en la charla son parte de mi Taller de Prácticas Técnicas para Scrum Master.

Agradezco a Camilo por invitación y lo felicito por iniciativa ya que al margen de este episodio hay otros episodios super interesantes. En lo personal me gustaron mucho los episodios 7 y 13 con Hiroshi y Alistair respectivamente.

Build for Operations: Mensajes de Log

Con el auge de las iniciativas DevOps/SRE resultan cada vez más importantes ciertos aspectos de cómo desarrollamos software, pues ciertas propiedades del software desarrollado pueden tener un impacto muy importante en la operación del software. Este conjunto de propiedades que van mucho más allá de la arquitectura bien podrían caracterizarse como «factores de operabilidad» o como las denomina James Shore «Build for Operations». Aquí tenemos cuestiones tales como: Threat Modeling, Configuration, Logging, Secrets y Monitoreo entre otras.

Desde hace ya un tiempo vengo incorporando algunas de estas cuestiones en mis materias y es por ello que he decidido inaugurar una nueva serie de videos titulada «Build for Operations» para ir cubriendo estos temas. Aquí les comparto el primer video de la serie: «Manejo de Logs»

Sobre las Pruebas de Integración

En mi opinión no hay una definición única sobre qué es una prueba de integración. En términos muy generales suele asumirse que prueba de integración verifica la integración de dos (o más) componentes. La cuestión (o diferencia) radica en qué son esos componentes.

Algunos (¿la mayoría?) considera que esos dos componentes son componentes de nuestra propia autoría, por ejemplo: tengo dos clases desarrolladas por mi con algún tipo de dependencia entre ellas, claseA y claseB, entonces mi prueba de integración busca verificar la correcta interacción de esas dos clases entre sí.

Otros, donde me cuento yo, pensamos más en línea con la propuesta de Freeman. En este caso uno de los componentes en la prueba de integración no está bajo nuestro control, o sea: no lo desarrollamos nosotros. Esto hace que el foco de la prueba de integración pase por verificar la interacción del código que está bajo nuestro control con código que no lo está. Un caso típico es cuando nuestra aplicación debe interactuar con una aplicación/servicio/api externo como ser una API REST desarrollada por otro equipo/organización. En este caso, no tiene ningun sentido utiliza mocks (dobles de prueba) porque justamente lo que quiero verificar es la interacción con ese sistema externo, entonces de nada sirve reemplazar ese sistema externo con un doble de prueba.

#DetrásDeEscena: Prácticas Técnicas para Scrum Masters

La semana pasada grabamos con mi colega Martín Alaimo una conversión «Detrás de Escena» sobre varios temas de «Agilidad Técnica» que son parte de mi Taller de Prácticas Técnicas para Scrum Masters.

Me resultó muy interesante la charla, Martín es un gran entrevistador, hablamos de varias cuestiones más allá de lo que sugiere el título.

Comparto aquí la grabación y aprovecho para mencionar que en noviembre estaré dictando una nueva edición de este taller enfocado en Scrum Masters y facilitadores de equipos que quieran profundizar en las cuestiones que mencioné en la charla la Martín.

[offtopic] Sobre el tamaño y eficiencia del estado

En los últimos años se ha hablado bastante en Argentina sobre el tamaño y los costos del estado. Este es un tema, que como a todo el mundo, me toca como ciudadano pero también me toca como empleado de dos universidades públicas. En este sentido llevo más de 20 años trabajando como empleado público, siempre en universidades nacionales, generalmente en tareas de docencia e investigación y en este último tiempo también en cuestiones de gestión. En alguna ocasión también trabajé como proveedor del estado. Todas estas experiencia me llevaron a formar algunas opiniones.

Sin duda en el estado hay gente muy buena tanto en lo profesional como en sus intenciones. Tal vez incluso gente mejor que la que uno podría encontrar en el varias empresas del sector privado. Pero al mismo tiempo hay gente que no está a la altura de las tareas que debe desempeñar. En ocasiones es por falta de capacidad, gente que no está preparada y no tiene las herramientas intelectuales para hacer las tareas que tiene a su cargo. Pero en otras ocasiones es un falta de voluntad, desidia, un mindset de «hacer lo mínimo indispensable» para que no los despidan y cuando a esto le sumamos el clásico «en el estado no se despide gente» terminamos con gente haciendo prácticamente nada.

Pero la cuestión no termina ahí, por que esa gente sin capacidad o sin voluntad que no realiza su trabajo en tiempo y forma termina impactando en otras dos cuestiones. Por un lado, hay tareas que no se completan y se asume que es por falta de personal entonces la institución contrata más gente y es así que tenemos una planta de bastante más grande que lo necesario si cada uno hiciera sus tareas en tiempo y forma. Por otro lado, esa gente también impacta negativamente en las tareas que deben desempeñar otras personas provocando una bola de nieve de retrasos, impedimentos, ineficiencias, etc, etc.

Desconozco cuál es la solución para esto. Pero sin duda algo que podría ayudar sería tener algún mecanismo de evaluación de desempeño periódica que resulte vinculante para la continuidad de la contratación.

Notas de Nerdearla 2023

Una vez más…¡EXCELENTE!

Esta edición tuvo 5 días: los primeros dos online y los otros 3 presenciales pero con transmisión en vivo. Estuve los 3 días presenciales y quedé sorprendido de la cantidad de gente que había. En particular, el viernes por la tarde no entraba un alfiler en la Gran Sala. Asimismo, al margen de la asistencia presencial, informan los organizadores que hubo más de 40.000 registrados.

El jueves pasé gran parte de la jornada hablando con colegas, varios de ellos ex-alumnos. Esto puede parecer una picardía pero yo no lo veo así pues creo que una de las cuestiones más ricas de este evento es la posibilidad de networking.

Más allá de las «charlas nerds» de temas de física, astronomía y demás, las 4 charlas de IT que más me tocaron fueron:

  • Revolución Web de midudev
  • Effortless Software Development de Anna Filina
  • LLMs en producción de Guillermo Watson
  • 10 cosas que los devs deberían saber sobre las DB de Carlos Tutte

El sábado me tocó subir al escenario para dar mi sesión «Integración Continua 3.0». Una curiosidad de backstage es que me maquillaron para salir a escena :-). Me gustó como fluyó la charla, cumplí con los tiempos y creo que legué a compartir todo lo que me había propuesto.

Es increíble como este evento se supera año a año. Mis fecilitaciones a los organizadores.

Diplomatura en Ingeniería de Software Continua, largamos

El miércoles pasado comenzamos el dictado de la Diplomatura en Ingeniería de Software Continua en la Universidad Nacional de Tres de Febrero. Un importante paso de una idea que para que comenzó a gestarse hace ya varios años.

Esta primera cohorte tiene 13 participantes, un muy buen número para la propuesta didáctica queremos implementar en la toda la carrera. Entre los participantes tenemos un extranjero residente en Costa Rica y gente de diversos lugares de Argentina: La Plata, Bariloche, Mendoza, Córdoba y San Martín de los Andes entre otros.

En este primer cuatrimestre comenzamos con el dictado de dos materias: Ingeniería de Software Moderna (a cargo de Carlos Fontela) y Diseño y Evolución de Arquitecturas de Software (a cargo de Andrés Pace y Diego Fontdevila).

Dado que las 4 materias del diploma están armadas de forma autocontenida y no tiene correlatividades entre ellas, en marzo del año próximo volveremos abrir la inscripción para quienes quieran empezar a cursar las otras dos materias que se comenzarán a dictar en abril: Entrega Continua (a mi cargo) y Operación y Gestión de Servicios de Software con DevOps (a cargo de Fede Casuscelli).

Quienes quieran saber más sobre esta propuesta educativa aquí hay un documento formal con detalles de objetivos, contenidos y bibliografía.

Código auto-documentado

Este es un tema recurrente a comienzo de cada cuatrimestre pues muchas veces los estudiantes vienen más enfocados en hacer codear correctamente los algoritmos que sea óptimos en lugar de que su código sea legible y mantenible. Es por esto que muchas veces agregan comentarios al código que no agregan valor. En parte es por esto que grabé un breve video sobre este tema.

Más allá de mi video, a quienes quieran profundizar en este tema le recomiendo el capítulo 42 del libro Code Complete de Steve McConnel.

Visual Story Mapping: recursos varios

Aprendí esta técnica allá por 2012 en un taller facilitado por Alejandra Alfonso. Por aquella época no había mucha información de esta técnica. Apenas un artículo en el blog de su autor, Jeff Patton, y algún otro artículo de gente que había aprendido la técnica con él.

Desde un comienzo esta técnica me ha resultado muy útil. Por eso, cuando escribimos «Una mirada ágil» allá por 2014 decidimos incluir una explicación de esta técnica acorde a la forma en que yo y los otros autores solíamos usarla. Casualmente el capítulo que describe la técnica es parte del extracto del libro que la editorial generó a modo promocional y que es de libre distribución. Ese material es el que uso actualmente en mi materia para explicar la técnica a mis alumnos.

Comparto aquí algunos otros recursos sobre Visual Story Mapping:

  • El capítulo «Definición de alcance» de mi libro «Una mirada ágil» y que incluye la explicación de esta técnica puede descargarse gratuitamente aquí.
  • El capítulo de «Product Discovery» del libro de Fede Zuppa también incluye una descripción de esta técnica con un ejemplo muy claro y está disponible para lectura gratuita online aquí.
  • En la página de Jeff Patton hay varios recursos sobre esta técnica incluyendo esta hoja de referencia.
  • El libro de User Story Mapping de Jeff Patton

Por último les comparto esta plantilla de Google Slides que suelo utilizar cuando utilizo esta técnica en una reunión virtual.