El marco Scrum es aplicable en muchos tipos de proyectos y tiene múltiples beneficios, pero, ¿cuándo se debe usar Scrum y por qué? En este artículo, nuestro objetivo es ilustrar un ejemplo de un proyecto partiendo de una situación de la vida real y explicar por qué no se podría haber realizado sin un marco ágil, en este caso Scrum.
Este cliente quería integrar una interfaz PWA (aplicación web progresiva) a su plataforma de comercio electrónico. Esta era la primera vez que integrábamos las dos tecnologías. Además, aunque esta plataforma estaba trabajando con ahínco para mejorar su solución de PWA, todavía no estaba madura y había muchas señales de advertencia claras con respecto al uso de sus API para resolver las complejas funcionalidades que teníamos como requisitos.
Cuando planificamos el proyecto, el equipo identificó varios desafíos a los que se enfrentaría, principalmente porque se trataba de una construcción por primera vez. En primer lugar, nos propusimos utilizar el marco tecnológico PWA de la plataforma de comercio electrónico, una tecnología vanguardista que aún se encuentra en permanente cambio, lo que requería comprender sus capacidades y limitaciones, así como la hoja de ruta de las versiones futuras para poder anticipar las próximas funciones que pudiéramos necesitar. El uso de un marco tecnológico que todavía está en fase de desarrollo y es algo inestable era una segunda dificultad a tener en cuenta. El hecho de que la tecnología aún no fuera estable exigía que el equipo de Scrum tomara constantemente decisiones sobre qué componente usar y cuál extender en función de las necesidades, lo que constituía un tercer problema. En cuarto lugar, la documentación estaba en fase de desarrollo, por lo que no podíamos confiar en que estuviera actualizada, lo que obligó al equipo a adoptar una modalidad de pruebas en tiempo real, a cometer errores, a adaptarse constantemente y a probar diferentes enfoques. En quinto lugar, también había incertidumbre sobre las limitaciones de las API GraphQL de la plataforma de comercio electrónico, en parte debido a la falta de documentación. Por último, pero no por ello menos importante, necesitábamos dos versiones en producción para coexistir: una tradicional y otra de PWA que utilizara el mismo backend. En este sentido, necesitábamos que la tecnología fuera compatible con varias tiendas y también con varios países.
La situación era de extrema incertidumbre. Las incógnitas eran enormes y la investigación que podíamos hacer para entenderlas se vio limitada por la falta de documentación, la falta de tecnología madura y los cambios en constante evolución en la plataforma. Sin embargo, comprendíamos la motivación que había detrás del proyecto, el problema que el patrocinador intentaba resolver con una solución como esta y el impacto económico de pasar cada día sin tener la solución disponible.
En este punto, estaba claro que si utilizábamos un enfoque de ciclo de vida en cascada (metodología tradicional) para la ejecución, perderíamos un tiempo valioso investigando e incluso entonces no habríamos podido estimar el proyecto con confianza. Además, la elección de un enfoque tradicional requería tener un conocimiento claro del aspecto del proyecto final, algo que no teníamos. Por otro lado, un enfoque ágil permitía avances breves y fuertes, midiendo constantemente cómo estábamos evolucionando.
La incertidumbre descrita anteriormente fue clave para nuestro proceso porque el marco ágil de Scrum funciona mejor en contextos inciertos como en el que nos encontrábamos. Ofrece la posibilidad de ver la evolución del producto sprint a sprint y permite al cliente darse cuenta, al finalizar cada sprint, de que el producto ha llegado a una fase en la que resuelve el principal problema empresarial y, por lo tanto, ponerlo en marcha para empezar a ver el valor empresarial es ahora una opción. Esta es una de las principales ventajas de Scrum, ya que el cliente ve que el producto evoluciona sprint a sprint, el sistema está siendo utilizado. Por lo tanto, el propietario del producto puede evaluar constantemente si el producto, en su estado actual, resolverá las necesidades del negocio. Si lo hace, puede entrar en producción mientras se desarrollan mejoras continuas y se ponen en marcha con frecuencia. Por lo general, se pasa por alto el doble beneficio que obtienen los clientes con este modelo. Si decide poner en marcha una solución parcial porque tiene un impacto económico positivo en su empresa, se beneficiará de una rentabilidad temprana del proyecto mientras la herramienta aún esté en fase de desarrollo. En cierto modo, el proyecto acaba amortizándose solo, al menos parcialmente. En cambio, con las metodologías tradicionales, hasta que no se alcance el alcance de trabajo definido, el cliente no tendrá nada que ver con respecto al progreso del proyecto. Esto significa que un producto funcional puede haber alcanzado los objetivos del proyecto durante el desarrollo, pero no estará listo en el tiempo necesario.
Empezamos con un equipo de Scrum en el que teníamos personas con las habilidades necesarias: teníamos desarrolladores de React y desarrolladores de backend que se formaban en GraphQL porque esta tecnología requiere una experiencia que no teníamos antes. La construcción del prototipo implicaba el desafío de aprender y generar valor al mismo tiempo. Es por eso que este marco permitió al equipo de Scrum estar en constante cambio sprint a sprint, siempre teniendo en cuenta el objetivo del sprint.
El marco Scrum nos permitió enfrentar los desafíos mencionados anteriormente de la siguiente manera. Prestamos atención a los impedimentos en cada reunión diaria y fuimos rápidos a la hora de resolverlos o resolverlos (gracias al Scrum Master). Como se trataba de una tecnología nueva, cuando algo ponía en peligro el objetivo del sprint, el propietario del producto siempre nos indicaba cómo podíamos tomar una ruta alternativa que no nos desviara del objetivo, no daba prioridad a las funciones que no serían necesarias para obtener un MVP (producto mínimo viable) ni asumía las consecuencias. Cancelar el sprint no era una opción. La necesidad de que coexistieran dos versiones en producción realmente dificultaba la viabilidad del MVP, ya que no podíamos usar dos backends diferentes. Por lo tanto, el equipo tuvo que crear una solución alternativa que lo permitiera. El requisito de que la tecnología fuera compatible con varias tiendas y varios países exigía volver a desarrollar una parte importante de la plataforma, y sabíamos que la función se incluiría en una versión futura que se publicaría próximamente. Por este motivo, decidimos que el MVP solo se aplicaría en un país hasta que la función estuviera disponible en la plataforma de comercio electrónico. Siempre nos preguntamos: «¿Podemos vivir sin que esto forme parte del MVP?» ya que puede ser muy fácil caer en el deseo de hacerlo todo y hacerlo a la perfección. El marco ágil permitía eliminar las características que finalmente no añadían valor al MVP, sin tanto estrés como lo habría hecho con una metodología tradicional.
Poco a poco nos dimos cuenta de que muchos aspectos no eran necesarios para que el producto funcionara, no añadían valor al negocio del cliente y que podíamos vivir sin ellos. Así fue como creamos el MVP, siguiendo el objetivo de cada sprint hasta que el MPV estuviera listo para que alguien lo comprara por Internet. Este producto aún podía mejorarse, pero era funcional, de modo que si alguien visitaba el sitio web, podía realizar una compra. A través de este proceso, demostramos en cada sprint el valor del producto, cometimos errores, probamos, aprendimos, hicimos que el producto evolucionara y pudimos poner en marcha una solución que añadía un valor significativo al negocio en poco tiempo. Esto no habría funcionado con una metodología tradicional.
En vista de lo anterior, se logró el objetivo del prototipo al permitir, en un máximo de 3 meses, demostrar una mejora del 50% en los tiempos de carga de las páginas en la navegación de la aplicación con respecto a una interfaz convencional. Además, se espera que cuando la aplicación sea 100% funcional, podamos presentar mejores tasas de conversión de 1 a 2 puntos. Sin duda, la elección de trabajar con un marco ágil, en este caso Scrum, fue uno de los puntos clave para el éxito del proyecto. La posibilidad de experimentar, cometer errores y aprender a medida que veíamos evolucionar el producto era perfecta para el contexto incierto en el que nos encontrábamos. Además, nos permitió evaluar cómo hacer progresar el prototipo añadiendo o eliminando funciones, independientemente de si añadían valor al negocio del cliente o no. Cuando se acerquen desafíos riesgosos, pruebe Scrum.
Ayudamos a los clientes a hacer crecer sus negocios haciendo que la creatividad, la flexibilidad y el talento converjan en el desarrollo de software y el diseño de UI/UX. Nos apasiona y nos compromete a asumir los desafíos que pueden impulsar su negocio.
Combinamos nuestra experiencia en comercio electrónico, dispositivos móviles y web en varios sectores, como el comercio minorista, el mayorista, el cuidado de la salud, el gobierno y el entretenimiento. De esta manera, trabajamos en estrecha colaboración con usted como equipo para colaborar en pos de implementaciones exitosas.
.svg)