Para consolidar todos los conceptos vistos, vamos a simular un proyecto de desarrollo de software desde cero: una aplicación web simple para compartir recetas de cocina llamada "RecipeShare".
12.1. Proyecto simulado con historias de usuario reales
El objetivo de "RecipeShare" es permitir a los cocineros aficionados y profesionales compartir sus recetas y descubrir nuevas ideas culinarias.
Personas de Usuario
- Cocinero Aficionado (Ana): Le encanta cocinar en casa y quiere encontrar recetas fáciles y guardar sus favoritas.
- Chef Profesional (Carlos): Quiere compartir sus creaciones culinarias para ganar visibilidad y construir su marca personal.
Historias de Usuario Iniciales
El Product Owner, después de hablar con usuarios potenciales, redacta las siguientes historias de usuario:
Como Cocinero Aficionado, quiero buscar recetas por ingrediente, para poder usar lo que ya tengo en mi despensa.
Criterios de Aceptación:
- Debe haber una barra de búsqueda en la página principal.
- Al buscar "tomate", deben aparecer todas las recetas que contengan tomate.
- Si no hay resultados, debe mostrarse un mensaje amigable.
Como Cocinero Aficionado, quiero guardar mis recetas favoritas, para poder acceder a ellas rápidamente en el futuro.
Criterios de Aceptación:
- Cada receta debe tener un botón de "Guardar como favorita".
- Debe haber una sección "Mis Favoritas" en mi perfil de usuario.
- Al hacer clic en el botón, la receta debe aparecer en mi sección de favoritas.
Como Chef Profesional, quiero publicar mis propias recetas con fotos y pasos, para compartir mi conocimiento con la comunidad.
Criterios de Aceptación:
- Debe existir un formulario para crear recetas con campos para título, ingredientes, pasos y foto.
- Al enviar el formulario, la receta debe aparecer publicada en el sitio.
- La receta debe asociarse a mi perfil de chef.
12.2. Creación de backlog, definición de sprint y revisión final
Creación y Priorización del Backlog
El Product Owner y el equipo realizan una sesión de refinamiento. Discuten las historias, aclaran dudas y las estiman usando Story Points (una medida relativa del esfuerzo).
| ID | Historia de Usuario | Prioridad | Story Points |
|---|
| HU-01 | Búsqueda de recetas | Alta | 5 |
| HU-03 | Publicar una nueva receta | Media | 8 |
| HU-02 | Guardar recetas favoritas | Baja | 3 |
Nota: La búsqueda (HU-01) se prioriza más alto porque genera valor inmediato para la mayoría de los usuarios, incluso sin que puedan publicar las suyas.
Definición del Sprint (Sprint Planning)
El equipo decide que su capacidad para el primer sprint es de 8 Story Points.
- Objetivo del Sprint: "Permitir a los usuarios encontrar y consultar recetas existentes de forma anónima."
- Selección de Historias: El equipo selecciona la historia HU-01 (5 puntos) y la HU-02 (3 puntos), sumando exactamente 8 puntos. Aunque la HU-02 tiene prioridad baja, cabe en el sprint y complementa la experiencia de consulta.
El equipo desglosa la HU-01 en tareas técnicas:
- Crear componente de UI para la barra de búsqueda.
- Desarrollar el endpoint de la API para la búsqueda en la base de datos.
- Diseñar la vista de la tarjeta de resultados de la receta.
- Implementar la lógica de frontend para llamar a la API y mostrar los resultados.
- Escribir pruebas unitarias y de integración para la búsqueda.
Revisión Final (Sprint Review)
Al final del sprint, el equipo presenta la funcionalidad completada a los stakeholders:
- Muestran la página principal con la barra de búsqueda.
- Realizan una búsqueda con un ingrediente y muestran cómo aparecen las recetas.
- Muestran el mensaje de "no hay resultados".
- Abren una receta y hacen clic en "Guardar como favorita", mostrando cómo aparece en una sección de perfil simulada.
Un stakeholder sugiere: "¡Sería genial si la búsqueda también sugiriera ingredientes mientras escribes!". El Product Owner agradece el feedback y lo anota para considerarlo como una nueva historia de usuario en el backlog.
12.3. Aplicación de todos los conceptos en contexto
Este ejemplo práctico conecta todo lo que hemos aprendido:
- Se partió de historias de usuario claras y centradas en el valor (Tema 2).
- Cada historia tenía criterios de aceptación medibles (Tema 3).
- Las historias seguían el principio INVEST: eran pequeñas, negociables y testeables (Tema 4).
- Se creó un backlog priorizado (Tema 6) y se estimó con story points (Tema 5).
- Se planificó un sprint con un objetivo claro, seleccionando historias que cabían en la capacidad del equipo (Tema 7).
- El trabajo se habría visualizado en un tablero Kanban (Tema 11) y discutido en Daily Scrums (Tema 8).
- La Sprint Review sirvió para demostrar valor y recoger feedback valioso (Tema 9).
- Finalmente, el equipo tendría una retrospectiva para mejorar su proceso en el siguiente sprint (Tema 10).