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…

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).

Por otro lado, es un libro recomendable por cuanto recoge el concepto de considerar el factor humano como parte esencial de los proyectos informáticos y equiparar la importancia del “Peopleware” al Hardware o al Software. Y conceptos como el “Spanish Management”, “Teamicide”, entrevistar a la gente para el puesto que va a cubrir (”Hiring a juggler”) o el respeto a la concentración necesaria para el trabajo intelectual son realmente novedosos para su tiempo.

Capítulos que merecieron comentario específico:

• El 30, sobre como es la distribución de gente de una empresa respecto a la capacidad de cambio y la resistencia natural al mismo del ser fumano: los anti, los pasivos, los que aceptan el cambio, los que ayudan… Recuerdo ahora que Julio habló una vez de un libro donde esa distribución llevaba a una campana de Gauss, pero no recuerdo cual era la referencia…
• El 29 sobre los programas de mejora de proceso como CMM. Fue una de las mayores discusiones. Mientras unos defendían que el libro critica abiertamente a CMM o a los procesos como tal (se aludió en una frase no encontrada durante la tertulia donde decía que los procesos matan la creatividad), otros defendían que lo que criticaba no era los programas sino la aplicación ineficaz de los mismos, y sobre todo de aquellos que tienen la certificación y no el cambio cultural como fin, y lo que se insitucionalizan como parte de la vida diaria sin llegar nunca a un objetivo.

Un comentario personal, para mi este libro tiene bastante peligro en su lectura por estar abierto a interpretación subjetiva desde puntos de vista antagónicos. Yo he visto (además de asaltar naves en llamas mas allá de Orion), a programadores acogerse a ideas como que no se les molestase mientras hacían trabajo intelectual que consistía en tocarse las pelotas con fruición o instalaban Mambo , o a managers acogerse a algunas ideas como la distribución de gente(de forma parcial) para refugiarse en ello cuando vienen los problemas (”yo os di lo que queriais…”, “es que el equipo técnico no funciona” etc etc).Me parece un libro atractivo de leer pero ciertamente peligroso por esa posibilidad de libre interpretación a la medida de cada uno.

Seguro que los otros asistentes recuerdan más detalles de la charla…

Por cierto, ya que el libro se prestaba a ello, la sesión terminó en el habitual muro de las lamentaciones, donde esta vez se llevaron el protagonismo principal Eduardo y sus chicos del CSIC… De nuevo naves ardiendo más allá de…

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.

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.

El primero, como ya habréis observado, es la completa traducción al castellano. También se ha unificado el layout de todas las páginas.

Hemos incluido un calendario con los próximos eventos (tales como las fechas de las tertulias). Podéis subscribiros mediante el estándar iCal desde el enlace que hay justo debajo del calendario, o introduciendo la URL:

webcal://seg-spain.org/?ec3_ical

Os recordamos que existen multitud de clientes que soportan este estándar, por ejemplo Google Calendar, Apple iCal, o Mozilla Sundbird.

Finalmente, os recomendamos suscribiros al feed RSS para seguir las modificaciones de la web.

Del artículo me quedo con la frase “the success of companies like Google, Yahoo, and Microsoft is not accidental, and is partially due to their emphasis on hiring talented people“. De todas las ideas que expone, ésta creo que es la que más alejada está de la cultura empresarial española.

Y vosotros, ¿compartís esta visión?

En esta nueva etapa vamos a intentar que no sólo aparezca información relativa a las tertulias, sino también escribir pequeños artículos de las conclusiones a las que lleguemos, o cualquier tema de discusión relativo a la ingeniería del software. Así, evitaremos que todo el conocimiento que vamos obteniendo se pierda, como lágrimas en la lluvia.

Os invito también a que enviéis un logo para la web. Así que los más manitas ya sabéis, a poneros manos a la obra.

Podéis registraros si queréis y haceros editores, para poner contenido. Y por supuesto, si queréis podéis solicitar un enlace a vuestra web.