![\"Continuous](\"https:\/\/cl.abstracta.us\/wp-content\/uploads\/2021\/07\/dan-ashby-devops-1024x624.jpg\")
Esta ilustraci\u00f3n de Dan Ashby<\/a> es excelente para ilustrar el concepto, y a su vez para ver c\u00f3mo participa el tester de todo esto.<\/p>\n\n\n\n Como puede ver\u2026 \u00a1estamos en todas partes!<\/p>\n\n\n\n En DevOps, las pruebas deben realizarse en cada una de las etapas del proceso de desarrollo. <\/strong>DevOps propone (as\u00ed como muchas metodolog\u00edas \u00e1giles) que las pruebas NO son algo que solo se hace al final, sino que se realiza de forma continua, asociado a cada tarea.<\/p>\n\n\n\n Por lo tanto, tenga en cuenta que en esta publicaci\u00f3n, todas las formas que se\u00f1alamos son necesarias para adoptar una cultura DevOps tambi\u00e9n son parte de la adopci\u00f3n de una cultura \u00e1gil.<\/p>\n\n\n\n Comencemos con el \u201cfeedback continuo\u201d ya que generar una cultura DevOps implica generar una \u201ccultura de feedback continuo\u201d, en la que todos aprenden de los dem\u00e1s en su propio equipo, as\u00ed como de los equipos con los que colaboran.<\/p>\n\n\n\n El primer paso que siempre sugerimos dar a la hora de promover este cambio cultural dentro de una organizaci\u00f3n es realizar reuniones retrospectivas<\/a> . S\u00ed, las famosos RETROs que provienen de la metodolog\u00eda Scrum. Es una ceremonia en la que la atenci\u00f3n se centra en obtener comentarios sobre el proceso y la forma en que est\u00e1 trabajando el equipo. En Scrum, estas reuniones se llevan a cabo con frecuencia, y es por eso que ayuda a implementar la pr\u00e1ctica de dar y recibir retroalimentaci\u00f3n.<\/p>\n\n\n\n Los testers, naturalmente, tienden a buscar oportunidades de mejora y a proporcionar comentarios, lo que nos hace aptos para “probar el proceso”.<\/p>\n\n\n\n A menudo, los equipos descartan la idea de realizar retrospectivas como una p\u00e9rdida de tiempo, inicialmente. Pero, despu\u00e9s de realizarlas de verdad, no pueden imaginarse no tenerlas. A menudo escuchamos: \u201c\u00bfC\u00f3mo manej\u00e1bamos nuestro trabajo antes? \u00bfC\u00f3mo no podr\u00edamos hacer este tipo de an\u00e1lisis? “<\/p>\n\n\n\n Gracias al feedback continuo mediante la celebraci\u00f3n de retrospectivas, los aprendizajes se comparten y el equipo tiene un espacio para experimentar e innovar. Adem\u00e1s, todos son conscientes de los problemas que se han tenido, fomentando la transparencia, la visibilidad y la inspecci\u00f3n, con el fin de adaptar el proceso y mejorarlo.<\/p>\n\n\n\n Lo mejor es comenzar con la realizaci\u00f3n de din\u00e1micas de grupo simples (qu\u00e9 sali\u00f3 bien o mal, qu\u00e9 empezar y qu\u00e9 dejar de hacer). Luego organizar la discusi\u00f3n, priorizando los temas a discutir. Es fundamental centrarse en un plan de acci\u00f3n para que el equipo pueda dar seguimiento a las ideas propuestas. A medida que pasa el tiempo, puede probar diferentes din\u00e1micas<\/a> para darle vida a los retrospectivas y hacerlas m\u00e1s entretenidas, y pensar los problemas desde una perspectiva diferente.<\/p>\n\n\n\n Para apuntar hacia una cultura DevOps, tambi\u00e9n es importante es considerar qui\u00e9n 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 \u00e1rea de testing, gerencial, de negocios, de soporte e infraestructura. En nuestras experiencia, s\u00f3lo al incluir a todos hemos visto una verdadera unidad dentro del equipo y se ha producido un fuerte cambio de cultura.<\/p>\n\n\n\n Lo primero que tenemos que entender es que cuando se habla de metodolog\u00edas \u00e1giles, cambia el paradigma de estimaci\u00f3n y planificaci\u00f3n. En lugar de fijar el alcance y estimar el tiempo y el presupuesto, establecemos el tiempo y el presupuesto, y estimamos el alcance.<\/p>\n\n\n\n Como no hay un alcance fijo, el equipo no tendr\u00e1 todo documentado ni establecer\u00e1 por completo lo que se lograr\u00e1, definitivamente. El equipo ver\u00e1 qu\u00e9 se puede entregar y entrar\u00e1 en m\u00e1s detalles a medida que avanza el desarrollo.<\/p>\n\n\n\n Los testers son fundamentales en la definici\u00f3n y refinamiento de los requisitos del software. De hecho, la idea es que el tester est\u00e9 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\u00e9n alguien de la infraestructura, soporte, etc. Esto cambia dr\u00e1sticamente los resultados, ya que cuando se debate sobre lo que se va a implementar, el equipo tambi\u00e9n considera c\u00f3mo se implementar\u00e1: ser probado, operado, puesto en producci\u00f3n, cu\u00e1l es la retroalimentaci\u00f3n anticipada de los usuarios, etc.<\/p>\n\n\n\n Existe otro cambio de paradigma que impacta mucho en los resultados: al planificar y estimar participa todo el equipo. Entre todos se decide qu\u00e9 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\u00e1 m\u00e1s comprometido ya que el trabajo no es algo que se les impone, sino algo que se acuerda entre todos.<\/p>\n\n\n\n Cuando se producen estos cambios, el equipo se vuelve m\u00e1s 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\u00edodo de tiempo.<\/p>\n\n\n\n La etapa de construcci\u00f3n en la cultura DevOps se define por un alto nivel de agilidad, trabajo en equipo (seg\u00fan su definici\u00f3n m\u00e1s real), iteraciones breves y retroalimentaci\u00f3n continua<\/strong>. En esta etapa, los incrementos de productos se env\u00edan al cliente de manera frecuente, por lo que es importante prestar atenci\u00f3n a c\u00f3mo se integran de manera eficiente con bajo riesgo. Aqu\u00ed es cuando entra en juego la automatizaci\u00f3n, ya sea en las pruebas, el despliegue o la integraci\u00f3n 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.<\/p>\n\n\n\n Una de estas barreras ocurre com\u00fanmente cuando hay especializaci\u00f3n en los m\u00f3dulos, donde solo un desarrollador puede trabajar en un m\u00f3dulo espec\u00edfico y desconoce los detalles del resto. No hay intercambio de conocimientos, y se vuelve muy complejo apoyar el desarrollo de un m\u00f3dulo cuando alguien se ausenta o por alguna raz\u00f3n no puede seguir trabajando, por lo que el progreso se detiene o se vuelve muy costoso.<\/p>\n\n\n\n Para combatir este problema, hemos sugerido a nuestros clientes que incorporen la programaci\u00f3n en pareja<\/a>. Se puede decir que la persona que tiene la mayor responsabilidad en el desarrollo de un m\u00f3dulo es el “jugador titular”, pero ahora tambi\u00e9n tendr\u00e1 otro miembro del equipo, un “jugador suplente”, que revisa el c\u00f3digo desarrollado y lo ayuda a comprender el l\u00f3gica y busca las mejores pr\u00e1cticas. Al mismo tiempo, cada uno juega el papel contrario en otros m\u00f3dulos (ya sea el jugador titular o el suplente). Esta pr\u00e1ctica ayuda a asegurar que siempre habr\u00e1 alguien que pueda asumir la responsabilidad de un m\u00f3dulo, limitando la dependencia de una sola persona para solucionar cualquier problema o continuar con el desarrollo.<\/p>\n\n\n\n El objetivo es vincular a todos en los diferentes m\u00f3dulos 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\u00ed que el equipo sea m\u00e1s \u00e1gil.<\/p>\n\n\n\n Otro problema t\u00edpico es tener pruebas que act\u00faan solo como un filtro antes de entrar en producci\u00f3n, 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\u00fae la producci\u00f3n y las pruebas (o peor a\u00fan, el tester) no pueden terminar a tiempo.<\/p>\n\n\n\n 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\u00f3n, las ideas de prueba, o incluso los casos de prueba ellos mismos. Adem\u00e1s, el soporte de las pruebas en la automatizaci\u00f3n de pruebas y en los enfoques de CI\/CD es fundamental para trabajar de la mejor manera.<\/p>\n\n\n\n Aparte de las \u00e1reas anteriores que hemos cubierto hasta ahora, algo que hemos visto de cerca que proporciona excelentes resultados es seguir otra metodolog\u00eda \u00e1gil: Kanban<\/a>.<\/p>\n\n\n\n Es posible que ya est\u00e9 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\u00e9n est\u00e1 trabajando en qu\u00e9.<\/p>\n\n\n\n En un tablero con columnas que se definen para un determinado proyecto, las tareas o historias pasar\u00e1n 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\u00ed, puede surgir una falsa sensaci\u00f3n de progreso. El desarrollador pensar\u00e1 que est\u00e1 progresando, pero en realidad, su trabajo no se pondr\u00e1 en producci\u00f3n de inmediato porque las pruebas son el cuello de botella. O peor a\u00fan, el probador ser\u00e1 visto como el cuello de botella (\u00a1de nuevo!). \u00bfQu\u00e9 puede hacer un equipo para evitar esto?<\/p>\n\n\n\n Lo que propone la metodolog\u00eda Kanban es limitar el trabajo en curso (WIP). Imagine que un equipo establece el l\u00edmite en la columna de prueba en tres, y ya hay tres tareas en esa columna. La tarea del desarrollador permanecer\u00e1 “En progreso” y no podr\u00e1 avanzar hasta que haya un espacio disponible en la columna “En prueba”. Para acelerar este lanzamiento, la soluci\u00f3n natural ser\u00e1 que el desarrollador ayude al probador con las otras tres tareas, ya sea ayudando a probar o preparando un poco de caf\u00e9 al probador.<\/p>\n\n\n\n Otra cosa que se debe hacer en estas situaciones es analizar la raz\u00f3n por la cual las tareas se acumulan en la columna de prueba. Quiz\u00e1s despu\u00e9s de hacer un an\u00e1lisis, el equipo se da cuenta de que las caracter\u00edsticas que llegan a esta etapa todav\u00eda son muy “verdes”. Algo que hemos hecho para ayudar con esto (en m\u00e1s de un proyecto) fue hacer que los desarrolladores y evaluadores estuvieran de acuerdo en que los desarrolladores har\u00edan algunas pruebas b\u00e1sicas primero (por ejemplo, basadas en una lista de verificaci\u00f3n). 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. <\/p>\n\n\n\n De esta forma, todo el equipo es responsable de la calidad y de que las cosas se publiquen a tiempo. La misma idea podr\u00eda aplicarse a diferentes columnas, y si somos DevOps, tal vez tambi\u00e9n gestionemos este tablero Kanban con una columna “Para implementar”. Los mejores resultados se obtienen cuando hay colaboraci\u00f3n en este nivel, con todo el equipo (desarrolladores, evaluadores, personal de operaciones) trabajando juntos para considerar algo terminado cuando se implementa.<\/p>\n\n\n\n En DevOps, con frecuencia ofrecemos nuevos incrementos que deben integrarse correctamente y deben verificar que todos los aspectos del software contin\u00faen funcionando como se espera. Se espera que todo esto ocurra mientras se asegura que no se genere fricci\u00f3n entre el desarrollo y las operaciones. CI \/ CD nos dice c\u00f3mo poner esos incrementos en producci\u00f3n sin inflar el costo.<\/p>\n\n\n\n Las etapas de Implementaci\u00f3n (puesta en producci\u00f3n) y Operaciones completan este ciclo que es verdaderamente infinito. Ser\u00eda 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.<\/p>\n\n\n\n El enfoque de las operaciones en un entorno de DevOps se mantiene haciendo que las compilaciones se realicen de manera m\u00e1s confiable, con m\u00e1s frecuencia y prestando cierta atenci\u00f3n a una buena automatizaci\u00f3n de las implementaciones. Las operaciones tambi\u00e9n pueden desempe\u00f1ar un papel en la supervisi\u00f3n, as\u00ed como algunos de los aspectos m\u00e1s complejos de la gesti\u00f3n de la configuraci\u00f3n.<\/p>\n\n\n\n Pero muchas veces hay separaci\u00f3n f\u00edsica 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\u00f3n de ambas partes al equipo (y no solo f\u00edsicamente).<\/p>\n\n\n\n Cuando el testing ayuda a impulsar el cambio hacia una Cultura DevOps, la calidad de las puestas en producci\u00f3n mejora notablemente, se reduce el estr\u00e9s y se controla mejor el riesgo.<\/strong><\/p>\n\n\n\n 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<\/em>, se logr\u00f3 por primera vez que una puesta en producci\u00f3n no causara ninguna queja entre los usuarios. Antes de tener una cultura DevOps, el equipo estaba acostumbrado a planificar una semana m\u00e1s entre sprints, despu\u00e9s de cada puesta a producci\u00f3n, para hacer correcciones basadas en las quejas que los usuarios reportaran.<\/p>\n\n\n\n Claramente, esto no es algo que se pueda cambiar de un d\u00eda para otro, pero los resultados lo valen. No solo para tener una cultura m\u00e1s \u00e1gil, que est\u00e1 de moda, sino porque se pueden crear mejores grupos de trabajo que sean m\u00e1s colaborativos y mejoren continuamente, generando naturalmente mejores resultados.<\/p>\n\n\n\n Espero que despu\u00e9s de leer esta publicaci\u00f3n, pueda ver m\u00e1s claramente la posibilidad de impulsar no solo a los equipos para ir m\u00e1s all\u00e1, sino tambi\u00e9n ayudarlos a despegar y llegar a lugares que nunca hab\u00edan imaginado.<\/p>\n\n\n\n En este White Paper desarrollado en conjunto con Testim<\/a>, abordamos los 8 errores comunes que cometen los equipos, y brindamos algunos consejos para una transici\u00f3n exitosa a CI\/CD<\/strong>; desc\u00e1rguelo sin costo y acceda a:<\/p>\n\n\n\n Shift Left Testing: Qu\u00e9, c\u00f3mo y por qu\u00e9 considerar este enfoque<\/a><\/p>\n\n\n\n C\u00f3mo Shift Left Testing puede impulsar la adopci\u00f3n de DevOps<\/a><\/p>\n\n\n\n Testing \u00c1gil para crear productos digitales de alta Calidad<\/a><\/p>\n\n\n\nFeedback continu<\/strong>o<\/h2>\n\n\n\n
Planificaci\u00f3n<\/strong><\/h2>\n\n\n\n
![\"Planificaci\u00f3n](\"https:\/\/cl.abstracta.us\/wp-content\/uploads\/2021\/07\/planificacion-agil.png\")
<\/figure><\/div>\n\n\n\nConstrucci\u00f3n \u00e1gil<\/strong><\/h2>\n\n\n\n
Programaci\u00f3n en pare<\/strong>ja<\/h3>\n\n\n\n
![\"Testing](\"https:\/\/cl.abstracta.us\/wp-content\/uploads\/2021\/07\/testing-wall.png\")
<\/figure><\/div>\n\n\n\nPruebe anticipadamente<\/strong><\/h3>\n\n\n\n
Kanban<\/strong><\/h2>\n\n\n\n
![\"Kanban\"](\"https:\/\/cl.abstracta.us\/wp-content\/uploads\/2021\/07\/kanban-1.png\")
<\/figure><\/div>\n\n\n\nCI\/CD e implementaciones<\/strong><\/h2>\n\n\n\n
![\"Etapas](\"https:\/\/cl.abstracta.us\/wp-content\/uploads\/2022\/01\/etapas-proceso-desarrollo-software-1024x477.png\")
DevOps para un software de mayor calidad<\/strong><\/h2>\n\n\n\n
8 errores que cometen las empresas al realizar la transici\u00f3n a CI\/CD<\/h2>\n\n\n\n
![\"8](\"https:\/\/cl.abstracta.us\/wp-content\/uploads\/2021\/07\/8-errores-transicion-integracion-entrega-continua.png\"){kind=spacer}
<\/a><\/figure><\/div>\n\n\n\n
\n\n\n\nOtros contenidos relacionados<\/h3>\n\n\n\n