Planeación y Estimación: El Mapa del Tesoro del Desarrollador
Especialízate en el stack que más te apasiona y destaca en el mercado laboral. La personalización de tus habilidades puede ser la clave para obtener el empleo y salario que deseas. ¡Inscríbete ya!
Quiero destacar en el mercado laboral
¡Bienvenido de nuevo, arquitecto de tu carrera! En la sesión anterior, trazaste tu mapa personal: tu “porqué”, tu “qué” y tu “cómo”. Ahora que tienes un destino, es hora de aprender a dibujar el mapa para cualquier proyecto: el plano que te guiará del caos a la claridad.
Imagina que quieres construir un rascacielos. No empezarías a soldar vigas de acero al azar. Necesitarías un plano arquitectónico, un plan de ingeniería, un cronograma. En software, es algo similar. Un proyecto sin un plan sólido está destinado al fracaso, sin importar cuán brillante sea el código.
En esta sesión intensiva de 4 horas, nos pondremos el casco de Jefe de Proyecto. Dominarás las habilidades que distinguen a un desarrollador senior: la capacidad de liderar, planificar y entregar valor de forma predecible.
Objetivos de la Sesión
Al finalizar este taller, serás capaz de:
- Identificar y evitar las trampas comunes que llevan a los proyectos al fracaso.
- Convertir requisitos de negocio ambiguos en Historias de Usuario claras y accionables usando criterios profesionales (INVEST).
- Desglosar Historias de Usuario en tareas técnicas específicas.
- Estimar el esfuerzo de un proyecto usando Story Points y la técnica de Planning Poker, abandonando para siempre las estimaciones en horas.
- Priorizar el trabajo utilizando matrices de Valor vs. Esfuerzo.
- Estructurar un proyecto en Sprints y gestionar el flujo de trabajo en un tablero Kanban.
Módulo 1: El Costo de la Improvisación
Antes de ver las soluciones, debemos entender el problema. Muchos equipos operan en un “Ciclo del Caos” sin siquiera saberlo.
El Ciclo del Caos: Requisitos Vagos ➔ Scope Creep (el proyecto crece sin control) ➔ Plazos Irreales ➔ Presión y Burnout ➔ Deuda Técnica (atajos y “chapuzas”) ➔ Producto Inestable ➔ Cliente Insatisfecho.
Este ciclo es la receta para el desastre. La planificación es el antídoto. Es nuestra herramienta para gestionar el riesgo, alinear las expectativas de los stakeholders (las partes interesadas: clientes, jefes, usuarios) y, sobre todo, proteger la salud mental y la calidad del trabajo del equipo.
Un desarrollador junior codifica. Un desarrollador senior, además, protege el proyecto.
Señales de que estás entrando al Ciclo del Caos:
- Tu backlog crece cada semana pero las demos muestran lo mismo: estás atrapado en scope creep.
- Los stakeholders cambian los criterios después de cada entrega porque nunca acordaron qué significaba “terminado”.
- Tu equipo salta entre tareas sin cerrarlas; el WIP sube y la motivación baja.
Si detectas una de estas señales en tu proyecto personal, esta sesión es tu momento de corregir el rumbo.
Módulo 2: De la Idea a la Tarea
La habilidad más crucial en la planificación es la traducción. Debes ser un traductor experto del lenguaje de negocio al lenguaje técnico.
Historias de Usuario Profesionales: El Criterio INVEST
Ya conoces el formato “Como…, quiero…, para…”. Ahora, vamos a añadirle un filtro de calidad: el acrónimo INVEST. Una buena historia de usuario es:
- I - Independiente: Debe poder desarrollarse sin depender de otra historia.
- N - Negociable: No es un contrato. Es el inicio de una conversación sobre la mejor forma de implementarla.
- V - Valiosa: Debe entregar valor tangible al usuario o al negocio.
- E - Estimable: El equipo debe tener suficiente información para estimar su tamaño.
- S - Pequeña (Small): Debe ser lo suficientemente pequeña para completarse en un Sprint (idealmente en pocos días).
- T - Testeable: Debemos poder verificar que está completa y funciona.
Criterios de Aceptación: La “Definición de Hecho”
¿Cómo sabemos que una historia está “terminada”? No es cuando “funciona en mi máquina”. Es cuando cumple sus Criterios de Aceptación (AC).
Ejemplo:
- Historia: “Como usuario, quiero iniciar sesión con mi email y contraseña para acceder a mi perfil.”
- Criterios de Aceptación:
- Dado que soy un usuario registrado, cuando ingreso mi email y contraseña correctos, entonces soy redirigido a
/dashboard.- Dado que estoy en la página de login, cuando ingreso una contraseña incorrecta, entonces veo el mensaje de error “Email o contraseña incorrectos”.
- Dado que estoy en la página de login, cuando hago clic en el botón “Iniciar Sesión” sin llenar los campos, entonces los campos se marcan en rojo.
Los AC eliminan la ambigüedad y son la base para las pruebas que escribirás más adelante.
Tareas Técnicas: El Puente entre la Historia y el Código
Cuando una historia ya está clara, todavía es demasiado grande para ponerla en “In Progress” tal cual. Necesitamos traducirla en tareas técnicas: acciones concretas, de bajo nivel, que normalmente puede ejecutar una sola persona en menos de un día.
- Son atómicas: “Configurar endpoint POST /sessions” es mejor que “Implementar login”. Si no puedes describir la tarea con un verbo único (crear, configurar, probar), aún está muy grande.
- Abarcan todo el flujo: piensa en frontend, backend, pruebas automatizadas, documentación y despliegue. Una historia de login suele implicar tareas de UI, validaciones, hashing en backend y casos de prueba.
- Se sustentan en los AC: cada criterio suele traducirse al menos en una tarea. Si tienes un AC que habla de errores visibles, necesitas una tarea específica de manejo de errores.
Esta descomposición permite distribuir el trabajo de forma justa, detectar dependencias técnicas y facilitar el seguimiento en tu tablero.
Spikes: Investigación con Fecha de Expiración
A veces una historia es imposible de estimar porque es terreno desconocido. En lugar de adivinar, creamos un spike: una tarea de investigación acotada (normalmente 4-8 horas) cuyo objetivo es aprender lo suficiente para tomar una decisión o escribir una estimación informada.
- Tienen entregables claros: un documento con hallazgos, una prueba de concepto o una lista de opciones comparadas.
- No son automatismos: si conoces la solución, no necesitas un spike; simplemente crea tareas técnicas.
- Se cierran con conclusiones: al terminar debes responder “¿seguimos?”, “¿cambiamos de librería?”, o “¿dividimos la historia?”.
Incluir spikes en tu plan demuestra madurez: reconoces la incertidumbre y la controlas antes de comprometer fechas.
Plantilla completa: de la idea a la prueba
| Nivel | Qué debes definir | Preguntas guía | Ejemplo (Registro de usuarios) |
|---|---|---|---|
| Épico | Meta SMART o Resultado esperado | ¿Qué cambio de negocio buscas? ¿Cómo lo medirás? | ”Reducir abandono en registro en 20%“ |
| Historia | User Story alineada a INVEST | ¿Quién obtiene el valor? ¿Cuál es la acción? ¿Qué beneficio recibe? | ”Como visitante, quiero crear una cuenta con mi email para guardar mi progreso” |
| AC | Criterios Dado/Cuando/Entonces | ¿Cómo sabrás que funciona? ¿Qué errores debes mostrar? | Ingresar datos válidos crea la cuenta, email inválido muestra error, duplicados se bloquean |
| Tareas técnicas | Pasos atómicos | ¿Qué debes construir en frontend, backend, pruebas y despliegue? | Formulario, endpoint POST /users, hash de contraseña, seed de datos |
| Spike | Investigación acotada | ¿Qué no conoces aún? ¿Cuánto tiempo invertirás? | Evaluar proveedor de emails transaccionales (4h) |
| Pruebas | Casos manuales o automatizados | ¿Qué validaciones cubrirás? ¿Dónde quedarán documentadas? | Test e2e de registro feliz, prueba de error, verificación de email |
Usa la tabla como checklist. Sustituye el ejemplo por tu contexto y asegúrate de rellenar cada fila antes de dar por “listo” cualquier entregable.
Módulo 3: El Arte de Estimar sin Mentir
“¿Para cuándo está?” - la pregunta más temida. Estimar en horas es una receta para el fracaso. La solución es la Estimación Relativa.
No preguntamos “¿cuántas horas?”, sino “¿qué tan grande es esto comparado con aquello?”.
Story Points: La Unidad de Esfuerzo
Usamos Story Points con la secuencia Fibonacci (1, 2, 3, 5, 8, 13, 21…) para medir el esfuerzo. El número no representa horas, sino una mezcla de:
- Complejidad: ¿Qué tan difícil es de entender y resolver?
- Incertidumbre: ¿Cuántas cosas desconocemos? (¿Es una API nueva? ¿Una librería que no hemos usado?)
- Volumen de Trabajo: ¿Son muchos cambios pequeños o uno muy grande?
La magia de Fibonacci es que la brecha entre números crece, reflejando que la incertidumbre se dispara con la complejidad. La diferencia entre un 1 y un 2 es pequeña; entre un 8 y un 13 es enorme. Una tarea de 13 o más puntos es una señal de alerta: ¡es demasiado grande, hay que dividirla! Cuando el problema es que no conocemos la tecnología o el alcance, levantamos un spike para descubrir la información que nos falta y así poder trocear la historia en tareas técnicas reales.
Capacidad y velocidad para tu Sprint
Con la estimación relativa lista, necesitas saber cuánto puedes comprometer.
- Velocidad base: toma los puntos completados en los últimos 2-3 Sprints personales (o usa una estimación conservadora de 8-10 puntos si estás empezando).
- Reserva de riesgo (20%): descuéntala para absorber imprevistos.
- Tiempo disponible: ajusta según horas reales que tendrás (si solo puedes dedicar 6h/semana, quizá completes la mitad).
Capacidad comprometida = (Velocidad Promedio x Disponibilidad Real) - Reserva de RiesgoEjemplo: Si en las últimas semanas completaste 12 puntos, pero esta vez tendrás solo el 75% del tiempo y quieres dejar 20% de colchón: (12 x 0.75) - 2 ≈ 7 puntos. Ese es tu límite para seleccionar historias.
Planning Poker: La Sabiduría del Grupo
Esta es la técnica para asignar los puntos.
- Lectura: El equipo lee una historia de usuario y sus AC.
- Discusión: Se aclaran dudas.
- Votación Secreta: Cada miembro elige en privado una carta de Fibonacci que representa el esfuerzo.
- Revelación: Todos muestran su carta a la vez.
- Conversación Clave: Si hay votos muy dispares (un 3 y un 8), se abre la discusión más importante del día. El del 8 explica los riesgos que ve (“Esta API siempre falla, y hay que hacer 3 queries complejas”). El del 3 explica su visión (“Podemos reusar este componente y sale rápido”). Esta conversación saca a la luz suposiciones y conocimientos ocultos.
- Re-votación: Se vuelve a votar hasta llegar a un consenso.
Este proceso no busca la “estimación perfecta”, busca el entendimiento compartido.
Módulo 4: Estrategia de Ejecución
Ya tenemos las tareas y su tamaño. Ahora, a la acción.
Sprints y Tableros Kanban
Trabajamos en Sprints: ciclos cortos (1-2 semanas) con un objetivo claro. Al final de cada Sprint, debemos tener un incremento de producto potencialmente entregable.
Visualizamos el trabajo en un Tablero Kanban, el cual nos da una vista clara del flujo de trabajo. Las columnas básicas son:
- Backlog: El universo de todas las tareas por hacer, priorizadas.
- To Do (Sprint): Las tareas que el equipo se ha comprometido a hacer en el Sprint actual.
- In Progress: Lo que estás haciendo ahora. (¡Regla: una tarea por persona a la vez!)
- In Review: El código está terminado, esperando revisión por un compañero (Pull Request).
- Done: La tarea cumple todos los AC, ha sido probada y fusionada. ¡Celebración!
Rituales y límites que evitan el caos
- Definition of Ready (DoR): Ninguna historia entra a “To Do” sin AC claros, tareas técnicas listadas y dependencias resueltas.
- Daily Focus (10 min): Cada día responde “¿qué cerré?, ¿qué desbloqueo hoy?, ¿qué me bloquea?”. Si se vuelve más largo, agenda otra llamada.
- Límites WIP: Máximo 2 tarjetas por persona entre “In Progress” y “In Review”. Si quieres empezar algo nuevo, primero termina o ayuda a cerrar otra tarjeta.
- Review + Retro semanal: Aunque trabajes solo, agenda una revisión contigo mismo o con un mentor para evaluar avances y aprendizajes.
Priorización Avanzada: Matriz de Valor vs. Esfuerzo
Con tu backlog estimado, ¿por dónde empezar? Usa una matriz 2x2.
- Alto Valor, Bajo Esfuerzo (Quick Wins): ¡Haz esto primero! Genera impacto rápido.
- Alto Valor, Alto Esfuerzo (Grandes Apuestas/Épicos): Son el corazón de tu producto. Planifícalos cuidadosamente.
- Bajo Valor, Bajo Esfuerzo (Rellenos): Si sobra tiempo.
- Bajo Valor, Alto Esfuerzo (Pozos sin fondo): ¡Evítalos a toda costa!
Un desarrollador senior no solo coge la siguiente tarea de la lista; ayuda al equipo a elegir la tarea correcta.
Conclusión y Próximos Pasos
¡Felicidades! Has completado una de las sesiones más densas y más importantes de tu carrera. Hoy has aprendido que la construcción de software de calidad empieza mucho antes de escribir la primera línea de código.
Has pasado de ser un programador a ser un planificador. Sabes cómo tomar una idea abstracta y convertirla en un plan de acción concreto, predecible y gestionable.
Tarea para Casa (Obligatoria)
- Finaliza tu Tablero o Documento: Completa y pule tu tablero (Trello/Notion) o tu plan en Markdown/hoja de cálculo con todas tus historias, estimaciones y tu primer Sprint planificado. Este será un documento vivo que usarás durante todo el curso.
- Comparte tu Plan: Publica el enlace a tu tablero en nuestro canal de la comunidad. Ver los planes de otros es increíblemente útil.
- Reflexiona: Escribe una breve reflexión sobre tu mayor “¡ajá!” de esta sesión. ¿Qué concepto te ha cambiado más la perspectiva?
Ahora que tenemos un plano maestro, la siguiente pregunta es: ¿cómo diseñamos el edificio para que no se derrumbe? En la próxima sesión, nos sumergiremos en el Diseño y Arquitectura de Aplicaciones.
¡Prepárate para pensar en sistemas!
Especialízate en el stack que más te apasiona y destaca en el mercado laboral. La personalización de tus habilidades puede ser la clave para obtener el empleo y salario que deseas. ¡Inscríbete ya!
Quiero destacar en el mercado laboral