Autor: NicoPaez

Balance 2018 y Plan 2019

En 2018 tuve la oportunidad de trabajar con empresas amigas como 10Pines, Grupo Esfera y Auth0. Participé de 7 conferencias. Publiqué 2 papers formales y 79 artículos en este blog. Mi dedicación industria / academia fue ~ 63 / 37.

Distribución de dedicación Industria vs Academia

Dentro del ámbito industrial estuve haciendo básicamente 4 tipos de tareas:

  • Proyectos de automatización, me sumo a un equipo para hacer tareas de automatización, o sea, soy parte de un equipo y trabajo en una dinámica de proyecto.
  • Training/capacitación, esto incluye tanto cursos, como tareas de generación de contenidos y afines
  • Proyectos de mentoring, me sumo a un equipo en el contexto de un proyecto para ayudarlos a mejorar algunos aspectos de su dinámica de trabajo.
  • Consultoría, son trabajos bien puntuales, de un par de sesiones donde opino, asesoro, ayudo a pensar, etc

Más del 60% de mi tiempo estuvo dedicado a proyectos de automatización, tanto de pruebas como de infraestructura/deployment, dos cuestiones que suelen ir de la mano. Uno de los principales beneficios que se esperan al automatizar es ganar velocidad, por ello si se automatiza la infraestructura y deployments, se termina también automatizando las pruebas para que la ganancia en velocidad venga acompañada de estabilidad/calidad y viceversa. Por otro lado, el ~25% de mi tiempo en la industria estuvo dedicado a training/capacitación en el ámbito privado, básicamente dictado de cursos, talleres, generación de contenido, etc. (esto no incluye mi trabajo en la universidad). Cabe aclarar que estos números surgen de mi registro de facturación y la forma bajo la cual son contratados mis servicios, pero suele ocurrir que muchas veces me contratan con un fin y luego termino haciendo algunas otras cosas. Un ejemplo clásico es que me contratan para un trabajo de consultoría y luego como parte de ese servicio termino dictando algún training.

Distribución de tiempo dedicado a la industria según tipo de tarea

Para 2019 estimo que seguiré en una situación global similar. Creo que seguiré trabajando fuertemente en temas de automatización ya que veo un importante crecimiento en el uso de Docker/Kubernetes, una temática en la que he acumulado bastante experiencia. En el ámbito académico tengo la intención de completar mi especialización en Tecnología Informática Aplicada a Educación y por otro lado es muy posible que también esté trabajando en la definición del plan de estudios de la Licenciatura en Informática de UNTreF.

Videos & Screencast sobre Desarrollo de Software

Hace un par de años comencé a hacer videos con el contenido de mis clases. Con el correr del tiempo fui probando distintas herramientas, plataformas y formatos. Finalmente me incliné por Camtasia como herramienta de grabación & edición, YouTube como plataforma de publicación y screencast como formato de video.

Aprovechando el recreo de fiestas de fin de año, estuve acomodando mis videos en YouTube y moviendo videos que tenia publicados en otras plataformas. A partir de esto tengo en este momento un canal de YouTube con diversas listas de reproducción que agrupan videos con temas tales como: DevOps, UML, Git e Ingeniería de Software entre otros.

Espero les resulten útiles.

Cierre del segundo cuatrimestre 2018 en MeMo2

Completamos la tercera edición de MeMo2. El resultado es raro, por un lado nuestra sensación como equipo docente es que la materia fluyó mucho mejor que el cuatrimestre anterior (lo cual en cierto modo se refleja en mejores notas de aprobación) pero otro lado, las encuestas incluyeron algunos puntos negativos. Hubo alumnos que manifestaron que el contenido de la materia no les resultó interesante. Es poco lo que podemos hacer sobre esto, pues el contenido viene principalmente dado por el plan de estudio. Personalmente me resulta curioso porque el contenido de la materia tiene mucho que ver con el ejercicio profesional y de hecho todos los encuestados indicaron que el contenido les pareció actualizado. Por otro lado hubo quejas respecto de las interacciones con los alumnos lo cual se debió en gran medida al hecho de que todas las comunicaciones las hacemos por medio de la lista de correo de la carrera, incluso las que implican aplazos en la materia. A esto se suma el uso de algunas expresiones/frases que han sonado poco amables. Ya hemos hecho nuestra retrospectiva interna de cátedra y hemos identificado algunos puntos de acción para mejorar este tema el próximo cuatrimestre. Adicionalmente, yo personalmente voy a trabajar en intentar mejorar mis expresiones. Más allá de estas cuestiones, estos son los números fríos para la estadística:

  • Evaluación general del curso (según encuesta interna): 7.8 / 10
  • Opinión general de la materia (según encuesta del departamento): 3.5 / 5
  • Claridad de los docentes (según encuesta interna): 4.6 / 5
  • Conocimiento de los docentes (según encuesta interna): 4.6 / 5
  • Dinámica de clases (según encuesta interna): 4.5 / 5
  • Materiales de estudio (según encuesta interna): 3.6 / 5
  • Dedicación promedio extra clase (según encuesta interna): 6 hs. semanales

Repensando los criterios de evaluación

Llega el fin de cuatrimestre y el sistema nos indica que debemos poner una nota numérica a los alumnos. La nota mínima de aprobación es 4, menos de 4 es desaprobado y 10 es la nota máxima. Esas son las reglas y no hay mucho más. Partiendo de esta base cada docente hace sus propias reglas. He conocido docentes con reglas tales como:

«Nunca pongo 10 porque el 10 no da espacio para la mejora»

«El 10 implica perfección y nadie es perfecto, por lo cual no pongo 10»

«Al mejor examen lo califico con 10, incluso cuando puede que tenga errores y de ahí para abajo»

«Para aprobar el alumno debe tener una idea mínima de cada tema, con lo cual si algún ítem del examen es dejado en blanco, el examen está automáticamente desaprobado»

Más allá de esto, creo que no es lo mismo una evaluación de análisis matemático que una de ingeniería de software o de historia del arte. Tampoco es lo mismo una evaluar un examen que evaluar el desempeño de un alumno en forma integral en un curso.

Desde hace varios años enseño Ingeniería de Software y desde un comienzo estuve convencido que la evaluación con exámenes no era la estrategia apropiada para evaluar dicha disciplina. Actualmente nuestro enfoque de evaluación consiste en un conjunto de tareas individuales (alrededor de 15), más 2 trabajos grupales. La calificación final del alumno surge de la siguiente fórmula:

  • 0,3 * Promedio Ponderado de notas de tareas individuales
  • 0,3 * Nota del trabajo grupal 1
  • 0,4 * Nota del trabajo grupal 2

A esto se suma la condición de que todas las tareas individuales deben ser completadas. Además cada uno de los 3 componentes de la nota final debe ser al menos 4. Si bien estamos conformes con este esquema aún nos falta encontrar algún mecanismo para asegurar un ritmo de trabajo constante y sostenible en la realización de la tareas individuales ya que es común que algunos alumnos tiendan a atrasarse en la realización de dichas tareas y luego deban realizar un esfuerzo superlativo para ponerse al día.

Cierre de segundo cuatrimestre 2018 en UNTreF

Ayer cerramos el cuatrimestre de la materia Ingeniería de Software. Fue un cuatrimestre un poco atípico, pues a mediado de cuatrimestre no nos gustó como estaba fluyendo la materia y por ello hicimos un ajuste importante en la planificación. Creemos que con esto logramos corregir el rumbo y finalmente cerramos la materia satisfactoriamente. Comparto algunos números del cuatrimestre.

  • Inscriptos: 9
  • Aprobados: 9
  • Nota promedio de aprobación: 7,6
  • Evaluación general de la materia: 8.4
  • Trabajos/tareas individuales: 10
  • Trabajos grupales: 1 (6 iteraciones)
  • Dedicación semanal promedio extra-clase: 11 horas (desvío 5)
Foto de WaldoG en el after-class luego del cierre de la materia

Enfrentando al «Agile Industrial Complex»

Enfrentando al «Agile Industrial Complex»

En los últimos años «el mundo agile» ha sido invadido por lo que Martin Fowler ha denominado como el «Agile Industrial Complex» y de la mano de ello las prácticas técnicas han quedado de lado. Mucho post-it y poco TDD, mucho «agile coach» y poca excelencia técnica. Esta situación desdibuja (o incluso viola) la ideas expresadas inicialmente en el manifiesto ágil.

Esto ha sido advertido por varios referentes de la industria mucho antes de que Fowler acuñara este título y ha generado a mi entender 2 corrientes:

  • Por un lado están lo que «luchan» con el «Agile Industrial Complex» intentando «reencauzar» el movimiento ágil.
  • Por otro lado están quienes en cierto modo han cortado por lo sano, inaugurando nuevos movimientos como Heart of Agile, Modern Agile, y Software Craftsmanship. 

Personalmente creo que yo también soy parte de este Agile Industrial Complex y no me gusta. Me incomoda. No estoy en contra de que se hagan negocios a partir de Agile pero me molesta cuando esos negocios se hacen utilizando el nombre/marca Agile sin respetar las cuestiones esenciales. No se puede hablar/vender Agile Software Development dejando de lado la excelencia técnica, la auto-organización, la entrega de valor y la mejora continua.

En un momento pensé en dejar de utilizar el término «Agile/Ágil» y en su lugar hablar de «Desarrollo Adaptativo» o «Ingeniería de Software centrada en el Valor» pero esas alternativas (al igual que algunas otras) no terminaron de convencerme pues si bien son correctas conceptualmente, no resultan cómodas. Finalmente decidí intentar evitar el término «Agile» y hablar de prácticas más concretas como Continuous Delivery, TDD y Planificación Adaptativa.

Continuará…

DevOps: un camino bottom-up

Actualmente estoy trabajando en una institución bancaria colaborando entre otras cosas en una iniciativa DevOps. En forma resumida la iniciativa surgió a partir de varios equipos de desarrollo trabajando en paralelo de forma independiente. Cada equipo fue trazando «su propio camino a producción» con la colaboración de algunos miembros del equipo de infraestructura. Luego, por iniciativa de un gerente de desarrollo, representantes de cada equipo y algunos miembros del equipo infraestructura comenzaron a reunirse para compartir lo hecho por cada uno.

De esta forma, con un esquema de reuniones periódicas, vamos generando acuerdos a partir de las experiencias concretas de cada equipo. Las primeras reuniones fueron un poco caóticas, pero gradualmente van mejorando y agregando más valor. 

A mi parece el uso de un enfoque bottom-up en una institución bancaria es algo novedoso porque tradicionalmente este tipo de organización tienen más a los enfoques top-down. En dicho enfoques top-down hay generalmente un equipo/grupo/gerencia que define/diseña/toma decisiones y luego baja linea al resto de la organización imponiendo dinámicas y políticas que suelen no convencer a la gente que concretamente hace el trabajo de desarrollo/operación.

En los enfoques bottom-up como el que menciono aquí, el trabajo suele ser más lento pero a mi parecer más efectivo ya que se le da voz a los equipos y se construye a partir de su experiencias.

Notas de mi Taller de TDD en CONAIISI 2018

La semana pasada estuve en Mar del Plata participando del sexto Congreso Nacional de Ingeniería en Informática y Sistemas de Información. En ese contexto hice mi Taller Introductorio de Test-Driven Development.

Del taller participaron unas 15 personas de 7 universidades distintas. La evaluación general del taller fue 4.6/5.

Comparto aquí los materiales de estudio que recomendé a los participantes para profundizar en los temas vistos:

Agradezco a la organización del CONAIISI por haberme dado la posibilidad de dar este taller en el contexto de la conferencia.

Mis notas de BETCON 2018

La semana pasada estuve participando del Congreso Boliviano de Tecnología e Ingeniería (BETCON) 2018 que se realizó en la Universidad Católica Boliviana, regional Cochabamba.

Más allá de mi rol de orador, pude escuchar varias disertaciones interesantes pero como me suele pasar en todas las conferencias, lo más atractivo para mi fueron las oportunidades de networking. En este sentido tuve la oportunidad de hablar con diversos investigadores y profesionales de la disciplina.

Agradezco a Frank Chirapa, chair de Computer Society de Bolivia, quien me invitó a participar de este evento y felicito a todo el equipo organizador por tan lindo evento.

Aquí y aquí están las diapositivas que utilicé en mis disertaciones.

Dinámica del taller online de Docker/Kubernetes

La semana pasada un publiqué artículo contando mi intención de hacer un taller online sobre Docker y Kubernetes. Resulta que hubo varios interesados y por ello ahora quiero compartir algunos detalles sobre la dinámica del taller.

La idea taller es aprender haciendo, con lo cual no bastará con asistir a las sesiones online para aprender. Las sesiones online estarán centradas en 2 cuestiones: presentación/explicación de conceptos y discusión/consultas. Luego, entre sesión y sesión, habrá actividades de estudio y prácticas que es donde espero se produzca el aprendizaje

El taller constará de 4 sesiones online de 2 horas. Cada una de esas sesiones será complementada con  un conjunto de ejercicios, lecturas y evaluaciones de nivel que según mi estimación requerirán de unas 2 o 3 horas de trabajo por semana. La duración calendario del taller será 4 semanas.

Los participantes trabajarán localmente en sus máquinas y para algunos ejercicios específicos utilizarán servicios en la nube. Al final de taller los participantes dispondrán de las diapositivas utilizadas, una serie de materiales de estudio y obviamente el código de los ejercicios que hayan resuelto.