En nuestra organización, utilizamos principalmente la estimación de Casos de Uso para nuevos casos de uso, lo cual es muy claro y simple. Sin embargo, a veces nos ocupamos de tareas que no están relacionadas con casos de uso o están relacionadas con la interfaz de usuario o, a veces, nos ocupamos de tareas de mantenimiento en aplicaciones heredadas de las que no tenemos casos de uso escritos. Así que desarrollamos un método interno utilizando puntos de complejidad para estas tareas. Simplemente clasifica las tareas en escalas desde muy simples a muy complejas de acuerdo con una guía y le da a cada escala un tamaño. Calculamos un coeficiente de conversión para convertir entre UCP (puntos de caso de uso) y CP (puntos de complejidad) en caso de que el proyecto utilizara ambos métodos. En nuestra organización, el PM generalmente tiene experiencia técnica para hacer la estimación. Él/ella puede consultar al equipo si es necesario.
Quiero saber más sobre la experiencia de otras personas.
¿Qué método(s) de estimación de tamaño usa/recomienda (Punto de caso de uso, Punto de función, Punto de clase, ...)? ¿O estimas el esfuerzo directamente? ¿Quién realiza la estimación en su proyecto (PM, Equipo, Comité de estimación como en el método Delphi, ...)?
Lo más importante, cuéntenos sobre una situación en la que falló su método y por qué cree que sucedió.
A veces simplemente no sabes cuánto tiempo va a tomar, o no sabes en alguna parte. A veces crees que sabes y tus desarrolladores tienen otro conocimiento diferente al que tienes (a veces más, a veces menos).
La mejor estimación la obtiene analizándose primero a usted como PM y sin darle al equipo información sobre sus números, solicite una reunión con el equipo para informarle sus estimaciones .
Si tú y ellos difieren mucho de lo que pensabas que tomaría, resuelve tus dudas preguntando cómo llegaron a esos valores. Y trate de establecer un punto razonable dado que usted o ellos pueden haber olvidado algo.
De los desarrolladores , usted requiere que le digan sus estimaciones de tiempo considerando también lo que tienen como territorio inexplorado . (Algo que a veces los desarrolladores tienden a obviar )
Es por eso que he creado mis propias Reglas generales para desarrolladores . Estos presupuestos no son imprescindibles, pero son una buena idea para empezar a gestionar presupuestos, realizar presupuestos y tareas de montaje en el proyecto a medio y largo plazo. Estas son mis reglas generales:
Esos pueden sonar un poco excesivos, pero les aseguro que no lo son.
No sé si en inglés se le llama colchón al "tiempo extra", el inglés no es mi idioma nativo. Lo siento por eso.
No recuerdo, que este método de estimación falló por mucho. Una vez sucedió que uno de los desarrolladores era junior y llegó a un punto en el que no solo hizo un lío en el código (complicando al siguiente tipo que tendría una tarea) sino que tampoco pudo resolver una tarea determinada, lo que retrasó el entrega, ya que en lo que se trabajaba era uno de los rubros principales.
Dado que la pregunta es amplia, hay una respuesta amplia. Comience con "Estimación de software: desmitificando el arte negro" de Steve McConnell . Una vez que obtenga algunos antecedentes "académicos" en la estimación, lea más sobre COCOMO y COSMIC .
jmort253
your answer is provided along with the question, and you expect more answers: “I use ______ for ______, what do you use?”. Si es posible, intente eliminar la respuesta de la pregunta para que podamos evitar cerrarla. Además, está bien responder a su propia pregunta, pero debe hacer clic en "Responder" y agregarla como una respuesta real. ¡Gracias por participar en nuestro sitio! :)