DevOops!

Tengo la sensación que más de una organización la está pifiando con DevOps tal como ocurrió (¿sigue ocurriendo?) con Agile.

Hubo casos en los que se creyó que Agile era pegar post-its, tener Scrum Masters y trabajar en forma iterativa. Muchos Scrum Master resultaron ser «PMs reciclados» y si bien los post-its sumaron alegría, el software seguió apestando. Tal magnitud tomó el fenómeno que le dieron nombre propio: Dark Agile según Ron Jeffries o Flaccid Scrum según Fowler. Yo lo llamo simplemente Fragile.

Con DevOps percibo algo similar. Como developer antes tenia que lidiar con áreas de operaciones, ahora tengo que lidiar con áreas de DevOps. El nombre es distinto pero las fricciones siguen estando. Apenas han sido mitigadas por el uso de ciertas herramientas de automatización. Más aún las personas en muchos casos siguen siendo las mismas, son «SysAdmins reciclados». Basta una búsqueda rápida en Linked de perfiles DevOps para confirmar que muchos de ellos eran SysAdmins poco tiempo atrás.

Hay organizaciones que directamente decidieron poner un área de DevOps cosa que personalmente no me convence. He logrado distinguir dos patrones cuando una organización crea un área de DevOps:

  • Un caso es cuando ese área DevOps es un refactor del área de Operaciones. Incluso en algún caso más que un refactor es un simple rename. Aquí no hay grandes cambios para la dinámica de trabajo con el equipo de desarrollo más allá de algunas nuevas herramientas principalmente de automatización y monitoreo. Las caras son las mismas, los actores y las actitudes también.
  • Un caso distinto es cuando ese área de DevOps es creada desde cero incorporando nueva gente a la organización. En estos casos este área de DevOps se convierte en la nueva interface con la que el equipo de desarrollo debe interactuar. Ese área de DevOps es como un proxy del área de Operaciones. Desarrollo interactuar con DevOps y luego DevOps se encarga de lidiar con los distintos actores de operaciones (networking, base de datos, seguridad, etc.)

A mi parece ninguno de los dos casos es «True DevOps» porque la realidad es que la fricciones no desaparecen sino que a lo sumo se mitigan y/o cambian de lugar.

En otro post contaré otros patrones DevOps que me mi entender son más efectivos o al menos con los que yo me siento más cómodo.

De desarrollo a Producción en 8 días

El jueves pasado completamos la primera iteración. Construimos una funcionalidad mínima pero que nos sirvió para sentar las bases del proyecto y mitigar muchos riesgos técnicos. Al mismo tiempo montamos la infraestructura de CI/CD y el ambiente de desarrollo.

En esta segunda iteración tenemos el objetivo de agregar un poco más de funcionalidad, ajustar la estética/pantallas de la aplicación e ir a producción. Para esto tenemos 8 días hábiles. Puede parecer más que suficiente pero yo tengo mis dudas. Ninguno de los presentes en la reunión de planificación conocía a ciencia cierta el procedimiento formal para ir a producción con una nueva aplicación. La complejidad radica en que la organización es una entidad financiera que está sujeta a ciertas normas y regulaciones generales definidas por una entidad controladora externa. Al mismo tiempo ocurre que la implementación de algunas de esas normas es en ciertos casos obsoleta, extremadamente burocrática y sin sentido.

En 2 semanales cuento que tal nos fue.

Sobre la cadencia de iteración

Sobre la cadencia de iteración

Personalmente me gusta trabajar con iteraciones de 1 semana. Pero en el proyecto que estoy trabajando actualmente acordamos trabajar en iteraciones de 2 semanas pues la mayoría del equipo así lo prefiere y no logré convencerlos. Y cuando digo la mayoría del equipo en este caso es todo el equipo salvo yo. Entre los argumentos de mis compañeros para no hacer iteraciones de 1 semanas se destacó: «si hacemos iteraciones de una semana vamos a invertir demasiado tiempo porcentual en planning, review y retro». Personalmente no coincido, al ser las iteraciones más cortas, la planning y la review deberían también ser más cortas. Pero es cierto que más allá del tiempo dedicado a planning y review hay un costo de logística/setup de cada reunión.

Mi preferencia por las iteraciones de una semana se remonta a unos 10 años atrás. Desde entonces siempre que puedo intento trabajar de esta forma. Otra de mis preferencias es hacer las iteraciones en continuado agrupado en un mismo día las reuniones de revisión y planificación. Respecto de las retrospectivas no considero mandatorio que tengan la misma cadencia que la planificación. En varios proyectos he trabajado con una cadencia de planning/review semanal y con retrospectivas cada 2 o 3 semanas dependiendo de la consolidación del equipo.

Cuando me toca trabajar en iteraciones de 2 semanas (como en mi proyecto actual) yo igualmente en iteraciones de 1. No es que yo haga planning y review en solitario ni en paralelo, sino que al inicio de la iteración yo mentalmente planifico que voy hacer durante la primera semana. Una vez completa la primera semana, hago un checkpoint de mitad de iteración, leo el burndown chart, analizo cuánto hemos completado y veo como enfocar la semana siguiente de cara a intentar asegurar cumplir con el plan de la iteración o de ajustarlo si es que el contexto así lo requiere.

El dilema de dónde estudiar informática, algunas cuestiones a considerar

El dilema de dónde estudiar informática, algunas cuestiones a considerar

En la época en que inicié mis estudios universitarios todavía estaba vigente la creencia de que un estudio universitario «aseguraba un futuro». Con lo cual si uno tenia la posibilidad económica y las ganas de hacerlo, solo había que decir qué estudiar. Al mismo tiempo en aquella época (fines de los ’90) internet no era lo que hoy y el acceso a la información era mucho más acotado. Hoy en día las cosas han cambiado mucho, comenzando por el hecho de que ya es claro qué hacer una carrera universitaria no asegura un futuro.

En en el caso particular de la informática hoy en día existen muchas opciones de estudio tanto dentro como fuera de la universidad. Intentaré resumir algunas de las opciones en forma simplificada.

Dentro de la educación universitaria hay un conjunto interesante de opciones que no existían cuando yo comencé a estudiar. En este punto me refiero concretamente a carreras universitarias cortas: diplomaturas y tecnicaturas como las que ofrece la Universidad Nacional de Quilmes. Son carreras cortas de 2 o 3 años que representan una opción rápida (en comparación con las carreras tradicionales) para la inserción laboral.

Fuera de la educación universitaria hay dos subgrupos: la educación no universitaria formal y la informal. Con educación no universitaria formal me refiero a carreras terciarias que tienen el aval/regulación del estado. Un caso de esto son las tecnicaturas superiores que ofrecen los Institutos Superiores de Formación Docente y Técnica.

En cuanto a la educación informal tenemos una variada oferta que incluye cursos presenciales, como los que ofrecen IT College, Digital House y Educación IT y cursos online, como los disponibles en Acamica y Coursera. Algunas de estas instituciones ofrecen incluso algunos cursos en modalidad mixta de clases online y encuentros presenciales. Estos tupo

Para cerrar esta enumeración vuelvo al comienzo: las carreras universitarias tradicionales de informática. Ingenierías y licenciaturas, carreras largas, de 4 o 5 años en los papeles pero más cerca de los 7 u 8 años en la práctica. Incluso dentro de esta opción hay varios caminos, uno típico de polémica es universidad pública o universidad privada.

Personalmente no creo que haya una opción mejor que otra, es simplemente una cuestión de expectativas y necesidades. Lo que me parece interesante e importante es que hay muchas opciones y la profesión está en ascenso. Al mismo tiempo es importante tener presente que el estudio es un primer paso que no está necesariamente relacionado al desempeño profesional. He trabajado con excelentes profesionales de diversa formación, algunos de ellos nunca completaron un estudio formal.

Insisto en que es una cuestión de expectativas, lo cual no es un tema menor. Si lo que pretendemos es hacer apps para iPhone, no me parece que sea imprescindible hacer una carrera universitaria larga. Pero si lo que buscamos es hacer aplicaciones de tiempo real tal vez sea distinto.

Cada una de las opciones de estudio habilita un conjunto de potenciales oportunidades. Un ejemplo concreto: conozco de empresas que para determinados puestos solo contratan personas con título de ingeniero y solo de determinas universidades. Tal vez este tipo de políticas cambie a futuro, pero no estoy tan seguro. De todas formas, si a uno no le interesa trabajar en empresas con esas políticas, no tiene de qué preocuparse. Ojo, con esto no estoy diciendo que sea mejor estudiar ingeniería, sino que lo importante es tener en claro las expectativas de cada uno y elegir en base a eso.

El curioso incidente del Scrum Master y el merge a master

El curioso incidente del Scrum Master y el merge a master

Estábamos arrancando con el setup del proyecto y nos enteramos que el área arquitectura definió que el único que puede aprobar los merge-requests a master es el Maintainer. Curiosamente arquitectura asignó el rol de Maintainer en nuestro proyecto al Scrum Master, el único miembro del equipo (junto con el PO) que no codea, ¡ooops!

Ayer comenté esto en twitter y generó varias reacciones.

Lo que me incomoda de esta situación no es el hecho de quién puede aprobar los merge-request sino el hecho de que alguien externo al equipo defina cómo debe trabajar el equipo. Entiendo que haya ciertos lineamientos generales en cuestiones que puedan tener impacto fuera del equipo, pero cuestiones como el esquema de branching creo que no es una de esas cuestiones.

Al mismo tiempo quiero destacar que si bien recién estamos comenzando con el proyecto, la persona en el rol de Scrum Master me cae muy bien, creo que está haciendo un buen trabajo y si bien actualmente no codea lo hizo en el pasado.

Otra curiosidad es que en los lineamientos de arquitectura se asume en cierto modo que el equipo utilizará branches y merge-request, cuando en realidad la intención de nuestro equipo es hacer trunk-based development trabajando de pares para todo código productivo.

En fin, como conozco a uno de los referentes de arquitectura y me parece una persona bastante criteriosa y accesible lo llamé por teléfono para comentarle esta situación. Me explicó algo razonable: solo una persona por equipo tiene el permiso Maintainer y cuando se creo el proyecto el único miembro del equipo de desarrollo que estaba confirmado era el Scrum Master. Adicionalmente me explicó que lo que hizo arquitectura no fue establecer «reglas de piedra» sino lineamientos generales que surgieron del diálogo con diversos referentes de la organización y que pueden revisarse en cada caso particular. Esto también me resultó muy razonable. Más aún me parece muy sano cuando uno comienza un proyecto no se encuentre con la nada misma, está bueno tener algunos lineamientos que luego uno pueda debatir y eventualmente ajustar.

Cerrando la historia pinta que el equipo trabajará sobre un branch develop y luego en la salida a producción haremos el trámite de merge-master.

Nuevo proyecto, nuevos desafíos

Nuevo proyecto, nuevos desafíos

Esta semana estoy arrancando formalmente un nuevo proyecto. La semana pasada hicimos el descubrimiento de producto y como parte del mismo identificamos objetivos de negocio y métricas para medir el éxito. También definimos algunas cuestiones de estrategia tanto técnica como de negocio.

Entre los desafíos del proyecto hay algunas cuestiones que me parece relevante mencionar:

  1. Un equipo de desarrollo distribuido en 2 ciudades y conformado por personas de 4 organizaciones distintas.
  2. El uso de un conjunto de tecnologías de desarrollo (.net core y angular) en las que la mayoría del equipo no tiene experiencia.
  3. El uso de una infraestructura de ejecución (docker y kubernetes) en la que la mayoría del equipo no tiene experiencia.
  4. La necesidad de generar un entregable de valor en un tiempo máximo de 6 semanas.
  5. La integración con una aplicación legacy.
  6. Requerimientos concretos de accesibilidad.
  7. El uso de ciertas prácticas de desarrollo de cara a intentar asegurar la calidad del entregable (continuous delivery, test-automation, infra as code, etc)

Mi participación en el proyecto tiene que ver principalmente con ayudar en los puntos 2, 3 y 7.

Como parte del trabajo de discovery (que duró 3 días) generamos también algunos acuerdos de trabajo:

  • Trabajaremos en iteraciones de 2 semanas
  • El jueves será el día de las ceremonias de planning/review/retro
  • La daily standup será 9.30
  • El trabajo lo organizaremos en Jira
  • Para la comunicación diaria utilizaremos Microsoft Teams
  • Para el código utilizaremos GitLab
  • Jenkins será nuestro Build Server

Me gusta mucho que la daily sea tempranito pero no me gustan tanto las iteraciones de 2 semanas, sinceramente prefiero iteraciones de 1 semana, pero en bueno, es algo con lo que puedo vivir.

A medida que el proyecto vaya avanzando iré compartiendo novedades en este espacio.