Experimento: Fiuba meets Discord

Estamos promediando el cuatrimestre, completamos la novena semana de clases y con ello cerramos la primera parte de MeMo2. Hasta aquí los alumnos estuvieron trabajando de forma individual estudiando, aprendiendo y practicando diversas técnicas para poder trabajar en equipo durante la segunda parte de la materia.

Es aquí donde entra Discord, este cuatrimestre hemos decido habilitar un servidor Discord para que los equipos de alumnos puedan trabajar sincrónicamente haciendo mob programming. Discord es una plataforma de colaboración similar a Slack, Microsoft Teams y otras tantas. Ofrece salas de video y de audio que emulan de forma virtual a salas físicas. El usuario puede estar en una sala de audio a la vez. Al mismo tiempo las salas de audio no tiene espacio de texto sino que los usuario “entran” con cámara y video y tienen la posibilidad de compartir pantalla.

El trabajo en equipo es un proyecto de desarrollo con alcance variable y esfuerzo fijo. Pedimos a los alumnos trabajar 6 horas semanales (extra clase) pero haciendo (dentro de lo posible) mob-programming todo el tiempo. En las próximas semanas veremos si también probamos Discord para las clases en vivo pero sabemos que esto puede resultar más complejo ya que tenemos colegas que han reportado inestabilidades en la suscripción gratuita de la plataforma. De todas formas, como nosotros tenemos pocos alumnos creemos que podría andar bien.

El mayor impedimento para una iniciativa DevOps

Si bien el término DevOps no lo explicita, toda iniciativa DevOps requiere del apoyo e involucramiento de negocio, pues la razón central de DevOps es poder dar respuesta rápida y consistente a las necesidades del negocio.

Si el negocio no se sube al barco de la iniciativa DevOps las probabilidades de éxito y sus beneficios estarán fuertemente limitados. Toda iniciativa DevOps requiere de cierta inversión, ya sea a nivel de capacitación, compra de herramientas o simplemente horas-hombre. Si el negocio ve a IT como un centro de costos difícilmente estará dispuesta a hacer la inversión en DevOps.

Desarrollo y Operaciones pueden tener las mejores intenciones, pueden colaborar de forma muy fluida, pueden incluso ser un mismo equipo, pero nada de eso alcanza si el negocio sigue viendo IT como un centro de costos.

Las empresas que logran implementaciones exitosas DevOps son aquellas que ven IT como una área estratégica, capaz de habilitar oportunidades de negocio, capaz de impactar en la performance del negocio/organización y de proveer un valor diferencial de cara al mercado.

En más de una ocasión me he encontrado trabajando con áreas de IT, tratando de armonizar la relación entre desarrollo y operaciones, pero sin contar con el apoyo suficiente del negocio. Así y todo es posible implementar algunas mejoras, pero difícilmente se logren los plenos beneficios de una cultura DevOps.

Mob-Programming, una práctica para probar

Remote Mob-programming figura entre las técnicas recomendadas para “considerar” (assess) en la edición de abril 2021 del Technology Radar de Thoughtworks y eso me motivó para comenzar escribiendo algunas ideas/definiciones sobre Mob-programming, en otro artículo hablará sobre las particularidades que agrega el componente Remote.

Mob Programming es un práctica a mi entender aún no muy difundida. Se cuenta que la práctica fue inicialmente utilizada por algunos equipos de XP allá por los años 2000, pero no fue hasta ~2014 que empezó a cobrar más popularidad a partir de la difusión impulsada principalmente por Woody Zuill. Fue precisamente de la mano de él que yo conocí la práctica en la XP 2016 en Edimburgo.

All the brilliant people working on the same thing, at the same time, in the same place, and on the same computer

Woody Zuill

En términos resumidos propone que todo el equipo trabaje en conjunto con una sola computadora. Dicho de otra forma, mob-programming es externder la idea de pair-programming a todo el equipo. En cierto modo, es posible que mucha gente considere que en algún momento ha aplicado mob-programming, pero muy posiblemente no sea así porque mob-programming implica ciertas cuestiones como ser:

  • Mob-programming implica cierta dinámica del grupo donde los miembros asumen distintos roles a lo largo del tiempo
  • Mob-programming propone que todo código productivo sea escrito haciendo mob-programming lo cual se traduce a que los miembros del equipo pasan casi todo su tiempo haciendo mob-programming.

Este último punto es el que suele generar cierta resistencia: que todo el equipo esté trabajando en una tarea por vez. Esta resistencia en ocasiones viene de parte de la gerencia pero en muchas ocasiones viene de los propios programadores. De hecho, en algunos contextos hay incluso rechazo al pair-programming. Veo muchos programadores que prefieren trabajar en una dinámica de solo-programming con feature-branches y merge-request aún cuando eso implique tener que lidear con merges y tiempos de espera para tener su código integrado a la rama principal de desarrollo.

Es interesante mencionar que en el contexto de Extreme Programming se propone que todo el código productivo se haga trabajando en pair-programming. En mi experiencia, pair-programming es un práctica de relativo poco uso en el sentido de que quienes la utilizan no la utilizan todo el tiempo (como propone XP) sino en situaciones muy puntuales donde la tarea en cuestión reviste de cierto grado de complejidad/riesgos.

En mi trabajo como coach/mentor casi todo el tiempo que estoy programando lo hago haciendo mob o pair programming.

El uso de mob-programming tiene ciertas consecuencias interesantes:

  • Como todo el equipo está trabajando en una misma tarea, hay una sola rama de desarrollo (trunk-based development) por lo cual no hay que lidiar con merges.
  • El código es revisado mientras se escribe así que no hay tiempo de espera de revisión
  • Todo el equipo está familiarizado con todo el código
  • Es muy fácil la gestión del Work-In-Progress ya que está automáticamente limitado a 1

Les dejo aquí algunos recursos para quienes quieran profundizar en estos temas:

En próximos post contaré mis experiencias aplicando esta técnica.

Charla: DevOps sin DevOps

Esta es la charla que di ayer en el contexto de la conferencia Agile en Español 1 iteración. Hubo alrededor de 90 personas conectadas pero en las actividades interactivas participó aproximadamente la mitad.

En un momento de la charla pedí a los participantes que compartieran por escrito las nuevas responsabilidades/habilidades necesarias para poder trabajar con un mindset DevOps. La siguiente imagen es el resultado de esta actividad.

Hay algunos de los términos que que surgieron que por distintos motivos me llamaron poderosamente la atención. Por ejemplo, cuestiones como integración continua, cobertura de código y tdd tienen más de 20 años, sin embargo parece que hay gente/organizaciones que recién tomaron conciencia de ellas con el auge de DevOps.

No llegamos a cubrir todos los temas que tenia en mente y por eso agendé un meetup para el este sábado 29 de mayo para continuar la charla, debatir, compartir experiencias e inquietudes. Los interesados pueden registrarse aquí y recibirán el link de conexión.

Aquí están disponibles los slides de la charla:

Gestión de Proyectos, video introductorio

Este es un tema que suelo dar en mi materia de ingeniería de de software. Si bien no es un tema central de la materia, resulta difícil hablar de procesos y prácticas de desarrollo sin tener al menos algunas nociones básicas de gestión de proyectos. Es por esto que grabé un breve video introductorio para que mis alumnos lo vean previamente a la clase de proyectos donde profundizamos sobre algunas cuestiones.

Sobre las estadísticas de inscriptos en FIUBA

Esta semana la facultad difundió un reporte bastante detallado de las inscripciones de este cuatrimestre. Comparto aquí algunas datos que me resultaron interesantes.

La cantidad inscriptos fue de 8.209, esto nos da una idea de la cantidad de alumnos regulares de la facultad (y ubica a fiuba bastante abajo en ranking de alumnos de facultades de la uba 😦 ).

La cantidad de inscripciones fue 31.495 lo cual da un promedio de 3.84 materias por alumno.

Al analizar el desagregado de género vemos que el 26% del los inscriptos son mujeres lo cual me sorprendió positivamente ya que tenia la sensación que había muchas menos mujeres en fiuba. Este cuatrimestre en MeMo2 tenemos ~15% de mujeres.

El departamento de computación se ubica cuarto en cantidad de inscripciones detrás de los departamentos de física, matemática y gestión. Que física y matemática sean los departamentos con mayor cantidad de inscriptos no me sorprende ya que todas las carreras tienen en los primeros años materias de esos departamentos. Pero si me sorprende la cantidad de inscriptos del departamento de gestión.

En departamento con mayor paridad de género en las inscripción es química (~49 % de mujeres). Esto no me sorprende pues es saber popular que las carreras del departamento de química concentran el mayor % de mujeres.

Quienes gusten leer el informe completo lo pueden encontrar aquí.

Ideas para trabajos finales de carrera

Una de las (¿pocas?) cuestiones positivas de la pandemia es que ha habilitado/forzado la “virtualización” de diversas actividades. De la mano de esto vienen un conjunto de potenciales ideas de trabajos finales de carrera.

En particular creo que hay todo un conjunto de problemáticas que se ponen de relieve al intentar llevar a una modalidad virtual eventos empresariales y académicos como conferencias, reuniones científicas, seminarios, etc. Asimismo en lo que tiene que ver con conferencias, es común en los eventos relacionados a agile que las sesiones tengan formatos “no tradicionales”. Para que se entienda: el formato tradicional sería un orador hablando a una audiencia mientras comparte unas diapositivas, la comunicación es principalmente unidireccional. El orador es el protagonista de la sesión, expone información hacia una audiencia que escucha generalmente de forma pasiva.

En los eventos relacionados a agile es común encontrarse con formatos donde el orador toma una actitud más pasiva, fomenta y facilita la participación de la audiencia que toma un mayor protagonismo durante la sesión. En este sentido el orador toma un rol más de facilitador que de expositor. Existen una serie de formatos, dinámicas y actividades bien conocidos como ser Open Space, Fishbowl y World Café entre otros. Todas ellas diseñadas para ser realizadas de forma presencial. He aquí la oportunidad: generar herramientas/aplicaciones que permitan realizar estas actividades de forma virtual.

Un ejemplo de esto es la herramienta Stooa que permite hacer de forma virtual dinámicas tipo fishbowl.

Para quienes esten interesados en explorar estas ideas les recomiendo dos libros donde encontrarán dinámicas que podrían ameritar el desarrollo de una herramienta especializada para su soporte virtual:

A tale of Slicing and Imagination

Este es el título de la charla que voy a estar dando en el contexto de la conferencia XP 2021 el 17 de Junio a las 14:00 (GMT-3). La charla está basada en un artículo que escribí a modo de reporte de experiencia con la colaboración de Rebecca Wirfs-Brock y que será publicado en el sitio de la Agile Alliance.

El punto central de la experiencia que voy a contar pasa por la estrategia de slicing que utilizamos en un proyecto en el que participé el año pasado. Dicha estrategia fue central para poder entregar incrementos de valor de forma continua. Al mismo tiempo la estrategia de slicing requirió del uso conjunto de otras técnicas como continuous delivery, feature toggles y una arquitectura de “micro-apps”.

Esta conferencia es una de las conferencias que más me gusta porque tiene la particularidad de combinar trabajos formales/académicos con experiencias de industria. Los interesados en participar pueden aprovechar la registración temprana que está habilitada hasta el 31 de mayo.

Actualización: ya está publicado en el sitio de la Agile Alliance el artículo que dio origen a la charla.

Todos son ágiles, pero no todos son felices

Los métodos ágiles surgieron en los 90′ y su “nacimiento formal” se ubica usualmente en 2001 con la firma del manifiesto.

Hacia 2010 Forrester ya decretaba Agile como mainstream.

Hoy, 2021, creo que “todos son ágiles” o al menos dicen serlo. Claro está que del dicho al hecho hay un gran trecho.

En los años que llevo trabajando como facilitador he visto situaciones de las más variadas respecto de la adopción de Agile a nivel equipos de desarrollo pero que en términos muy simplificados podrían clasificarse en dos grandes grupos: 1) Equipos que llegan a agile desde “el desorden” y 2) Equipos que llegan a agile desde un proceso definido, no-agile, generalmente controlado, secuencial o “iterativo “laxoo”(iteraciones de duración variable, típicamente no time-boxes, etc.)

En el caso de los equipos que provienen del desorden, generalmente optan por agile (y particulamente por Scrum) sin mayor cuestionamiento. Como que simplemente siguen al rebaño. Esto obviamente trae sus riesgos ya que en más de un caso los equipos no cuentan con los requisitos mínimos para aplicar agile de forma eficaz (usuario/PO muy involucrado, developers capaces de auto-organizarse, etc). Según he visto, en muchos casos esto resulta en equipos que dicen practicar agile pero que en la práctica terminando haciendo ScrumBut y/o Flaccid Scrum. Obviamente esto les impide alcanzar todos los beneficios que generalmente se esperan de un equipo usando agile, pero a pesar de eso puede que el equipo termine trabajando de una forma mejor que lo era su situación previa trabajando en el total desorden.

El caso de los equipos que llegan a agile desde un proceso no-agile pero definido, controlado y generalmente secuencial es menos frecuente en mi experiencia. En los casos de este tipo con los que me he cruzado mi sensación es que logran una implementación más sólida de agile, ya que generalmente cuentan con cierto orden y capacidades que les permiten gradualmente incorporar distintas prácticas de agile.

Esta situación de que “todos son ágiles” me ha llevado personalmente a intentar evitar el término agile para definir una forma de trabajo. En general prefiero hablar en términos de prácticas pues me parece que resulta mucho más concretro que hablar de “Agile en abstracto” o “Scrum by the book”.

Desde hace ya un par de años me hace más sentido hablar de prácticas y performance de delivery que de Agile o Scrum. En este sentido me resulta mucho más significativo que un equipo me diga que su lead time es de 1 semana a que me diga que hace Scrum.

En fin, resumiendo: hoy en día todos dicen ser Agiles, pero en la práctica no todos lo son en verdad. Muchos practican agile con un grado tal de ineficacia que su “agilidad” bien podría debatirse. Esto me lleva a reforzar el fondo de la cuestión (al menos desde mi perspectiva): la cuestión no es si agile o no, la cuestión es cuan buenos(y felices) somos entregando valor independientemente de la forma en que lo hagamos. Personalmente hoy creo que para muchos contextos tiene más sentido analizar la entrega de valor desde un perspectiva Lean que desde una perspectiva Agile.

Nota: Lean y Agile no son lo mismo, son dos marcos diferentes, con mucha afinidad, pero distintos. Diferencias y similitudes de estos marcos serán tema de otro artículo.

C# 2021: mucha magia y grandes riesgos

Cuanto más veo las nuevas características que están introduciendo C# más “miedito voy sintiendo”. Veo algunas características que se anuncian con un espíritu de “mucha funcionalidad con muy poco código“. Un ejemplo de esto es el tweet de ayer de David Fowler.

Cuando veo este tipo de anuncios no puedo evitar recordar los primeros años de .Net cuando ASP.NET WebForms generaba también ilusiones de simplicidad y productividad. En cierto modo la promesa sonaba como “podes hacer aplicaciones web como si fueran aplicaciones desktop y sin tener que aprender de tecnologías web“. Tiempo después descubrimos que el uso de WebForms tal como era promocionado (sin entender bien la web) tenía un conjunto de efectos colaterales que causaron estragos negativos en muchas aplicaciones y dolores de cabeza en muchos programadores.

Por otro lado, esta constante evolución de los lenguajes me resulta molesta y hasta inconveniente. En el caso de C# no bastaba con tener clases, enums, structs, interfaces, etc. que había que agregar records. Entiendo que la intención de gran parte de estos cambios es proveer mejores niveles de abstracción y simplificar el trabajo de programador. Si es así, estoy de acuerdo con la intención pero no comparto la estrategia. Yo personalmente me inclino más por la estrategia de Smalltalk, mantener el lenguaje al mínimo y agregar funcionalidades mediante el agregado de paquetes de clases.

Y ya que estamos, otra cuestión que no me gusta de .Net/C# es que el modelo de ejecución sync/async resulta extremadamente intrusivo, forzando a que las clases de dominio que contienen la lógica de negocio se vean “contaminadas” con elementos del modelo de ejecución (async, await, etc). Entiendo que esto es en favor de una mejor performance en mi opinión no vale la pena. Prefiero mantener el código más limpio y lidiar con el modelo de ejecución a nivel de infraestructura incluso cuando ello conlleve cierta penalidad de performance.

Es por todo esto que muchas veces mi código C# no hace uso de “las magias” recientes del lenguaje/plataforma y confío en que es mucho más claro que sí usara “esas magias”.

En fin, C# como lenguaje me gustó mucho desde un comienzo así que solo espero que quienes trabajan en su evolución no lo choquen.