SCRUM – Metodología Ágil

Antes de meternos en las tareas del día a día de un QA, vamos a aprender o repasar lo que es Scrum.
Existen muchas metodologías ágiles, Scrum es una de ellas, y decidí escribir sobre ella, debido a que es la más utilizada hoy en día.

Las metodologías ágiles, son la evolución de las metodologías tradicionales, tales como la de cascada. Para aquellos que no sepan lo que es, les dejo un gráfico representativo


Vamos a suponer que un cliente llamado Carlos, tiene una tienda de computadoras y vende insumos informáticos.
Carlos nos llama al teléfono y pide reunirse para que le desarrollemos un sistema de stock.
En esta reunión, nos explica que necesita llevar un inventario de todos los insumos, clientes, proveedores y ventas de su negocio.

Con esta información, ya tenemos los requisitos del sistema, que es el primer paso del gráfico que les mostré anteriormente.

Llegamos a nuestra casa, y diseñamos en papel como debería ser el sistema. En el papel escribimos que será un sistema web, en donde al ingresar a la URL de su negocio se topará con un panel de login, al ingresar podrá ver un menú con cada uno de los módulos. En el módulo de productos podrá dar de alta sus insumos y al realizar una venta, descontará automáticamente el stock... Y así con cada una de los módulos a desarrollar (Etapa de diseño)

Una vez que ya tenemos en mente como será la plataforma, comenzamos a desarrollarla... (Etapa de implementación)

Después de 3 largos meses de desarrollo, logramos tener todo lo que nuestro cliente Carlos nos pidió (Etapa de verificación). Regresamos victoriosos a su tienda, ansiosos de cobrar el dinero por la plataforma y al enseñar el sistema, Carlos comenta que es muy distinto a lo que el quería realmente.
El se imaginaba otros colores distintos a los que pusimos en su sistema, al formulario del inventario le faltan campos como el del código de producto, el precio de costo y que automaticamente calcule un precio de venta, entre varias otras cosas más.
Teniendo estos nuevos requisitos, volvemos a nuestra casa y nos situamos nuevamente encima de la cascada para volver a comenzar. Y esto no quiere decir que la próxima presentación quede todo solucionado, sino que corremos riesgos de que vuelva a pasar lo mismo

Seguramente dirán... ¿Qué tiene que ver todo esto con SCRUM?

La respuesta es fácil. Hubiesemos utilizado alguna metodología ágil como lo es SCRUM, nos ahorrabamos esos ida y vuelta.

Pero... ¿Cómo funciona SCRUM?

Para entenderlo de forma fácil, también lo explicaré con una imagen característica de esta metodología.


Busqué una imagen en inglés a propósito, ya que son los términos que se suelen utilizar en las empresas de software. Otra cosa a tener en cuenta, es que esta metodología se usa cuando trabajamos con equipos de trabajos y ahora veremos por que.
Product Owner (Dueño del producto) nos da los requerimientos del sistema que debemos realizar (Product Backlog).
Seguido a esto, separamos las tareas que podemos realizar en un lapso de 1 a 4 semanas. (Este ciclo se define antes de arrancar el proyecto). Supongamos que los ciclos o sprints son de 2 semanas, entonces en la Planning Meeting debemos tomar tareas que nos lleven 2 semanas o menos y esas tareas son colocadas en el Sprint Backlog. Por ejemplo, en el primer sprint (primeras 2 semanas), haremos el Login y el módulo de productos. Al siguiente sprint (sprint 2), haremos el módulo de clientes, y así con todos los módulos. El orden de desarrollo, suele ser por prioridad. Esto quiere decir que si desarrollarmos primero el el login y el módulo de productos, el dueño del negocio podrá utilizar la plataforma mientras desarrollamos el resto de los módulos.
Una vez que ya esta todo definido en el Sprint Backlog (3er dibujo en la imagen), comienza el ciclo de desarrollo.
Si prestan atención, por fuera del círculo del sprint, hay otro más chico que dice «Daily Scrum», también conocido como «Daily Meeting» o «Stand Up Meeting», esto es una reunión diaria que se tiene con todos los miembros del equipo, y debe ser sumamente corta, lo suficiente como para poderla tener de pie, de ahí viene el «Stand Up Meeting».
En esta reunión, que suele ser al principio de cada día, debemos responden las siguientes preguntas:

– ¿Qué hice ayer?
– ¿Qué estoy haciendo ahora?
– Si estoy bloqueado con algo

Ejemplo:

– Ayer comencé con el diseño del login
– Hoy voy a finalizar toda la interface del login
– Estoy bloqueado para hacer el backend porque mi compañero aún no termina de crear las tablas en la base de datos del login.

Si prestan atención, sale una figura en la imagen llamada Scrum Master, esta persona es la encargada de solucionar los problemas o bloqueos que podamos tener. En este caso, hablaría con esa persona que esta atrasada y vería cual es el motivo, o intentaría ayudarlo para que avance más rápido y así desbloquear a su compañero.
En caso de no tener ningún problema, solo mencionan que no estan bloqueado con nada y le pasan la voz a su compañero para que diga su status.

Una vez finalizadas las 2 semanas de desarrollo, se presenta una DEMO al cliente para que vea lo desarrollado.
Lo bueno de esto, es que si tiene algún comentario, ejemplo colores, formas, posiciones, etc. Las puede mencionar y no solo se arregla en lo que ya está hecho, sino que se tiene en cuenta para el resto de los módulos.

Por ultimo, podemos ver 2 figuras más en la imagen como el Sprint Review y Retrospective, que basicamente en estas reuniones se suelen mencionar que cosas salieron bien y que cosas salieron mal durante ese sprint para aplicarlo o corregirlo en el siguiente.

Ya sabemos que es SCRUM, pero ¿En dónde entran los QA?

Voy a responder en detalle esta pregunta en otro post, pero para no dejarlos con la duda, podemos decir que en el QA esta presente en todo el proceso del desarrollo.

Cuando el cliente define el backlog, debemos ayudarlo a pasar todos los requerimientos a un issue tracker y asegurarnos de que quede todo lo suficientemente claro como para que luego los desarrolladores puedan leerlos y comenzar a programar sin problemas.

Mientras los programadores se encuentran en fase de desarrollo, los QA tenemos que comenzar a escribir los casos de prueba y a organizar nuestras suites para luego someter a esa plataforma a los diferentes tests que preparemos.
No me voy a meter mucho en detalle ahora, porque tengo pensado dedicarle un post completo a esto.

Quiero aclarar que todo esto que he redactado es en base a mi experiencia personal. SCRUM es una metodología muy flexible, puede que tenga más reuniones que solo son necesarias en ciertos proyectos. El gráfico que expliqué en este post, es lo más común de ver en las empresas de software factory.

Dejen en los comentarios, que otros tipos de metodologías conocen, o cual es las que más les gusta!

la verdad que me gusto mucho, como se relacionan los diferentes grupos de trabajo para llegar a un producto final, gracias por el aporte.

Muy bueno ! Gracias!

muy clara tu forma de explicar, muchas gracias

Gracias por compartir! Muy clara la explicación

Hay un libro llamado "El método LEAN STARTUP" de Eric Ries. Esta enfocado en la implementación de la metodologia LEAN para administrar empresas de manera eficiente, enfocandose en el aprendizaje continuo y validacion para lograr fallar rapido y barato. Muy parecido a SCRUM, tambien se trata de sacar un MVP y mejorar de manera iterativa.

Muy bueno justamente estaba dando algo de ello.

Muy claro y práctico el material. Gracias! Tenés alguna experiencia para comentarnos en otra metodología ágil? Está buenísimo cómo se entiende con ejemplos! jaja.

Abrazo!

Muchas gracias por toda la info, excelente ejemplo.

Excelente!

El mundo sería otro si todos aplicaran metodologías ágiles en sus equipos de trabajo! Gracias por la explicación!

Muchas gracias!

Gracias, una explicación muy bien hecha!

Muchas gracias. Excelentemente claro

No tienes permitido ver enlaces. Registrate o Entra a tu cuenta

Antes de meternos en las tareas del día a día de un QA, vamos a aprender o repasar lo que es Scrum.
Existen muchas metodologías ágiles, Scrum es una de ellas, y decidí escribir sobre ella, debido a que es la más utilizada hoy en día.

Las metodologías ágiles, son la evolución de las metodologías tradicionales, tales como la de cascada. Para aquellos que no sepan lo que es, les dejo un gráfico representativo

Vamos a suponer que un cliente llamado Carlos, tiene una tienda de computadoras y vende insumos informáticos.
Carlos nos llama al teléfono y pide reunirse para que le desarrollemos un sistema de stock.
En esta reunión, nos explica que necesita llevar un inventario de todos los insumos, clientes, proveedores y ventas de su negocio.

Con esta información, ya tenemos los requisitos del sistema, que es el primer paso del gráfico que les mostré anteriormente.

Llegamos a nuestra casa, y diseñamos en papel como debería ser el sistema. En el papel escribimos que será un sistema web, en donde al ingresar a la URL de su negocio se topará con un panel de login, al ingresar podrá ver un menú con cada uno de los módulos. En el módulo de productos podrá dar de alta sus insumos y al realizar una venta, descontará automáticamente el stock... Y así con cada una de los módulos a desarrollar (Etapa de diseño)

Una vez que ya tenemos en mente como será la plataforma, comenzamos a desarrollarla... (Etapa de implementación)

Después de 3 largos meses de desarrollo, logramos tener todo lo que nuestro cliente Carlos nos pidió (Etapa de verificación). Regresamos victoriosos a su tienda, ansiosos de cobrar el dinero por la plataforma y al enseñar el sistema, Carlos comenta que es muy distinto a lo que el quería realmente.
El se imaginaba otros colores distintos a los que pusimos en su sistema, al formulario del inventario le faltan campos como el del código de producto, el precio de costo y que automaticamente calcule un precio de venta, entre varias otras cosas más.
Teniendo estos nuevos requisitos, volvemos a nuestra casa y nos situamos nuevamente encima de la cascada para volver a comenzar. Y esto no quiere decir que la próxima presentación quede todo solucionado, sino que corremos riesgos de que vuelva a pasar lo mismo

Seguramente dirán... ¿Qué tiene que ver todo esto con SCRUM?

La respuesta es fácil. Hubiesemos utilizado alguna metodología ágil como lo es SCRUM, nos ahorrabamos esos ida y vuelta.

Pero... ¿Cómo funciona SCRUM?

Para entenderlo de forma fácil, también lo explicaré con una imagen característica de esta metodología.

Busqué una imagen en inglés a propósito, ya que son los términos que se suelen utilizar en las empresas de software. Otra cosa a tener en cuenta, es que esta metodología se usa cuando trabajamos con equipos de trabajos y ahora veremos por que.
Product Owner (Dueño del producto) nos da los requerimientos del sistema que debemos realizar (Product Backlog).
Seguido a esto, separamos las tareas que podemos realizar en un lapso de 1 a 4 semanas. (Este ciclo se define antes de arrancar el proyecto). Supongamos que los ciclos o sprints son de 2 semanas, entonces en la Planning Meeting debemos tomar tareas que nos lleven 2 semanas o menos y esas tareas son colocadas en el Sprint Backlog. Por ejemplo, en el primer sprint (primeras 2 semanas), haremos el Login y el módulo de productos. Al siguiente sprint (sprint 2), haremos el módulo de clientes, y así con todos los módulos. El orden de desarrollo, suele ser por prioridad. Esto quiere decir que si desarrollarmos primero el el login y el módulo de productos, el dueño del negocio podrá utilizar la plataforma mientras desarrollamos el resto de los módulos.
Una vez que ya esta todo definido en el Sprint Backlog (3er dibujo en la imagen), comienza el ciclo de desarrollo.
Si prestan atención, por fuera del círculo del sprint, hay otro más chico que dice «Daily Scrum», también conocido como «Daily Meeting» o «Stand Up Meeting», esto es una reunión diaria que se tiene con todos los miembros del equipo, y debe ser sumamente corta, lo suficiente como para poderla tener de pie, de ahí viene el «Stand Up Meeting».
En esta reunión, que suele ser al principio de cada día, debemos responden las siguientes preguntas:

– ¿Qué hice ayer?
– ¿Qué estoy haciendo ahora?
– Si estoy bloqueado con algo

Ejemplo:

– Ayer comencé con el diseño del login
– Hoy voy a finalizar toda la interface del login
– Estoy bloqueado para hacer el backend porque mi compañero aún no termina de crear las tablas en la base de datos del login.

Si prestan atención, sale una figura en la imagen llamada Scrum Master, esta persona es la encargada de solucionar los problemas o bloqueos que podamos tener. En este caso, hablaría con esa persona que esta atrasada y vería cual es el motivo, o intentaría ayudarlo para que avance más rápido y así desbloquear a su compañero.
En caso de no tener ningún problema, solo mencionan que no estan bloqueado con nada y le pasan la voz a su compañero para que diga su status.

Una vez finalizadas las 2 semanas de desarrollo, se presenta una DEMO al cliente para que vea lo desarrollado.
Lo bueno de esto, es que si tiene algún comentario, ejemplo colores, formas, posiciones, etc. Las puede mencionar y no solo se arregla en lo que ya está hecho, sino que se tiene en cuenta para el resto de los módulos.

Por ultimo, podemos ver 2 figuras más en la imagen como el Sprint Review y Retrospective, que basicamente en estas reuniones se suelen mencionar que cosas salieron bien y que cosas salieron mal durante ese sprint para aplicarlo o corregirlo en el siguiente.

Ya sabemos que es SCRUM, pero ¿En dónde entran los QA?

Voy a responder en detalle esta pregunta en otro post, pero para no dejarlos con la duda, podemos decir que en el QA esta presente en todo el proceso del desarrollo.

Cuando el cliente define el backlog, debemos ayudarlo a pasar todos los requerimientos a un issue tracker y asegurarnos de que quede todo lo suficientemente claro como para que luego los desarrolladores puedan leerlos y comenzar a programar sin problemas.

Mientras los programadores se encuentran en fase de desarrollo, los QA tenemos que comenzar a escribir los casos de prueba y a organizar nuestras suites para luego someter a esa plataforma a los diferentes tests que preparemos.
No me voy a meter mucho en detalle ahora, porque tengo pensado dedicarle un post completo a esto.

Quiero aclarar que todo esto que he redactado es en base a mi experiencia personal. SCRUM es una metodología muy flexible, puede que tenga más reuniones que solo son necesarias en ciertos proyectos. El gráfico que expliqué en este post, es lo más común de ver en las empresas de software factory.

Dejen en los comentarios, que otros tipos de metodologías conocen, o cual es las que más les gusta!

muy buena la explicación, me ayudo mucho los ejemplos que pusiste. Gracias

Muchas gracias por compartir tu experiencia,siemprees util leer post en foros que cuentan el dia a dia en esta maravillosa carrera.