Agile por Kilo

El año pasado me contactó un directivo de una empresa multinacional que estaba interesado en empezar a trabajar con métodos ágiles. Me reuní con él para entender su necesidad. Una vez comenzada la reunión le pregunté sobre la motivación que lo llevaba a los métodos ágiles, o sea, yo quería entender qué problema se esperaba resolver o que situación se esperaba mejorar a partir del uso de métodos ágiles. La respuesta fue muy concreta: a nivel global la organización había decidido adoptar una “forma de trabajo ágil combinada con DevOps” y por ello este directivo quería contratar a la brevedad 5 coaches/scrum masters para generar un “shock de agilidad” que se tradujera en una mejora notable de productividad. De esta forma esperaba contagiar al resto de los equipos de la subsidiaria local para que se subieran “al tren ágil”. Esta estrategia distaba mucho de lo que yo hubiera hecho y en un punto hasta podría considerársela “anti-ágil”. En enfoque ágil implicaría crecimiento orgánico y sustentable lo cual es muy distinto a “un shock”. En vano intenté convencerlo de utilizar un enfoque distinto y la cuestión no pasó de esa reunión.

Estos son los tiempos que vivimos. Del mismo modo que hay organizaciones que desde hace años pretenden “comprar programador por kilo” hoy en día, con agile siendo mainstream, hay organizaciones que pretenden “comprar agile coaches por kilo”.

Pero en cierto modo creo que lo más triste no es la intención de los que quieren comprar, sino que hay organizaciones dispuestas a satisfacer esos pedidos :-(.

Ya lo decía mi abuela: la culpa no es del chancho sino de quien le da de comer 😦

Anuncios

Lecciones aprendidas automatizando pruebas en ambientes corporativos (parte 2)

En el artículo anterior me centré en los desafíos técnicos. Ahora quiero centrarme en los desafíos humanos, los cuales en ocasiones son aún más complejos: las máquinas hacen lo que uno les dice, pero no las personas no, ¡ja!

El primero de los desafíos humanos aparece en la concepción misma de la iniciativa de automatización. En la mayoría de los casos que he participado la motivación de automatizar ha surgido de una gerente/jefe/líder, pero no de la gente que realiza el desarrollo de los sistemas (developers), ni tampoco de la gente que realiza las pruebas manualmente (testers).

Por lado las iniciativas en las que he participado han caído en manos de equipos incompletos y/o grupos con muy poco compromiso. Gente a la que “se le endosa” la obligación de colaborar en esta iniciativa pero para la cual esta iniciativa no reviste de mayor interés.

Luego de haber participado en varias iniciativas de este estilo solo puedo reconocer 2 de ellas como exitosas (aún cuando los clientes han quedado conformes con lo realizado en casi todos los casos). Los puntos que identifico comunes en esos mencionados casos de éxito son:

  • En ambos casos se contó con una persona en el rol de Software Engineer in Test, alguien que se encarga de proveer/desarrollar herramientas, guías y ayuda en general para facilitar el trabajo de todos aquellos que deban realizar tests.
  • La dedicación pro-activa, comprometida y explícita (en términos de asignación y planificación) de un desarrollador/implementador del sistema core para que asista en el setup de los set de datos necesarios en el sistema core.

En breve estaré empezando un nuevo proyecto de este estilo, por ello en un próximo artículo contaré lo que lo tenemos planeado.

Lecciones aprendidas automatizando pruebas en ambientes corporativos (parte 1)

En los últimos años he participado en un par de iniciativas para automatizar pruebas en “ambientes corporativos”. Cuando digo ambientes corporativos me refiero a organizaciones cuyo core de sistemas está implementado por algún  tipo de enlatado con cierto grado de customización (ERP, CRM, Core bancario, etc). Alrededor de este core la organización desarrolla aplicaciones satelitales que suelen actuar como canales implementado alguna funcionalidad complementaria al core. Estas aplicaciones satelitales/canales suelen tener una gran cantidad de requerimientos y cambios ya que son uno de los medios principales en la actualidad para permitir la innovación del negocio. A la hora de desarrollar estas aplicaciones aparece la necesidad de poder testearlas y que dicha prueba sea (al menos en parte) automatizada.

En particular he tenido la oportunidad de trabajar en contextos de instituciones bancarias y también del ámbito de las telecomunicaciones y en ambos casos he detectado situaciones/desafíos comunes que me parece son habituales en entornos corporativos.

En mi experiencia he identificado dos tipos de desafíos: los técnicos y los humanos.

En lo que respecta a desafíos técnicos el principal pasa por la dificultad de contar con un ambiente de pruebas sobre el cual uno pueda tener control de estados/datos.  En el escenario ideal yo quisiera poder contar con una instancia exclusiva y on-demand del core, cuyo estado pueda manipular a mi gusto sin impactar en otros equipos. Esto no es simple, ya que muchas veces el setup de estos sistemas core es bastante complejo y poco automatizado. Lamentablemente en ninguno de los casos que he trabajo he tenido esta posibilidad, lo cual me ha llevado a buscar soluciones alternativas.

Una situación que me he encontrado en todos los casos que participé es la presencia de un de ESB (enterprise service bus) que funciona como orquestador/integrador de mensajes entre los diversos sistemas de la organización incluido el core. De hecho es común que la interacción de los canales/satélites con el core se haga por medio de un ESB.  Si bien esto puede interpretarse como una complejización de la arquitectura, se supone que en general la simplifica. Al mismo tiempo representa una posible salida al problema del testing.

Escenario corporativo

Entonces ante la imposibilidad de contar con un core para las pruebas (y también para el desarrollo) tenemos dos opciones. Una primera opción es mockear “a la salida” las interacciones con el core.

Opción 1. Mock “a la salida”

La otra opción sería hacer que el ESB devuelva respuestas mockeadas.

Opción 2. Mock en el ESB

Algunos puntos a tener presente independientemente de la estrategia utilizada:

  • Al utilizar una estrategia de mocking en este contexto es necesario tener algún mecanismo para detectar potenciales cambiamos en el sistema que estamos mockeando/emulando. Una estrategia posible es hace contract testing del sistema que estamos mockeando de manera que los tests de contrato se ejecuten periódicamente y nos alerten de eventuales cambios.
  • En algún punto, previo al pasaje al ambiente productivo es necesario poder correr algún tests contra una instancia del core real.  En uno de los casos que me toco participar, la instancia de test del sistema core era tan inestable y distinta al core productivo que lo que se decidió hacer un despliegue canary a un servidor productivo, accesible solo internamente, y de esa forma probar directamente en producción.  Una vez realizada la validación, entonces se completaba el despliegue al resto de los servidores habilitando la aplicación al público en general.

Continuará…..
(en un futuro artículo me referiré a los “desafíos humanos de esta problemática”)

Preparando la versión 5 de mi Taller de Prácticas DevOps

A partir de un pedido de un cliente he empezado trabajar en un nuevo módulo para la versión 5 del taller. Este módulo estará enfocado en el ecosistema Docker (particularmente Swarm, Compose y Kubernetes) y en cuestiones de monitoreo y logging. Estimo que esto podría llegar a extender la duración del taller unas 3 o 4 horas adicionales.

Esta semana debería terminar de completar el contenido conceptual (diapositivas) y la semana próxima debería comenzar a trabajar en el diseño de los ejercicios. Una vez tenga estos ejercicios completos será hora poner fecha para el estreno de esta versión, lo cual con viento a favor será hacia fines de agosto.

IEEE ARGENCON 2018, Desarrollo de Software en tiempos Messi

A comienzos de este mes estuve en Tucumán participando de 2 eventos: ARGENCON (organizado por IEEE) y La Semana de la Ingeniería (organizada por UTN Tucumán). Además de dictar un par de charlas y talleres, tuve también la oportunidad de escuchar varias presentaciones de otros autores  y debo decir que el nivel en general me pareció muy bueno. Más allá de las sesiones formales, compartí charlas muy interesantes con estudiantes, docentes y practicantes. En la cena social de ARGENCON compartí la mesa con Alejandro Bianchi (presidente de Liveware) y David Trejo (participante de Singularity University).

Una de las charlas que di la titulé Desarrollo de Software en tiempo de Messi, un título con “intención marketinera” que tuvo el efecto deseado atrayendo a la charla a varios asistentes. Aquí están las diapositivas que utilicé durante la charla.

Participantes del Taller de Automatización de Pruebas
Gustavo Juarez, presidente de IEEE Argentina, en la cena de gala

Mi enfoque para una adopción DevOps

Recientemente me he encontrado hablando con varios colegas sobre posibles estrategias para “adoptar” DevOps y eso me llevó a poner por escrito lo que viene siendo mi estrategia preferida cuando me toca participar.

De cara  lograr una adopción efectiva de una estrategia DevOps y considerando las experiencias en organizaciones de distinta índole en las que he estado involucrado mi propuesta consiste en 3 fases:

Fase 1: assessment
Me gusta comenzar realizando una primer reunión con quien será el sponsor de esta iniciativa de cara a  asegurar la intención/motivación de todos los sectores involucrados: negocio + desarrollo + operaciones.
Luego suelo pedir al sponsor que encuentre dos equipo de desarrollo que quieran recorrer este camino y que actualmente sea conscientes de algunas limitaciones/situaciones que quieran resolver/mejorar a partir de una iniciativa DevOps. Como siguiente paso propongo realizar un par de entrevistas (~30 minutos) con los equipos identificados y también con gente de las otras área (negocio y operaciones)
Esta fase cierra con un informe y una propuesta de plan a corto plazo y una visión a largo plazo. Para este trabajo estimo un esfuerzo de unas 10 horas máximo y debería poder ejecutarse en 1 semana (o eventualmente 2 semanas si se complica agendar las reuniones). Más allá de las particularidades del caso, la propuesta es trabajar bottom-up, generando consenso desde la gente que realiza el trabajo en el día a día. Esto difiere de otras estrategias muy comunes, generalmente de tipo top-down: los jefes/gerentes/directivos definen como los developers deben trabajar.

Fase 2: exploración
Partiendo de lo realizado en la fase anterior, empiezo a trabajar con 1 de los equipos identificados durante 3 iteraciones (asumiendo que el equipo trabaja en forma iterativa). Yo me sumo al equipo en forma part-time para ayudar en la mejora actuando de coach tanto en lo técnico como en la gestión y coordinación con las otras areas.
Durante la primer iteración relevo el proceso y los impedimentos, y establecemos métricas que nos permitan medir objetivamente el estado actual y la potencial mejora.
Al cabo de dos iteraciones más, debería empezar a notarse alguna mejora en las métricas. En este punto hacemos un checkpoint y vemos si mi participación ha generado alguna mejora razonable y en base a ello decidimos mi continuidad o no.
Aproximadamente en la sexta iteración el equipo ya debería tener una mejora visible y podríamos empezar a replicar el proceso con un segundo equipo.
Habiendo recorrido este camino de mejora con al menos 2 equipos, estamos en condiciones de refinar la visión y definir un plan de implementación a mediano plazo.

Fase 3: expansión
En esta fase trabajamos en implementar el plan de mediano plazo y deberíamos poder generar líderes internos que serán los encargado de materializar el plan de largo plazo. Es aquí donde comenzar a intentar formalizar acuerdos y convención sumando iterativamente más gente a la iniciativa.

 

XP2018, day 3 to 5 summary

My initial plan was to write a different article for each day, but the time is running and I have not enough time to do it, so here it goes: a quick summary of the best things I saw during days 3, 4 and 5.

Day 3 started with Kent Beck. No slides, just “the guy” in the middle of the stage.

Beck started talking about accepting the diversity when working in teams. That part of the talk was ok but it was not big deal for me. What was really great for me was the second part of the talk when Beck talked about the 3X model for product development. In the afternoon I attended some other sessions but nothing very relevant except for a one-to-one talk I had with Beck about his 3X model. The day ended with a social event in the terrace of research center next to the sea.

On Thursday (day 4) the most interesting things I saw were 2 session in the afternoon. The first one was “Contract Testing in theory and practice” by Seb Rose and as usual with his sessions, it was an excellent session. The second one was a research work presented by Ernani Dos Santos about “Automated Acceptance Tests as Software Requirements: An Experiment to Compare the Applicability of Fit tables and Gherkin Language”, it was really interesting and provided me with resources for my software engineering course.

Friday was the last and possible the day with the best content. During the morning I attended to a hands-on session with Cucumber guys: Aslak Hellesøy and Steve Tooke. The session was focused on how to create super-fast acceptance tests. During the afternoon the was in the session “Refactoring Legacy Code: Mobbing Dojo” that was facilitated by Danijel Arsenovski and Steve Bement.