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.