SEG Spain

Últimamente me estoy leyendo el libro de McConnell, Software Estimation: Demystifying the Black Art, y claro, de vez en cuando te da por buscar entre los recursos que se anuncian en el libro, podríamos incluso decir que con descaro, y me he encontrado con esta presentación.

Os lo pongo aquí por que creo que puede mostrar en pocas palabras los principales problemas en la estimación de proyectos software. Yo personalmente me siento otra vez en evidencia… otra cosa más que estudiar. ¿Cuando se va a acabar esto? ¿Por que en la uni no tuvimos una asignatura de estimación?

Sin embargo hay una cosa sobre la que me gustaría hablar: acerca del cono de incertidumbre. Por que claro, el cono de incertidumbre es la solución a nuestros problemas, es nuestra Tizona siempre que nos pidan una estimación… o no. Por que, aparte de que ese comercial enamorado de la luna se va a pasar el cono por el arco del triunfo, el cono sólo muestra lo difícil que lo tienes para acertar.

Para empezar, todo depende del tipo de de proyectos que te toque estimar. El libro te recomienda que no te metas a estimador si el proyecto tiene más de 100 años hombre, que eso lo dejes para Los Hombres de Paco.

Así que yo, que no soy un estimador experto, lo tengo difícil para caer dentro del cono de incertidumbre. Sin embargo, lo que no puedo hacer es dejar de refinar mis estimaciones a medida que avanza el proyecto, por que las métricas obtenidas tienen un valor incalculable en futuras estimaciones.

El tema es que te puedes encontrar con un proyecto firmado, con una planificación basada en una estimación de te da vergüenza y cada vez que refinas, estás hurgando más en la herida. Conclusión: las primeras estimaciones se convierten en una carrera de Jackass, cada vez que se estrecha el cono de incertidumbre, más acelera el carrito de la compra…

Esta vez es Javier Martín quien nos resume la tertulia:

La tertulia que versaba sobre Peopleware de Tom de Marco y Timothy Lister, llegó a un cierto consenso general de que no siendo un libro clave para la Ingeniería del Software, era un libro de lectura recomendada que aportaba ideas basadas en la experiencia que podían ser útiles para su aplicación práctica.

No puede ser un libro clave por no estar basado en estudios rigurosos sobre un conjunto de proyectos escogidos con criterios estadísticos, ni tener una base científica. Los estudios realizados sobre una base de 500 proyectos desde 1977 hasta la escritura del libro, son más bien una recogida de tendencias o impresiones. Se habló de que es más un recetario de consejos basados en la experiencia de los autores y que repite o recoje ideas de libros o estudios anteriores (High.tech illusion, laetrile recuerdan mucho al Mythical-man month y su silver bullet).

Continuar Leyendo »

Yo me hago una pregunta… ¿Que nos ha pasado?

Un extracto de una conferencia de la NATO y no es de ayer:

Perlis: I’d like to read three sentences to close this issue.

1. A software system can best be designed if the testing is interlaced with the designing instead of being used after the design.

2. A simulation which matches the requirements contains the control which organizes the design of the system.

3. Through successive repetitions of this process of interlaced testing and design the model ultimately becomes the software system itself. I think that it is the key of the approach that has been suggested, that there is no such question as testing things after the fact with simulation models, but that in effect the testing and the replacement of simulations with modules that are deeper and more detailed goes on with the simulation model controlling, as it were, the place and order in which these things are done.

A esto le añades un poco de educación, no usar colonias fuertes y evitar poner a una mujer al lado del obseso sexual del grupo ¿Y que obtienes? XP (¿¡Un smiley?!)

La verdad es que merece la pena leerlo. Lo malo es que me ha quedado la sensación de que no ha pasado el tiempo, que con todo el “avance” de la “ingeniería del software” en estos 40 años, estamos peor.

Entonces, retomando la pregunta… ¿Qué nos ha pasado para que estemos peor que los mejores de hace 40 años? Y eso que nos creiamos tan listos.

Voy a tomarme una pastilla roja, pero esto no es una pelicula, no va a ser tan fácil.

Un desarrollador de Microsoft (afortunadamente trabaja ahora en Google) comenta los problemas que tuvo para implementar la funcionalidad de apagado del menú de inicio de Windows Vista.

Resumiendo las quejas del desarrollador: añadir gente a un proyecto retrasado, problemas de gestión de la configuración, sobre-gestión (8 personas por desarrollador), falta de especificación de los requisitos / casos de uso, etc. Vamos, todo lo que libros como Mythical Man Month o Peopleware dicen que NO se debe hacer.