El delicado arte de calcular el tiempo que lleva crear un software
Realmente quiero contarles a todos cómo estimo el tiempo necesario para desarrollar proyectos de software.
En los últimos 10 años me han preguntado esto cientos de veces.
- “Necesitamos implementar esta función. ¿Cuánto tiempo te llevará?”
- “Dame una descripción detallada de cuánto tiempo tomará este proyecto en términos de tiempo. ¿1 mes? ¿2 meses?”
- “Quiero que me envíes esto. ¿50 horas de tiempo facturable son suficientes?”
La respuesta a esas preguntas ha sido , en el caso más optimista, una apuesta o un acto de fe , sabiendo que si prometía una cifra, probablemente esa habría sido mi paga, independientemente del tiempo que realmente hubiera tardado.
En ocasiones con clientes de largo plazo pude amortizar los proyectos que excedieron mis estimaciones con proyectos en los que completé el trabajo antes de lo esperado, haciéndole saber al cliente.
Al final terminé diciendo “ no puedo estimarlo ”.
Entonces, la respuesta a “Realmente quiero contarles a todos cómo estimo el tiempo necesario para desarrollar proyectos de software” es: no .
Pero puedo estimar que nadie es realmente capaz de estimar cuando se trata de desarrollar software, debido a las complejidades internas que este campo puede poner en tu contra.
A los “verdaderos ingenieros” les resultará difícil admitirlo, pero nunca he sido el típico ingeniero verdadero.
Estimar es probablemente lo más difícil cuando se trabaja como desarrollador.
Aquí tienes una tabla de referencia interesante que puedes usar cuando necesites estimar una tarea.
Tarea | Tu estimas | Te olvidaste | Tiempo real necesario |
---|---|---|---|
Una pequeña corrección de errores | 2 minutos | Necesitamos encontrar la función que tiene el error en el código fuente, git pull, verificar que no rompimos ninguna otra función, necesitamos agregar algunas pruebas, ejecutar las pruebas, corregir las pruebas que rompimos, implementar, actualizar el rastreador de errores | 2 horas |
Una característica menor | 2 horas | Debes corregir ese TODO que quedó en el código de la función que vas a editar y ver por qué hay un //don't touch this comentario. Debes realizar pruebas manuales con cuidado, además de pruebas del navegador, y verificar por qué Edge no funciona como se esperaba. Ah, tenemos que actualizar todas las capturas de pantalla en los documentos. | 10 horas |
Mejorar el rendimiento de un punto final | 10 horas | Necesita puntos de referencia precisos que pueda usar para demostrar que su nueva implementación está funcionando correctamente y agregar 10 pruebas más que no estaban presentes antes; de lo contrario, corre el riesgo de romper el código de producción utilizado por miles de clientes. | 5 días |
Reescribir todo el código del frontend | 3 semanas | Empiezas con el nuevo marco más escalable con el que estabas experimentando, sin tocar la interfaz de usuario, pero te encuentras con un conjunto de problemas completamente nuevo, pero esta vez no hay StackOverflow ni Google para ayudarte, ya que el marco es demasiado nuevo. Estás teniendo problemas únicos y necesitarías contratar al encargado de mantenimiento de la biblioteca para que trabaje contigo, pero él ya pasó a la siguiente gran novedad. Mientras estás en ello, el equipo de interfaz de usuario decide trabajar en una reescritura completa de la interfaz, dos veces. Los gerentes de producto a mitad de camino quieren cambiar a un producto ligeramente diferente. | 12 meses |
Esta podría ser una buena estimación de nuestra falta de estimación, pero, por supuesto, las cosas también pueden funcionar a la inversa: algo que estimas que podría tomar 5 días puede tomar solo 1 día porque descubres que ya está todo en su lugar para agregarlo y toma mucho menos de lo previsto. Blog sobre termux
Algunos podrían sobreestimar, proyectando que podrían tener dificultades, agregando un 30% más de lo que creen.
La estimación de proyectos en equipo es aún más difícil, ni siquiera lo intentaré.
¿Qué hacer entonces?
En lugar de hacer presupuestos detallados, propongo una comunicación continua con el cliente o jefe o quien te encargue el trabajo, y hacer revisiones semanales del avance del proyecto, sin predefinir cuándo terminará el proceso.
Porque después de todo el proceso nunca terminará.
Tal vez te puede interesar:
- Introducción a React
- Agregar evento de clic a los elementos DOM devueltos desde querySelectorAll
- Cómo cambiar el valor de un nodo DOM
- Cómo comprobar si un elemento DOM tiene una clase
Cómo estimar el tiempo de programación
Realmente quiero contarles a todos cómo estimo el tiempo necesario para desarrollar proyectos de software. El delicado arte de calcular el tiempo que lleva cr
programar
es
https://aprendeprogramando.es/static/images/programar-como-estimar-el-tiempo-de-programacion-1894-0.jpg
2024-10-29
Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente