El testing como impulsor del cambio hacia una cultura DevOps
•Download as PPTX, PDF•
0 likes•595 views
Como me gusta tanto lo que estamos logrando, y creo que está al alcance de todos, es que me encuentro motivado a compartirlo para ver si alguien más puede aprovechar esta experiencia, tomar ideas y ponerlas en ejecución. Todo el mundo habla de equipos de trabajo ágiles, cultura DevOps, scrum, kanban y mucho más. Si estudiamos sus beneficios, creo que está claro que todos queremos ir para ahí. Trabajar mejor, más felices y con mejores resultados. El tema es, ¿por dónde empezar? ¿Cómo impulsar esos cambios? En esta charla quiero compartir una experiencia donde en un lapso de 8 meses (hasta ahora) hemos venido trabajando con un equipo que utiliza tecnología GeneXus, realizando determinados cambios, de manera controlada y pasito a pasito, obteniendo grandes resultados en estos aspectos tan soñados. https://meetings.genexus.com/session/el-testing-como-impulsor-del-cambio-hacia-una-cultura-devops/ESP
Recommended
More Related Content
What's hot
What's hot (20)
Similar to El testing como impulsor del cambio hacia una cultura DevOps
Similar to El testing como impulsor del cambio hacia una cultura DevOps (20)
More from Federico Toledo
More from Federico Toledo (20)
Recently uploaded
Recently uploaded (20)
El testing como impulsor del cambio hacia una cultura DevOps
- 1. El testing como impulsor del cambio hacia una cultura DevOps Federico Toledo federico@abstracta.us Arcadio Abad arcadio@abstracta.us
- 4. DevOps, originalmente “Agile Operations” Agile DevOps
- 6. ¿De qué NO vamos a hablar?
- 12. Ejemplos • http://tastycupcakes.org/es/category/agile/ • https://es.atlassian.com/team-playbook • http://www.funretrospectives.com/ Luego variar
- 13. Importante: ¿cómo formular preguntas? http://www.onpurposeconsulting.ca
- 14. También hablar de sentimientos
- 18. ¿Se planifica en agile?
- 20. Asignación
- 24. Construcción agile: iteraciones cortas
- 27. Pair Programming / Code Review
- 29. Waterfall en Sprints Code Test Sprint Water-Scrum-fall
- 32. ¿Cómo estar en sintonía? • ¿En qué estuve? • ¿Qué me bloquea? • ¿Qué voy a hacer hoy? • ¿Cómo hacemos entre todos para cumplir el objetivo del sprint?
- 35. • GX27 (2017) • GeneXus Continuous Delivery • Fabián Baptista y Federico Toledo • DevOps y GeneXus • Laura Aguiar y Federico Toledo • GX28 (2018) • GXtest 4, Testing en GeneXus IDE • Fernanda Sesto y Fabián Baptista • Performance en Integración Continua • Federico Toledo • Laboratorio de GXtest 4 • Equipo de Abstracta
- 42. El testing como impulsor del cambio hacia una cultura DevOps Federico Toledo federico@abstracta.us Arcadio Abad arcadio@abstracta.us ¡¡GRACIAS!!
Editor's Notes
- Buenas a todos. Mi nombre es Federico, estoy junto a Arcadio, ambos formamos parte del equipo de Abstracta, donde trabajamos dando servicios de testing y calidad de software. 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 queremos compartirles algunos de estos aprendizajes, pensando en que puedan aprovecharlas ustedes también. Tenemos el convencimiento que los equipos con cultura devops trabajan mejor, obtienen mejores resultados y son más felices.
- Empecemos hablando de que es devops Básicamente es una cultura de trabajo en equipo, donde se intenta romper las barreras que tradicionalmente existieron entre los equipos de desarrollo y operaciones, buscando romper esos conflictos de intereses que aparentemente tenían. Y a lo que se apunta es a este ciclo infinito, en donde lo que lo caracteriza es el feedback continuo. 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 https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/
- ya que como pueden ver acá, debería haber testing en cada una de las etapas. 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. El testing es algo 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 nace como “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, pero no solo en desarrollo Muchas de las cosas que vamos a ver en esta charla son para adoptar agile, que es la base para luego adoptar devops
- Agradecimiento
- Si bien toda charla de Devops habla de CI/CD y de herramientas y automatización, nosotros nos vamos a concentrar en aspectos más de la cultura y valores
- y si algo resume lo que significa devops es esta imagen, similar a la ilustración inicial acá tenemos ese concepto de loop infinito, con distintas etapas, una alimentando la otra, todo rodeado de real-time communication lo que vamos a hacer en la charla es ir compartiendo nuestros aprendizajes de cómo desde el testing pudimos aportar en cada una de estas etapas que se ven en la imagen
- vamos a arrancar por acá, por “continuous feedback”, ya que como ya lo mencioné es lo que considero más clave en cuanto a la cultura devops, cultura de feedback continuo. Si se van a quedar con una sola idea de esta charla, piensen 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 primero 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 vamos a hablar 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? Luego, a partir de las dificultades y oportunidades de mejora que se van detectando, se fueron adoptando otras prácticas: planificación, la gestión de un backlog, pruebas de usabilidad, y stand-up daily meetings. Gracias a esto se comparten aprendizajes, se experimenta, se innova. Además, todos conocen los problemas, suyos, y de los demás. de otra forma no hay transparencia, visibilidad, inspección, etc.
- La recomendación es comenzar con dinámicas simples (lo que anduvo bien, mal, comenzar, dejar) Organizar discusión, priorizar Foco en plan de acción, dar seguimiento Que no quede en una reunion de catarsis y nada más
- Es lo mismo pero con distinto foco, distinta perspectiva, entonces las propuestas y los resultados se renuevan
- Y para que todo esto sea efectivo, algo Importantísimo es la forma en la que se hacen las preguntas: No es lo mismo preguntar “quién está de acuerdo? O estamos todos de acuerdo?” para un determinado plan de acción, A preguntar “alguien no está de acuerdo?”, porque ese alguien va a ser interrogado y se le van a pedir argumentos de por qué no quiere seguir adelante con determinado plan de acción La forma de hacer preguntas puede frenar o impulsar Los testers por lo general hacemos tantas preguntas en nuestro trabajo, que estamos entrenados
- En estas reuniones también está bueno hablar de sentimientos, de nuestra motivación y del relacionamiento con los otros, y así ver cómo eso va evolucionando. Por ejemplo: Dinámica del termómetro, del velocímetro para medir motivación. Dinámica del velocímetro para medir sensación de qué tan rápido vamos.
- 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 que hacer y que no, todos se hacen cargo de probar, documentar, mejorar el proceso y uso de herramientas.
- 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 alacnce 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 invlucre desde el mismo momento que el dev, 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.
- Y luego 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 concreto En 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
- Feedback continuo en la construcción. Integración continua de nuevos incrementos. Se suele apoyar en la automatización 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 es el foco de la charla. Estaremos comentando algunos aspectos que desde nuestra posición de tester hemos visto pueden mejorarse para hacer la etapa de construcción más ágil y eficiente, acercando a los equipos a un mayor nivel de agilismo y con esto a la cultura Devops. 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 o puede ser que nuestras vacaciones terminen siendo así (Imágenes)
- Algo que hemos propuesto para solucionar esto es la programación en pares, hoy existe esa persona que es la que mayor peso ha tenido en el desarrollo del módulo se puede decir que 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, seamos un equipo más eficiente y ágil. Esto es algo que Fede y Laura Aguiar mencionaron en una charla el año pasado, y 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.
- Pruebas sólo como filtro para salir a producción. Cascada dentro de un sprint. Tester sobrecargado al final de cada sprint. Responsabilidad de la calidad. Otros problema típico es el de tener pruebas solo como filtro para salir a producción lo que provoca un efecto cascada dentro del sprint y altester sobrecargado al final de cada sprint. Para esto en el desarrollo de nuestros clientes se fomentó el uso de las pruebas unitarias, se incorporaron distintos tipos de pruebas, incluyendo pruebas de usabilidad. Continuous Integration y Automation. En el desarrollo con Genexus se automatizó con GXtest y ya en algunos hemos incluido la automatización con GXtest 4 que incluye pruebas unitarias y de UI desde el propio marco de trabajo de GX tero. . Otro aspecto fundamental es el pensar las pruebas antes del desarrollo, o sea, a medida se trabaja en definir los requerimientos (ya sea el PO 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í. Responsabilidad ante las pruebas: Problema típico es el 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. Para evitar esto, independientemente de lo explicado anteriormente, algo que se puede hacer es seguir los lineamientos planteados en otra metodología ágil llamada Kanban
- Para evitar esto en nuestros clientes se fomentó el uso de pruebas unitarias, además se incluyeron otros tipos de pruebas como de usabilidad, integración y automatizadas, esta última con el apoyo de GXtest que permite la automatización de pruebas unitarias y de UI desde el propio IDE de GX. Otro aspecto importante es el pensar en las pruebas antes de desarrollar, incluso desde que se definen los requerimientos, ya sea por el product owner escribiendo historias de usuarios o en los refinamientos o en el propio planning, ya el tester puede ir escribiendo los criterios de aceptación, ideas de pruebas y hasta casos de pruebas en sí. Así reforzamos la responsabilidad de la calidad en todo el equipo y no solo en el tester. 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 (Diapo 8)
- 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. Que puede hacer el equipo para evitar esto? Lo que plantea la metodología Kanban es limitar el work in progress (wip). Imaginemos como dice la imagen 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 ej 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. Se hicieron capacitaciones, en temas de scrum, testing, usabilidad, aspectos de negocio, de configuraciones del software, entre otras a todo el equipo. Uno de los objetivos de estas capacitaciones fue generar T-shaped skills (“Nadie ignora todo, nadie sabe todo, por eso aprendemos siempre.” Paulo Freire). Como ya mencionamos la inserción de un equipo en metodologías ágiles debe ser de manera progresiva y la capacitación del equipo y la adaptación de los procesos juega un papel primordial.
- La inserción en las metodologías ágiles implica adoptar buenas prácticas como por ejemplo el Status compartido de cada tarea, esto puede aplicarse en reuniones del equipo como en las daily stand up o similares según la metodología, no viendo en qué estuvo y estará cada uno (parece un reporte a un jefe) sino ver cada historia analizando qué falta para terminar y cómo cada cual puede aportar para terminarla. Así generamos ese Sentimiento de empujar entre todos para cumplir el objetivo del sprint.
- 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. CI/CD nos ordena cómo poner esos incrementos en producción sin que genere un costo extra. el año pasado dimos charlas de esto específicamente. también ver charla de GXtest, para agregar automatismos y lab de gxtest
- 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 rol 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 devops por lo que una de las principales cosas a lograr es acercar y no solo físicamente a ambas partes del equipo 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.
- El estrés se redujo, el riesgo se controla mejor. Aumentó la confianza del equipo para salir a producción con calidad. Puesta en producción sin llamada de quejas de usuarios. 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. Culpas a testing. Desde que se impuso 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 prod venía seguida de una semana de correcciones en base a lo que los usuarios reporten.
- no se logra cambiar de un día para otro pero los resultados valen la pena cultura ágil, incluyendo devs, líderes, operaciones, soporte, etc. (img Katrina) equipo más unido, más motivado, con mejores resultados
- 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