SCRUM se ha convertido en la metodología de desarrollo de software predilecta por su enfoque ágil e iterativo. Sin embargo, al observar su aplicación, surge una pregunta intrigante: ¿Por qué el backend parece ser un actor invisible en la conversación?

El éxito de SCRUM no reside únicamente en el frontend. Un backend visible y reconocido es clave para alcanzar la excelencia en el desarrollo de software.

Pero antes de dar respuesta a eso, quizá deberíamos de repasar ¿qué es SCRUM?

SCRUM es un marco de trabajo ágil diseñado para gestionar proyectos complejos mediante iteraciones cortas llamadas Sprints (generalmente de 2 a 4 semanas). Su objetivo es entregar valor incremental al cliente, priorizando la adaptabilidad sobre la rigidez. Sus pilares son:

• Transparencia: Todos los aspectos del proceso deben ser visibles para el equipo.

• Inspección: Evaluación constante del progreso.

• Adaptación: Ajustes rápidos ante cambios o bloqueos.

Todo ello bajo el compromiso del Manifesto Agile.

Los componentes esenciales de SCRUM son:

1. Roles:

   • Product Owner: Define las prioridades del backlog y maximiza el valor del producto.

   • Scrum Master: Facilita el proceso y elimina obstáculos.

   • Equipo de Desarrollo: Multidisciplinar y autoorganizado (desarrolladores, diseñadores, QA, etc.).

2. Artefactos:

   • Product Backlog: Lista priorizada de requisitos.

   • Sprint Backlog: Tareas seleccionadas para el Sprint actual.

   • Incremento: Producto funcional entregado al final de cada Sprint.

3. Eventos:

   • Sprint Planning: Planificación de tareas para el Sprint.

   • Daily Stand-up: Reunión diaria de 15 minutos para sincronizar avances.

   • Sprint Review: Demostración del Incremento a stakeholders.

   • Retrospectiva: Análisis de mejoras para el próximo Sprint.

Aunque SCRUM se aplica tradicionalmente a nivel de squad (equipos pequeños y multidisciplinares), algunas empresas lo escalan a nivel organizativo usando marcos como SAFe o LeSS. Sin embargo, su esencia reside en la autonomía del equipo para gestionar su trabajo.

Pero entonces ¿cuáles son las razones de la supuesta invisibilidad?

• Naturaleza del trabajo: El trabajo en backend suele ser menos visible que el del frontend, ya que se centra en la lógica y la arquitectura del software, aspectos que no son directamente perceptibles para el usuario final.

• Comunicación asimétrica: La comunicación entre los equipos de frontend y backend puede ser desigual, con el frontend demandando funcionalidades y el backend respondiendo a sus necesidades.

• Falta de reconocimiento: El trabajo del backend a menudo se da por sentado, sin recibir el mismo reconocimiento que el del frontend, a pesar de ser fundamental para el funcionamiento del producto.

• En ocasiones los actores implicados en la toma de decisiones a nivel de producto no tienen un background técnico tan marcado con lo cual la complejidad de ciertas tareas puede verse infravalorada.

• Backend se encarga de otro tipo de tareas que no suelen entrar dentro del ciclo de planificacion scrum y pueden estar mas cerca a otros, más ligados a operaciones, como el CI/CD.

• En muchas ocasiones backend si está dentro de ese ciclo de scrum, pero simplemente implementa el suyo propio ya que buena parte de las tareas que desde producto puede parecer de poca complejidad incluyen muchas tareas en backend. Ademas es necesario el combinarlas con el soporte de las funcionalidades actuales y su mantenimiento. Esto hace que se requiera una planificación paralela.

Consecuencias de la invisibilidad

• Falta de motivación: Los equipos de backend pueden sentir una menor motivación al no ser reconocidos por su trabajo.

• Dificultades en la colaboración: La falta de comunicación y reconocimiento puede generar dificultades en la colaboración entre los equipos.

• Productos de baja calidad: Un backend descuidado puede afectar la estabilidad, seguridad y escalabilidad del producto final.

Beneficios de un backend visible

• Mayor motivación: Un equipo de backend motivado se traduce en un mejor rendimiento y calidad del trabajo.

• Colaboración efectiva: La comunicación y el reconocimiento fomentan la colaboración y el trabajo en equipo.

• Productos de alta calidad: Un backend sólido y bien desarrollado crea productos estables, seguros y escalables.

  
  

Planificación efectiva de tareas de diseño y backend para un desarrollo frontend impecable

La coordinación entre diseño, backend y frontend es crucial para un desarrollo eficiente y un producto final impecable. A continuación, te presento estrategias para planificar y ejecutar las tareas de diseño con backend de forma que se puedan implementar en frontend:

1. Comunicación clara y constante

• Establecer un canal de comunicación abierto entre los equipos de diseño, backend y frontend.

• Realizar reuniones periódicas para discutir el progreso, los próximos pasos y los posibles obstáculos.

• Utilizar herramientas de comunicación y colaboración como Slack, Trello o Jira para mantener a todos informados.

2. Definición clara de objetivos y requisitos:

• Establecer una visión clara del producto final y definir los objetivos de cada etapa del desarrollo.

• Documentar detalladamente los requisitos del diseño, incluyendo funcionalidades, flujos de usuario y especificaciones técnicas.

• Utilizar herramientas de prototipado como Figma o Adobe XD para comunicar visualmente el diseño y facilitar la comprensión.

3. Planificación y priorización de tareas:

• Dividir el proyecto en tareas pequeñas y manejables que puedan asignarse a los diferentes equipos.

• Priorizar las tareas en función de su impacto en el producto final y la complejidad técnica.

• Utilizar herramientas de gestión de tareas como Asana o Monday.com para organizar y monitorizar el progreso.

4. Integración y pruebas:

• Establecer un proceso de integración para que el equipo de frontend pueda trabajar con las funcionalidades desarrolladas por el equipo de backend.

• Realizar pruebas exhaustivas para asegurar que el diseño se implementa correctamente en frontend y que la experiencia del usuario sea óptima.

• Utilizar herramientas de testing como Selenium o Cypress para automatizar las pruebas y garantizar la calidad del producto.

Mejores prácticas

• Utilizar un sistema de diseño centralizado que documente los componentes de diseño y las mejores prácticas para su implementación en frontend.

• Crear un entorno de desarrollo compartido donde los equipos de frontend puedan trabajar con las últimas versiones del código backend.

• Realizar pruebas de usuario con frecuencia para obtener comentarios sobre el diseño y la funcionalidad del producto.

• Implementar un proceso de retroalimentación continua para mejorar la colaboración y la eficiencia del equipo.

• Prototipado técnico: Usar herramientas como Postman o Swagger para simular APIs durante la fase de diseño.

• Definición de "Ready": Acordar que una historia frontend solo empieza cuando el backend provee contratos de API firmes.

• Entornos compartidos: Garantizar que frontend y backend trabajen con la misma versión de APIs (usando herramientas como Docker o Kubernetes).

Herramientas útiles

Es hora de darle al backend el lugar que se merece en el escenario de SCRUM. Al reconocer su importancia y fomentar su participación activa, podemos crear productos de software de mayor calidad y fortalecer la colaboración entre los equipos.

Artículo escrito en colaboración con Carlos Enríquez, Backend Engineer Lead en Proqio.