Competencia · Análisis de la especificación de requisitos del software
Aprende a seleccionar historias de usuario, estimar el esfuerzo y convertir un objetivo de producto en un Sprint ejecutable.
¿Cómo se conectan las 4 guías de la fase de Análisis y Planeación?
Se caracteriza el proceso y se aplican dos instrumentos distintos al proyecto.
La evidencia se transforma en contexto, historias, requisitos y ejemplos verificables.
La historia toma forma y se observa a una persona intentando una tarea.
El paquete trazable se ordena en un objetivo y un plan realista de construcción.
01 · El cambio de mentalidad
Los enfoques de trabajo no son una receta única: ayudan a organizar decisiones, reducir riesgos y entregar valor con frecuencia según el contexto.
Metodología tradicional
Organizar el trabajo en fases secuenciales con entregables y control formal de cambios.
Marco de trabajo adaptativo
Trabajar en ciclos cortos, inspeccionar resultados y adaptar el plan con evidencia.
Un Sprint es un ciclo con objetivo y límites. El equipo pronostica el trabajo posible con la capacidad disponible, se compromete con el Sprint Goal y adapta el alcance sin reducir la calidad.
Lenguaje esencial desde cero
No memorices siglas aisladas. Para cada concepto identifica qué decisión permite tomar y qué evidencia produce.
Capacidad de aprender y adaptarse entregando valor en incrementos, con colaboración y retroalimentación frecuente.
Marco de trabajo ligero para generar valor frente a problemas complejos mediante responsabilidades, eventos y artefactos. No prescribe puntos de historia ni asignación individual.
Enfoque para visualizar trabajo, limitar trabajo en curso (WIP), gestionar flujo y mejorar con datos; puede complementar Scrum.
Evento de duración fija de un mes o menos que contiene el trabajo necesario para alcanzar un Sprint Goal.
Lista ordenada y cambiante de lo necesario para mejorar el producto; es la fuente del trabajo del equipo Scrum.
Sprint Goal, ítems seleccionados y plan de los Developers para producir el incremento. Se actualiza cuando se aprende.
Propósito único del Sprint. Da flexibilidad para renegociar detalles sin perder el valor buscado.
Resultado usable que se suma a lo anterior y cumple la Definition of Done. Puede liberarse, pero no tiene que publicarse en ese momento.
Responsable de maximizar valor y ordenar el Product Backlog; no reparte tareas como jefe del equipo.
Su responsabilidad es ayudar a que Scrum se comprenda y funcione, eliminar impedimentos sistémicos y facilitar la mejora.
Personas que crean el incremento. Son autogestionadas: deciden conjuntamente cómo realizar el trabajo.
Pronóstico bajo incertidumbre sobre tamaño, esfuerzo o complejidad. Se revisa cuando aparece nueva información.
Medida relativa opcional elegida por algunos equipos. No son horas, no son requisito de Scrum y no comparan personas.
Disponibilidad real del equipo para un periodo, descontando formación, reuniones, ausencias y soporte.
Cantidad histórica de trabajo terminado bajo la misma DoD. Sirve para pronosticar con cautela, nunca para medir productividad individual.
Acuerdo opcional del equipo sobre información mínima para iniciar un ítem. Hace visibles faltantes, pero no es un artefacto oficial de Scrum.
Descripción formal de la calidad que debe cumplir un incremento. Si un ítem no la cumple, no cuenta como parte del incremento.
Trabajo iniciado y no terminado. Limitarlo ayuda a enfocarse, terminar antes y descubrir cuellos de botella.
Obstáculo que reduce el avance del equipo y requiere una acción, responsable y seguimiento.
E-01 → H-01 → CTX-01 → HU-01 → RF/RNF-01 → CA/PR-01 → UI-01 v1 → VAL-01 → BL-01 → Sprint Backlog → tareas y evidencia de DoDAnálisis Continuo
La DoR es un acuerdo opcional para preparar ítems; la DoD es el compromiso de calidad del incremento. Ninguna se satisface con una etiqueta o una captura.
02 · Instrumentos de decisión
La Guía 3 entrega una interfaz observada. Aquí se decide qué entra, cómo se comprueba y qué significa terminar antes de escribir código.
Usa este filtro con la HU-003 (Registrar Equipo) de la Guía 3 antes de comprometerla.
Un incremento no está listo por “funcionar en mi máquina”. Define la calidad y la evidencia antes de iniciar el Sprint.
Valor: Reducir registros incompletos y facilitar la consulta del estado del equipo.
Incluye: Registro con serial válido, confirmación visual y consulta del resultado.
No entra: Reportes históricos ni exportación a Excel; quedan en el Backlog para un Sprint futuro.
Prueba (BDD): Dado un serial nuevo, cuando registro, entonces se muestra un identificador de confirmación y el equipo aparece en la consulta.
Una IA puede proponer descomposición, riesgos o pruebas. No conoce la capacidad real, la dinámica del equipo, la deuda técnica ni las consecuencias para las personas. El equipo decide el objetivo, negocia alcance, verifica seguridad y calidad, y responde por lo que entra al Sprint.
BITÁCORA HUMANO–IA · G4
Uso: [no utilizada / utilizada]
Decisión o artefacto apoyado:
Propósito, prompt y datos protegidos:
Propuesta recibida:
Verificación: [equipo / fuente / prueba / política]
Riesgos detectados:
Decisión humana: [aceptar / modificar / rechazar]
Justificación, responsable y fecha:03 · Laboratorio de planeación
Tu misión didáctica: selecciona la combinación de mayor prioridad que quepa en la capacidad, mantén el total dentro del límite y simula el recorrido de una tarjeta hasta Done.
También puedes usar los botones en cada tarjeta.Entrada
Historias priorizadas por el Product Owner.
Compromiso
Ejecución
Mueve las tarjetas para ensayar el flujo y detectar límites de WIP. Arrástralas entre columnas o usa sus controles rápidos; el estado es simulado.
04 · Comprueba tu aprendizaje
Revisa prioridad, capacidad y recorrido simulado. La preparación real también requiere el paquete del taller, DoR, DoD, dependencias y revisión del equipo.
Formación SENA por Proyectos
Al cerrar esta guía entregas el Plan de Sprint del MVP: una decisión de equipo trazable, realista y lista para iniciar construcción. El plan se puede resolver con lo aprendido aquí y con los insumos de la Guía 3; no se presenta como software construido ni como un incremento Done real.
El PDF de esta fase consolida el pronóstico y las reglas con las que el equipo iniciará el trabajo.
Estos elementos no se pueden demostrar moviendo tarjetas; se anexan después, durante construcción y revisión.
Consolida un paquete trazable y coherente con el objetivo y la capacidad. No se exige un número arbitrario de historias: se incluyen las que el equipo puede pronosticar y explicar.
| Lo que practicas | Lo que queda en el PDF |
|---|---|
| Ordenar y refinar el Product Backlog | Backlog completo, prioridad, criterios y razones de selección. |
| Estimar y calcular capacidad | Método, disponibilidad, supuestos, puntos y pronóstico dentro del límite. |
| Aplicar DoR y DoD | Checklist de entrada por ítem y definición de calidad del incremento. |
| Gestionar flujo e inspeccionar | Tablero, WIP, impedimentos, plan de Review/Retrospective y evidencia futura. |
Confirma con tu instructor el código de la evidencia y el canal LMS (por ejemplo, Zajuna o Territorium). No uses un código sugerido si la ficha vigente indica otro.
Nomenclatura de ejemplo: G4_PlanSprint_PrimerNombre_PrimerApellido_v01.pdf