project management - tecnicas - Evaluar las estimaciones de software: ¿signos seguros de cifras poco realistas?

métodos para calcular los tiempos y costos del proyecto.

Question

Mientras respondía " Tratando con terribles estimaciones " publicado por Ash , compartí algunos consejos que aprendí y uso personalmente para detectar estimaciones débiles. ¡Pero estoy seguro de que debe haber muchos más!

¿Qué heurística usar en el escenario cuando se necesita hacer una evaluación rápida de la estimación del proyecto de software que ha sido compilada por un tercero (un colega, un socio comercial o una empresa externa)?

¿Cuáles son los signos obvios y no tan obvios de las estimaciones de software débiles que se pueden detectar sin un conocimiento detallado de la tarea en cuestión?

Answer 1

¿Cuáles son los signos obvios y no tan obvios de las estimaciones de software débiles que se pueden detectar sin un conocimiento detallado de la tarea en cuestión?

Las estimaciones que se dan sin mucho conocimiento detallado de la tarea en cuestión generalmente no son buenas.

Quizás un enfoque general que podría tomar es verificar que los elementos en los requisitos correspondan a los que figuran en el presupuesto. Si quieres ser muy rápido, comprueba los tamaños relativos, si hay una estimación de 100 palabras para un escrito de 100.000 palabras, no hay ninguna posibilidad de que sea correcto.

También (como han dicho otros) compruebe que se mencionan el análisis, la codificación, la depuración, las pruebas, la integración, la contingencia, etc. Muestra que se ha pensado algo.

Tener éxito y firmar los criterios en varias etapas es una gran señal. Si tienen un punto definido que está al 10% hecho al menos si la estimación es incorrecta, lo sabes temprano y tienes la oportunidad de adaptarte. Si no hay puntos de control hasta que "termine", es posible que no sepa que está rezagado hasta que llegue esa fecha.

Answer 2

Compruebo las estimaciones contra el poder del hombre. Aunque no es una heurística muy precisa, está claro si un trabajo masivo tiene solo uno o dos desarrolladores asignados a él, que la tarea no se estimó correctamente

Answer 3

Las estimaciones de la forma 3, 6 o 12 meses (básicamente cualquier número redondo ) apestan a adivinar. Por lo general, cuando adivina que elige un número redondo más grande de lo que cree que tomará, cuartos, medio año, etc., son los sospechosos habituales. Prefiero las estimaciones en términos de iteraciones de desarrollo reales (cualquiera que sea su tamaño).

Answer 4

Nadie lo ha dicho, así que lo haré. La respuesta obvia es que si tiene estimaciones de programación de software, entonces esa es una señal segura de cifras poco realistas. Sí, hay muchos métodos para estimar software, pero ninguno de ellos es preciso de ninguna manera, forma o forma. Lo que generalmente sucede es que los plazos están establecidos. Si la tarea se sobreestima, se gastará más tiempo para mejorar el resultado. Si la tarea está subestimada, se sacrifica algo para cumplir con la entrega (como pruebas y funciones).

Sé que esta respuesta no es lo que la gente quiere creer, pero estimar siempre es una suposición. La mayoría de las veces, un desarrollador no puede predecir cuánto lograrán al final del día. Esperas que adivinen cosas meses / años en el futuro sobre algo que ni siquiera están seguros de lo que realmente está involucrado.

La única respuesta práctica a su pregunta que no es propensa a dar resultados poco realistas sería el uso de una hoja de trabajo que arroje suposiciones basadas en la historia previa de su empresa. Desafortunadamente, eso no explicará las tareas que el estimador omitió. Al menos esto puede dar números de estadio.

A menos que desarrolles knock offs del mismo sistema una y otra vez, entonces cualquiera que piense que lo ha descubierto se está engañando a sí mismo. Hay demasiadas variables involucradas.

Answer 5

Otra forma útil de evaluar las estimaciones es compararlas con el esfuerzo real que se gastó en proyectos anteriores de tipo similar. Los mejores datos para la comparación serían los datos de esfuerzo de los proyectos anteriores que la organización ha realizado. Si no hay datos históricos organizacionales, puede tratar de comparar el estimado con los puntos de referencia de toda la industria.

También diría que si la estimación se presenta como un número absoluto (digamos 180 días), entonces no es una buena señal. Un único número absoluto indica que la estimación es que la tarea se finalizará con un 100% de probabilidad sobre los datos dados. Las estimaciones presentadas en un rango (digamos de 130 a 180 días) indicarían que el rango en el que la tarea podría completarse.

Mucho de lo que he escrito arriba lo atribuyo al libro:

Estimación del software: Desmitificando el arte negro por Steve McConnell

Answer 6

Una buena heurística es ver si el tiempo de prueba es más o menos el mismo tiempo de desarrollo. Esa es una buena señal para la estimación.

Si no pueden darle un desglose de la estimación, entonces eso es algo malo. Por lo general, es un signo de muchas cosas pequeñas que pueden haber sido olvidadas. No es necesario que proporcionen el desglose original completo, solo un desglose como:

• requisitos
• desarrollo
• pruebas
• embalaje y despliegue
• etc.

Deben usar una plantilla estándar para calcular su estimación. No necesitan un número en cada columna, pero hacen la plantilla para enumerar todas las tareas posibles. De esa forma, la plantilla se puede usar para hacer que la mente de las personas se mueva de un lado a otro al trabajar en el cálculo aproximado.

Si la estimación es demasiado precisa, por ejemplo, incrementos de 0,25 horas, entonces, para mí, es un mal olor.

Si faltan cosas como captura de requisitos, pruebas, implementación y entrega a cualquier grupo de operaciones. Si alguno de ellos falta, ese es el tipo de cosas que volverán y te morderán.

Editar: Otra cosa a tener en cuenta son las tareas antiguas "perpetuamente 90% completas". Obtiene la actualización de progreso después de la actualización de progreso que enumera una tarea como "90% completado". ¡Eso no es bueno!

HTH

aclamaciones

Answer 7

• Una sola persona que haya hecho las estimaciones, en lugar de haber utilizado una estimación basada en el consenso (para comprender completamente el alcance implícito de los requisitos) como Wideband Delphi .
  • Especialmente cierto si la persona que hace la estimación no es la persona que realiza la implementación. - Una vez trabajé en un proyecto estimado por otra persona como 60 días antes de que se hubieran dado siquiera los requisitos. Digamos que no era un conejito feliz
• No hay tiempo para la documentación.
• No hay tiempo para la aceleración (en términos de aprendizaje y tamaño del equipo).
• Sin lista de riesgos, y su impacto en la escala de tiempo.
• Sin amortiguación para lo inesperado, en términos de requisitos y riesgos de última hora.

Answer 8

• ¿El compilador de la estimación está disponible y dispuesto a discutirlo con otros miembros senior del proyecto? Si no, eso a menudo es una preocupación.

• ¿Se envió el presupuesto al cliente antes de conocer la experiencia y las habilidades del personal de desarrollo? Dos estimaciones puntuales pueden ayudar, pero solo en cierta medida.

• Antes incluso de tener la oportunidad de ver el estimado, se le informa que está comprometido a entregar todas las funciones descritas en una fecha específica.

(Gracias por responder a mi pregunta, por cierto).

Answer 9

Si ve uno o más de estos, es posible que tenga una mala estimación:

• Estimaciones de punto único: una estimación debe asociarse con un rango de fechas posibles o un valor de confianza
• Insuficiente granularidad de las tareas: una gran cantidad de tareas generalmente indica que la funcionalidad no se entiende bien (lo que es especialmente un problema ya que los problemas poco entendidos suelen subestimarse)
• Sin expresión de suposiciones y / o riesgos
• Inadecuado esfuerzo asignado para artículos comúnmente omitidos o subestimados (por ejemplo, scripts de construcción, documentación, implementación, etc.)

Estoy de acuerdo con Sateesh, realmente me gusta la estimación de software: Desmitificar el arte negro de Steve McConnell. Él tiene varias listas de verificación que son útiles al revisar y / o preparar las estimaciones.

Answer 10

Una buena estimación tendrá un buen desglose, que involucrará todas las fases del proyecto.

Es casi seguro que no terminará en una fecha conveniente para el negocio.

Incluirá riesgos de varios tipos.

Se presentará en términos de intervalos de confianza, ya sea implícitamente (10-12 meses) o mediante el uso de unidades grandes (alrededor de cuatro trimestres).

Lo hará alguien con la responsabilidad de realizar el proyecto, preferiblemente más de una de esas personas.

Si hay retrasos al inicio, habrá retrasos al final (expresados ​​como 10-12 meses desde el comienzo, o aproximadamente 1T2010 si comenzamos ahora, no algo así como enero de 2010 cuando el proyecto aún no ha comenzado).

Los supuestos y las dependencias se enumerarán clara y prominentemente.

Editar: Parte de esto depende de la etapa en que se encuentre el proyecto. Una estimación temprana pero precisa es una señal de advertencia, particularmente si no hay un intervalo de confianza asignado. Eso apesta a un cálculo de Procrustean.

Además, observe otras metodologías de desarrollo. Un proyecto de timeboxing puede tener un horario rígido y arbitrario, pero el conjunto de características será flexible.

Answer 11

Cualquiera de los siguientes:

• Es un gran proyecto y no hay una estrategia breve de alto nivel descrita
• No hay una visión clara, breve y concisa de lo que se quiere lograr con el proyecto
• El proyecto no está estructurado en torno al valor comercial que se entrega gradualmente
• El equipo está tratando de dar estimaciones "precisas" para un gran proyecto, entrando (¿o se hizo con) una larga fase de análisis? (Los cambios vendrán, y generalmente afectarán esas estimaciones de una manera que no se puede cuantificar fácilmente sin aún mayores esfuerzos)
• Hay estimaciones "detalladas" para todo el proyecto (relacionadas con el anterior)
• No hay estimaciones detalladas para la primera fase, o hay algo mal en eso.

Answer 12

Guau ... Realmente me gusta la respuesta del juego de herramientas.

Y estoy de acuerdo en que cualquier estimación es defectuosa, porque supone que el estimador tiene una mejor pista sobre cómo resolver el problema que cualquier estimador en realidad cuando se estima un proyecto. Sin embargo, creo que todavía necesita al menos estimar el tamaño de la montaña antes de comenzar. Algunos pensaban que si vale la pena intentarlo debería preceder a cualquier esfuerzo y esa es la esencia de una estimación.

Me vino con algunos indicadores más de una estimación peligrosa:

• Sin referencias cruzadas : si la estimación no se puede validar al menos de dos maneras diferentes, es probable que no sea confiable. Por ejemplo, las últimas estimaciones que he hecho han sido capaces de dividir el trabajo en pequeños fragmentos de características, y considerar cuánto tiempo le tomó a nuestro equipo realizar funciones de alcance similar. Luego, pude ver la suma de estos costos y ver cuán grande era el alcance en relación con otros proyectos en los que he trabajado. Esas son dos formas de validar.
• Los antecedentes del estimador , si se trata de una estimación de software realizada por un tipo de hardware que nunca ha escrito un código, tengan mucho miedo. Más sutil: cuanto más cerca esté la base del estimador de la tecnología y el dominio del problema del proyecto, mejor.
• Detalle , como dije algunas formas diferentes en algunas publicaciones diferentes, me gusta ver detalles de las características individuales, así como las tareas necesarias para completar cada función. La mayoría de las estimaciones que veo no muestran los detalles en la presentación formal, pero si le preguntas a la persona que hizo el cálculo, deberían tener un archivo en alguna parte. Con suerte no es la parte posterior de una servilleta de papel manchada con cerveza y ketchup. :)
• Suposiciones documentadas : cualquier estimador tendrá que hacer un conjunto de suposiciones sobre la tarea. Estos deben estar documentados en alguna parte, preferiblemente en la documentación formal. Siempre me siento un poco preocupado cuando veo una propuesta corta con pocas suposiciones documentadas. O bien fueron pensados ​​y no comunicados al cliente, o no se pensaron bien. No estoy honestamente seguro de cuál es peor. No hace falta decir que las suposiciones también deberían ser razonables.
• Ciclo de vida equilibrado : sin embargo, la tarea se desglosa, ¿cuál es la proporción de diseño, código y prueba? ¿Qué hay de la documentación, la integración con sistemas externos y el soporte posterior a la publicación? ¿Qué hay de esas cosas adicionales que son tan vitales (administradores de sistemas, gurús CM, esfuerzo de gestión)?
• Slack - Estoy seguro de que los demonios corporativos de la baratura vendrán y me desilusionarán, pero un cronograma y un costo deberían tener cierta holgura. Si la estimación parece ambiciosa y agresiva para un ojo experimentado, es probable que sea demasiado baja. Las estimaciones casi nunca son demasiado altas.

Answer 13

¿Cuán familiar es la persona que da el estimado con las personas que hacen el trabajo?

A menudo he visto estimaciones donde hay una persona genérica que hace el trabajo, a pesar de que el equipo está formado por personas con antecedentes muy diferentes. Lo más probable es que las tareas y las especialidades no se alineen perfectamente y obtienes un programador de servidor de C ++ que termina haciendo tu GUI o tu base de datos ... A veces el gerente del equipo realmente no aprecia las fortalezas de los miembros del equipo, por lo que si se le ha pedido que presente la estimación por su cuenta porque su equipo está ocupado en el proyecto anterior, verá que el trabajo en cuestión solo es adecuado para una parte del equipo (sin motivación, falta de habilidades, etc.)

Answer 14

Estoy totalmente de acuerdo con Dunk, el primer signo de las malas estimaciones es la mera presencia de un gran calendario detallado por adelantado. Las estimaciones son exactamente eso, una aproximación, de lo contrario las llamaríamos imágenes exactas . Por lo tanto, nunca deben usarse solos en la administración de un proyecto.

El punto más importante a considerar no es la exactitud de las estimaciones, sino la consistencia . Si un tercero estaba haciendo estimaciones para usted, solicite ver un historial de sus éxitos o fracasos, hable con sus clientes anteriores y determine su fiabilidad.

Dicho todo esto, desde un punto de vista ágil, algunas de las formas en que intentamos obtener estimaciones más consistentes durante un proyecto son;

• Use un estándar de tamaño relativo (S, M, L, XL) en lugar de basado en el tiempo (días ideales).
• enfocarse en la complejidad, no en el tiempo
• Utilice siempre estimaciones grupales, no estimaciones de una sola persona
• Obtenga estimaciones con frecuencia a lo largo del proyecto, generalmente al comienzo de cada sprint
• utilizar los comentarios de los sprints anteriores para determinar la complejidad de la historia
• rastrear la velocidad para dar sentido al tamaño relativo
• retrospección frecuente y temprana de la historia para examinar / entender cualquier golpeteo

Si está tratando con compañías que usan estos métodos de estimación, entonces es probable que reciba resultados consistentes y, por lo tanto, mejores.

Answer 15

"De cuatro a seis semanas" , cuando no va acompañado de un desglose en tareas más cortas ...

Answer 16

Hay dos tipos de estimaciones: estimaciones de tareas y estimaciones de proyectos . Puede ver estos como imágenes grandes y pequeñas.

Las estimaciones del proyecto son necesariamente de alto nivel (la granularidad no es menor que los días típicos) y deben incluir cosas como:

• Arquitectura de alto nivel;
• Tiempo de prueba;
• Tiempos de aceleración;
• Procesos de defectos;
• Tiempo para la documentación;
• Entrenamiento relevante;
• Suposiciones;
• Dependencias (p. Ej., El equipo A no puede hacer lo que necesita hasta que el equipo B entrega la fase 1);
• Ruta crítica (qué piezas pueden determinar si el proyecto falla y cuánto); y
• Riesgos

Cuantas más cosas falten, menos realistas (o arriesgadas) serán las estimaciones.

El segundo tipo de una tarea estimada, que generalmente es un nivel mucho más bajo. Para este tipo de estimación, debe ser simplemente un desglose de tareas (sin ninguna tarea que sea mayor que, por ejemplo, 5 días).

Estos no tienden a abordar los elementos anteriores, pero algunos de ellos pueden ser relevantes, como las suposiciones con respecto a decisiones aún no tomadas (por ejemplo, hardware de producción). También puede valer la pena identificar quién puede y no puede realizar las tareas debido a la experiencia relevante, los conocimientos previos o las habilidades (ya que esa persona o esas personas pueden terminar comprometidas).

Otras publicaciones han mencionado que el tiempo de prueba debe ser igual o superior al tiempo de desarrollo. Estoy totalmente en desacuerdo con esto. He visto que las tareas de desarrollo de 8 horas dan como resultado más de 100 horas de prueba y las tareas de desarrollo de 80 horas resultan en menos de 2 horas de prueba. En ambos casos, el tiempo de prueba fue completamente razonable. No hay una correlación absoluta entre los dos. En el mejor de los casos, hay una conexión suelta.

Answer 17

• ¿Es la estimación lo que la gerencia quería que se le dijera?
• ¿El presupuesto encaja perfectamente con la fecha de envío planificada para el próximo lanzamiento?
• ¿La gerencia recompensa a las personas que dan buenas noticias más que a las personas que dan malas noticias?
• ¿Se preparó el presupuesto antes de saber quién estaría trabajando en el proyecto?
• ¿Alguien que quería ese pedazo de implementación funcional prepara la estimación?
• ¿Hay un historial de software que llega tarde?
• ¿Es normal que los desarrolladores pasen a otras tareas a mitad de camino a través de un proyecto?
• ¿Alguno o todos los desarrolladores han renunciado a comentar las malas estimaciones como una pérdida de tiempo?

Cuente el número de preguntas que obtiene respuestas "sí" o "tal vez" ...

Si obtiene principalmente respuestas "no" a las preguntas anteriores, entonces puede valer la pena examinar el presupuesto en detalle para ver si incluye las tareas que otras personas enumeraron en este hilo.