project-management - ruta - pert
Cálculo de tiempos de programación de proyectos (6)
Este es probablemente uno de los grandes misterios en el negocio de TI. Innumerables proyectos de software fallidos han demostrado que todavía no hay una solución perfecta, pero lo más cercano a resolver esto es el uso del mecanismo de estimación adaptativo integrado en FogBugz .
Básicamente, usted está rompiendo sus hitos en pequeñas tareas y adivine cuánto tiempo le llevará completarlos. Ninguna tarea debe ser superior a unas 8 horas. Luego ingresa todas estas tareas como características planificadas en Fogbugz. Al completar las tareas, realiza un seguimiento de su tiempo con FogBugz.
Fogbugz luego evalúa sus estimaciones pasadas y el consumo de tiempo real y utiliza esa información para predecir una ventana (con probabilidades) en la que habrá cumplido sus próximos hitos.
Como desarrollador líder, a menudo me entrego especificaciones para un nuevo proyecto y me preguntan cuánto tiempo llevará completar la parte de programación del trabajo involucrado, en términos de horas.
Me preguntaba cómo otros desarrolladores calculan estos tiempos con precisión.
¡Gracias!
Ah, y espero que esto no sea considerado como una pregunta argumentativa, ¡solo estoy interesado en encontrar la mejor técnica!
La buena estimación viene con la experiencia, o a veces nada.
En mi trabajo actual, mis 2 compañeros de trabajo (que aparentemente tenían mucha más experiencia que yo) usualmente subestimaban los tiempos en 8 (sí, OCHO ) veces. Yo, OTOH, solo he pasado una vez en los últimos 18 meses una estimación original.
¿Por que sucede? Ninguno de los dos, parecía no saber realmente lo que están haciendo, de manera codificada, por lo que literalmente estaban chupándose el dedo.
Línea de fondo:
Nunca subestimes, es mucho más seguro sobreestimar. Dado lo último, siempre puede "acelerar" el desarrollo, si es necesario. Si ya estás en una línea de tiempo ajustada, no hay mucho que puedas hacer.
La estimación a menudo se considera un arte negro, pero en realidad es mucho más manejable de lo que la gente piensa.
En Inntec, contratamos el desarrollo de software, la mayoría si implica trabajar con un costo fijo. Si nuestras estimaciones estuvieran constantemente muy lejos, estaríamos fuera del negocio en poco tiempo.
Pero hemos estado en el negocio por 15 años y somos rentables, así que claramente todo este asunto de la estimación es solucionable.
Empezando
La mayoría de las personas que insisten en que la estimación es imposible están haciendo suposiciones salvajes. Eso puede funcionar esporádicamente para los proyectos más pequeños, pero definitivamente no se escala. Para obtener una precisión constante, necesita un enfoque sistemático.
Hace años, mi mentor me dijo lo que funcionó para él. Es muy parecido al antiguo método de estimación de Joel Spolsky, que puedes leer aquí: Joel en Estimación . Este es un enfoque simple, de baja tecnología, y funciona muy bien para equipos pequeños. Se puede descomponer o requerir modificaciones para equipos más grandes, donde la comunicación y los gastos generales del proceso comienzan a tomar un porcentaje significativo del tiempo de cada desarrollador.
En pocas palabras, utilizo una hoja de cálculo para dividir el proyecto en partes pequeñas (menos de 8 horas), teniendo en cuenta todo, desde las pruebas hasta la comunicación y la documentación. Al final, agrego un multiplicador del 20% para los elementos inesperados y los errores (que debemos solucionar de forma gratuita durante 30 días).
Es muy difícil mantener a alguien en una estimación de que no tuvo parte en el diseño. A algunas personas les gusta que todo el equipo haga una estimación de cada elemento e ir con el número más alto. Yo diría que, al menos, debe hacer estimaciones pesimistas y dar a su equipo la oportunidad de expresarse si piensan que usted está ausente.
Aprendiendo y mejorando
Necesitas feedback para mejorar. Eso significa hacer un seguimiento de las horas reales que pasa para que pueda hacer una comparación y ajustar su sentido de estimación.
En este momento, en Inntec, antes de comenzar a trabajar en un gran proyecto, las líneas de la hoja de cálculo se convierten en notas adhesivas en nuestro tablero kanban, y el administrador del proyecto realiza un seguimiento del progreso en ellas todos los días. Cada vez que revisamos o tenemos un artículo que no consideramos, sube como un pequeño pegajoso rojo, y también se incluye en nuestro informe de incendio. Esas dos herramientas juntas proporcionan una valiosa retroalimentación a todo el equipo.
Aquí hay una foto de una tabla kanban típica, aproximadamente a la mitad de un pequeño proyecto.
Es posible que no pueda leer los encabezados de las columnas, pero dicen que Backlog, Brian, Keith y Done. La acumulación se divide en grupos (área de administración, etc.) y los desarrolladores tienen una columna que muestra los elementos en los que están trabajando.
Si pudiera mirar detenidamente, todas esas notas tienen el número estimado de horas en ellas, y las de mi columna, si las sumara, deberían ser de alrededor de 8, ya que esa es la cantidad de horas en mi día laboral. Es inusual tener cuatro en un día. La columna de Keith está vacía, por lo que probablemente estuvo fuera ese día.
Si no tiene idea de lo que estoy hablando acerca de re: reuniones de pie, scrum, informes de quemados, etc., eche un vistazo a la metodología de scrum . No nos atenemos a la carta, pero tiene algunas ideas geniales no solo para realizar estimaciones, sino también para saber cómo predecir cuándo se enviará su proyecto a medida que se agregue nuevo trabajo y se pierdan o cumplan las estimaciones (esto sucede ). Puede ver esta increíble herramienta llamada informe de quema y decir: podemos enviarlo en un mes, y veamos nuestro informe de quema para decidir qué características estamos eliminando.
FogBugz tiene algo que se llama Programación Basada en la Evidencia que podría ser una forma más fácil y automatizada de obtener los beneficios que describí anteriormente. Ahora mismo lo estoy probando en un pequeño proyecto que comienza en unas pocas semanas. Tiene un informe de grabación integrado y se adapta a sus imprecisiones de programación, por lo que podría ser bastante potente.
Actualización: Sólo una nota rápida. Han pasado algunos años, pero hasta ahora creo que todo en este post todavía se mantiene hoy. Lo actualicé para usar la palabra kanban, ya que la imagen de arriba es en realidad una tabla kanban.
La sobreestimación es bastante mejor que la subestimación. Esto se debe a que no sabemos que las especificaciones "desconocidas" y (en la mayoría de los casos) cambian durante el ciclo de vida del desarrollo del software.
En mi experiencia, usamos pasos iterativos (al igual que en Metodologías ágiles) para determinar nuestra línea de tiempo. Dividimos los proyectos en componentes y sobreestimamos esos componentes. La suma de estas estimaciones se utiliza y agrega tiempo adicional para las pruebas de regresión y el despliegue, y todo el buen trabajo ...
Creo que tienes que volver de tus proyectos anteriores y aprender de esos errores para ver cómo puedes estimar sabiamente.
No existe una técnica general. Tendrá que confiar en su experiencia (y la de sus desarrolladores). Deberá tener en cuenta también todas las variables del entorno y del proceso de desarrollo. E incluso si se las arregla con esto, existe una gran posibilidad de que se pierda algo.
No veo ningún punto en estimar los tiempos de programación solamente. El proceso de desarrollo está tan interconectado que la estimación de uno de los lados no producirá ningún resultado valioso. Todo debe ser estimado, incluida la programación, prueba, implementación, desarrollo de la arquitectura, redacción de documentos (documentos técnicos y manual del usuario), creación y administración de tickets en un rastreador de problemas, reuniones, vacaciones, bajas por enfermedad (en ocasiones es un bateador esperar) El chico, luego asignando la tarea a otra), planeando sesiones, descansos para tomar café.
Aquí hay un ejemplo: solo se necesitan 3 minutos para que el huevo se ase una vez que se deja caer sobre el bolígrafo. Pero si dices que toma 3 minutos hacer un huevo frito, estás equivocado . Te lo perdiste:
- tomar el bolígrafo para freír (¿tienes uno listo? ¿Tienes que ir y en uno? ¿Tienes que esperar en la cola para este bolígrafo?)
- haciendo el fuego (¿tienes un horno? ¿Tendrás que conseguir troncos para construir una chimenea?)
- obteniendo el aceite (¿tiene alguno? ¿Hay que comprarlo?)
- conseguir un huevo
- freírlo
- Servirlo en el plato (¿está listo? ¿Limpiar? ¿Lavarlo? ¿Comprar? ¿Esperar a que el lavavajillas termine?)
- limpiando después de cocinar (no lo harás con la sucia freidora, ¿verdad?)
Aquí hay un buen libro de inicio sobre la estimación de proyectos:
http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351
Tiene una buena descripción sobre varias técnicas de estimación. Te levantará en un par de horas de lectura.
Si está utilizando FogBugz , entonces su programación basada en evidencia hace que estimar una fecha de finalización sea muy fácil.
Puede que no lo esté, pero tal vez podría aplicar los principios de EBS para llegar a una estimación.