¿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!