¿Cómo crea con precisión los estimados para los proyectos de programación que recibe? [duplicar]

Realmente me gustó la idea de Programación basada en evidencia , y tuve cierto éxito con ella. Al usar medidas estadísticas de la precisión de su estimación pasada, le brinda un intervalo de confianza de cuán precisas serán las estimaciones futuras, en lugar de una fecha fija. Los inconvenientes que encontré fueron que requiere recordar actualizar una herramienta con el tiempo que dedica al final de una tarea, algo con lo que nunca he sido muy bueno para ser diligente, ya que es muy difícil hacerlo con precisión si cambia frecuentemente entre tareas . Además, a pesar de que se supone que tiene en cuenta la probabilidad de interrupciones y pistas laterales, aún siento que mis estimaciones eran un disparo en la oscuridad.

Recientemente, comencé a usar la técnica pomodoro , y realmente ha mejorado mi percepción sobre cuánto tiempo ininterrumpido y enfocado. Tiene la tarea de terminar ciertos tipos de tareas, y cuánto tiempo ininterrumpido y enfocado tengo disponible en un día típico. Los bloqueos mentales anteriores con el hecho de recordar registrar mi tiempo no son un problema porque básicamente es solo un botón al final de cada intervalo de 25 minutos para grabarlo. Actualmente estoy trabajando en una herramienta para mí que hibrida EBS y pomodoro para aprovechar lo mejor de ambos mundos.

A pesar de nuestra naturaleza a menudo sarcástica e irónica, los programadores son optimistas extremos cuando se trata de estimar cuánto tiempo tomarán las tareas.

No sigo una metodología formal, pero tengo un sistema que parece funcionar razonablemente bien.

Mi enfoque habitual es pensar en todas las tareas y averiguar cuánto tiempo me tomará (como desarrollador experimentado) hacerlas. Eso se convierte en mi línea de base. Si el proyecto lo realizará un grupo promedio de desarrolladores, duplicaré mi estimación. si será hecho por nuevos desarrolladores, lo triplicaré. Si lo hacen los internos, lo cuadruplicaré y advertiré a todos los afiliados que el producto final que producen los internos casi seguramente tendrá que ser desechado y reescrito. Los pasantes que escriben sistemas complejos son una idea horriblemente mala.

Esta es la estimación del esfuerzo. A partir de ahí, debe agregar tiempo para las pruebas, la implementación, la resolución de problemas y, por supuesto, las reuniones con el cliente. En un proyecto promedio para mí, esto representa aproximadamente el 10-20% de la estimación del esfuerzo.

Cualquier proyecto tendrá una cierta cantidad de incógnitas, por lo que puede comenzar con un 5% para las tecnologías establecidas con un producto final definido e ir tan alto como el 100% para la tecnología de punta con un objetivo móvil como objetivo final. Si sabe dónde están las grandes incógnitas (es decir, un nuevo marco para hacer XYZ), deje tiempo extra para todas las tareas que interactúan con esa incógnita.

Después de que hagas algunos proyectos, te darás una idea de dónde están tus puntos ciegos personales y aprenderás a rellenar esas áreas un poco más.

Naturalmente, una vez que le dé esta estimación a su supervisor, probablemente la duplicarán cuando la transmitan a las partes interesadas, simplemente porque saben cómo los programadores tienden a ser optimistas :)

No sé por qué, pero siempre parece funcionar bastante bien para que tome el cálculo promedio de los programadores involucrados y se multiplique por 3. Se siente como lanzar dardos en un tablero, pero a menudo se acerca. que los métodos de estimación más formales.

La precisión de la estimación del proyecto depende en gran medida de la capacidad de los clientes y hará que sus deseos se conviertan en requisitos de negocios sin introducir una gran dificultad. Y, la paciencia de los clientes para una planificación adecuada.

Teniendo en cuenta los buenos requisitos comerciales y la mínima dificultad, todavía enfrentamos el problema de estimar la complejidad ... no es tarea fácil.

Ahora, trabajo para las grandes empresas. A menudo, donde el software es un centro de costos. En este entorno, uno debe lidiar con un cierto nivel de calidad. Por debajo de lo que dice ... Google.

En un intento de compensar esta baja calidad, he encontrado mi propio método de ataque. Básicamente toma:

• Requisitos comerciales (que pueden estar en cualquier lugar del 1 al 100%) completa.
• Divida los requisitos en tareas.
• Ahora, puede cambiar las tareas a una línea de tiempo, consulte gantt gráfico, o vaya al paso 4.
• Convierta las tareas en requisitos técnicos de alto nivel. Esta Podrían ser formales los planes escritos. Pero, Normalmente no hago esto en papel. En su lugar, crea un conjunto de clases / interfaces sin implementación. Algo como refactor rojo / verde .
• Ahora, uno puede estimar con mayor precisión la complejidad para implementar Clases que dicen, "¿Cuánto tiempo durará? tomar para hacer un seguimiento de inventario sitio web? ".

Obviamente, hay mucha dependencia del equipo en el proceso. Así que mi consejo es tratar de ser alegre y hacer lo mejor que puedas. Hay tanto que podemos hacer.

Para fines de estimación a lo largo de los años, he desarrollado una "receta" para la tarea de estimación.

Primero, en lugar de calcular por horas, utilizo fracciones diarias, donde 0.25 son 2 horas (en base a 8 horas por día).

Intento desglosar cada tarea para obtener un máximo de 1 unidad (o 1 día). Después de eso, puede tener una buena estimación para producir una buena versión Beta.

Luego tuve un 45% de ese tiempo en refactorización / documentación / optimización y, finalmente, un 100% completo para la depuración y la prueba (en casa y con el cliente)

Cuando sumo todo lo que obtengo, para un estimado de 1 día, es el resultado de 20 horas de trabajo real.

Finalmente, divido esas 20 / {horas de trabajo reales} para obtener el número de días necesarios para desarrollar la versión final.

Inicialmente, la parte de prueba / depuración no se utilizará de inmediato, pero a la larga se terminará.

Combine eso con EBS y podrá obtener una fecha de entrega probable que funcione

Utilizamos la técnica de estimación de los componentes. Así es como llamamos al tipo de estimación que es más libre de riesgo para proveedores y clientes

Uno puede hacer uso de la estimación de tipo componente para todo el proceso de desarrollo. No es necesario volver a estimar desde cero cuando desee agregar, eliminar o reemplazar funciones, servicios, etc. Puede eliminar fácilmente una función sin afectar la precisión; como puede ver, este tipo es muy flexible. Es lo más cerca que se puede llegar al estimado de precio exacto. Con una estimación componencial clara, un prospecto tendrá una comprensión completa de lo que paga.

Pero para hacer una estimación de este tipo, debe tener requisitos claros, comprender todas las características del proyecto y qué servicios necesita su cliente. Normalmente no, pero deberías intentarlo. Como resultado, obtendrá un proyecto exitoso y un cliente feliz.

Espero que esta información te ayude! Para nuestro equipo es la mejor técnica para hacer una estimación precisa.

Lea la Estimación de software: desmitificando el arte negro por Steve McConnell. Se describen muchas técnicas diferentes.

Mi consejo es que proporcione un estimación de 3 puntos , ya que ayuda a comunicar el riesgo del trabajo que se está realizando. y te obliga a pensar en lo que podría salir mal.

También ejecute sus estimaciones antes que otra persona antes de comprometerse con ellas. Y si hay varias personas trabajando en la tarea, encontré que Planning Poker es una gran técnica.