Ejemplos de cálculos resueltos
Las historias reales están presentes a lo largo de todo el proceso de estimación (inicio de sesión, pagos, migraciones, picos de tráfico), además de las preguntas que deben aclararse antes de que nadie vote una cifra.
Cómo evaluar una función de inicio de sesión: el alcance oculto (restablecimiento de contraseña, autenticación de dos factores, federación, limitación de frecuencia, sesiones) y las cuestiones que deben abordarse antes de que nadie vote.
Cómo estimar una integración de SSO: el trabajo no reside en su código fuente, sino en las particularidades del proveedor de identidad. Las preguntas que debe responder antes de fijar una cifra.
Cómo realizar una estimación de una integración de pagos: entorno de pruebas frente a entorno de producción, reembolsos, webhooks, idempotencia y ámbito de aplicación de la norma PCI. La conversación que debe mantenerse antes de fijar cualquier cifra.
Cómo realizar una estimación de una función de búsqueda: relevancia, clasificación, facetas y quién es el responsable del índice. Las preguntas que convierten la simple idea de «añadir una barra de búsqueda» en una estimación real.
Cómo evaluar un sistema de notificaciones: canales, preferencias, deduplicación y garantías de entrega. Por qué «enviar un correo electrónico» se convierte, sin que uno se dé cuenta, en un proyecto de seis semanas.
Cómo calcular el tiempo necesario para la subida de un archivo: límites de tamaño, análisis antivirus, reanudación, almacenamiento y retención. La función de «arrastrar y soltar» es la parte más sencilla; lo complicado está en el fondo.
Cómo realizar una estimación de un panel de control: fuentes de datos, frecuencia de actualización, zonas horarias, desglose de datos y permisos. El gráfico es sencillo; lo complicado es el proceso de tratamiento de datos que hay detrás.
Cómo estimar una prueba inestable: por qué se necesitan dos estimaciones, y no una, y por qué es mejor fijar un plazo que discutir sobre puntos cuando la respuesta depende de lo que se descubra.
Cómo estimar un error sin posibilidad de reproducirlo: no se puede calcular el esfuerzo de la corrección, solo el de la búsqueda. Cómo establecer un plazo para la investigación en lugar de votar sobre una historia que nadie puede ver.
Cómo evaluar una disminución del rendimiento: la mayor parte del trabajo consiste en el diagnóstico, no en la solución. Cómo evaluar su magnitud cuando se desconoce la causa y está en juego un SLO.
Cómo estimar un error notificado por un cliente: la descripción que figura en el ticket determina la envergadura. Cómo distinguir entre una corrección de una sola línea y una respuesta que se lleva todo el sprint.
Cómo calcular el tiempo necesario para una migración de base de datos: rellenado, duración del bloqueo, implementación y reversión. «Añadir una columna» es una línea de SQL; el tiempo estimado es aproximadamente el de un segundo.
Cómo realizar una estimación de una migración de datos: traslado de datos entre sistemas, conciliación y transición. La transformación se lleva a cabo en una hora; la limpieza dura un trimestre.
Cómo estimar una actualización del marco de trabajo: por qué un cambio de versión importante es un proyecto, no una incidencia, y cómo dividirlo en historias que realmente se puedan cuantificar.
Cómo estimar una actualización de dependencias: el aumento de larga duración que oculta N picos en un único ticket. Lea primero los registros de cambios y, a continuación, estime lo que haya encontrado.
Cómo estimar una revisión integral de CI/CD: el trabajo en el pipeline no tiene demostración, así que divídalo en partes según lo que se pueda eliminar. Esa tarea que lleva todo un trimestre y que se esconde en la lista de tareas pendientes como una refactorización.
Cómo evaluar la sustitución de una API de terceros: lagunas semánticas, ejecución simultánea y los supuestos implícitos en las peculiaridades del antiguo proveedor. La nueva API solo parece idéntica.
Cómo planificar la implantación de un límite de tráfico: umbrales, periodos de prueba y comunicaciones con los clientes. El código se escribe en medio día; lo difícil es elegir unos límites que no generen quejas.
Cómo evaluar un cambio en el sistema de diseño: implementaciones de tokens, rutas de obsolescencia, cobertura de Codemod y los 200 puntos de llamada que utilizan el componente antiguo. Evalúe el impacto en las fases posteriores.
Cómo estimar una corrección de accesibilidad: los problemas de accesibilidad son funcionalidades que no se incluyeron en la primera versión. Por qué hay que evaluar la magnitud del problema en su conjunto, y no un caso concreto.
Cómo planificar el lanzamiento de un «feature flag»: porcentajes por fases, «kill-switches», métricas de control y la limpieza que nadie programa. Un «feature flag» es un pequeño producto, no una implementación.
Cómo estimar un «spike» de investigación: un «spike» es un intervalo de tiempo con un resultado concreto, no una «story». Cómo evitar que, sin darse cuenta, se convierta en el trabajo que se pretendía incluir en el alcance.
Cómo evaluar un prototipo: se trata de un producto diseñado para el aprendizaje, no para su uso. Cómo evitar que lo que se ha creado como prototipo se convierta en el código de producción que nadie había previsto.
Cómo realizar una estimación de un experimento de aprendizaje automático: se trata de investigación combinada con ingeniería. El modelo es sencillo; el trabajo está en los datos. Cómo determinar el presupuesto adecuado, no una previsión.