¿Cómo explicar que es difícil estimar el tiempo requerido para un proyecto de software más grande?

37

Soy un desarrollador junior y me resulta difícil estimar cuánto tiempo lleva terminar un proyecto de software más grande. Sé cómo estructurar la arquitectura en general, pero es difícil para mí saber qué detalles tengo que hacer y qué problemas tengo que resolver. Por lo tanto, es difícil estimar cuánto tiempo tomará terminar un proyecto más grande, porque no sé qué problemas necesito resolver y cuánto tiempo lleva resolverlos.

¿Cómo le explico esto a una persona que no es desarrollador de software ?

Jonas
fuente
55
Curioso: ¿por qué es tu trabajo como desarrollador junior explicar esto a los desarrolladores que no son de software? ¿Hay alguien en su grupo de trabajo o cadena de administración que pueda ayudarlo con el proceso de convencer a quien sea que necesite convencer?
Alex Feinman
@Alex: No, no es una persona en la misma compañía. Solo una persona con ideas para hacer una startup. Y soy el único desarrollador con el que tiene contacto.
Jonas

Respuestas:

48

Podrías pedirle que calcule cuánto tiempo le tomaría acceder a un lugar lejano en un rincón deshabitado del mundo. Como ejemplo extremo, elijamos un pico menos conocido en el Himalaya, donde muy pocas personas (si alguna) han subido. Ella necesitaría mucha preparación y práctica antes de comenzar el viaje, además de un montón de permisos, cada uno de los cuales puede retrasar el viaje durante meses o años ... y un buen equipo de apoyo ... luego una vez en la colina pendiente, ella tendría que esperar y orar por un buen clima para comenzar a subir hacia la cima ... etc. etc. La mayoría de estos son difíciles de estimar, incluso con experiencia previa.

Y el punto es: cada proyecto de software es un poco como escalar una nueva montaña, donde nadie ha estado antes, por lo que nadie tiene experiencia previa directa. Los desarrolladores experimentados pueden haber acumulado experiencia en proyectos más o menos similares , pero siempre habrá nuevos elementos y sorpresas; de lo contrario, si un proyecto de software fuera exactamente igual a otro anterior, no tendría ningún sentido hacerlo .

Péter Török
fuente
Más incógnitas significa más incertidumbre.
surfasb
99
Olvídate lejos. Pídales que estimen, al minuto, cuándo llegarán a casa del trabajo esta tarde. ¿Qué pasa si el tráfico es diferente, qué pasa si comienza a llover, qué pasa si recibe una llamada telefónica mientras conduce, etc. Si algo tan mundano, y realizado tan a menudo como el auto de regreso a casa, no se puede medir con ningún grado de precisión? ¿podemos esperar hacer una mejor estimación del tiempo requerido para implementar algún software complejo, que tiene innumerables variables cada vez más significativas que un miserable viaje a casa desde el trabajo?
quentin-starin
8
@qes, uso el transporte público, así que puedo decir con un 10% de precisión cuándo llegaré a casa. Creo que la mayoría de los gerentes de proyectos de SW estarían contentos con este nivel de precisión ;-)
Péter Török
1
Los objetivos del proyecto de software también cambian, por lo que después de estimar el tiempo que necesitarían, el OP podría preguntarles si todavía estarían a tiempo después de que alguien les dijera que cambiaran los picos cuando estaban a la mitad del primero.
Paul
18

¿Le has explicado eso a la persona? Usted es el ingeniero de software profesional, por lo que la persona para la que está construyendo el software debe considerar sus conocimientos y comentarios cuando se trata del diseño e implementación de sistemas de software.

El cono de incertidumbre es probablemente un buen punto de partida. Los proyectos de software son difíciles de estimar hasta que se conozcan más detalles, lo que sucede más adelante en el proyecto. Además, los requisitos cambiantes también cambiarán las estimaciones. Sus estimaciones iniciales al comienzo de un proyecto tendrán una gran variabilidad.

Es posible que también le interesen otras técnicas de estimación. Mencionaste que solo eres un desarrollador junior. En general, los desarrolladores más experimentados tienen una mejor capacidad de estimar ya que han visto más problemas, los resolvieron y (con suerte) realizaron un seguimiento de la estimación en comparación con el tiempo real. Podrías aprovechar esto usando técnicas de estimación como delphi de banda ancha o planificación de póker .

Como desarrollador junior, comience a hacer un seguimiento de las estimaciones y el tiempo real ahora. Es posible que le interese leer sobre el Proceso de software personal desarrollado en el Software Engineering Institute. Los libros básicos de PSP son Una disciplina para la ingeniería de software , PSP: Un proceso de auto-mejora para ingenieros de software e Introducción al proceso de software personal . Creo que la Introducción al proceso de software personal cubriría los temas que le resulten más útiles. Creo que, en general, es excesivo para la mayoría de los desarrolladores, pero tiene algunas buenas ideas y buenas prácticas que se pueden extraer y utilizar para mejorar la productividad personal y perfeccionar diversas habilidades (incluida la estimación) que utilizará continuamente durante su carrera.

Si va a hacer mucho más trabajo en la estimación, le recomendaría dos de los libros de Steve McConnell: Estimación de software: Desmitificar el arte negro (se centra en la estimación como arte y ciencia) y Desarrollo rápido: Programación de software Taming Wild (software general proceso de ingeniería y temas de gestión de proyectos).

Thomas Owens
fuente
7

Consulte la literatura. Hay una gran cantidad de material complejo y a menudo contradictorio que, como lo demuestra la práctica (experimentos), no funciona como se esperaba. Al menos los académicos se dejan llevar por una pila de libros.

Debe leer: http://en.wikipedia.org/wiki/The_Mythical_Man-Month

The Mythical Man-Month: Ensayos sobre ingeniería de software es un libro sobre ingeniería de software y gestión de proyectos de Fred Brooks, cuyo tema central es que "agregar mano de obra a un proyecto de software tardío lo hace más tarde". Esta idea se conoce como la ley de Brooks y se presenta junto con el efecto del segundo sistema y la defensa de la creación de prototipos.

Las observaciones de Brooks se basan en sus experiencias en IBM mientras gestionaba el desarrollo de OS / 360. Había agregado más programadores a un proyecto retrasado, una decisión que luego concluiría de manera contraintuitiva que había retrasado el proyecto aún más. También cometió el error de afirmar que un proyecto, escribir un compilador ALGOL, requeriría seis meses, independientemente de la cantidad de trabajadores involucrados (requirió más tiempo). La tendencia de los gerentes a repetir tales errores en el desarrollo del proyecto llevó a Brooks a decir que su libro se llama "La Biblia de la Ingeniería del Software", porque "todo el mundo lo cita, algunas personas lo leen y algunas personas lo siguen". El libro es ampliamente considerado como un clásico sobre los elementos humanos de la ingeniería de software ...

Jürgen Strobel
fuente
2

Descubra lo que planean hacer con esta estimación. En su opinión, quieren saber si llevará meses o años y está tratando de obtener las horas exactas (Ingeniero típico).

Vea si puede trabajar en una parte del proyecto y luego haga una mejor estimación si es necesario.

Si continúan presionando, se verá obligado a detallar la mayor cantidad de tareas que pueda y aplicar un marco de tiempo. Dígales que les hará saber tan pronto como vea algo que pueda afectar la estimación y haga ajustes. La gente generalmente trata de evitar sorpresas.

JeffO
fuente
1

He conocido personas que afirman que pueden estimar el software, pero no sé cómo lo hacen. Ninguno de ellos ha podido explicar cómo lo hacen.

Como consultor, mis clientes a menudo requieren que trabaje en base a una oferta fija. Por lo tanto, necesito estimar para poder preparar una oferta realista. Nunca he tenido éxito en esto. Uno pensaría que sobrepondría tantas veces como subestimé, pero ese nunca es el caso. El resultado es que a menudo pierdo mucho dinero en mis contratos y termino ganando mucho menos de lo que ganaría si estuviera trabajando para una empresa como empleado regular.

He estado buscando durante muchos años un libro que me enseñe cómo calcular el software, pero aún no he encontrado uno.

En cuanto a explicar esto a alguien que no es un codificador. Podría señalar que nadie en la industria es capaz de cumplir sus estimaciones de manera consistente. Sucede todo el tiempo que se anuncian nuevos productos de software, solo para enviar meses o años después de la fecha que se anunció originalmente.

Si una gran empresa como Microsoft no puede descubrir cómo calcular el tiempo que lleva producir sus propios productos, ¿cómo puedo hacerlo?

Ya sea que me paguen por hora o por el trabajo, mis clientes siempre esperan que proporcione estas estimaciones. No sé cómo esperan que los produzca cuando tal estimación no se enseña en ninguna parte, y no tengo una base racional para mis estimaciones.

Mike Crawford
fuente
1
El libro de Steve McConnell Software Estimation: Desmystifying the Black Art es realmente bueno para explicar cómo estiman los ingenieros de software. Puede aprender técnicas y herramientas, pero la única forma de ser bueno en la estimación es estimar continuamente, aprender de sus estimaciones y repetir. Como nadie puede cumplir con las estimaciones de manera consistente, hay organizaciones que constantemente se encuentran dentro de un par de puntos porcentuales en sus estimaciones: el libro de McConnell habla sobre organizaciones (a menudo CMMI Nivel 4 o 5, con mejora continua y seguimiento detallado) que logran esto consecuentemente.
Thomas Owens
En cuanto a su problema con malas estimaciones. ¿Lleva un registro de su estimación frente al tiempo real de finalización? Si es así, determine por qué factor subestima y multiplique todas sus estimaciones por ese número.
kubi
0

La estimación del tiempo completo del proyecto generalmente la realiza el gerente del proyecto, no el programador.

Puede crear un argumento basado en el hecho de que el gerente del proyecto tiene la lista completa de tareas requeridas. Sin esta lista, cualquier estimación será una "mala" suposición.

Además, el tiempo depende de muchos factores, como la cantidad de personas disponibles y el alcance de los requisitos, que usted no dijo que tenía. La arquitectura sola no es suficiente.

Ninguna posibilidad
fuente
Dependiendo de la metodología de gestión del proyecto, es posible que el PM ni siquiera tenga la lista completa de tareas. En algo como la gestión de proyectos de olas sucesivas, a menudo hay un cubo nebuloso que describe un nivel de tarea muy alto que generalmente es demasiado grande para estimarlo con un nivel de confianza decente. A medida que finalizan las tareas anteriores, las tareas que forman parte de este grupo están más bien definidas y pueden estimarse. En los métodos ágiles, las tareas se agregan, eliminan o priorizan con frecuencia en varios puntos, lo que nuevamente dificulta la estimación de hitos a largo plazo más allá de un par de iteraciones.
Thomas Owens
0

Otro punto que podría señalar es que la ingeniería de software todavía está en su infancia en comparación con otros campos de la ingeniería, y no ha madurado lo suficiente como para que aparezcan técnicas de desarrollo estimables.

La ingeniería de software también está en un estado continuo de flujo. Cuando una tecnología ha existido lo suficiente como para considerarse madura, a menudo se abandona en favor de alguna nueva tecnología. Eso evita que cualquiera gane suficiente experiencia con cualquier tecnología para poder producir estimaciones confiables.

Contraste esto con la estimación de la construcción. Ese es un problema muy bien entendido, no solo porque los contratos se otorgan en función de las ofertas, sino porque la humanidad ha estado construyendo cosas desde los albores de la civilización.

Mike Crawford
fuente
1
La ingeniería de software es aún más joven (con diferencia) que la mayoría de las otras disciplinas de ingeniería a una edad de 42 años. Sin embargo, hay varias técnicas y herramientas de estimación maduras. Wideband Delphi (desarrollado en la década de 1970, popularizado por Software Engineering Economics de Barry Boehm en 1981), puntos de función (1979), SEER-SEM (raíces en la década de 1960), estimación basada en proxy (utilizada en la PSP, desarrollada en 1994 en SEI) y COCOMO (1981) y COCOMO II (1997). En un campo de solo 42 años, ya hay casi 40 años de trabajo realizado en la estimación de proyectos.
Thomas Owens