La metodología SCRUM ayuda a gestionar mejor los proyectos digitales.

Desarrollo de proyectos ágiles con SCRUM

Desarrollo de proyectos ágiles con SCRUM

La metodología SCRUM ayuda a gestionar mejor los proyectos digitales.
La metodología SCRUM ayuda a gestionar mejor los proyectos digitales.

SCRUM se define como una metodología desarrollo ágil fundamentada en una estrategia de desarrollo incremental, a diferencia de las estrategias tradicionales de desarrollo basadas la elaboración completa y directamente del producto.

En este artículo profundizaremos más en los elementos que conforman un proceso de desarrollo en SCRUM, si aún te estás introduciendo en este concepto quizá te interesaría antes este artículo de mi compañero Carlos, «Introducción a SCRUM. Metodología de desarrollo ágil«.

Ahora bien, antes de empezar a definir cómo se debe llevar a cabo un proceso de desarrollo mediante SCRUM, conviene conocer sus ventajas respecto otras formas de trabajar.

La velocidad de desarrollo del software es la principal fortaleza de la metodología SCRUM, pues permite entregar productos aún no finalizados pero con funcionalidades terminadas. Esto supone una ventaja pues ahorra tiempo de desarrollo en caso de necesidad de realizar cambios, no es necesario terminar por completo un producto para poder probar sus funcionalidades.

Además, con SCRUM, el proyecto es más fácilmente adaptable y tiene mayor flexibilidad ante nuevos requerimientos o prioridades del mismo. Estos aporta un beneficio considerable respecto a otras metodologías de desarrollo por el simple hecho que aporta mayor versatilidad al equipo para reaccionar ante decisiones o imprevistos que requieren de modificaciones imprevistas durante el desarrollo del producto.

Por otro lado, conviene conocer también cuáles son los actores que intervienen durante el proceso de desarrollo de un proyecto SCRUM. Estos son básicamente tres: el producto owner (o PO), el equipo de desarrollo (conformado, evidentemente, por uno o más desarrolladores) y el Scrum Master.

El Product Owner es quien tiene la máxima responsabilidad sobre el proyecto, recibe los inputs de los otros actores y su función consiste en transformar y organizar toda esta información en historias de usuario en un backlog. Por lo general, estas histórias se suelen organizar según su importancia para el avance sostenible del proyecto o por su valor comercial.

El Equipo de Desarrollo es grupo de desarrolladores cuyo cometido primordial es realizar las tareas que el Product Owner previamente ha planificado. Este equipo vendría a ser como el brazo ejecutor del proyecto, el equipo humano que conforma este equipo será quien realmente «elabora» el producto en cuestión.

Por último, el Scrum Master es quien guía el proyecto, su función es servir de canal de comunicación entre equipo, el Product Owner y el cliente final. De esta forma, a este cargo también se le suele llamar «facilitador» pues es el encagado de velar por el correcto funcionamiento de todos los procesos del proyecto. En ocasiones, sobretodo en proyectos pequeños, este rol lo desempeña el Product Owner.

Una vez definidas las funciones de los actores del proyecto, solo queda ver cuáles son los pasos o procedimientos que conforman el proceso de desarrollo de proyectos según esta metodología. A estos procedimientos les denominamos eventos. A continuación te muestro un esquema típico de proceso de desarrollo SCRUM como apoyo de la explicación de los procedimientos que lo componen.

juatdigital-proceso-scrum

Todos los eventos empiezan cuando se reciben los inputs, los cuales el Product Owner tranformará en historias de usuario. Estas historias se reúnen todas en el blacklog, punto de partida del primer evento en este proceso, el Spint planning.

Antes de hablar sobre un Sprint planing conviene definir que es un Sprint, un Sprint no es más que un periodo de tiempo establecido para conseguir un objetivo, con sus respectivas tareas técnicas. Este objetivo equivaldría a la meta fijada para el equipo durante un periodo corto de tiempo, pues un sprint no durará nunca más de cuatro semanas.

Entonces, un Sprint Planning consiste en realizar una reunión de equipo donde el Product Owner define con el equipo las tareas del equipo de desarrollo según las historias de usuario asignadas para el objetivo del Sprint, esto se denomina «bajar a nivel técnico». Posteriormente, se le asigna un valor a cada tarea, normalmente en tiempo, para establecer la duración o complejidad de todas las acciones, esto permite facilitar el control y posterior análisis del desempeño del equipo.

A partir del Sprint planning, se deben asignar tareas y definir qué labores desempeñará cada miembro del equipo. Para ello se realizan los Daily Meeting, reuniones diarias escuetas donde todo el equipo de desarrollo coordina las tareas de ese día y comparte los progresos que hicieron el día anterior, es el momento en que se plantean los problemas de cada miembro y se observa el cumplimiento de los tiempos de las tareas.

Los daily meeting se realizan hasta el cierre del Sprint, es en ese momento cuando se realizará el Sprint review, esta no es más que una revisión del Sprint para medir el resultado del trabajo realizado y actualizar el backlog, eliminar las historias acabadas y añadir las nuevas.

Finalmente, por norma general, se suele realizar la Retrospectiva del Sprint, esto consiste en que todo el equipo que ha intervenido en el proceso SCRUM valora el Sprint para encontrar los puntos fuertes y flacos y así mejorar y optimizar futuros procesos del proyecto.

El cierre de un Sprint debería equivaler a crecimiento del producto, por lo menos ese es su cometido. Por lo que cada vez que se cierra uno, el producto ha incorporado nuevas funcionalidades. Por ese motivo, suele realizarse una «demo» entre el Product Owner y el cliente, para que el primero pueda mostrar al segundo la evolución de su producto. Una vez finalizado el proceso, se volverá a repetir con objetivos actualizados y nuevas historias de usuario para continuar con el desarrollo del producto.

Si te ha interesado este artículo, te recomiendo que leas también estos artículos de sobre Agile y Test Driven Development: