Scrum para un equipo de uno: requisitos y sprints semanales en mi TFM

Scrum para un equipo de uno: requisitos y sprints semanales en mi TFM

Scrum está pensado para equipos: un product owner, un scrum master, desarrolladores y un tablero que todos actualizan. Mi TFM del máster, una app de ecommerce multiplataforma con un cliente en Ionic y un backend en Laravel, tenía a una sola persona ocupando todos los roles. Aun así lo organicé en sprints, y al repasar las notas que guardé, la pregunta útil no es si eso cuenta como Scrum «de verdad». Es qué partes del método siguen compensando cuando trabajas solo y cuáles se convierten en ceremonia por la ceremonia.

Por qué no bastaba con una lista de tareas

La alternativa a un método iterativo es la clásica secuencia en cascada: requisitos, diseño, implementación, verificación y mantenimiento, cerrando cada fase antes de empezar la siguiente. Para un proyecto como el mío sus problemas eran evidentes desde el principio: es lento y da por hecho que los requisitos se conocen y son estables desde el inicio, cuando en la práctica cambian a medida que construyes y descubres lo que el producto necesita de verdad.

La premisa de Scrum es la contraria: entregar en piezas pequeñas, aprender y ajustar. Aunque ningún cliente me diera feedback cada semana, yo era mi propio primer usuario, y cada semana de desarrollo cambiaba lo que creía que necesitaba la app.

Ingeniería de requisitos, versión en solitario

Antes de planificar sprints recorrí las fases clásicas del análisis de requisitos, adaptadas a un proyecto sin cliente externo:

• Iniciación: entender el problema y el tipo de solución: una tienda que funcione en el móvil y tenga un panel de gestión en condiciones.
• Elicitación: convertir eso en requisitos funcionales y no funcionales explícitos, con un alcance definido.
• Elaboración: modelar funciones y escenarios con diagramas. En mi caso, el diseño de la base de datos (que pasé a dbdiagram.io porque se leía mejor) y bocetos en Excalidraw de las pantallas de administración.
• Negociación: sin un cliente con el que negociar, negocié con el calendario. Las funcionalidades que no cabían pasaban a una lista explícita de «opcionales de momento» en lugar de desaparecer.
• Especificación: los requisitos por escrito, funcionales y no funcionales, como referencia para el resto del proyecto.
• Validación y administración: contrastar el producto con esa referencia y llevar el control de los cambios a medida que los requisitos evolucionan.

La validación es la fase que más sufre sin equipo. Nadie más lee tu especificación ni te hace la pregunta incómoda. El remedio parcial que encontré fue la revisión semanal contra el backlog, que explico más abajo.

El backlog: cuatro bloques y una lista de «opcionales de momento»

El product backlog era una única nota dividida en bloques: pantallas del cliente (Ionic), pantallas de administración (Laravel), conexión entre cliente y servidor, y pruebas. Dentro del bloque del cliente había una sublista explícita llamada «opcionales de momento»: enlaces a redes sociales, atención por teléfono, un apartado de mensajes, política de privacidad y términos de uso, traducciones y compartir productos en redes sociales.

Esa sublista hizo más por controlar el alcance que cualquier otra cosa. Una funcionalidad en «opcionales de momento» no está rechazada ni olvidada: está aplazada de forma consciente. Te permite decirte que no a ti mismo sin perder la idea.

Sprints semanales en lugar de quincenales

La recomendación habitual de Scrum son sprints de una a cuatro semanas, con dos como estándar más común. Yo usé sprints de una semana, cada uno en una nota con el nombre de la semana ISO (2024-05, 2024-06, etc.) y enlazada desde el backlog. Mis notas cubren los sprints desde principios de febrero hasta mediados de abril de 2024.

Cada nota de sprint es una lista corta de tareas concretas con fecha de inicio y fecha de finalización. Un sprint típico del principio: barra de pestañas, buscador, añadir al carrito y a favoritos, y el propio carrito. Los posteriores: crear los modelos y seeders de Laravel, rutas y controladores, paginación y tablas con filtros en vivo en el panel, exportaciones a PDF y Excel, y tratamiento de imágenes en el servidor.

Una semana era la duración adecuada para una persona: lo bastante larga para terminar algo visible y lo bastante corta para que una mala estimación costara días, no semanas. Y el sprint backlog no cambia durante el sprint: las ideas nuevas van al product backlog, no a la semana en curso.

Qué ceremonias sobrevivieron

Scrum enumera cinco ceremonias: refinamiento del backlog (grooming), planificación del sprint, revisión del sprint, retrospectiva y daily stand-up. En solitario no todas tenían sentido.

• La planificación del sprint sobrevivió intacta. Escribir la nota de la semana era la planificación: una lista realista y alcanzable, no una carta a los Reyes Magos.
• La revisión del sprint se convirtió en marcar tareas como hechas con su fecha de finalización. Las fechas resultaron más útiles que las marcas: muestran qué tareas llevaron un día y cuáles se alargaron.
• El refinamiento ocurría cada vez que movía tareas entre el product backlog, un sprint y la lista de opcionales.
• La retrospectiva se redujo a un apartado de «dudas» en algunas notas de sprint. Un ejemplo: si la tabla de pedidos necesitaba guardar el precio, cuando se puede calcular a partir de las líneas del pedido. Anotar la pregunta y la respuesta (no es estrictamente necesario, pero merece la pena por eficiencia) es una retrospectiva en miniatura.
• El daily stand-up no sobrevivió. Preguntarte qué hiciste ayer y qué harás hoy no aporta nada cuando la fecha de inicio de cada tarea ya lo responde.

También creé un tablero Kanban con columnas «Por hacer», «En curso» y «Hecho». Se quedó prácticamente vacío. Para un equipo de uno, la lista semanal era el tablero.

El trabajo sin terminar también es información

No todo se terminó. La verificación del email y la configuración del correo para la API aparecen en un sprint, se arrastran al siguiente y siguen sin marcar. Verlo en las notas no es un fallo del método; es el método funcionando. La tarea estaba a la vista, se despriorizó de forma consciente frente a las funcionalidades del panel y nunca amplió el alcance sin que me diera cuenta.

La documentación también entraba en los sprints. Redactar el marco teórico de la memoria, corregirla y planificar sus capítulos (planificación, implementación, resultados y trabajos futuros) eran tareas del backlog como cualquier otra. Tratar la escritura como trabajo con fecha límite, y no como algo que se deja para el final, es probablemente la costumbre que más diferencia marcó.

Aprender el vocabulario después de la práctica

Hay una ironía en mis notas: el resumen que escribí sobre Scrum (cascada frente a ágil, sprints, artefactos, ceremonias, roles) tiene fecha de abril, en uno de los últimos sprints que registré, mientras que los sprints semanales empezaron en febrero. Practiqué el método antes de formalizarlo, y formalizarlo después sirvió sobre todo para ponerle nombre a lo que ya funcionaba.

El proyecto obtuvo Matrícula de Honor. No se lo atribuiría a Scrum. Pero para un proyecto en solitario con una fecha de entrega fija, un sprint semanal, una lista explícita de «opcionales de momento» y fechas en cada tarea son la forma más barata que conozco de mantener el alcance bajo control.