¿Cuánto tiempo se tarda realmente en hacer algo?[cerrado]

Question

Me refiero a mencionar un proyecto de programación que hiciste y cuánto tiempo tomó, por favor.El jefe nunca se ha quejado pero a veces siento que las cosas tardan demasiado.Pero esto podría deberse a que yo también estoy impaciente.Déjame saber tus experiencias para comparar.

También he notado que las cosas siempre parecen tomar más tiempo, a veces mucho más, de lo planeado originalmente.No sé por qué no empezamos a planificarlo, pero creo que tal vez sea con fines motivacionales.

ryan

Answer 1

Lo mejor es simplemente tomar el tiempo, registrar sus estimaciones y determinar el porcentaje promedio en el que está equivocado.Dado que, siempre que sea constante, puede estimar adecuadamente los tiempos reales en función de cuándo creía que lo haría.No se trata simplemente de determinar qué tan mal eres estimando, sino más bien de tener en cuenta la regularidad de las distracciones inevitables (tanto personales como de jefe/cliente).

Esto está basado en Joel Spolsky. Programación basada en evidencia, lectura esencial, ya que explica que el otro aspecto importante principal es dividir sus tareas en tareas pequeñas (16 horas como máximo), estimarlas y sumarlas para llegar al total final del proyecto.

Answer 2

Las estimaciones basadas en el instinto vienen con la experiencia, pero realmente es necesario detallar las tareas involucradas para obtener algo razonable.

Si tiene una especificación o al menos algunas restricciones, puede comenzar a crear tareas (diseñar página de usuarios, diseñar página de etiquetas, implementar página de usuarios, implementar página de etiquetas, escribir consulta de etiquetas, ...).

Una vez que hagas esto, súmalo y duplícalo.Si va a tener que coordinarse con otros, triplíquelo.

Registre su tiempo real en detalle a medida que avanza para que pueda evaluar su precisión cuando finalizó el proyecto y perfeccionar sus habilidades de estimación.

Answer 3

Estoy completamente de acuerdo con los carteles anteriores...No olvides también la carga de trabajo de tu equipo.El hecho de que haya estimado que un proyecto tomaría 3 meses no significa que se realizará ni cerca de eso.

Trabajo en un equipo más pequeño (5 desarrolladores, 1 líder), muchos de nosotros trabajamos en varios proyectos a la vez, algunos grandes y otros pequeños.Dependiendo de la prioridad del proyecto, los caprichos de la dirección y la disponibilidad de otros equipos (si es necesario), el trabajo de un proyecto se intercala con los demás.

Entonces, sí, 3 meses de trabajo pueden ser acertados, pero podrían ser 3 meses de trabajo en un período de 6 meses.

Answer 4

He realizado proyectos de entre 1 y 6 meses por mi cuenta y siempre tiendo a duplicar o cuadriplicar mis estimaciones originales.

Answer 5

Es efectivamente imposible comparar dos proyectos de programación, ya que hay demasiados factores que significan que las métricas de uno solo no son aplicables a otro (por ejemplo, tecnologías específicas utilizadas, experiencia previa de los desarrolladores, requisitos cambiantes).A menos que esté eliminando otro sistema que sea casi idéntico a uno que haya construido anteriormente, sus estimaciones tendrán una baja probabilidad de ser precisas.

Una advertencia es cuando estás creando la próxima revisión de un sistema existente con el mismo equipo;la experiencia específica adquirida mejora la capacidad de estimar el siguiente lote de trabajo.

He visto demasiados intentos de metodología de estimación y ninguno ha funcionado.Puede que tengan un atractivo pseudocientífico, pero simplemente no funcionan en la práctica.

La única respuesta significativa es la iteración relativamente corta, como defienden los defensores de la metodología ágil:elija un alcance de trabajo que pueda ejecutarse en un corto período de tiempo, entréguelo y luego pase a la siguiente ronda.Luego, los presupuestos se asignan a corto plazo, y las partes interesadas pueden evaluar si su dinero se está gastando eficazmente.Si les lleva demasiado tiempo llegar a alguna parte, pueden abandonar el proyecto.

Answer 6

Ley de Hofstadter:

"Siempre lleva más tiempo del esperado, incluso teniendo en cuenta la ley de Hofstadter".

Creo que esto se debe a que:

• El trabajo se expande para llenar el tiempo disponible para realizarlo.No importa lo despiadado que seas eliminando funciones innecesarias, habrías sido más brutal si los plazos fueran aún más ajustados.
• Se producen problemas inesperados durante el proyecto.

En cualquier caso, comparar anécdotas es realmente engañoso, en parte porque la gente tiene memoria selectiva.Si les digo que una vez me tomó dos horas escribir una clasificación rápida completamente optimizada, entonces tal vez me estoy olvidando del hecho de que sabía que tendría esa tarea con una semana de anticipación y había estado pensando en ideas.Tal vez me estoy olvidando de que había un error que pasé otras dos horas solucionando una semana después.

Es casi seguro que estoy dejando de lado todo el trabajo no relacionado con la programación que se realiza:reuniones, diseño de arquitectura, consultar a otras personas que están estancadas en algo que yo sé, administrador.Por lo tanto, es injusto para usted pensar en un ritmo de trabajo que parezca plausible en términos de "sentarse ahí codificando" y esperar que se mantenga todo el tiempo.Esta es la fuente de muchos sentimientos después del hecho de que "debiste haber sido más rápido".

Answer 7

Hago proyectos desde 2 semanas hasta 1 año.En general mis estimaciones son bastante buenas, posteriormente.Sin embargo, al comienzo del proyecto, generalmente me critican porque mis estimaciones se consideran demasiado grandes.

Esto se debe a que considero muchas cosas que la gente olvida:

• Es hora de corregir errores
• Es hora de implementar
• Tiempo de gestión/reuniones/interacción
• Es hora de permitir que los propietarios de requisitos cambien de opinión
• etc.

El truco consiste en utilizar una programación basada en evidencia (consulte Joel en Software).

La cuestión es que si planeas un poco de tiempo extra, lo usarás para mejorar la base del código si no surgen problemas.Si surgen problemas, todavía estás dentro de las estimaciones.

Answer 8

Creo que Joel ha escrito un artículo sobre esto:Lo que puede hacer es pedirle a cada desarrollador del equipo que describa su tarea en detalle (cuáles son todos los pasos que deben realizarse) y pedirles que estimen el tiempo necesario para cada paso.Más tarde, cuando el proyecto esté terminado, compare el tiempo real con el tiempo estimado y obtendrá el sesgo para cada desarrollador.Cuando se inicia un nuevo proyecto, pídales que evalúen el tiempo nuevamente y multiplíquelo con el sesgo de cada desarrollador para acercar los valores a lo que realmente se espera.

Después de algunos proyectos, deberías tener muy buenas estimaciones.