Categoría: opinion

Estudio sobre la comunidad ágil de latam: paper aceptado y publicado

Tiempo atrás comenté que habíamos enviado el paper resultante de nuestro trabajo investigación a la International Conference on Agile Software Development (informalmente llamada XP Conf). Dicho trabajo fue aceptado y estaremos presentándolo la semana próxima en Porto, lugar donde se lleva a cabo la conferencia.

Comparto aquí de modo muy resumido los hallazgos más relevantes del trabajo:

  • Las prácticas organizacionales son mucho más usadas que las prácticas técnicas.
  • La cantidad de prácticas utilizadas aumenta con la mayor experiencia de la organización en el uso de métodos ágiles.
  • La diferencia entre la cantidad de prácticas técnicas y la cantidad de prácticas organizacionales disminuye a medida que aumenta la experiencia de la organización en el uso de métodos ágiles.
  • Las variables tamaño de equipo y duración del proyecto no tienen impacto en la cantidad de prácticas utilizadas.

Si bien puede que estas conclusiones parezcan evidentes, la realidad es que no había prueba científica de esto y eso es precisamente lo que generamos con este trabajo.

El trabajo está disponible en forma abierta en el sitio de Springer.

Quiero agradecer a todos aquellos que colaboraron con este estudio completando la encuesta y en particular a Juan Gabardini, Soledad Pinter, Emilio Gutter, Federico Zuppa, Thomas Wallet, Natalia Baeza y tantos otros que nos ayudaron en la difusión de la encuesta y en la validación de algunas ideas.

HOY: Patrones de Infraestructura para Continuous Delivery

Esta tarde a partir de las 18.50 estaré en la oficinas de RyanAir Madrid, exponiendo sobre esta temática.

De paso, voy a aprovechar el contacto con la comunidad ágil de Madrid para hacer difusión de algunos libros «Made in Argentina». Voy a estar sorteando entre los participantes algunos ejemplares de «Construcción de Software, una mirada ágil» y «Experiencias ágiles, relatos de experiencias del uso de métodos ágiles en Argentina».

Si están por Madrid y quieren sumarse, la entrada es gratis pero es necesario registrarse aquí.

Promediando el cuatrimestre en AyDOO @ UNTREF

Hemos completado la séptima semana de clase de Análisis y Diseño Orientado a Objetos en UNTreF. Este cuatrimestre viene con varias novedades.

En primer lugar tuvimos un cambio de equipo el cual esta conformado por: Diego Marcet (egresado de FIUBA con quien tuve el gusto de trabajar profesionalmente en diversas ocasiones y que está definitivamente en mi Dream Team) y Lucas Campaner (estudiante de UNTreF y uno de los mejores ex-alumno de la materia).

Otra novedad fue el cambio de la herramienta de soporte, comenzamos a utilizar Canvas LMS, una herramienta que yo ya venía utilizando en otras materias.

Finalmente la novedad a mi parecer más importante es el cambio en la dinámica de la clases. Este cuatrimestre estamos dividiendo la clase en 2 partes. En la primera vemos algo de teoría, atendemos consultas o resolvemos algún ejercicio en forma conjunta utilizando el proyector. En la segunda nos dedicamos a programar. Planteamos alguna consigna y programamos en grupos de tres, haciendo lo que podríamos denominar como «trio-programming» (o pair-programming con trios en lugar de pares). Al mismo tiempo los docentes vamos rotando por los equipos atendiendo dudas, debatiendo diseños y programando.

Esta semana, hicimos un retrospectiva con la intención de tener un feedback formal de los alumnos y detectar oportunidades de mejora. El feedback fue muy positivo y los alumnos destacaron el hecho de programar en clase. Entre los puntos accionables que salieron de la retrospectiva están:

  • Tener una semana sin tareas. En la dinámica que llevamos los alumnos tienen tareas todas las semanas lo cual hace que la materia tenga un ritmo intenso. Suele ocurrir (como en cualquier contexto de aprendizaje) que los alumnos deben reentregar alguna tarea y eso complica aún más la dinámica ya de por si intensa. En ese contexto los alumnos sugirieron tener una semana sin tareas para que quienes estén adeudando algo puedan ponerse al día.
  • Mejorar el material de estudio sobre diagramas de secuencia que actualmente resulta insuficiente.
  • Ajustar el tiempo de requerido por la materia y la dinámica de reentregas. Si bien en nuestro diseño de la materia esperábamos una dedicación extra-clase de 6 horas semanales, los alumnos reportaron estar invirtiendo unas 10 horas. Parte de las cuales resulta consecuencia de las múltiples reentregas que tienen algunas tareas. En este sentido acordamos que cada tarea tendrá solo una reentrega.

Un tercio de cuatrimestre en MeMo2@Fiuba

Hemos completado la sexta semana de clase y estoy conforme con como viene saliendo la materia. Tenemos 18 alumnos firmes, uno en la cuerda floja y uno que abandonó en la segunda semana.

La semana pasada hicimos una retrospectiva y las conclusiones fueron muy buenas a mi juicio. Entre los puntos positivos mencionados por los alumnos estuvieron los videos, la actividad de programación en clase, el material de lectura y el feedback dado en las correcciones de las tareas. Entre los action ítems resultantes acordamos trabajar en los siguientes 3:

  • Habilitar un espacio en el campus para debatir las preguntas de los cuestionarios
  • Seguir agregando más videos al material de estudio de forma de poder utilizar más tiempo de clase para actividades interactivas
  • Procurar que las preguntas de los cuestionarios que sean de tipo verdadero/falso tengan un campo de justificación

Herramientas para gestión de backlog

Ayer recibí esta consulta de un colega:

«[…] te consulto porque estoy buscando para el banco una herramienta para Agile y seguimiento. ¿Tenes alguna recomendación al respecto?»

Esta es una consulta que he recibido varias veces y en primer lugar me veo obligado a decir que «la gestión ágil» no requiere de herramientas particulares y al mismo tiempo las herramientas toman un plano muy secundario. Ya lo dice el manifiesto «Individuos e interacciones por encima de  procesos y herramientas«.

Hecha esta aclaración mi respuesta a esta consulta suele tener dos partes.

En primer lugar suelo recomendar comenzar trabajar con un tablero físico y post-its. Hacer un par de iteraciones, refinar el workflow de estado de los ítems e identificar las necesidades reales en términos de gestión y seguimiento. Si el equipo no está distribuido o simplemente el tablero físico no es una opción, entonces comenzar utilizando una simple hoja de cálculo. Suelo recomendar esto porque en general que visto mucha gente comprando y/o adaptando herramientas a partir de elucubraciones teóricas, las cuales en muchos casos terminan plasmando en una herramienta un proceso «inventado de la nada» que poco tiene que ver con las necesidades de los proyectos.

Por otro lado, si quien me consulta alguien ya tiene en claro el workflow de estados y las necesidades reales (respaldadas por evidencia), entonces cuento mi experiencia:

  • Me gusta Jira, me parece una herramienta simple y muy flexible. Es paga y aunque no es muy cara, puede resultar inconveniente pagar por una herramienta sin tener en claro el proceso.
  • De las herramientas gratuitas me gustan Redmine y Trac, porque además de las funcionalidades de gestión de proyecto, ofrecen otra serie de cuestiones como Wiki e integración con herramientas de SCM. (los creadores de Jira también ofrecen herramientas adicionales como Confluence, que se integran con Jira y cubren funcionalidades adicionales).

 

Herramientas varias para Docker

Quiero compartir algunas herramientas que me han resultado muy útiles al trabajar con Docker/Kubernetes.

En https://access.redhat.com/containers/ se puede encontrar una interesante cantidad de imágenes Docker curadas por Red Hat.

El Red Hat Container Development Kit, es un conjunto de herramientas para facilitar el desarrollo de contenedores. Entre estas herramientas se encuentra una variante de Minishift.

Minishift una herramienta que permite correr un cluster de OpenShift de forma local en cualquier notebook.

Source to Image es una herramienta que permite crear imágenes de una forma repetible trabajando a un cierto nivel de abstracción sin necesidad de escribir Dockerfiles.

 

Tareas de un DevOp Engineer

Hoy un colega me consultó si tenía alguna descripción de las tareas que debería hacer un DevOp Engineer y eso motivo a escribir este artículo.

Debo empezar diciendo que no estoy muy convencido de que exista la profesión  DevOp Engineer, o sea: me consta que existe pero dudo que sea conceptualmente correcta su existencia. Al margen de esto: actualmente estoy trabajando como DevOps Engineer en un proyecto, ¡ja!.

Vamos por partes: la idea de DevOps es derribar los silos organizacionales para optimizar el flujo de entrega de valor. Si tenemos un área de operaciones y un área de desarrollo, deberíamos apuntar a que comiencen a trabajar de forma más integrada. En principio no creo que eso requiera de la aparición de un nuevo rol porque en principio no hay una nueva tarea. Alguien podría pensar que sí hay una nueva tarea dentro del grupo de operaciones (o del de desarrollo) y que esa tarea es encargarse de la interacción con el otro grupo. Esto podría tener sentido (de hecho es una de las tareas que estoy haciendo en mi proyecto actual) pero no estoy convencido porque se corre el riesgo de seguir operando como silos.

Por otro lado, dependiendo del estado en que nos encontremos, puede que como parte de la iniciativa DevOps decidamos empezar a utilizar nuevas herramientas (por ejemplo para automatizar tareas). Entonces podría tener sentido incorporar un nuevo rol con conocimiento de  dichas herramientas y de los conceptos que las mismas implementan. Este es justamente mi caso: la organización a la que pertenece el proyecto en el que estoy trabajando ha decido dockerizar su infraestructura y justamente esa la razón de mi involucramiento en el proyecto.

Dicho todo esto, podríamos decir que las tareas de un DevOp Engineer incluirían principalmente:

  • Facilitar el trabajo conjunto de las área de Desarrollo y Operaciones
  • Asistir a los equipos de Operaciones y Desarrollo en las tareas de definición e implementación de arquitectura (lógica y física) de aplicaciones
  • Asistir a los equipos de Operaciones y Desarrollo en la definición e implementación de la infraestructura de CI/CD
  • Asistir a los equipos de Operaciones y Desarrollo en la definición de procesos de monitoreo.

De estas tareas se desprenden una serie de habilidades/conocimientos de distinta índole: «soft-skills», configuration management, scripting/programación, operación, etc. A mi me suena que una persona aspirante a un puesto así debería tener bastante experiencia en la profesión.

Para cerrar: lo importante es que desarrollo, operaciones y el negocio trabajen en forma conjunta, coordinada e integrada para optimizar el flujo de entrega de valor, la incorporación de un nuevo rol para lograr esto es un detalle de implementación.

 

Spring Config: a key tool for DevOps & Continuous Delivery

Spring Cloud Config (scc) is a tool that provides support to externalize application configuration in a REST Service. The big picture is:

  • Add a SCC client your application so when your application starts, it can fetch its configuration from SCC server.
  • Setup a SCC server, which is a Java REST Service (more specifically is a Spring-Boot application).

The following image offers a overview of how Spring Cloud Config fits in you application architecture.

Some benefits of this strategy are:

  • You decouple the evolution of your application from the evolution of the configuration, that is: you application will be the same in every environment while the configuration will be different in each environment. At the same time the change rate of your application is different from the change rate of the configuration.
  • Your application forgets about where the configuration it stored because it delegates that concern to SCC server.
  • SCC server supports several storage options: Git, File System, Vault, Database, ConfigMaps, etc. The default option is Git which is great because it «force» you to have your configuration versioned.
  • SCC provides several common features related to configuration management like: check the current configuration values, configuration reloading, encryption of secrets and support for different configuration formats among other things.

While working with SCC I faced some issues regarding how to specify its configuration so I want to share some details here.

To make SCC Server read configuration from a remote Git repository:

spring.cloud.config.server.git.uri=https://.....

(this would work fine for public repositories, but if you need to use a private repository, which is a common case, you will need to specify some more parameters like strictHostKeyChecking and privateKey that are very well explained in the official documentation). When SCC server starts, it will clone the remote repository into a local directory whose location will be generated randomly at runtime (but it is also possible to specify the clone location).

To make it work with a local git repository (which contains a .git subdirectory), just use:

cloud.config.server.git.uri=file:///your/local/git/repo

To make ir work with a local «plain» directory we need to specify active profile as «native» which makes SCC server to read the config from a plain local directory (not a git directory)

spring.profiles.active=native
spring.cloud.config.server.native.searchLocations=file:/your/directory

It worth mentioning that even when Spring Cloud Config is built on Java, you can use any client technology to consume it because it exposes a REST API. The Spring team provides a Java client, but there are also clients for other technologies.

 

El Perfil de los alumnos de MeMo2 @ Fiuba

La semana pasada comenzaron las clases y de cara a conocer fehacientemente el perfil de los alumnos hice una breve encuesta. Comparto aquí algunos de los resultados.

Respecto de la condición laboral, el 70% trabaja y mayoritariamente lo hace en una actividad afín a la carrera.

Respecto de la cantidad de materias que están cursando este cuatrimestre, la mayoría (55%) contestó 3. Es un número «conservador» pero inferior a la cantidad que prescribe el plan de estudios formal. Esto podría ser una explicación para el hecho de que en general son muy pocos los que completan la carrera en el plazo estipulado por el plan.

Un dato que me llamo mucho la atención es la gran dispersión en la cantidad de materias aprobadas: el alumno con menos materias aprobadas tiene 10, mientras que el alumno con más materias aprobadas tiene 27. Una explicación posible para esto es que quienes tienen más materias, han cursado varias de las electivas, mientras que quienes tienen menos, han cursado solo las obligatorias para llegar a esta materia.

Finalmente, la última pregunta apuntaba al rol en el que les gustaría desempeñarse profesionalmente a largo plazo. Me alegró ver que la gran mayoría eligió roles técnicos.

Libros sobre estimación y planificación Ágil

Durante mucho tiempo mi libro de referencia sobre esta temática fue el clásico Agile Estimating and Planning de Mike Cohn. Pero hace un par de años lei otro libro que me pareció mucho mejor: Planning Extreme Programming, de Kent Beck y Martin Fowler. Este libro fue publicado en 2001, 5 años antes del libro de Cohn y si bien tiene mucho puntos en común con este, tiene también un conjunto de cuestiones muy prácticas que no están presentes en el libro de Cohn. Entre las cuestiones que me gustan de este libro es que sugiere como proceder cuando las cosas no funcionan «felizmente». Por otro lado creo que es un libro para leer de punta a punta, ya que -al igual que todos los libros de la serie XP- tiene capítulos cortos que hacen muy amena su lectura.

Resulta que ayer estaba preparando una clase para FIUBA y tomé algunas cosas de este excelente libro de Beck y Fowler y me pareció que sería interesante compartir esta opinión pues tengo la sospecha que no es muy popular.