Lecciones aprendidas al ayudar a las organizaciones a fomentar una cultura DevOps, a través de las prácticas de testing ágil.

En Abstracta trabajamos con muchas empresas, varias de las cuales ya tienen una cultura DevOps y otras a las que hemos ayudado a definirla y promoverla. A lo largo de los años, hemos visto cómo DevOps ha ganado popularidad, y la mayoría de los equipos están en camino de lograrlo. En este post, compartiré algunas lecciones de nuestras experiencias al ayudar a las empresas con sus transformaciones ágiles.

Por lo que hemos visto, estamos convencidos de que los equipos con una cultura DevOps funcionan mejor, obtienen mejores resultados y son, simplemente … más felices.

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

Como puede ver… ¡estamos en todas partes!

En DevOps, las pruebas deben realizarse en cada una de las etapas del proceso de desarrollo. DevOps propone (así como muchas metodologías ágiles) que las pruebas NO son algo que solo se hace al final, sino que se realiza de forma continua, asociado a cada tarea.

Por lo tanto, tenga en cuenta que en esta publicación, todas las formas que señalamos son necesarias para adoptar una cultura DevOps también son parte de la adopción de una cultura ágil.

Feedback continuo

Comencemos con el “feedback continuo” ya que generar una cultura DevOps implica generar una “cultura de feedback continuo”, en la que todos aprenden de los demás en su propio equipo, así como de los equipos con los que colaboran.

El primer paso que siempre sugerimos dar a la hora de promover este cambio cultural dentro de una organización es realizar reuniones retrospectivas . Sí, las famosos RETROs que provienen de la metodología Scrum. Es una ceremonia en la que la atención se centra en obtener comentarios sobre el proceso y la forma en que está trabajando el equipo. En Scrum, estas reuniones se llevan a cabo con frecuencia, y es por eso que ayuda a implementar la práctica de dar y recibir retroalimentación.

Los testers, naturalmente, tienden a buscar oportunidades de mejora y a proporcionar comentarios, lo que nos hace aptos para “probar el proceso”.

A menudo, los equipos descartan la idea de realizar retrospectivas como una pérdida de tiempo, inicialmente. Pero, después de realizarlas de verdad, no pueden imaginarse no tenerlas. A menudo escuchamos: “¿Cómo manejábamos nuestro trabajo antes? ¿Cómo no podríamos hacer este tipo de análisis? “

Gracias al feedback continuo mediante la celebración de retrospectivas, los aprendizajes se comparten y el equipo tiene un espacio para experimentar e innovar. Además, todos son conscientes de los problemas que se han tenido, fomentando la transparencia, la visibilidad y la inspección, con el fin de adaptar el proceso y mejorarlo.

Lo mejor es comenzar con la realización de dinámicas de grupo simples (qué salió bien o mal, qué empezar y qué dejar de hacer). Luego organizar la discusión, priorizando los temas a discutir. Es fundamental centrarse en un plan de acción para que el equipo pueda dar seguimiento a las ideas propuestas. A medida que pasa el tiempo, puede probar diferentes dinámicas para darle vida a los retrospectivas y hacerlas más entretenidas, y pensar los problemas desde una perspectiva diferente.

Para apuntar hacia una cultura DevOps, también es importante es considerar quién asiste a estas reuniones. Si solo se llevan a cabo entre los desarrolladores, entonces no es realmente una cultura DevOps. Debe estar representado al menos alguien del área de testing, gerencial, de negocios, de soporte e infraestructura. En nuestras experiencia, sólo al incluir a todos hemos visto una verdadera unidad dentro del equipo y se ha producido un fuerte cambio de cultura.

Planificación

Lo primero que tenemos que entender es que cuando se habla de metodologías ágiles, cambia el paradigma de estimación y planificación. En lugar de fijar el alcance y estimar el tiempo y el presupuesto, establecemos el tiempo y el presupuesto, y estimamos el alcance.

Como no hay un alcance fijo, el equipo no tendrá todo documentado ni establecerá por completo lo que se logrará, definitivamente. El equipo verá qué se puede entregar y entrará en más detalles a medida que avanza el desarrollo.

Los testers son fundamentales en la definición y refinamiento de los requisitos del software. De hecho, la idea es que el tester esté involucrado comenzando al mismo tiempo que el desarrollador, o incluso antes. En DevOps, no solo el tester debe estar involucrado desde el principio, sino también alguien de la infraestructura, soporte, etc. Esto cambia drásticamente los resultados, ya que cuando se debate sobre lo que se va a implementar, el equipo también considera cómo se implementará: ser probado, operado, puesto en producción, cuál es la retroalimentación anticipada de los usuarios, etc.

Existe otro cambio de paradigma que impacta mucho en los resultados: al planificar y estimar participa todo el equipo. Entre todos se decide qué tan complejo es construir algo y si es posible hacerlo en el sprint o no. Luego, a la hora de asignar tareas, todos se asignan algo, asumiendo la responsabilidad de ello. En cierto modo, los gerentes pierden algo de poder, pero el beneficio es que el equipo está más comprometido ya que el trabajo no es algo que se les impone, sino algo que se acuerda entre todos.

Cuando se producen estos cambios, el equipo se vuelve más predecible. Su capacidad para apuntar a un objetivo mejora y se afina su capacidad para estimar lo que se puede hacer en un cierto período de tiempo.

Construcción ágil

La etapa de construcción en la cultura DevOps se define por un alto nivel de agilidad, trabajo en equipo (según su definición más real), iteraciones breves y retroalimentación continua. En esta etapa, los incrementos de productos se envían al cliente de manera frecuente, por lo que es importante prestar atención a cómo se integran de manera eficiente con bajo riesgo. Aquí es cuando entra en juego la automatización, ya sea en las pruebas, el despliegue o la integración continua, etc. Para algunos clientes con los que hemos trabajado, este es el punto en el que hemos encontrado algunas barreras que les impiden alcanzar este punto de agilidad.

Una de estas barreras ocurre comúnmente cuando hay especialización en los módulos, donde solo un desarrollador puede trabajar en un módulo específico y desconoce los detalles del resto. No hay intercambio de conocimientos, y se vuelve muy complejo apoyar el desarrollo de un módulo cuando alguien se ausenta o por alguna razón no puede seguir trabajando, por lo que el progreso se detiene o se vuelve muy costoso.

Programación en pareja

Para combatir este problema, hemos sugerido a nuestros clientes que incorporen la programación en pareja. Se puede decir que la persona que tiene la mayor responsabilidad en el desarrollo de un módulo es el “jugador titular”, pero ahora también tendrá otro miembro del equipo, un “jugador suplente”, que revisa el código desarrollado y lo ayuda a comprender el lógica y busca las mejores prácticas. Al mismo tiempo, cada uno juega el papel contrario en otros módulos (ya sea el jugador titular o el suplente). Esta práctica ayuda a asegurar que siempre habrá alguien que pueda asumir la responsabilidad de un módulo, limitando la dependencia de una sola persona para solucionar cualquier problema o continuar con el desarrollo.

El objetivo es vincular a todos en los diferentes módulos a lo largo del tiempo, hasta que cada desarrollador pueda respaldar o desarrollar uno determinado y abrirlo para que todos puedan asumir cualquier tarea dentro del backlog del sprint, haciendo así que el equipo sea más ágil.

Pruebe anticipadamente

Otro problema típico es tener pruebas que actúan solo como un filtro antes de entrar en producción, lo que provoca un efecto en cascada dentro del sprint y un tester sobrecargado al final. Se produce un cuello de botella en el proceso antes de que continúe la producción y las pruebas (o peor aún, el tester) no pueden terminar a tiempo.

Un aspecto fundamental para prevenir esto es pensar en las pruebas antes del desarrollo, es decir, a medida que se van definiendo los requisitos, el tester empieza a escribir los criterios de aceptación, las ideas de prueba, o incluso los casos de prueba ellos mismos. Además, el soporte de las pruebas en la automatización de pruebas y en los enfoques de CI/CD es fundamental para trabajar de la mejor manera.

Kanban

Aparte de las áreas anteriores que hemos cubierto hasta ahora, algo que hemos visto de cerca que proporciona excelentes resultados es seguir otra metodología ágil: Kanban.

Es posible que ya esté familiarizado con el uso de tableros de Kanban, donde las personas organizan su trabajo en diferentes columnas y, por lo tanto, todo el equipo tiene visibilidad de quién está trabajando en qué.

En un tablero con columnas que se definen para un determinado proyecto, las tareas o historias pasarán por las columnas, cambiando de estado. Si un desarrollador comienza a trabajar en el desarrollo de funciones y, a medida que terminan, las pasa a la columna de “pruebas”, independientemente de si ya hay varias acumuladas allí, puede surgir una falsa sensación de progreso. El desarrollador pensará que está progresando, pero en realidad, su trabajo no se pondrá en producción de inmediato porque las pruebas son el cuello de botella. O peor aún, el probador será visto como el cuello de botella (¡de nuevo!). ¿Qué puede hacer un equipo para evitar esto?

Lo que propone la metodología Kanban es limitar el trabajo en curso (WIP). Imagine que un equipo establece el límite en la columna de prueba en tres, y ya hay tres tareas en esa columna. La tarea del desarrollador permanecerá “En progreso” y no podrá avanzar hasta que haya un espacio disponible en la columna “En prueba”. Para acelerar este lanzamiento, la solución natural será que el desarrollador ayude al probador con las otras tres tareas, ya sea ayudando a probar o preparando un poco de café al probador.

Otra cosa que se debe hacer en estas situaciones es analizar la razón por la cual las tareas se acumulan en la columna de prueba. Quizás después de hacer un análisis, el equipo se da cuenta de que las características que llegan a esta etapa todavía son muy “verdes”. Algo que hemos hecho para ayudar con esto (en más de un proyecto) fue hacer que los desarrolladores y evaluadores estuvieran de acuerdo en que los desarrolladores harían algunas pruebas básicas primero (por ejemplo, basadas en una lista de verificación). Esto lleva a que las tareas se pasen de un lado a otro entre las pruebas y el desarrollo con menos frecuencia, y el tiempo que las tareas pasan en la columna “En prueba” se reduce.  

De esta forma, todo el equipo es responsable de la calidad y de que las cosas se publiquen a tiempo. La misma idea podría aplicarse a diferentes columnas, y si somos DevOps, tal vez también gestionemos este tablero Kanban con una columna “Para implementar”. Los mejores resultados se obtienen cuando hay colaboración en este nivel, con todo el equipo (desarrolladores, evaluadores, personal de operaciones) trabajando juntos para considerar algo terminado cuando se implementa.

CI/CD e implementaciones

En DevOps, con frecuencia ofrecemos nuevos incrementos que deben integrarse correctamente y deben verificar que todos los aspectos del software continúen funcionando como se espera. Se espera que todo esto ocurra mientras se asegura que no se genere fricción entre el desarrollo y las operaciones. CI / CD nos dice cómo poner esos incrementos en producción sin inflar el costo.

Las etapas de Implementación (puesta en producción) y Operaciones completan este ciclo que es verdaderamente infinito. Sería un error considerar y tratar cualquiera de estas etapas como definitiva. En realidad, el equipo de operaciones debe estar, como equipo de prueba, presente desde el principio.

El enfoque de las operaciones en un entorno de DevOps se mantiene haciendo que las compilaciones se realicen de manera más confiable, con más frecuencia y prestando cierta atención a una buena automatización de las implementaciones. Las operaciones también pueden desempeñar un papel en la supervisión, así como algunos de los aspectos más complejos de la gestión de la configuración.

Pero muchas veces hay separación física como diferentes pisos, diferentes oficinas o incluso diferentes empresas que se encargan de las operaciones. Esto ya implica una barrera para el buen funcionamiento, por lo que una de las principales cosas a conseguir es la incorporación de ambas partes al equipo (y no solo físicamente).

DevOps para un software de mayor calidad

Cuando el testing ayuda a impulsar el cambio hacia una Cultura DevOps, la calidad de las puestas en producción mejora notablemente, se reduce el estrés y se controla mejor el riesgo.

En un caso en el que ayudamos a una empresa a cambiar a DevOps 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 causara ninguna queja entre los usuarios. Antes de tener una cultura DevOps, el equipo estaba acostumbrado a planificar una semana más entre sprints, después de cada puesta a producción, para hacer correcciones basadas en las quejas que los usuarios reportaran.

Claramente, esto no es algo que se pueda cambiar de un día para otro, pero los resultados lo valen. No solo para tener una cultura más ágil, que está de moda, sino porque se pueden crear mejores grupos de trabajo que sean más colaborativos y mejoren continuamente, generando naturalmente mejores resultados.

Espero que después de leer esta publicación, pueda ver más claramente la posibilidad de impulsar no solo a los equipos para ir más allá, sino también ayudarlos a despegar y llegar a lugares que nunca habían imaginado.

8 errores que cometen las empresas al realizar la transición a CI/CD

En este White Paper desarrollado en conjunto con Testim, abordamos los 8 errores comunes que cometen los equipos, y brindamos algunos consejos para una transición exitosa a CI/CD; descárguelo sin costo y acceda a:

• Buenas prácticas en integración continua y Entrega Continua (CI/CD) para lograr ciclos de lanzamiento más rápidos y software de mayor calidad.
• Una guía para comprender el cambio técnico y cultural y crear un impacto duradero.
• Crear una transición de CI/CD sin problemas, a través de la cultura del equipo, los procesos y el establecimiento de expectativas.

Otros contenidos relacionados

Shift Left Testing: Qué, cómo y por qué considerar este enfoque

Cómo Shift Left Testing puede impulsar la adopción de DevOps

Testing Ágil para crear productos digitales de alta Calidad