¿somos ingenieros los del software?

Seguro que ya te has enterado del revuelo que se ha armado con el artículo en IEEE de Tom diMarco, sobre su cambio de parecer con el control y métricas en los proyectos de software.

Las métricas que inicialmente expuse en mi libro Controlling Software Projects: Management, Measurement and Estimation, han definido la forma en la que muchos ingenieros construian el software y planificaban el trabajo. Con un ánimo de estado reflexivo, ahora me pregunto: ¿Fué correcto el asesoramiento en métricas? ¿Sigue siendo pertinente? y ¿creo todavía que las métricas son una necesidad para el éxito de cualquier desarrollo de software?. Mis respuestas son no, no y no. [*]

Yo no creo que sea un cambio en el parecer de Tom, no tienes más que leer PeopleWare escrito 20 años más tarde que el tema de control y métricas en los proyectos de software, para darte cuenta de su evolución.
El post que más me ha gustado sobre este tema ha sido el de Juan Palacios, y coincido en gran medida con lo que explica en él. El verdadero bombazo ha sido otro post de coding horror, preguntando si la ingeniería del software está muerta, y entronca con el nuevo movimiento que defiende al mundo del desarrollo de software como "artesanía". No sé, quizás debería ser una ciencia experimental -Conocimiento ordenado y, generalmente experimentado, de las cosas- de manera que vayamos aprendiendo posibilidades de hacer bien las cosas...
Cuando salía de la carrera, siempre recalcaba que no era informático, si no -ingeniero- informático. Ahora, aunque esté mal visto, siempre digo que me gusta programar, pero que hay que saber las bases matemáticas y conceptuales necesarias para hacerlo bien. La respuesta a esto muchas veces suele ser: "¿pero los ingenieros seguís programando tras 10 años de experiencia? (sic)

• La ingeniería entendida como un conjunto de procesos plausibles y realizables para solventar un problema, no existe -todavía!- en la informática. Algunos pensaron que CMMI-5 lograba eso, pero se equivocaron.
• La ingeniería civil trasladada al control de proyectos de software no es lo adecuado para todos los proyectos. El "rebote" de las metodologías ágiles así lo confirman.
• Las métricas están sobrevaloradas en los proyectos de software, y sus equipos. Forman parte de una burocracia que genera poco valor cuando se abusa.
  
• No se trata -o no debería tratarse- de una guerra entre bandos. Somos niños con un juguete nuevo, y cada uno cree que se usa de una manera diferente. Debemos aprender.
• Hay una parte de "juego cooperativo", de "problemas sociológicos" que se ha olvidado en la gestión de proyectos tradicional.
• Las metodologías ágiles resuelven algunos problemas, pero no tardarán en salirles puntos débiles, debemos auncar esfuerzos para seguir mejorando.

Finalmente, cada proyecto es diferente. No solo por que el resultado deba ser diferente, si no por que se va a realizar con equipos diferentes. Quizás todos los proyectos del mismo tipo podrías gestionarlos igual, pero nunca gestiones igual equipos diferentes. Debes estudiar personas, perfiles, intereses,... y eso es dificilmente medible. Ignoro si CMMi, por ejemplo, tiene un area de trabajo sobre este tema, la creación de verdaderos equipos de trabajo. Un libro sorprendente en este area, que me recomendó Mario, es Software for your head. Se supone que habla de desarrollo de software, y "solo" ¡de gestión de equipos!

PD: Seguiré con mis posts sobre Lean que prometí, pero ha sido una temporada dura!

El círculo proceso-persona

Leyendo esta entrada sobre la idea recurrente de que lo más importante para hacer software son las personas, me ha venido a la cabeza una reunión de hoy que hemos tenido en Biko. Las mejoras en el desarrollo de software no se acaban nunca, y cuando tienes a medio hacer algo (podeis echar un ojo al documento libre sobre la implantación de técnicas ágiles con CMMI) ya estás pensando en lo siguiente.
Como decía, el post referenciado, me recordaba lo que hacemos cuando intentamos mejorar las cosas. En la mente tienes que lo importante son las personas, pero lo más facil ¿qué es? ¡¡Definir procesos!! Te pones a pensar: si hacemos las cosas así, o de esta otra manera, y luego nos sale esta otra situación, entonces lo que hay que hacer es... definimos cómo se debe hacer esto, para que después se haga igual...

Así que nos hemos ido a los procesos y parecería que nuestra intención es implantar CMMI nivel 4 o 5. (uf, y por cierto, no os olvideis de la encuesta, gracia). Yo siempre acabo diciendo que lo mejor es usar el sentido común, conociendo bien las herramientas disponibles y con la experiencia, se pueden tomar decisiones acertadas que son totalmente diferentes en el marco de un proyecto u otro. Pero siempre parece que tiras a definir los procesos, más que a pensar que la gente que tenga que resolverlos ya sabrá hacerlos, o que precisamente, a los que no sepan les vas a formar.

Es una dialéctica complicada, la de procesos contra personas planteada en el manifiesto ágil. Y cuesta romper. Supongo que tenemos hecha la cabeza de una manera (dura) que es dificil de cambiar la forma de pensamiento.
Todo esto está relacionado con lo que ya he comentado en otras ocasiones: ¿buenas prácticas o procesos? Al final, depende de la gente, a unos los puedes matar de aburrimiento siguiendo procesos muy formales, y a otros perderlos por el camino si no les pones las luces de aterrizaje bien claras.

Encuesta sobre CMMI

A raiz de este post que menciona que hay 85 empresas más en España este año que han obtenido una certificación CMMI, me ha picado la curiosidad, yestoy montando una pequeña encuesta con intención de recoger información de aquellas personas que trabajen en una empresa con certificación CMMI. He reducido bastante el número de preguntas que quería hacer, para que no se haga pesada (que es lo que a mi me suele echar atrás para rellenarla, sobre todo, ;) si como en este caso no hay premio por hacerlo).

Si te apetece, aquí tienes el enlace: Encuesta sobre CMMI.

Y si conoceis a gente que pueda encajar en el perfil para rellenarla, por favor, me encantaría que les distribuyeseis el enlace.
Obviamente, después publicaré los datos y la información que pueda extraer de ellos en esta misma página. ¡GRACIAS!