Bienvenidos a Micro píldoras de Software Testing. Soy Alina Sainz, tu amfitriana y estoy acá para llevarte del Amano del Malavilloso Mundo del Test in Software. Si son no en el ambiente informático y no tenés idea de la jerga de TI, acabas de llegar al lugar correcto. Así que si quieres conocer más sobre cómo se asegura la calidad de software y manejar esta industria, este es el podcast que estamos buscando. Comencemos. Hola gente, como están, bienvenidos
a otro Micro píldoras de Software Testing. Espero que estén teniendo una excelente día, tarde, una chillaca, contenta de volver con otro capítulo. Hemos vuelto, pero antes que nada quería agradecer a vos. He estado conversando con algo en ustedes y me alegre el alma que esta información lo se esté haciendo de ayuda para su crecimiento como profesional. Y desde este rinconciste escondido de Uruguay, les confirmo que sí se llega y que vale la pena a lo que están haciendo, aunque ahora
no lo vean. Yo recién ayer apliqué algo que había aprendido a los 17. En este episodio vamos a estar hablando sobre la metodología a Xia. Que es lo que estoy sonando en estos momentos. Bueno, entonces, a Xia. Una metodología de desarrollo de software como cualquier otra, pero no. Acá nos vamos a centrar en dos cosas. La entrega continua y la adaptabilidad. Realía un par de cosas más, también, pero no nos adelantemos. Tomemos nota.
Resumiendo, vamos a ver. ¿Qué es cómo funciona y en qué no beneficiosar esta metodología? Empecemos. ¿Qué es la metodología a Xia? O a Xia. Esto es una forma de ir gestionando los proyectos como les venía comentando. Vamos a darle mucho enfoque a la colaboración y la comunicación entre todo el equipo. Nos vamos a mover como un verdadero en granaje. Y cómo lo vamos
a hacer? El lugar de planificar todo el proyecto desde el principio a Xia va a agarrar la idea del cliente y junto con el equipo de TeI, vamos a definir todo lo que se necesita en un plazo corto de tiempo. Vamos a ir comando pasos con información más real de cómo va avanzando el proyecto, teniendo una visión también general del proyecto y hacia dónde nos estamos moviendo. No, no se olvidemos de esa parte. Uruguayizando el concepto, lo podemos pensar como cuando
nos vamos a preparar un mate. Por ejemplo, en lugar de una receta rigurosa detallada para hacer un mate que te la pasó el amigo, al que se le laban en la segunda ronda, se puede hacer un enfoque ágil. Por ejemplo, podemos comenzar por definir el objetivo principal, que sea preparar un buen mate amarlo. Ahora, en lugar de seguir este proceso de preparación más rígido, podemos preparar el mate en ciclos cortos y pues como frecuentes para ir adaptando
y vamos a soitando el proceso a medida que vayamos necesitando, ¿no? ¿Qué podríamos ajustar acá? Bueno, por ejemplo, se podría ajustar la cantidad de yerba o la temperatura del agua o la cantidad de tiempo de espera para obtener diferentes resultados de sabor o incluso si te gusta el mate de calabaza o si quieres probar en uno de vidrio o en uno
de goma. Ahora, no nos confundamos porque capaz pensamos que al decir ágil vamos a tener el proyecto como el relloma cuinda rápido y no es por ahí, sino que hay más oportunidades de ver las que estamos embarándolas para que no se nos la ve el mate. Me explicó, ¿o qué podemos hacer para mejorar para no seguir cometiendo los mismos errores de siempre durante todo el proyecto, sino que bueno, ¿tá? Frenemos chicos, digamos, a ver qué está
pasando, corrigamos lo que está mal y sigamos. La gilidad está en el proceso en cómo se adapta el equipo para ir solucionando los problemas y mejorando ese proceso dentro del funcionamiento mismo del equipo. Aparte, le pasa el mate al que tenéis salado, que en el contexto acá, a Ylte y equipo sería tu compañera de equipo y te va a dar un feedback como qué buen mateico o te pasaste deyer va o esto es una piscina y es una porquería y todo esto nos va a ir
llevando también una mayor colaboración entre nosotros la flexibilidad, nos vamos adaptando, vamos aprendiendo otras cosas, otras perspectivas, pero lograr un matioli de los que se tomó artigantes de arrancar la batalla de las piedras. La metodología parte me gusta por algo más que me gusta ver en los proyectos, que a veces cuando nos complica nos vamos olvidando y nos ponemos un poco violentos a veces, mi incluyo,
que es que a Giroca va a eximizar el valor entreado el cliente, ¿vale? En lugar de simplemente seguir el plan estricto del proyecto como veníamos hablando. Aquí voy con todo esto, dos cosas. No me lo bunyó. Yo creo que tenemos que ser conscientes de cuánto y de cómo hemos avanzado como profesional, a medida que vamos aprendiendo en este proceso. Podríamos hacer estos sprints que les voy a mencionar ahora en breve, pero en nuestro recorrido personal
en el proyecto y en el recorrido profesional del proyecto también. Para así mejorar nosotros mismos y no necesariamente tiene que ser en el trabajo. Y número dos es que tenemos que disfrutar lo que estamos haciendo. Mi objetivo y esto sea la metodología que sea, es eso de las cosas lo mejor posible. No importa si lo que está pasando la empresa ni el proyecto ni nada. Mientras creamos en lo que estamos haciendo
lo que saquemos de enseñanza de esa situación vale hora. Y esa actitud habla de nosotros como personas. Siendo con toda esta idea de mejora continua y sumando que a Yael es super flexible, no va a ir permitiendo a nosotros ir adaptando y nos también a los cambios, a los requisitos del proyecto a medida que va pasando el tiempo. Cada proyecto es un mundo aparte y a Yael nos ayuda a ir moviendo y no sintando otra persona en el camino.
Acá vamos a involucrar al cliente en cada etapa que pasemos del proceso de desarrollo de su propio producto. Entendernos exactamente qué quiso decir cuando apareció los requerimientos de que necesitaba y de sus expectativas va a ser mucho más fácil porque va a estar con
nosotros de cerca. Vamos a estar continuamente entregando avances que funcionan claramente en periodo bastante cortos de tiempo porque podemos tomar más el control y responsabilidad en nuestro trabajo y tomar decisiones en conjunto, nosotros equipo de TI con cliente y podemos ir aportando nuestra perspectiva desde nuestro lado de TI estar para poder mejorar la calidad del trabajo del resultado final. Las oportunidades de aparentes aje que tenéis acá son inumerables.
Los proyectos pueden y van a cambiar y van a evolucionar con el tiempo. Allá te deja adaptarte de alguna manera los cambios por los costos del proyecto. Es más ergonómico, digamos, más práctico, más eficiente. Ahora, para movernos dentro de esta metodología y entendernos realmente lo que está acontecendo en este momento en nuestras vidas, tenemos tres palabras claves principales que van a ser nuestras aliadas durante este proceso
para que podamos llevar a cabo todo esto que él les estoy contando. ¿Qué se llama? el sprint artefacto y ceremonia. El sprint es como nuestro reloj. Es la medida de tiempo que vamos a tener y a donde nos vamos a mover en espacio tiempo. ¿Tá? Poniendo en días laborales, ¿cómo se vive el sprint día a día es algo así? Cada sprint dura como unas 12 más o menos. El reloj comienza, esta reloj que les comento, comienza en el principio del sprint claramente y vamos a comenzar a planear en que vamos
a enfocarnos en ese periodo de tiempo en ese sprint. Entonces, comenzamos a estudiar lo que tenemos que hacer. Después tiramos poderes y vamos avanzando a medida que van pasando de los días, buena semana, sarumpe algo para ahí, pasa la otra, se arregla, llegamos al final y en ese punto el equipo separa, mira para atrás y el aluga. Y eso por los siglos de los siglos. Recuerden esta palabra porque la van a usar muy seguida. Sígamos.
Los artefactos que los siguientes son los o documentos o elementos ya más tangiblees que vamos a usar para ir planificando, vamos a poder rastrear, se llanas para dar algo, gestionando y trabajo que tengamos en ese momento. También se usa para mantener la transparencia con el cliente, porque son documentos que se van editando y van actualizando con el correo del tiempo y se intenta mantenerlo los más actualizados posibles, se intenta.
También por eso el encapié en la colaboración, porque es suelen ser visibles y accesibles para todos los miembros del equipo y alguna otra parte que le interese a alguna otra persona que le interese para el buen motivo. Y esto fue mental justamente, uno de los principios que le comentaba yo antes que la comunicación y el entendimiento compartieron.
Entonces, este flujo constante que vamos a tener y suteniendo de información, también nos va a ir ayudando a tener como una base común de cosas que pasan en el proyecto, de conocimiento de cosas que pasan en el proyecto en ese momento para tomar decisiones. Y el seguimiento del proyecto que también va incluido se hace muchísimo más fácil con esto.
Bueno, los artefactos, comencemos por el back-load del producto, que es básicamente una lista priorizada de todas las características, las funcionalidades, las mejoras, lo que se les ocurra, que esté en planificadas para el producto. Acá es donde el producto uner, que es el dueño tanto del producto como de la lista, va a ir actualizando para poner prioridades, para poner cambios a los requisitos y eso, ver dependiendo de
varios factores también, como la importancia más estratégica, capaz de cada característica o de las funcionalidades que tenemos a la lista, o el valor que le aporta y cliente en ese momento, esa funcionalidad o los plazos del proyecto, y eso se va viendo. Si vamos entonces con el sprint back-load que es básicamente otra lista de tareas, pero
estas tareas se sacan del back-load del producto. Acá vamos a tener las tareas para hacer con la prioridad más alta, y esta lista ya es más prioridad del equipo, porque la vamos a ir usando para ir llevando un seguimiento del progreso, de las tareas que tenemos, de lo
que nos falta, y sobre la entrega de los incrementos durante los sprints. Y un incremento que es exactamente el siguiente artefacto es justamente la actualización más nueva que tenemos para este bebé, que es nuestro sitio, nuestra aplicación, nuestro lo que quieran, y es como el último resultado tangible y que potencialmente podemos entregar del trabajo que hicimos durante el sprint. Un criollo es la versión funcional del producto que se va mejorando a medida que vamos avanzando en el proyecto.
Por último, tenemos la Definition of Don o la Definición de Terminado. Como toda cada buena práctica es tener desde el principio una buena y completa definición de terminado,
pero en la realidad pasan cosas. La definición de terminado es básicamente un conjunto entre criterios que ya se definieron de andemano y otros estándares que acomodamos, que nos van a decir, bueno, los requisitos mínimos para una tarea que teníamos en el backlog, podemos considerarla como que completamente se terminó y está potencialmente entregable.
La cosa es que van variándose con el equipo y son bastante amplias, también podemos incluir pruebas, revisiones de todo, con el caso de pruebas, con el decódigo, con el nombre que quieras. Hay una documentación jugosa, también, dependiendo de las necesidades de el proyecto, es lo que va a salir generando.
Bueno, vamos a ir terminando porque se me fue el amoto hablando, así que si vamos a hacer hemoñas, las hemoñas en Allaiso en un par, dos pares para hacer más precisa de raoñones, base que tienen o se deberían de cumplir el momento clave del ciclo de vida mientras va transcurriendo el ciclo de vida de un proyecto.
Para qué tanta reivinión me preguntarán, para poder hacer todo lo anterior que venimos mencionando, la comunicación, la retroalimentación, continua, la colaboración, la toma de decisiones, la transparencia, todo esto. En primer lugar, tenemos la Spring Planning, que es la reunión que les mencioné antes, que se hace el comienzo de cada Spring para ver elementos, ya sean mejoras o arreglos que quieran que estén en el Product Back-Long, que se vayan a incluir en la lista
del Spring Back-Long. Es como que esa mejora, digamos, que está un escalón más cerca de ser llevada a cabo en el proyecto. Aquí el equipo de desarrollo más que nada, es el que colabora con el Product Owner para ir seleccionando las tareas y bueno, estarles en las prioridades y el objeto. El objetivo del Spring y con tiempos razonables.
En segundo lugar, tenemos la Daily Stand Up o Daily de Cariño, que es básicamente una reunión diaria, de generalmente, unos 15 minutos, en la que nos ponemos al día con el equipo sobre el proyecto y que progreso tuvo cada uno. Vamos tirando un status de lo que se hizo el día anterior, lo que planeamos hacer este día y si tenemos algo que nos bloquea para llegar recuerdo en el objetivo. En el siguiente lugar, tenemos al Spring Review, que es la reunión al final de cada Spring.
Ahí es cuando le presentamos el incremento que tuvo el proyecto durante el periodo de este Spring al Product Owner y algunas otras personas que, por alguna razón, estuviera interesada. Es como que das un paseo por las funcionalidades que terminaron, o sea, que terminamos el equipo y se arregopila también el feedback para ajustar prioridades, para ver la planificación de siguiente Spring y así vamos haciendo números.
Y por último, en el lugar en la ceremonia tenemos la Spring Retrospective, que es la reunión que viene después del Spring Review, también se le dice a Retro, en la que, de alguna manera, reflexionamos sobre el Spring que terminó, discutimos sobre las cosas que funcionaron bien, o los problemas que tuvimos y hay alguna posible mejora que hayamos visto que podíamos comenzar a aplicar en el próximo Spring.
Y acá aparece otro de los objetivos que mencionamos antes, que es fomentar la mejora continua del equipo. Yo es la verdad que no veo fallas en su lógica, pero que les parece ustedes? Que tan dispuesto están a reunirte con gente con tanta frecuencia. Igual, estando dentro del proyecto es super lindo, parece como una danza, con coreografías de dos semanas, pero danza en fin, ustedes mendenen.
En conclusión, la metodología ágil se usa para la gestión de proyectos de software, y se enfoca el entregar continua la adaptabilidad y la colaboración. Es flexible, es eficiente y proporciona un valor constante a cliente. Nos da también la posibilidad de ofrecer nosotros un valor constante de cliente desde nuestra perspectiva para poder mejorar la calidad del proyecto en el que estamos trabajando. Y recuerden siempre hacer shiflas de Steam para tener proyectos exitosos.
Y con esto queréis, si hemos oyente llegamos al final de otro episodio de Micro�aldora de Testin de software. Espero que os disfrutamos de este microdosis de conocimiento tanto como yo disfrute a Zalala, que hayan aprendido algo nuevo o reafirmado algún concepto que tuviera aprendido con el filer es por ahí. Recuerden que cada capitulo de nuestro podcast es un granito más al diccionario que estamos construyendo juntos.
Episodio tras episodio, con términos usados a la jerga de TI, pero explicados sin mucha vuelta. Así que si quieres ser parte de esta famosa familia que se está formando o si quieres un capitulo de un tema específico, no te vayas de este canal sin suscribirte. Alina, ¿sáis de este lado? Muchísimas gracias por sintonizar, tomando un abrazo y nos vemos en otro episodio de Micro�aldora de Testin de software.