El Viernes, con Esteban Lorenzano, antes de dar la charla en Cafelug, nos colgamos hablando del tema y vimos que hay dos cosas totalmente equivocadas o mitos sobre las estimaciones que no estamos de acuerdo para nada, y son:
- Querer establecer un modelo matemático para poder justificar un metodo de estimación. Si bien sería algo ideal, es algo imposible (desde nuestro punto de vista) y principalmente por que la unidad de trabajo (ya sea, LoC, UCP, FP, CocomoFuckingFactors) es inmedible, recuerden que la construcción de software es un proceso creativo y no repetible!!! y no solo eso las personas importan y no hay proceso que pueda hacer repetible ninguna tarea de construcción de software.
- Los profesionales del software no entienden que quiere decir una Estimación. No quieren entender que es un Pronóstico, una simple (o compleja, de acuerdo a que método uses) predicción del esfuerzo (tiempo, costo y scope) que puede tomar la construcción. Nunca debe tomarse como un hecho, ni tampoco se puede planificar detalladamente y menos que menos controlar en base a una planificación errónea asumiendo estimación... o sea, todo mal. Con lo cual, tomemos el resultado de una estimación como debe ser, algo que nos permita tener una idea y tengamos en cuenta que es errónea desde un principio.
- Separar lo que es un restricción del negocio (para cuando se quiere el software) de una estimación de esfuerzos, son cosas diferentes... no hay que confundirlas.
- Muchas veces, la estimación es un problema de ineptitud del Equipo que la ejecuta el proyecto. Esto puede ser por falta de comunicación de la estimación y los fundamentos de esa estimación, falta de recursos en tiempo, mal manejo de requerimientos, etc, etc.
- Hay que tener muy en cuenta el nivel de in/certidumbre por falta de información u otros temas, y eso no solo se mitiga agregando más tiempo a la estimación, sino poniendo el % de desvío correspondiente.
- Tener en cuenta que el software es algo creativo y depende muuuuuuucho de las personas, y aca se te va la estimación a la mierda, aca es donde hay que estimar "constantemente" por cada iteración para generar un compromiso del team para lograr algo, y eso va ajustando el estimación original que nunca es precisa.
- Segun McConnel, (opino lo mismo) siempre está mejor sobre estimar que estimar menos de lo que es, ya que estar siempre atras de lo que se estimó genera más ruido, más comunicación, mas reuniones de tracking, mal ambiente que sigue atrasando el proyecto... pero obviamente hay que tener cuidado con la ley de parkinson.
- No solo se estima tiempo, sino que se estima esfuerzo y costo, ojo aca
- Las factores son un excelente medio de ir perfeccionando una estimación, pero cuidado con los pesos que se le ponen a dichos factores por que pueden ser comienzo del problema, creo que definir una serie de factores que ajusten la estimación es correcto (no más de 10/15) ya después entra la subjetividad.
- Está claro que Wideband Delphi es el método que puede tener mejores resultados, pero es muy costoso hacerlo. Y lo que te queda es irte a las estadísticas de la organización para buscar proyectos similares, con tecnologías iguales y dominios similares.
Que lindo sería una materia de esto, no? Aunque prefiero antes que la gente aprenda a construir software como la gente, luego aprender a estimar, asi que todavía tenemos un largo camino que transitar.
1 comentario:
En cuanto a estimaciones de todo lo que vi. Creo que nunca la idea es tratar de armar un "modelo matematico" o al menos no uno universal.
Por lo que entendi la idea es recolectar informacion estadistica de como te fue en el pasado (todas las variables que se puede) a partir de ahi ver que variabes influyen en el tiempo y poder medir, pero es como un proceso iterativo que cada vez que se le entrega input nueva, variables nuevas y nuevos proyectos se va a utoajustando.
Lo veo mas como una red neuronal, donde tenes multiples variables de entrada, vas ajustando los pesos de cuanto influye cada variable en el resultado final e inferis basandote en los resultados de casos anteriores como se relacionan entre si. Al brindarle a esa "red" un proyecto nuevo puede aplicar lo que se aprendio anteriormente para estimar un tiempo, al menos con "CIERTO GRADO" de realismo, pero no hay cosas magicas, y es diferente para cada organizacion, porque cada organizacion es diferente, y diria que cada grupo de trabajo es diferente.
Use el ejemplo de red neuronal porque es el que mas manejo, pero el concepto para mi es ese. No hacer estimaciones de la nada, sino basandote en lo que paso antes. Cuanto mas info tengas mejores seran las estimaciones. En las primeras estimaciones, por ahi te vas a equivocar.
Publicar un comentario