Cómo desarrollamos productos usando Scrum en Creativería
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.
¿Por qué Scrum?
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:
- Entregables de valor en intervalos más cortos que las metodologías tradicionales
- Habilidad de recibir feedback desde la primera etapa, lo que permite realizar ajustes lo más pronto posible
- Promueve el trabajo colaborativo
- Facilita la comunicación constante entre todas las partes. Todos conocen el status del proyecto
- Es especialmente útil para proyectos con requerimientos cambiantes y mucha incertidumbre
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.
¿Cómo manejamos en Creativería el desarrollo de un producto usando Scrum?
Paso 1: Asignamos los roles
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:
- Product Owner (PO): Es el encargado de que el proyecto genere valor en cada una de sus iteraciones y es el responsable de comunicar la visión del producto al equipo y stakeholders.
- Equipo de Desarrollo: Los expertos que trabajarán directamente en alcanzar el objetivo del sprint.
- Scrum Master: Sirve, entrena y supervisa al equipo para que ejecuten la metodología según los lineamientos y se asegura de que se cumplan los objetivos de cada sprint.
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)
- Son básicamente todas las demás personas que intervienen en el proyecto pero que no forman parte del equipo principal de trabajo. Pueden ser informantes, usuarios finales, gerencias, sponsors, equipos de TI del lado del cliente, etc.
Aquí podés profundizar un poco más sobre las responsabilidades específicas de cada rol y sus interacciones.
Paso 2: Creamos un Backlog del Producto
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:
- Establece entregables claros
- Elimina la ambigüedad entre interpretaciones
- Permite que todas las partes estén en la misma página
Paso 3: Planeamos y ejecutamos el Sprint
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:
- ¿Qué hice ayer?
- ¿Qué voy a hacer hoy?
- ¿Qué es lo que me está bloqueando?
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.
Paso 4: Revisamos el 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.
Paso 5: Hacemos una Retrospectiva
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:
- Ayuda a identificar problemas actuales.
- Promueve la unidad, la comunicación y la confianza dentro del equipo.
- Representa una mejora continua del proceso.
- Da la oportunidad de que todos los miembros del equipo tengan vos en las decisiones que se toman.
Paso 6: Planeamos un nuevo Sprint y el ciclo vuelve a comenzar…
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:
