GX28: Charla “El testing como impulsor del cambio hacia una cultura DevOps”

Junto a Arcadio Abad, de Abstracta también, dimos una charla que titulamos “El testing como impulsor del cambio hacia una cultura DevOps” en el marco del encuentro GeneXus GX28. 
Te dejo por acá el video:

Las slides quedaron disponibles en Slideshare:

El testing como impulsor del cambio hacia una cultura DevOps from Federico Toledo

A continuación transcribo las notas que hacen referencia a lo que dijimos.

En Abstracta trabajamos con diversas empresas, muchas de ellas tienen ya una cultura DevOps, y en otras hemos ayudado a definirlo e impulsarlo, y creo que es porque al haberlo visto en algunos lugares, nos dan ganas que todos vayan hacia ahí. En particular, hemos ayudado en este impulso en algunas empresas que trabajan con GeneXus. En esta charla compartimos algunos de estos aprendizajes, pensando en que algunos pueden ser útiles para otros equipos también. Tenemos el convencimiento que los equipos con cultura DevOps trabajan mejor, obtienen mejores resultados y son más felices.
Para saber qué es DevOps, te recomiendo que vayas a leer este otro post. 

Esta ilustración de Dan Ashby me pareció genial para ilustrar el concepto, y a su vez para ver cómo participa el tester de todo esto.

Como se puede ver en la figura, debería haber testing en cada una de las etapas del proceso. Y esto ya es una característica de lo que DevOps propone, pensando también en cualquier metodología ágil: el testing NO es algo que solo se haga al final, sino que se hace de manera continua, asociado a cada una del resto de las tareas.
Algo interesante también relacionado al término de DevOps es que se le llamó en un inicio “agile operations”, y si vemos estas imágenes de Katrina Clokie, de su libro “testing in devops”, podemos ver cómo la idea de DevOps puede ser concebida como llevar agile a otros rincones.

Entonces, cuando hablemos en esta charla de adoptar Cultura DevOps tenemos que tener en cuenta que vamos a tener que adoptar también una cultura Agile. Muchas de las cosas que vimos en esta charla son para adoptar agile, que es la base para luego adoptar DevOps.

Continuous Feedback

Vamos a arrancar por “continuous feedback”, ya que es lo que considero más clave en cuanto a la cultura DevOps, cultura de feedback continuo. Si te vas a quedar con una sola idea de esta charla, pensá en que generar una “cultura DevOps” implica generar una “cultura de continuous feedback”, aprender de otros, ya sean de mi área o de las áreas con las que colaboro.
El primer paso que siempre damos al intentar impulsar el cambio cultural, es el de plantear una reunión de retrospectiva. Las famosas RETROs que vienen de la metodología SCRUM (que es uno de los tantos tipos de metodologías ágiles, pero por su fama y adopción hablamos más que nada de esto).

Esta es una ceremonia puntual donde se enfoca a obtener feedback del proceso y de la forma en la que el equipo está trabajando. Esta metodología apunta a tener este tipo de reuniones de manera frecuente, y por eso ayuda a incorporar en nuestra cultura esta idea de dar y recibir feedback.
Nuestra costumbre como testers de buscar oportunidades de mejora y brindar feedback nos hace buenos para “hacerle testing al proceso”. 
Lo que nos ha pasado en la mayoría de los equipos donde planteamos hacer esto, es que al principio se ve como una pérdida de tiempo, y luego no pueden vivir sin tener estas reuniones. Literal. “¿Cómo hacíamos antes?” “¿Cómo trabajaríamos sin hacer estos análisis?”
Gracias a esto se comparten aprendizajes, se experimenta, se innova. Además, todos conocen los problemas, suyos, y de los demás. Fomenta a que haya transparencia, visibilidad e inspección, para poder así adaptar el proceso y mejorar.
La recomendación es comenzar con dinámicas simples (lo que anduvo bien, mal, comenzar, dejar). Luego organizar la discusión, priorizando los temas a conversar. Es fundamental poner foco en el plan de acción, para poder así luego dar seguimiento a las ideas propuestas. Que no quede en una reunion de catarsis y nada más.Luego se pueden variar las dinámicas para hacer las reuniones más entretenidas, y pensar los problemas con una perspectiva diferente.

Acá se pueden conseguir ideas:

• http://tastycupcakes.org/es/category/agile/
• https://es.atlassian.com/team-playbook 
• http://www.funretrospectives.com/

Creo que para apuntar a DevOps, lo importante acá también pasa por a quién invitamos a estas reuniones. Si solo lo hacemos entre los desarrolladores, no estamos muy devops que digamos. Deberíamos invitar también a testers, gerencia, negocio, soporte, infra, etc. Realmente hemos notado una unidad, una conformación de equipo buenísima YA SOLO gracias a esta práctica.
Todos se ponen de acuerdo en qué hacer y qué no, todos se hacen cargo de probar, documentar, mejorar el proceso y uso de herramientas.

Planificación 

Lo primero que tenemos que entender es que al hablar de metodologías ágiles cambia el paradigma de estimación y planificación. En lugar de fijar alcance y estimar el tiempo y presupuesto, acá vamos a fijar tiempo y presupuesto, y vamos a estimar el alcance.

Y la otra es que no temenos todo documentado y establecido de qué es lo que se va a hacer. Como el alcance se va ajustando a medida se avanza, entonces se va detallando qué es lo que se va a implementar a medida se va avanzando.

El tester es fundamental en la definición y refinamiento de los requerimientos. De hecho, la idea es que el tester se involucre desde el mismo momento que el desarrollador, o incluso antes.Y si pensamos en DevOps, no solo el tester, también alguien de infraestructura, de soporte, etc. Cambia drásticamente el resultado si al conversar de cómo se va a implementar algo, también se conversa de cómo se va a probar, de cómo va a operarse, de cómo va a ponerse en producción, y cuál es el feedback o problemas típicos de los usuarios.

Hay otro cambio de paradigma que cambia mucho los resultados, es que al planificar y estimar participa todo el equipo. Entre todos decidimos cuánto cuesta armar algo, y si podemos hacerlo en el sprint o no.Luego, al momento de asignar, cada uno se asigna, asumiendo la responsabilidad por un item en concretoEn cierta forma los managers pierden algo de poder, pero el beneficio es que el equipo se siente más comprometido, ya que no es algo impuesto, sino que es algo que acordamos, entre nosotros.
Aplicando estas cosas realmente se está mejorando en la estimación. El equipo se vuelve más predecible. Se afina la puntería en qué cosas sí se logran hacer en el sprint y qué cosas no.

Construcción ágil

La etapa de construcción en la cultura DevOps está definida por un alto nivel de agilismo, dígase trabajo en equipo, iteraciones cortas y feedback continuo. En esta etapa se envían incrementos de producto al cliente de manera frecuente, por lo que hay que prestar atención a cómo se integran esos incrementos al producto de manera eficiente y a bajo riesgo.Para esto,  se suele apoyar en la automatización, ya sea de pruebas, despliegue, integración continua, etc. pero este no fue el foco de la charla.En algunos clientes en los que hemos estado trabajando hemos detectado elementos que les limita llegar a este punto de agilismo.

Un aspecto bastante común es la especialización en módulos, donde solo un desarrollador es capaz de trabajar en un módulo específico y desconoce detalles de otros módulos. Con esto no hay generosidad en el conocimiento, se torna muy complejo apoyar en el desarrollo de un módulo que no es el “mío” y, por ejemplo, si alguien se va de licencia, el avance en eso se detiene o es muy costoso.

Algo que hemos propuesto para solucionar esto es la programación en pares. Esa persona que es la que mayor peso ha tenido en el desarrollo del módulo se puede decir que es el jugador titular, pero también ahora se cuenta con otro miembro del equipo, jugador suplente, que revisa el código desarrollado, que apoya al compañero a entender la lógica y buscar las mejores prácticas para desarrollar. A su vez cada uno juega en otros módulos los roles opuestos (ya sea titular o suplente). De esta forma se puede prever que siempre haya alguien que domine el módulo para poder solucionar cualquier problema o continuar un desarrollo, limitando la dependencia y responsabilidad de una sola persona por un módulo.
El objetivo es ir vinculando a todos en los distintos módulos, hasta que cada desarrollador pueda apoyar o desarrollar cualquier módulo y abrirnos así a que todos puedan asumir cualquier tarea dentro del sprint backlog, siendo así un equipo más eficiente y ágil.

Esto es algo que el año pasado con Laura Aguiar mencionamos en una charla también en el evento GeneXus.
En particular Laura comentaba que ella venía siguiendo la práctica de pair review, o code review desde hace años, pero no tanto para evitar bugs, sino para compartir conocimiento, que más de una persona conozca cómo están hechas las cosas, y a su vez aprender unos de otros sobre cuáles son las mejores maneras de resolver ciertos problemas.

Otro de los problemas típicos es el de tener pruebas solo como filtro para salir a producción, lo que provoca un efecto cascada dentro del sprint y al tester sobrecargado al final de cada sprint. De esta forma se observa un cuello de botella en el proceso antes de la salida a producción, viéndose al testing (o peor, al tester) como responsable de que no se pueda cumplir con el tiempo para la salida.
Un aspecto fundamental para prevenir esto es el pensar las pruebas antes del desarrollo, o sea, a medida se trabaja en definir los requerimientos (ya sea el Product Owner escribiendo las historias, o en los refinamientos, o en la misma planning) el tester va escribiendo los criterios de aceptación, ideas de prueba, o hasta casos de prueba en sí.También el apoyo en automatización de pruebas y en enfoques de CI/CD son críticos para poder trabajar de la mejor manera. 

Kanban

Independientemente de lo expresado con anterioridad, algo que hemos propuesto, se ha aplicado y ha tenido muy buenos resultados, es seguir los lineamientos planteados por la también metodología ágil Kanban. 
Seguramente de Kanban conozcan este tipo de tableros, donde uno organiza su trabajo en distintas columnas, y así todo el equipo tiene visibilidad de en que se está trabajando.

En un tablero con las columnas que se definan en el proyecto, las tareas o historias irán cambiando de estado. Si un desarrollador se pone a trabajar en desarrollar features, y a medida va terminando las va pasando a la columna “testing” sin importar que ahí se estén acumulando, podemos estar cayendo en ese problema de generar una falsa sensación de progreso. El desarrollador va a pensar que está avanzando, pero en realidad eso no será puesto en producción porque el tester es el cuello de botella. Para peor, el tester será visto como el cuello de botella. ¿Qué puede hacer el equipo para evitar esto?
Lo que plantea la metodología Kanban es limitar el work in progress (WIP). Imaginemos que establecemos el límite en la columna de testing a 3, y ya hay 3 tareas en esa columna, y un desarrollador termina con una tarea “En proceso” no podrá pasarla a testing hasta que se libere un espacio en la columna “en testing”. Para agilizar esta liberación lo natural es que el desarrollador debe ayudar al tester con esas 3 tareas, ya sea ayudando a probar o sirviendo café al tester. Ojo, si va a ayudar con el testing, debería ser sobre las features que no haya desarrollado él mismo.
Otra cosa que se debería hacer en estas situaciones es analizar por qué se le acumulan cosas en la columna de testing. Tal vez luego de analizar con el equipo observan que es porque las features llegan muy verdes a esta etapa. Algo que hicimos para reducir esto en más de un proyecto, fue ponernos de acuerdo que el dev antes de pasar a testing le hacía un test básico (por ejemplo basado en una checklist), y así se redujo los idas y vueltas, y las cosas estaban menos tiempo en testing.
De esta forma todo el equipo es responsable de la calidad y de que las cosas salgan.

CI/CD y Deploys

En DevOps estamos entregando frecuentemente nuevas porciones del producto que necesitan ser integradas correctamente y verificar que todo el software sigue funcionando como se espera, y que eso no sea algo que genere fricción entre desarrollo y operaciones. CI/CD nos ordena cómo poner esos incrementos en producción sin que genere un costo extra.
El año pasado y este dimos charlas que recomendamos que veas.

• Cultura DevOps en GeneXus – Laura Aguiar y Federico Toledo
• GeneXus Continuous Delivery – Fabián Baptista y Federico Toledo
• GXtest 4, Testing en GeneXus IDE – Fernanda Sesto y Fabián Baptista

Las etapas de Deploy (Puesta en producción) y Operaciones completan este lazo que en verdad es infinito, un error es ver y tratar estas etapas como cierre, de hecho el equipo de operaciones debe estar, como las pruebas, desde el comienzo.

El foco de operaciones en un entorno DevOps se mantiene en hacer que las construcciones sucedan de manera más confiable, más frecuente y con alguna atención hacia la buena automatización de despliegues. También pueden jugar un rol en el monitoreo, así como algunos de los aspectos más complejos de la gestión de configuración.
Pero muchas veces hay separaciones físicas, dígase distinto piso, distinta oficina o incluso distinta empresa, encargándose de las operaciones. Esto ya implica una barrera para el buen funcionamiento por lo que una de las principales cosas a lograr es acercar a ambas partes del equipo (y no solo físicamente).
Algunos ejemplos de acciones que logran todo lo contrario es cuando en lugar de colaborar se apunta a contratos incluyendo sanciones y multas por incumplimientos.

Cerrando

Se mejoró notoriamente la calidad de las puestas en producción, el estrés se redujo, el riesgo se controla mejor. Ojo con la responsabilidad de errores en producción. Es difícil cambiar la cabeza de quién es responsable (siempre las culpas de errores en producción son asignadas a testing). En un cliente en particular, donde estamos impulsando todo esto, desde que se agregaron actividades de testing en el proceso como parte del Definition of Done, se logró por primera vez que una puesta en producción no tenga ninguna llamada de quejas de usuarios. Antes estaban acostumbrados a que cada puesta en producción venía seguida de una semana de correcciones en base a lo que los usuarios reporten.
Claramente esto no es algo que se logre cambiar de un día para otro, pero los resultados valen la pena. No solo por tener una cultura más ágil, que eso está de moda, sino porque se armaron mejores grupos de trabajo, más colaborativos, apuntando a la mejora continua, lo cual trae mejores resultados y un equipo más motivado y unido. 
Así veremos que el testing no solo nos impulsa a llegar más lejos, sino que también nos puede ayudar a despegar y llegar a lugares que no habíamos imaginado.