Era mi trabajo de freelance en oDesk. He realizado varios trabajos antes en un tiempo determinado, pero esta fue la primera vez que no cumplí el plazo. Fue un trabajo muy largo y lo intenté lo mejor que pude, pero aún no cumplí el plazo. Ahora tengo mucho miedo. Porque es mi culpa que no haya cumplido el plazo.
Mi pregunta es: ¿Es esto una gran preocupación o se pierden los plazos comunes entre los trabajos de programación, por lo que no debería preocuparme demasiado por esto?
Respuestas:
Si. Los plazos vencidos son comunes en el desarrollo de software.
Muchos freelancers cumplen con los plazos incurriendo en deudas técnicas u ocultando la suciedad debajo de la alfombra.
Parafraseando el mes del hombre mítico de Frederick Brooks :
A menudo se pierden los plazos porque los líderes del proyecto continúan estimando las tareas de software de la misma manera que las tareas de ingeniería civil, lo cual es un enfoque defectuoso porque el software es una industria artesanal novedosa sin un cuerpo claro de normas. Esto es tan cierto que no puede revocar el "permiso" de un programador para codificar por negligencia, ni puede demandar a alguien por programar sin un título.
El desarrollo de software tiene una complejidad inherente que otras disciplinas carecen. Un gran programa puede tener más componentes que un automóvil, y estos componentes pueden interactuar de más formas diferentes.
El software es difícil de visualizar, por lo que se utilizan diferentes tipos de diagramas para ver diferentes aspectos de un proyecto, y estos aspectos pueden no ser ortogonales. La ingeniería civil, por otro lado, tiene planos que le permiten ver plomería, cableado, etc., todo en la misma tabla (o capas) de forma ortogonal.
No es común, después de que un puente o edificio esté medio construido, que el cliente cambie completamente el alcance del proyecto. Este suele ser el caso en proyectos de software.
El estado del arte en el desarrollo de software no ha llegado al punto en que los proyectos de software sean repetibles y casi libres de riesgos. Incluso las compañías de software más grandes como Microsoft pueden perder los plazos por meses o años.
La mayoría de los programas de vapor no son más que proyectos de software que se cortaron debido a este tipo de problemas.
En conclusión:
Las malas estimaciones y la subestimación de la complejidad, debido a la naturaleza artesanal del proceso de desarrollo de software, significa que sigue siendo una disciplina inmadura.
fuente
makeo lo que sea). Lo que es 'plan' en informática sería un 'plan de plan 'en ingeniería. La diferencia es quemakeen ciencias de la computación lleva pocas horas, mientras que escribir el código fuente (incluidas las pruebas y la integración) lleva meses, mientras que en ingeniería la planificación puede llevar meses (incluido el cálculo estructural) mientras que la construcción lleva años. Por lo tanto, la variación de la planificación tiene un impacto menor en este último.Los plazos vencidos no deberían convertirse en una práctica común si desea continuar obteniendo empleos.
Dicho esto, por lo general, desea dejar un margen adicional de "meneo" en sus estimaciones en caso de que suceda algo (y siempre sucede). No necesita revelar que ha agregado tiempo adicional, simplemente no lo haga irrazonable. ¿Quizás entre 5 y 10% del tiempo total? La única forma de averiguarlo es hacerlo varias veces.
Para ser realmente bueno en las estimaciones, debe saber cuánto tiempo lleva codificar un cierto tipo de widget ... por ejemplo, supongamos que debe crear un widget de desplazamiento infinito para el cliente X. Si le toma una semana para implementarlo en producción sin errores, puede usarlo como base para sus estimaciones de desplazamiento infinito.
fuente
La falta de plazos no es infrecuente en el desarrollo de software. Es casi imposible estimar con precisión cuánto tiempo llevará un proyecto de software.
La profesionalidad se muestra en la forma en que lo manejas. Cuando sepa que perderá una fecha límite, informe a su cliente lo antes posible para que pueda planificar en consecuencia.
fuente
Es bastante común, pero puedes mejorar en eso. Es posible que desee considerar la estimación utilizando algo abstracto como los puntos de la historia , y realizar un seguimiento de su velocidad para calcular sus estimaciones reales. Esos conceptos se asocian más comúnmente con scrum, pero se pueden usar incluso si no lo haces.
Lo sorprendente de la velocidad es que abarca todas las cosas intangibles como interrupciones y complejidad inesperada que los desarrolladores tienen dificultades para explicar en sus estimaciones. Todas las probabilidades promedian con el tiempo. Con un promedio de más de 10 semanas, nuestras estimaciones de velocidad han sido precisas en aproximadamente un 5%. Sin embargo, cuando estimamos las mismas tareas en horas, el mismo equipo exacto subestima constantemente en un 30-50%.
fuente
Mi teoría (no comprobada) es que los humanos han evolucionado para subestimar los trabajos complicados en dos o tres a uno. Cada vez que el Congreso le pregunta a la NASA algo como: ¿cuánto costará construir un transbordador o viajar a la luna? Regresan dentro de una semana con un número. Después de que se agoten todos los costos esperados, descubren que costará tres veces más.
Tuvimos una broma en la década de 1970: tome cualquier estimación del programador, duplique el número y luego muévalo a la siguiente unidad de tiempo. Por lo tanto, si un programador dice que se puede hacer en dos semanas, lo terminará en cuatro meses.
Si alguien ha remodelado una cocina, generalmente piensan 'Bueno, lo haré en dos semanas'. Lo terminan unas seis semanas después.
fuente