DevOps sin DevOps

Este es título de la charla que estaré dando en el contexto de la primera conferencia de la Agile Alliance en Español. Esta conferencia será en modalidad online los días 27 y 28 de mayo. En particular mi charla será el jueves 27 de mayo a las 18 hs (GMT-3). Les comparto aquí el resumen de la charla.

Sin bien llevamos varios años hablando de DevOps, sigue habiendo mucho ruido y confusión respecto a su significado y estrategia de implementación. Muchos creen que DevOps implica tener un área o gente especializada con dicho nombre/rol, lo cual es completamente discutible y hasta en un punto contrario a lo que muestran varios casos de éxito.
En esta sesión repasaremos los pilares fundamentales de esta corriente junto algunos casos exitosos de implementación de DevOps sin “Ingenieros DevOps” ni un área especializada en DevOps.

Scrum: en general no alcanza pero en ocasiones es incluso demasiado

Scrum es el marco de trabajo ágil más utilizado en la actualidad. Es al mismo tiempo en muchos casos el punto de partida para equipos que pretenden comenzar a trabajar de forma ágil. A simple vista Scrum parece simple, la guía oficial de Scrum tiene apenas 15 páginas y un curso típico de Scrum ronda las 16 horas.

Sin embargo esta simplicidad aparente en la teoría resulta bastante distinta en la práctica. Que sea fácil de entender no implica que resulte fácil de poner en práctica.

Scrum es un marco de trabajo para gestión y colaboración que puede utilizarse tanto en proyectos de software como también en otro tipo de proyectos. El hecho de que sea un marco de trabajo es lo que permite utilizarlo en contextos muy distintos pero implica al mismo tiempo que al utilizarlo en un escenario concreto es necesario “completar alguno huecos”. Algunos de esos “huecos” son muy explícitos pues son simples parámetros, por ejemplo la duración de los sprint. Pero de esos huecos son mucho menos explícitos, por ejemplo la forma en que estimaremos y que forma tendrán nuestros items de backlog. Es así que para un equipo que desarrolla software no alcanza con Scrum en abstracto, es necesario “llenar huecos” con prácticas concretas. Un complemento que ha resultado muy efectivo es utilizar Scrum con Extreme Programming(XP), o sea, “llenar los huecos” de Scrum con las prácticas de XP. XP es una propuesta de trabajo concreta para desarrollo de software y como tal contempla tanto cuestiones de gestión/colaboración como cuestiones de programación/prueba/despliegue, etc.

Pero por otro lado, para un equipo que viene de trabajar en una dinámica desordenada de “code-and-fix” meterse de lleno con Scrum puede resultar demasiado. Pasar de la nada a iteraciones time-boxed, gestionar explícitamente el backlog e incorporar todas las ceremonias de un día para otro, no me parece un apropiado. Es así que para esos escenarios yo suelo proponer una adopción gradual de Scrum y en ese sentido el mi recomendación es comenzar haciendo retrospectivas. La retrospectiva tiene la particularidad de ser una práctica sin dependencias, o sea, uno puede hacer retrospectivas sin utilizar ninguna otra práctica de Scrum. Al mismo tiempo la retrospectiva debería guiarnos en nuestro proceso de mejora. Dicha mejora podría llevarnos a incorporar otras prácticas de Scrum o no, tal vez podríamos terminar incorporando otras prácticas. O sea, tal vez arrancamos con la intención de hacer Scrum pero terminamos haciendo algo distinto. Pero esto no está mal, porque Scrum no debería ser un fin en sí mismo, sino un medio para lograr un fin de nuestro equipo/organización que en términos de Agile es agregar valor.

Impulsando el cambio desde la trinchera

Este es el título de la charla que di la semana pasada en el contexto de un webinar organizado por la Agile Alliance. El webinar estaba titulado “Camino hacia la agilidad: Una mirada integral” y constó de 3 oradores: Israel Alcázar, Ana Carmona y yo.

Israel fue el primero en presentar, su charla se tituló “Un enfoque integral para entender la agilidad”. Luego fue mi turno. Finalmente fue el turno de Ana cuya charla se tituló “Cuando un equipo tiene que seguir siendo ágil”. Creo que las 3 charlas estuvieron muy alineadas, primero Israel habló sobre cuestiones de transformación nivel organización/empresa. Luego yo hablé desde mi rol de XP coach trabajando con equipos de desarrollo. Finalmente Ana se centró en las situaciones que enfrenta un equipo luego del primer momento de transformación, cuando ya el equipo trabaja de forma autónoma sin la guía de un coach externo.

Luego de las tres charlas hubo un espacio de preguntas y respuestas. Toda la actividad estuvo moderada por Juan Banda.

A pesar de llevar más de un año de eventos online, no termino de acostumbrarme, sigo sintiendo como que estoy hablando al aire.

Todo el evento fue grabado y está disponible aquí en la web de la Agile Alliance, el acceso es gratuito pero requiere registración.

Taller: Tddeando microservicios a kubenertes

Ayer completé el dictado de la primera edición de mi taller “TDD your Microservice from Git to Kubernetes“. El título está en inglés porque efectivamente fue en inglés. Asimismo, si bien en el título dice TDD, el taller es mucho más amplio. Incluye también varias prácticas relacionadas como Configuration Management, Continuous Integration, Design Patterns, Architecture guidance, etc.

Hace un tiempo decidí no dictar más cursos de TDD porque la experiencia me demostró que luego del curso, el salto que debían hacer los participantes entre la “simpleza didáctica” de los ejercicios del curso y su código de trabajo cotidiano era muy difícil de realizar. Luego de analizar el origen de esas dificultades decidí armar este curso que apunta precisamente a trabajar con ejercicios más “de mundo real”, lo cual implica lidiar con un proceso de desarrollo en equipo, versionado, integración con otros sistemas e infraestructura, entre otras cuestiones.

Obviamente cubrir todas estas cuestiones en un solo taller resulta muy desafiante, es por ello que el taller está estructurado en varios encuentros. Al mismo tiempo es un taller “avanzado”, en el sentido de que requiere que los participantes tengan:

  • experiencia en desarrollo de software en un contexto de industria
  • conocimiento de TDD (al menos conceptualmente)
  • práctica en la automatización de pruebas (al menos de tipo unitario)

Al mismo tiempo, para achicar más el salto entre el taller y los proyectos diarios de los participantes, este taller está basado en tecnologías concretas incorporando también patrones de uso común en dichas tecnologías. Esta versión en particular la hice utilizando C# (netCore),NUnit, Moq, Gitlab y Kubernetes.

En los próximos meses estaré haciendo una edición en castellano. Los interesandos pueden contactarme aquí.

Recomendaciones para alumnos de MeMo2

Como de costumbre en cada cuatrimestre intentamos incorporar mejoras en base al feedback recibido el cuatrimestre anterior. Entre esas mejoras vienen algunas recomendaciones para los alumnos:

  • Dado que gran parte del trabajo de la materia es en grupo te recomendamos que ya de entrada coordines con otros alumnos para conformar grupos 3 integrantes.
  • La materia se dicta en modalidad virtual con lo cual es mandatorio para cursarla contar con sistema de audio (parlante y micrófono). Asimismo es importante que cuentes con cámara.
  • Si aún no tienes una cuenta @fi.uba.ar es un buen momento para que la tramites.
  • La materia tiene un flujo importante de mails durante la época de trabajos grupales con lo cual podría resultar muy útil (y conveniente) aprender a armar filtros en tu herramienta de correo electrónico.
  • En la materia utilizamos Git y Ruby pero no dedicamos tiempo de clases a enseñar ninguna de estas dos herramientas, por ello si aún no estas familiarizado con estas herramientas te recomendamos que comiences a estudiarlas a la brevedad.
  • Si sos alumnos de Ingeniería Informática y como tal debes cursar Técnicas de Diseño (75.10) te recomendamos que leas este artículo donde explicamos que MeMo2 no es TDD.
  • Más allá de las 6 horas de clases semanales (de asistencia obligatoria), la materia suele demandar una dedicación semanal constante de otras ~6 horas semanales de trabajo/estudio fuera del horario de clase todas las semanas. Durante las primeras semanas puede que sea un poco menos y durante las últimas semanas puede que sea un poco más.
  • Es muy importante que asistas las primera clase, pues ahí explicamos varias cuestiones sobre la dinámica de la materia y la modalidad de evaluación. Si por alguna razón no puedes asistir por favor comunícate conmigo a la brevedad.

Antes cualquier duda puedes contactarme por aquí.