Historias
Slashboxes
Comentarios
 

Login Barrapunto

Login

[ Crear nueva cuenta ]

10 razones por las que fallan las estimaciones de plazos

editada por Candyman el 31 de Julio 2010, 09:01h   Printer-friendly   Email story
desde el dept. te-estimo,-bastante
El proyecto está mal especificado, el tiempo de desarrollo está estimado por gente que no son programadores, los desarrolladores son demasiado optimistas en sus estimaciones, cada fase del proyecto es demasiado grande, los programadores usan todo el tiempo que se les da, se comete el error de pensar que más desarrolladores equivalen a menos tiempo de desarrollo, las especificaciones cambian a medio proyecto (pero el tiempo estimado se deja fijo), se olvida el tiempo de pruebas, y las estimaciones se toman demasiado literalmente. Estas son las 10 razones por la que fallan las planificaciones de proyectos de software según Sitepoint. ¿Os parece que falta alguna?

Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • por Barru (48325) el Sábado, 31 Julio de 2010, 09:29h (#1230634)
    El jefe de proyecto ó desarrollador subcontratado que se olvida del proyecto hasta la última semana antes de la fecha de fin de proyecto.
  • tiempos muertos

    (Puntos:2, Interesante)
    por topper_harlie (30728) el Sábado, 31 Julio de 2010, 09:30h (#1230636)
    yo añadiría que cuando hacemos la estimación pensamos en las 8h de trabajo diarias, y siempre hay distracciones (me refiero a distracciones legitimas, como atender a algún cliente, asistir a compañeros, reuniones, "apagar algún fuego" etc), que en el caso de algunos puestos pueden mermar el tiempo de desarrollo bastante y aunque es parte del trabajo, casi nunca se cuenta en las planificaciones.
  • Sí y no

    (Puntos:5, Interesante)
    por ejimenez (23107) el Sábado, 31 Julio de 2010, 09:36h (#1230641)
    ( http://www.ingsoftagil.com/ | Última bitácora: Viernes, 24 Septiembre de 2010, 22:50h )

    Todos esos puntos son correctos, pero en esencia, o en la raíz de todos ellos, hay una única razón por la que las estimaciones suelen fallar. Como explica Martin Fowler aquí [martinfowler.com], las técnicas de estimación predictivas sólo funcionan con problemas predictivos, predecibles, deterministas.

    Los problemas adaptativos, no predictivos, y especialmente los problemas perversos [wikipedia.org], requieren técnicas de estimación adaptativas, como por ejemplo las utilizadas por los métodos ágiles (Scrum, XP, Evo, etc...).

    Perdonad la autocita, pero un libro que expone exhaustivamente los fallos de la ingeniería de software clásica, y de los métodos clásicos de estimación o medición, como COCOMO y Puntos de Función, es Ingeniería de Software Ágil [ingsoftagil.com].

    También os recomiendo un artículo [idiom.com], relacionado con la complejidad algorítmica, donde se demuestra matemáticamente por qué no es posible predecir la duración de los proyectos de Software, de forma objetiva y a priori.

    • Re:Sí y no de Candyman (Puntos:2) Sábado, 31 Julio de 2010, 09:47h
    • Re:Sí y no de lechosopowers (Puntos:2) Sábado, 31 Julio de 2010, 10:07h
      • Re:Sí y no de ejimenez (Puntos:2) Sábado, 31 Julio de 2010, 10:50h
        • Re:Sí y no de MaGaO (Puntos:2) Domingo, 26 Septiembre de 2010, 10:24h
    • Re:Sí y no de angrychai (Puntos:1) Domingo, 01 Agosto de 2010, 19:29h
    • Re:Error de concepto de pobrecito hablador (Puntos:1) Sábado, 31 Julio de 2010, 12:08h
    • 1 respuesta por debajo de tu umbral de lectura actual.
  • eso

    (Puntos:1, Inspirado)
    por pobrecito hablador el Sábado, 31 Julio de 2010, 10:57h (#1230669)
    Yo creo que es un asunto meramente social, donde los programadores solo reciben en raras ocasiones un migaja del beneficio, todo tipo de metodologías solo son validas si hay fe.Estoy cansado de directivos que en las reuniones semanales con la boca llena dicen, " estamos creando", "vamos a hacer", "esto es algo grande" y de repente te dicen , ... si pera para cuando estará....
  • por eggun (1255) el Sábado, 31 Julio de 2010, 12:04h (#1230683)
    ( http://www.linux-party.com/ | Última bitácora: Miércoles, 03 Junio de 2009, 15:55h )
    El tiempo de pruebas, suele ser muy corto, esa sería una de las fallas más importantes.
  • Añadiría al menos dos más

    (Puntos:2, Inspirado)
    por faragon (17575) el Sábado, 31 Julio de 2010, 13:29h (#1230693)
    ( http://www.voluntariado.net/ | Última bitácora: Martes, 07 Diciembre de 2010, 19:25h )
    • El que a menudo la gente se pierde por lo accesorio durante el primer 0-50% del tiempo de desarrollo, despierta en el 50-75%, y se tira de los pelos en la fase final del 75-100%. Y luego, claro, es que "era difícil", "eso no se podía prever", "es que no se acaba", etc.
    • No empezar ningún desarrollo sin tener las cosas claras, y que tal desempeño esté asignado a alguien que esté capacitado para ello. Las tareas y responsabilidad estarían asignadas por persona, no transferible salvo imprevisto. En mi opinión, es mejor tener 1 programador excelente que 5 chapuceros, o 2 excelentes antes que 15 (los resultados empeorarían geométricamente).
  • Arbeitmachfrei

    (Puntos:1, Divertido)
    por pobrecito hablador el Sábado, 31 Julio de 2010, 19:06h (#1230720)
    La razon principal se produce cuando El jefe de proyecto se encariña con los programadores y los sobrealimenta con donuts,descuida la provision de cafeina y no les fustiga con el latigo al ritmo adecuado.
  • Erase una vez que se era...

    (Puntos:1, Informativo)
    por pobrecito hablador el Sábado, 31 Julio de 2010, 19:44h (#1230725)

    Vamos a contar historias alrededor del fuego.

    Recuerdo una vez en que la empresa para la que trabajaba ganó un concurso en cierto ayuntamiento para implantar un sistema. Al revisar la documentación y los plazos, los técnicos alertamos sobre los plazos, DEMASIADO CORTOS, pero no nos hicieron ni puto caso.

    En fin, al empezar la implantación del sistema en cuestión, el coordinador de proyectos de dicho ayuntamiento (diría supuesto, porque menudo pieza) va y nos suelta que por la experiencia que tenía los proyectos solían tener un retraso de no recuerdo cuántas semanas.

    Es decir, que te meten unos plazos que luego ellos mismos saben que no se van a respetar. El caso es que a ver qué vas a decir, pero menudos jetas. Obviamente, la culpa de los retrasos toda nuestra, no de ellos ni de los plazos irrisorios impuestos.

    Si una cosa he aprendido con el tiempo es que las prisas no son buenas y al final los proyectos salen en el mismo tiempo si corres o si vas andando. Y mejor no estresarse.

  • La principal

    (Puntos:2, Divertido)
    por pobrecito hablador el Sábado, 31 Julio de 2010, 23:38h (#1230745)
    ¡Esto es ESPAÑAAAAAA! (A lo Leonidas)
  • Referencias bibliográficas

    (Puntos:3, Interesante)
    por aquerman (36565) el Domingo, 01 Agosto de 2010, 01:30h (#1230758)
    ( http://xr.com/aquerman | Última bitácora: Jueves, 18 Noviembre de 2010, 07:15h )

    El punto número 6 sobre por qué el número de programadores no es proporcional a la productividad, está muy bien explicado en el clásico The Mythical Man Month [wikipedia.org] de Fred Brooks [wikipedia.org].

    También recomiendo un libro (bastante extenso) que cubre todos estos puntos y más, llamado Rapid Development [stevemcconnell.com] escrito por Steve McConnell [stevemcconnell.com].

    Opino que cualquier personal que vaya a ser jefe de proyecto o a realizar estimaciones sobre tiempos, debería conocerse de memoria todas estas cosas.

  • Combinación lineal de problemas

    (Puntos:2, Inspirado)
    por pobrecito hablador el Domingo, 01 Agosto de 2010, 10:47h (#1230796)
    Si te dedicas sólo a programar es una historia, pero si además de eso tienes que mantener todos los equipos de la red local, mantener los de una red distante, es otro cantar.

    Si aparte de eso resulta que quien tiene que explicarte lo que tienes que hacer, tampoco lo tiene claro, también es otro cantar.

    Si primero te explican un 80% de los casos (1 solución) y el 20% restante tienen que ser 20 soluciones distintas, también es otro cantar.

    Si el desarrollo es para una planta productiva que está a 1200 km, también es otro cantar.

    Si nadie tiene claro el alcance del proyecto, es otro cantar.

    Si el/la analista que mejor conoce el proyecto abandona (o le hacen abandonar) en mitad del proyecto, también es otro cantar.

    Si resulta que a medida que avanzas en el proyecto surgen más proyectos igual de urgentes, o a veces incluso más, también es otro cantar.

    Si tu jefe no entiende lo que haces, y le parece que todo es sencillo y que te cuesta miseria cambiar algo, también es otro cantar.

    Si hay que hacerlo todo (programar y dar soporte) y encima en un idioma extranjero, también es otro cantar.

    Y si encima resulta que los problemas del proyecto son una combinación lineal de los anteriores, no te puedes imaginar en que lio te has metido.

    Sálvese quien pueda
  • Es mas simple

    (Puntos:2)
    por Lock (3731) <{lock_peter} {at} {yahoo.es}> el Lunes, 02 Agosto de 2010, 13:15h (#1230962)
    ( http://barrapunto.com/ )
    Los plazos no se cumplen nunca porque es imposible predecirlos para algo superior a una modificacion-chorrada o un pequeño error del que ya sabes la causa.

    Cuando más codigo se involucra y más requerimientos se involucran y más tecnologías se involucran lo que haces es añadir variantes imponderables como nivel de conocimiento 'desconocido', nivel de detalle de los requerimientos 'desconocido' o problemas de cada tecnología 'desconocidos' (como impactos en tiempo) y se alarga la lista con bajas medicas, traceo y solucion de errores (que SIEMPRE los hay y en una cantidad imponderable en cuanto a lo que van a consumir de tiempo (busca la causa de que hoy la aplicacion no conecte, ¿una hora? ¿un dia? ¿una semana (es posible)? ) etc etc.

    Y los listos responden: pero mis técnicas mega guays me dicen que como la otra vez pintando monas fueron 2 semanas ahora calzando caballos son dos semanas. O la version friki: que en realidad es culpa del programador que no sabe hacer pruebas unitarias a 50k lineas de codigo en sus ratos libres-
    --
    ¿¿PETER?? ¿Demostenes? Y actualmente Lockpeter
  • Desarrollo en bazar

    (Puntos:1)
    por jabelchi (48338) el Martes, 03 Agosto de 2010, 09:46h (#1231086)
    Muy ciertos todos los puntos que aporta el escrito. El punto 6 (más desarrolladores != desarrollo más rápido) es completamente cierto (lo he experimentado en persona). Sorprendentemente, el desarrollo en bazar típico del software libre rompe estrepitosamente con esta tesis. Cientos (o miles) de desarrolladores sin ninguna estructura jerárquica son capaces de entregar algunos de los mejores softwares desarrollados en tiempos sorprendentes. Evidentemente, ninguna empresa comercial se podría permitir pagar las horas invertidas por todos esos voluntarios.
  • Re:Leyes de Murphy

    (Puntos:1, Inspirado)
    por pobrecito hablador el Sábado, 31 Julio de 2010, 17:31h (#1230710)
    O no pejar ojo por tener un bebé, ansiedad por problemas económicos (hipotecas, pareja en paro, etc.), problemas de salud, etc. Que son cosas que no se contabilizan, pero tienen mucha influencia.
    [ Padre ]
  • 4 respuestas por debajo de tu umbral de lectura actual.