Scrum es uno de los marcos de trabajo ágil más populares en las empresas de software. Complementa ciclos cortos y procesos incrementales para el desarrollo de productos, lo que permite ver progreso desde el inicio del proyecto. Esta metodología usualmente es ejecutada por un equipo interdisciplinario enfocado en realizar entregas con el máximo valor en el menor tiempo posible.
En Creativería hemos tenido la oportunidad de usar metodologías ágiles como Scrum y Kanban desde hace 6 años. Esta experiencia nos ha permitido madurar nuestro proceso de desarrollo de productos digitales y queremos compartir cómo lo hemos implementado en nuestros proyectos.
Scrum es una de las metodologías más versátiles para el desarrollo de software gracias a su flexibilidad y a que permite ver valor muy rápido, desde las primeras etapas del proyecto.
Específicamente, Scrum aporta ventajas como:
Otra de las grandes ventajas de Scrum es cómo maneja la relación del alcance, tiempo y costo de los entregables respecto a las metodologías tradicionales de dirección de proyectos.
Por ejemplo, en el método tradicional de cascada, el alcance define cuál va a ser la duración y el costo del proyecto. Es como si dijéramos: “quiero que mi producto tenga todas estas funcionalidades, ¿cuál es el costo y cuánto se durará en completar todo el alcance?”.
En cambio en Scrum, el tiempo y el presupuesto (costo) disponible determinan el alcance que se puede desarrollar dentro de esas limitantes. Lo que diríamos entonces es: “con la cantidad de tiempo y presupuesto que tengo, ¿cuántas funcionalidades se pueden desarrollar?”.
Este cambio de óptica obliga inmediatamente a priorizar cuáles son las funcionalidades más importantes. De esta manera se comenzará a dar forma al Producto Mínimo Viable (MVP) o a un prototipo del que se puede obtener feedback de los usuarios y stakeholders.
Este paso es uno de los más importantes ya que define lo que cada integrante del equipo debe y no debe hacer. Los involucrados deben entender el alcance de su rol muy bien ya que hay responsabilidad específicas que deben cumplir.
El Equipo de Scrum está formado por 3 roles:
Bonus tip: si bien la teoría de Scrum solo define estos 3 roles, en Creativería consideramos a los stakeholders como un integrante más de la ecuación para administrar el proyecto o producto adecuadamente.
Stakeholders (o interesados del proyecto)
Aquí podés profundizar un poco más sobre las responsabilidades específicas de cada rol y sus interacciones.
El Backlog del Producto es una “lista de deseos” donde se colocan todos los requerimientos, solicitudes, tareas y objetivos que se desean completar durante el desarrollo del producto.
Los ítems que se agregan al Backlog deben redactarse como Historias de Usuario (HU) y deben priorizarse de acuerdo al valor de negocio que generarán.
Si al inicio del proyecto los criterios de aceptación de cada Historia de Usuario no están claros porque aún falta definir criterios de aceptación, se pueden agregar los requerimientos en forma de Funcionalidades. Las Funcionalidades son similares a las HU pero su información es más general.
Entre los ítems que normalmente se agregan al Backlog están: nuevas funcionalidades deseadas, correcciones, mejoras, ejecución de pruebas de usuario, parches, información por investigar, etc…
Después de la creación inicial del Backlog se pueden seguir agregando Historias de Usuario durante el proyecto hasta que no hayan nuevos requerimientos y se haya completado cada ítem.
Bonus tip: Las Historias de Usuario son una herramienta para describir específicamente los requerimientos y criterios de aceptación.
Las HU siempre se redactan desde la perspectiva del usuario que recibirá el valor una vez esté implementada. Por ejemplo:
Como cajero, quiero digitar el monto con el que el cliente paga y que el sistema me indique cuál es el cambio para agilizar el cobro y reducir el error humano
Ventajas de las HU:
Un Sprint es un periodo o “caja de tiempo” en la que un número determinado de tareas o Historias de Usuario será completado por el Equipo de Desarrollo. Normalmente se recomienda que la duración de los sprints sea entre 2 y 4 semanas máximo pero la recomendación es comenzar con 2 semanas para medir la velocidad del equipo y así ir ajustando hasta llegar a la duración ideal.
El equipo continúa planeando y ejecutando Sprints indefinidamente hasta que se logren completar todas las Historias de Usuario y tareas del Backlog.
El Sprint comienza con la sesión de Sprint Planning donde el equipo se reúne para decidir cuáles Historias de Usuario se trabajarán y formarán parte del Backlog del Sprint.
El objetivo principal de esta reunión es que el equipo se comprometa a tener un Incremento de Trabajo Terminado al final del Sprint y comprobar que todos estén alineados al alcance de cada Historia de Usuario.
Adicionalmente se acuerdan las fechas de reuniones y entregas que se harán durante ese Sprint y se definen los Criterios de Aceptación: básicamente lo que el PO espera ver en el entregable al final del Sprint.
Como la comunicación es de gran importancia en Scrum, durante la ejecución del sprint se realizan varias reuniones para garantizar que el equipo sigue alineado con los objetivos del Sprint.
Daily Scrum:
Reunión o llamada diaria de máximo 15 minutos donde el Equipo de Desarrollo comenta sobre el progreso de las tareas. Cada miembro debe responder 3 preguntas:
Adicionalmente se pueden resolver dudas que aparezcan o solicitar pendientes del cliente.
Se recomienda que esta sesión se lleve a cabo en la mañana, a la misma hora y lugar para evitar complejidad y además de pie para evitar extenderse más de lo necesario.
Backlog Grooming:
Antes de terminar el Sprint, el equipo se reúne para refinar el Backlog con el Product Owner. En esta sesión, si fuese necesario, el PO repriorizará las Historias de Usuario de acuerdo a las necesidades actuales y así el equipo comienza a prepararse para el próximo sprint.
Al finalizar el Sprint se realiza el Sprint Review donde el equipo entrega el Incremento de Trabajo Terminado al Product Owner y los Stakeholders más relevantes.
Es importante que en la sesión se haga una demostración funcional del incremento y no solo se reporte sobre lo realizado ya que este debe estar listo para lanzarse tal cual.
Adicionalmente, el PO debe validar que los Criterios de Aceptación definidos en el Sprint Planning se cumplan. En caso que haya feedback, el equipo decide si los ajustes se trabajan inmediatamente en el siguiente Sprint o se agregan al Backlog para ser completados en un Sprint futuro.
Al finalizar un Sprint, el equipo tiene una sesión de Retrospectiva para examinar y discutir sobre lo que salió bien y lo que se puede mejorar para el siguiente Sprint.
Importancia:
No hay límite para la cantidad de Sprints que se pueden ejecutar, a menos, claro, que haya una limitante de tiempo o de presupuesto; o si bien se lograron completar todos los ítems del Backlog del Producto. Si ninguna de estas situaciones sucede los sprints siguen ejecutándose agregando más y más funcionalidades al producto.
En resumen, en Creativería aplicamos Scrum en 6 pasos (relativamente) sencillos para desarrollar productos digitales que satisfacen las necesidades de nuestros usuarios:
Compartir artículo
