¿Qué tan posible es estimar el tiempo para programar proyectos? [duplicar]

Nuestro anfitrión Joel recomienda programación basada en evidencia , que incluye métodos para dar cuenta de una estimación inexacta , interrupciones y distracciones, y todos los demás sospechosos habituales.

Los elementos más grandes de la explosión:

• La persona haciendo un trabajo determinado tiene una última palabra en su estimación. No se permite a los gerentes, líderes o comités anular las estimaciones, solo reasignar el trabajo a otra persona.
• Cuanto más se desglosen las tareas, más confiable será la estimación final. El efecto es doble: primero, los errores por encima o por debajo de la estimación tienden a cancelarse entre sí más, y segundo, para realizar el desglose, terminas pensando en el trabajo con más detalle, lo que mejora la precisión general.

Realmente me gusta el libro Estimación de software: desmitificando el arte negro de Steve McConnell. Un par de puntos realmente importantes en los que se centra:

1. ¿Está buscando una estimación o un objetivo? Una estimación significa "¿Cuánto tiempo llevará implementar estas características?" Un objetivo significa "¿Cuántas características puedo implementar para esta fecha?" Son dos cosas diferentes, y es importante asegurarse de que todos los involucrados sepan de qué están hablando y no confundirlos.

2. Tenga cuidado de dar una estimación con demasiada precisión, especialmente antes. No dé estimaciones de un solo punto; si su mejor estimación al comienzo de un proyecto es de 4 semanas, calcule algo así como "2 a 8 semanas". Es imposible ser más preciso hasta que trabaje en las fases del proyecto (desarrollo de requisitos, diseño, etc.) que eliminan parte de la incertidumbre.

Recomendaría dividir la tarea tanto como sea posible antes de realizar cualquier evaluación, este ejercicio solo lo forzará a tener una comprensión profunda de lo que tiene que hacer y cómo planea hacerlo. Una vez hecho esto, aumentas tus posibilidades de comparar la subtarea con algo que ya has hecho y tienes algo más cercano a la realidad. Si la especificación de lo que tienes que hacer no está clara, también lo descubrirás en este momento, lo que es bueno.

Las tareas de más de 40 horas difícilmente se pueden evaluar con precisión, si su gerente de proyecto es bueno, ¡lo sabrá! Está bien estar equivocado, la experiencia es la única cosa real que marcará una diferencia real en sus evaluaciones (y al final, solo lo ayudará a estar más cerca de una respuesta correcta, no a la perfección).

También tuve una experiencia muy agradable con la planificación del póquer, cuanto más lo utiliza mi equipo, mejores son sus evaluaciones (¡y además es divertido!)

Trabajar como freelancer es un problema constante para mí. Si me equivoco, pierdo dinero.

El problema con la estimación de la programación es precisamente el que varias personas han identificado aquí: son las incógnitas y los errores que pueden explotar y estimar en la tierra de nunca jamás.

Cada vez más, lo que uso es un enfoque doble

A. Si el problema está en un dominio conocido en el software con el que estoy totalmente familiarizado, realizo un desglose mental directo y doy una cotización. A menudo, con los clientes que solicitan un estadio de béisbol por adelantado cuando se habla del proyecto y con estos, por lo general estoy feliz de estar de acuerdo, estoy del lado de la precaución, pero esto es solo la experiencia basada en proyectos anteriores.

B. Si el problema es un dominio desconocido. En este caso, intentaré identificar cuáles son los problemas principales por adelantado y codificaré un caso de prueba en torno a ellos para "analizar" el problema. A veces, se puede persuadir al cliente de que pague por esto como un estudio de "factibilidad", pero incluso si no puede dedicar el tiempo sin pagar y el alcance del problema es más barato que citar al cliente X, entonces encontrar el tiempo necesario para resolverlo es nx. p>

Identificar qué problemas caen en A o B, e identificar cuáles son los elementos de crux en B, se debe a la experiencia, pero creo que la regla general es universalmente aplicable: siempre aísle los problemas de crux por adelantado y enfréntelos primero. Una vez que se conozcan, se pueden utilizar técnicas más convencionales con cierta confianza.

Este es el mejor método que he usado: enlace

Todavía no es perfecto, pero si lo haces bien, al menos te mete en el estadio.

Aquí hay dos métodos de estimación que he usado en el pasado. Funcionan, pero no los recomiendo.

1. Estima cuánto tiempo crees que debería tomar, y luego duplícalo. Al comienzo de cada proyecto, dejé en claro que los cambios aumentarían la cantidad de tiempo. También recordaría esto cada vez que se solicita un cambio. Es un método de estimación bastante simple, pero fue imposible establecer algo realista porque la empresa no creía en las metodologías o las reuniones.

2. Se hará cuando se haga. Por lo general, esto solo funciona para proyectos de tiempo libre, pero logré convencer a un ex gerente cuando se dio cuenta del método de doble adivinación. Creo que la única razón por la que funcionó es porque el beneficio esperado del proyecto fue enorme y la necesidad de la solución se consideró crítica. Su única alternativa era comprar software comercial, que se negaron a hacer el 99% del tiempo.

Tardará entre 6 y 8 semanas.

Pase un par de días de planificación, y divida el proyecto en unidades de 2 o 3 días, y luego tome en cuenta el tiempo dedicado a las actividades que no son de desarrollo. Pero cualquier cosa más larga que unas pocas semanas, será una estimación basada en otros proyectos de dificultad similar.

Cuando surgen cosas inesperadas, reaccionamos cambiando la arquitectura, el diseño o el código, etc. La estimación en sí misma debería evolucionar junto con esas cosas. No debe ser un valor determinado al comienzo de un proyecto y nunca debe actualizarse cuando todo , de lo contrario, se puede actualizar y evolucionar durante el proyecto.

Una cosa es que la estimación es posible solo si está trabajando con algo familiar, utilizando tecnologías familiares. Si está trabajando en algo realmente nuevo, las estimaciones de tiempo ciertamente no se mantendrán. Sin embargo, hacer un plan (romper el proyecto en pedazos y ordenarlos de alguna manera) es bastante beneficioso por sí mismo, incluso si las estimaciones de tiempo son realmente solo suposiciones. Su primer ministro probablemente sabe esto; lo principal es hacer algún tipo de plan , no que las estimaciones sean correctas.

la experiencia cuenta. Sabes lo que sucedió la última vez y el tiempo anterior a eso, y sabes cuánto puedes hacer por un tipo particular de tarea, por lo que la estimación es realmente fácil. Yuo elige un número del aire basado en una suposición educada. A medida que adquiera más experiencia en la estimación y el desarrollo, descubrirá que lo mejora.

Nunca serás lo suficientemente perfecto como para satisfacer a un administrador de proyectos y sus diagramas de Gantt (suspiro, tales cosas deberían tener bordes borrosos habilitados de forma predeterminada) pero está estimando el tiempo, no dando una garantía tiempo.

Para mí, es solo algo que viene con la experiencia. Cuando era pequeño como programador, parecía que siempre estaba subestimando la duración de un proyecto. Como dijiste, las cosas surgirían y el proyecto tomaría más tiempo. Ahora que tengo "tiempo de vuelo", soy mucho mejor para anticipar cuáles son esas "cosas". Aún sucederán cosas inesperadas, pero en general los plazos son mucho más precisos en estos días.

Recomendaría encarecidamente "Estimación y planeación ágiles" por Mike Cohn. Describe la estimación relativa basada en puntos que es más fácil de hacer por la naturaleza humana. Este libro también describe la planificación del póker, que es realmente divertido.