Clase 5 - Lunes, 14 de septiembre de 2026 (14 09 26) - Ingeniería de software
Planificación del Sprint y Metodologías Ágiles en la Ingeniería de Software
Este documento constituye una guía técnica y académica exhaustiva sobre la gestión de proyectos de software bajo marcos de trabajo ágiles, específicamente Scrum. Se centra en la transición del Product Backlog hacia la ejecución del primer Sprint, abordando roles, técnicas de estimación y la dinámica de planificación necesaria para asegurar la entrega de valor constante.
1. Introducción General
En el desarrollo de productos de software contemporáneos, la agilidad no es solo una metodología, sino una respuesta a la volatilidad intrínseca del mercado y las necesidades tecnológicas. El paso fundamental tras la concepción de una visión de producto es la planificación del primer Sprint, un proceso dinámico donde se transforma un listado de deseos (Backlog) en un compromiso de trabajo ejecutable y medible.
2. Contexto del Tema
El desarrollo ágil se basa en iteraciones cortas y constantes. En un entorno académico y profesional, esto implica pasar de una estructura rígida de requerimientos a un Backlog dinámico. Este repositorio de historias de usuario es "volátil"; es decir, puede ajustarse, dividirse o refinarse a medida que el equipo profundiza en la comprensión del producto. El objetivo primordial es generar un resultado funcional en el menor tiempo posible que aporte un valor real al destinatario final.
3. Marco Conceptual
Para comprender la planificación, es esencial dominar los términos fundamentales que rigen el ecosistema de Scrum.
Definición de Conceptos Clave
| Concepto | Descripción |
| Product Backlog | Repositorio central de todas las funcionalidades, mejoras y correcciones que el producto podría tener. Es dinámico y propiedad del Product Owner. |
| User Story (Historia de Usuario) | Descripción breve de una funcionalidad contada desde la perspectiva del usuario. Debe cumplir con criterios de calidad (como la categoría INVEST). |
| Épica | Una historia de usuario de gran tamaño que debe ser descompuesta en historias más pequeñas para ser abordable en un Sprint. |
| Sprint Backlog | Conjunto de historias de usuario seleccionadas para ser completadas durante un Sprint específico, junto con el plan para entregarlas. |
| MVP (Mínimo Producto Viable) | Versión del producto con las funcionalidades mínimas necesarias para ser entregado y generar valor, permitiendo el aprendizaje temprano. |
| Incremento | La suma de todos los elementos del Backlog completados durante un Sprint que resultan en un producto funcional y estable. |
Herramienta "Persona"
Proveniente del Design Thinking, la herramienta Persona consiste en crear sujetos ficticios (ej. "Agustín" o "Laura") que representen a los grupos de usuarios reales. Esto permite que el equipo empatice con las necesidades específicas del destinatario, evitando generalizaciones vagas como "el cliente".
4. Desarrollo del Tema: La Planificación del Sprint (Sprint Planning)
La planificación es un evento obligatorio en Scrum con un tiempo delimitado (time-boxed). Su propósito es definir qué se va a hacer y cómo se va a lograr.
Los Tres Roles de Scrum en la Planificación
- Product Owner (PO): Define el "qué". Es el experto en el negocio y responsable de priorizar el Backlog para asegurar el máximo valor.
- Equipo de Desarrollo: Define el "cómo". Es el encargado de traducir las historias en código y de estimar el esfuerzo necesario. Son autogestionados.
- Scrum Master (SM): Actúa como líder servidor, coach y facilitador. Asegura que el proceso se siga y ayuda a remover obstáculos.
Pasos para una Planificación Exitosa
Paso 1: Priorización (Método MoSCoW)
El Product Owner debe categorizar las historias de usuario para identificar qué es esencial para el MVP.
- M (Must have): Requerimientos vitales sin los cuales el producto no sirve.
- S (Should have): Importantes pero no vitales en la iteración actual.
- C (Could have): Deseables si hay tiempo y recursos.
- W (Won't have this time): Historias que no se realizarán en este Sprint o MVP, pero que se conservan para el futuro.
Paso 2: Conversación y Criterios de Aceptación
El equipo de desarrollo analiza las historias prioritarias. Se resuelven dudas técnicas y de negocio. Aquí se definen los Criterios de Aceptación: condiciones específicas que debe cumplir la historia para ser considerada "terminada" (ej. manual de uso, validación de estados, infografías específicas).
Paso 3: Estimación (Planning Poker)
El equipo de desarrollo utiliza la Serie de Fibonacci (1, 2, 3, 5, 8, 13, 20...) para puntuar las historias.
- Naturaleza Relativa: No se miden horas, sino puntos de historia basados en complejidad, dependencia y riesgo.
- Interpretación: Un "1" es una tarea atómica y simple. Un "13" o "20" indica una historia muy compleja o con demasiadas incertidumbres que probablemente deba dividirse.
Paso 4: Definición de la Meta del Sprint (Sprint Goal)
Es un objetivo único que describe lo que se pretende lograr. No es un listado de tareas, sino una frase que resume el incremento (ej. "Lograr la creación, visualización y selección de ítems del catálogo").
5. Relaciones entre Conceptos y Estructuras
La agilidad funciona como un "efecto mamushka":
- Visión del Producto: El norte estratégico.
- Funcionalidades Macro: Identificadas a través de la visión.
- Épicas: Divisiones de esas funcionalidades.
- Historias de Usuario: El nivel más finito para el desarrollo.
- Tareas: El desglose técnico (opcional en el Backlog, pero útil para la Daily).
La conexión entre el PO y el equipo de desarrollo debe ser directa y sin intermediarios (burocracia) para mantener la agilidad.
6. Dinámica de Trabajo: La Daily Scrum
Una vez iniciado el desarrollo, el equipo realiza reuniones diarias de máximo 15 minutos enfocadas en tres preguntas:
- ¿Qué hice ayer para aportar al objetivo del Sprint?
- ¿Qué voy a hacer hoy?
- ¿Qué obstáculos tengo?
7. Ejemplos Prácticos
Ejemplo de Estimación y Compromiso: El Catering
Imagine que se solicita un servicio de catering para 50 personas mañana (5 tortas, pizzas, sándwiches). El equipo de cocina (desarrollo) debe estimar si tiene capacidad. Si el equipo determina que solo puede entregar 2 tortas y sándwiches para 10 personas, eso es a lo que se compromete. Aceptar todo sin estimar lleva al fracaso del proyecto y a la entrega de productos incompletos.
Ejemplo de Criterios de Aceptación: Seguimiento de Pedido
- Historia: "Como administrador quiero consultar el estado de una compra".
- Duda del equipo: "¿Qué estados? ¿Cómo se visualiza?".
- Criterio de Aceptación: "El seguimiento debe mostrarse mediante una línea de tiempo (infografía) con postas: Comprado -> Pagado -> En Envío -> Entregado".
8. Errores Comunes y Confusiones
- Confundir Historia de Usuario con Tarea: La historia es el "qué" (el valor para el usuario); la tarea es el "cómo" (la acción técnica, ej. "crear tabla en BD").
- Falta de Criterios de Aceptación: Entregar algo que el PO no considera útil porque no se definieron las "letras chicas" del entregable.
- Estimación Lineal: Creer que los puntos de historia son equivalentes a horas hombre. La estimación es relativa al esfuerzo y riesgo.
- Ignorar la Meta del Sprint: Crear un "Frankenstein" de historias inconexas que no forman un incremento funcional al final del Sprint.
9. Síntesis y Conclusiones
La planificación del Sprint es el corazón de la ejecución ágil. Requiere un Product Owner que conozca profundamente el negocio, un Equipo de Desarrollo corajudo que se comprometa basándose en estimaciones reales, y un Scrum Master que facilite la dinámica. El éxito no se mide por la cantidad de historias terminadas, sino por la calidad del incremento y el valor que este aporta al usuario final el día de la entrega.
10. Preguntas de Repaso
Básicas
- ¿Cuáles son los tres roles fundamentales de Scrum y qué responsabilidad tiene cada uno en la planificación?
- ¿Qué diferencia existe entre el Product Backlog y el Sprint Backlog?
- ¿Qué significa que una historia de usuario sea "volátil"?
Intermedias
- Explique el método MoSCoW y cómo ayuda al Product Owner a definir el MVP.
- ¿Por qué se utiliza la serie de Fibonacci en el Planning Poker en lugar de una escala lineal (1, 2, 3, 4, 5...)?
- ¿Qué elementos deben considerarse para puntuar la complejidad de una historia de usuario?
Avanzadas
- Si un equipo es "conservador" y otro "arriesgado" en sus estimaciones de puntos de historia, ¿quién es mejor equipo y por qué?
- ¿Por qué el Manifiesto Ágil valora más el "producto funcionando" que la "documentación exhaustiva", y cómo se aplica esto en la relación PO-Desarrollador?
- Analice la importancia de la Meta del Sprint (Sprint Goal) frente a la simple acumulación de tareas en el tablero.
11. Fechas Importantes y Avisos Académicos
A continuación se detallan las fechas clave y las indicaciones proporcionadas para la organización del cronograma del proyecto:
| Fecha | Evento | Descripción |
| 14 de septiembre | Planificación (Clase Actual) | Inicio de la planificación del Sprint 1 y configuración de herramientas (Jira). |
| 21 de septiembre | Sin Clases | Feriado/Receso por el Día del Estudiante. |
| 28 de septiembre | Sprint Review (Revisión) | Presentación del incremento terminado a los stakeholders (profesora). Se realiza equipo por equipo (15 min c/u). |
| 05 de octubre | Cierre de Sprint 1 y Retrospectiva | Fecha límite técnica para cerrar el Sprint y realizar la sesión de reflexión sobre el proceso. |
| 16 de noviembre | Entrega Final del MVP | Fecha límite para la entrega del producto mínimo viable funcionando y estable. |
| 30 de noviembre | Última Clase | Cierre del ciclo lectivo. |
Recordatorios Importantes:
- No "Iniciar el Sprint" en Jira: Se advierte explícitamente no presionar el botón de inicio de sprint en la herramienta para mantener la visibilidad histórica de las historias y evitar que desaparezcan al finalizar el tiempo configurado.
- Compromiso de Entrega: Todo lo incluido en el Sprint Backlog para el 28 de septiembre/5 de octubre debe estar terminado. No se aceptan productos "por la mitad".
- Rol del Scrum Master: Debe asegurar que las Dailies ocurran con una frecuencia que mantenga al equipo conectado (se sugiere diariamente o cada dos días como máximo).