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”)