Estimar cuánto tiempo llevará una tarea determinada parece ser una de las partes más difíciles del desarrollo de software. En mi tienda actual, calculamos las tareas en horas al comienzo de una iteración, pero una vez que la tarea está completa, no la utilizamos para ayudarnos en futuras estimaciones.¿Cómo se refina su proceso de estimación?
¿Cómo utilizas la información que reúnes de estimaciones anteriores para refinar las futuras?
Con mucho, uno de los enfoques más interesantes que he visto para programar de forma realista es Evidence Based Scheduling, que es parte de la versión FogCreek FogBugz 6.0. Consulte la publicación de blog de Joel vinculada anteriormente para obtener una sinopsis y algunos ejemplos.
Si se produjo una estimación, intente identificar si fue solo al azar (medio ambiente roto, alguna vez error complicado, etc.) o si había algo que no identificó.
Si un esimate era demasiado grande, identifique qué era lo que pensaba que iba a tomar tanto tiempo y descubra por qué no lo hizo.
Se espera que hacer eso sea suficiente para ayudar a los desarrolladores en sus estimaciones.
Por ejemplo, si un desarrollador cree que las pruebas de escritura para un controlador demorarán años y luego toma menos tiempo de lo que imaginaba, el próximo cálculo que haga para un controlador de alcance similar puede mantenerlo mente.
Estimo con mis compañeros de equipo de forma iterativa hasta que lleguemos a un consenso. Claro, cometemos errores pero no calculamos explícitamente el factor "velocidad", sino que usamos la experiencia recopilada en nuestros nuevos debates de estimación.
He descubierto que el tiempo estimado le llevará tan lejos. Las interupciones con otras tareas, las circunstancias imprevistas o las influencias del proyecto inevitablemente cambiarán los marcos de tiempo y, si se vuelven a evaluar constantemente, perderá mucho tiempo gestionando cuándo podría estarse desarrollando.
Por lo tanto, aquí proporcionamos una estimación inicial basada en la experiencia de la solución por tiempo (no usamos un modelo, no encontré uno que funcione lo suficientemente bien en nuestro entorno) pero no juzgamos nuestros KPI en su contra, ni le aseguramos a la empresa que este plazo será afectado. Nuestro enfoque de desarrollo aquí es en gran medida reactivo, y parece satisfacer muy bien los requisitos de la empresa.
cuando las estimaciones están apagadas, casi siempre hay una causa evidente, que conduce a una lección aprendida. Los recientes de la memoria:
interfaz de usuario asume la funcionalidad de .NET que no existía (la capacidad de insertar una nueva fila y editarlo en línea en un GridView); La lección aprendida es verificar la funcionalidad de las clases elegidas antes de comprometerse a estimar. Este error costó una semana.
El proceso ftp supuso que FtpWebRequest podría hablar con el servidor ftp seguro de un banco; Resultó que hay un error conocido en esta clase si el servidor ftp devuelve algo más que una barra diagonal inversa para el directorio actual; La lección aprendida es buscar 'error' y 'problema' en google con el nombre de la clase, no solo 'tutorial' y 'ejemplo' para asegurarse de que no haya 'trampas' al acecho. Este error costó tres días.
estas lecciones van en un documento de "lista de control" Estimación de Proyectos y Desarrollo, por lo que no serán olvidados para el próximo proyecto
GridViews son malos! – DaveDev