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

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 ?

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 .

¿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).

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 ...

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.

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.

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.

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.