domingo, 31 de mayo de 2009

Ingeniería del Software... ¿utopía?

En estos últimos días he estado dándole vueltas a una idea, que la verdad no me deja vivir demasiado tranquilo.

En las consultoras de software como en la que trabajo, es tristemente habitual el trabajo improvisado, mal planificado, con muy escasa generación de documentación que pueda ser útil a los equipos de desarrollo... en fin, el día a día de muchos consultores: ¿qué os voy a contar?.

La cosa es que este desorden, este caos viene provocado por desórdenes anteriores, caos de base: malas ventas, ignorancia a todos los niveles de la jerarquía, falta de interés en la metodología, falta de formación y conocimientos básicos... y aquí viene el problema: "no hacemos las cosas bien porque no tenemos tiempo ni recursos, y no tenemos tiempo ni recursos porque no hacemos las cosas bien". Es decir, nos acostumbramos a "torear" los problemas en nuestro día a día y consideramos que esto es "lo normal de la consultoría", cuando realmente tenemos una serie de herramientas, legadas por nuestros "hermanos mayores del software", agrupadas bajo el nombre de metodologías de software que están precisamente pensadas para ayudarnos a evitar la cantidad de "marrones" que nos llueven a diario.

Tenemos unas valiosísimas recomendaciones extraídas de la vida real, surgidas de fracasos previos a los nuestros y aún así seguimos dándole la espalda.

Recientemente asistí a un curso para analistas software y en ella se dió una idea muy interesante, y esta es: "a pesar de que en tu empresa no se favorezca este tipo de "buenas prácticas", y aunque sea imposible introducir de forma rápida este cambio en la mentalidad de los equipos de desarrollo y en las consultoras en general, debemos luchar por el cambio desde la base.

Este cambio (que redundará sin duda en nuestro beneficio personal tanto como en el de la empresa) debe ser primero un cambio personal, en tu día a día, apostando por la ejecución de las buenas prácticas de la ingeniería del software a nivel personal, para luego extender esta filosofía a tu equipo de trabajo."

Evidentemente no estoy hablando de un cambio instantáneo, pero sí debe un objetivo a medio plazo, que no debe estar eclipsado por la histeria del día a día.

Escribiendo esto último se me viene a la cabeza la frase: "Que lo urgente no te impida ver lo importante", interesante máxima a aplicar en nuestra trabajo.

Espero vuestras opiniones al respecto. Yo por mi parte iré escribiendo los resultados de este "paradigm shift", este cambio de mentalidad.

Un saludo
Juan Fernández

6 comentarios:

gpfdez dijo...

Me ha gustado el artículo. Ojalá no sea una utopía y poco a poco se organicen las cosas en condiciones. Probablemente el problema venga de que la Ingeniería Informática y por lo tanto Ing. del Software son demasiado "actuales", por lo que toda la organización de proyectos y el sistema de desarrollo de los mismos ha sido muy caótica desde el principio, porque probablemente las personas que se dedicasen a eso, al igual que ahora, serían intrusos en la profesión.

Poco a poco podemos ir metiendo orden, pero piensa que toda la cabeza de empresas, vease gerentes, jefes de proyecto,... no son informáticos, por lo que probablemente no tengan una formación para que puedan organizarse las cosas en condiciones...

Adolfo dijo...

Bueno,ante todo me ha gustado bastante el artículo aunque quizas me ha parecido algo "soso", es decir, mencionas todo el tema muy de pasada sin profundizar en nada concreto. A eso me referia cuando te comente que me esperaba algo mas "revolucionario".

Entrando ya en tema, el problema como bien dices es cosa de mentalidad de todos, los informaticos tendemos a culpar a telecos, matematicos, fisicos, etc. pero la culpa es nuestra al 90%. Es decir, argumentamos siempre que debido a nuestra formación somos capaces de hacer las cosas mejor, pero a la hora de verdad caemos en las mismas chapuzas que cualquiera, desarrollamos a lo loco sin metodologia, por seguir la corriente de la empresa donde estamos. Al final tenemos que lo hacemos de la misma forma que todos,y tenemos que supuestamente los que tenemos capacidad para cambiar las cosas seguimos la corriente, haciendo bien poco para demostrar que somos mejores.

Y si encontramos ingenieros que estan dispuestos a cambiar las cosas es dificil encontrarlos sin el "ego" subido, con la consabida frase de "yo soy ingeniero y no programo". Y para mí este es el principal fallo de la ingeneria, es lógico que en un proyecto bien organizado no este un ingeniero "picando", pero la ingeneria del software no acaba ni mucho menos en el analisis, mucha parte de ella acaba en el codigo, ya sea de forma directa como el diseño de la algoritmia compleja, como indirecta en los diagramas de clases,de navegación, etc.

Un ingeniero a mi parecer debe preocuparse mucho de como se haga el código, pues el proyecto mejor documentado puede darse al traste con unos malos habitos de programación. Son los ingenieros mejor preparados los que acaban desarrollando nuevas técnicas de programación y herramientas que las favorecen (Por ejemplo, la programación agil, y sus frameworks mas representativos como ROR, GRAILS, etc..). Son personas que acaban plasmando toda la metodologia del software en guiar al programador a que la siga de forma comoda.


¿Que quiero decir con todo esto? que la labor de analista no acaba en la documentación, debe preocuparse como ese analisis se plasma en código. Un profesor un dia me dijo que nuestra profesión debería acabar como la de la construcción. Donde hay un experto en diseño (arquitecto) que se empapa del terreno y condiciones donde se va a construir (equivalente a la tecnologia en nuestra rama) y un experto en construcción (aparejador), especializado este ultimo en interpretar y levantar esos planos. Actualmente lo que yo veo es que hay alguien que diseña ( sin ser experto, y a veces sin tener ni idea de que va el tema), y cada desarrollador lo interpreta como quiere y como puede. Y claro, así no se puede...

Despúes de salirme un poco las ramas y volviendo más al tema de tu entrada decir que ando 100% de acuerdo contigo es que el cambio debe venir desde la base, pero es dificil hacerlo en un entorno hostil a estos cambios, donde hay un gran porcentaje que odia la parte técnica de la informatica,con plazos que te obligan a torear, poner parches y a huir sino quieres acabar empleando tu escaso tiempo libre en ello, y especialmente es dificil cambiar algo cuando eres el ultimo mono en la cadena.

En resumen, cualquier idea, iniciativa o propuesta para intentar cambiar algo sera bienvenida, por mi parte intentare hacer todo lo que pueda para fomentar las "buenas practicas".

donyomismo dijo...
Este comentario ha sido eliminado por el autor.
donyomismo dijo...

En mi empresa ocurre lo mismo. En los proyectos, por ejemplo, la documentación de análisis se genera después de casi haber terminado el proyecto y, simplemente se realizan para presentarlos en las auditorías de calidad.

Lo que, en principio, debería servir como ayuda al desarrollo software, al final no sólo no se aprovecha, sino que se convierte en una carga.

En mi trabajo, como buena práctica, empecé trabajando elaborando mi propia documentación, con el objetivo de no olvidarme nunca de nada, estructurándola de acuerdo con lo que todos hemos aprendido. Esos documentos empezaron a ser útiles para los demás compañeros que lo veían como una fuente de información. Ahora muchos del departamento, aún no siguiendo una metodología al pie de la letra, tienen documentos compartidos en Google Docs que rellenan colaborativamente siguiendo la estructura de esos documentos iniciales.

En vez de esto, habría sido mucho más útil que todos los compañeros del departamento(con diferente formación académica) hubiéramos sido formados en una metodología en concreto y pudiéramos aprovecharnos de sus beneficios.
Al final, debido a que los proyectos que llevamos a cabo no son muy grandes, los jefes se escudan en que se siguen una metodología ágil para el desarrollo, o lo que es lo mismo, “hacemos lo que nos da la gana”. Es un misterio cómo puede ser que muchos de los proyectos llegan a ser terminados, aunque con una calidad cuestionable.

Es una pena, pero algunos "jefes" ni siquiera saben para qué sirve seguir una metodología, sólo saben que han de tener ciertos documentos preparados para cierta fecha.

Ahora mismo me encuentro desarrollando un proyecto de máster consistente en el estudio del concepto de “metodología” en el desarrollo de software, y es asombroso ver que hay metodologías, bastante maduras, para todo tipo de proyectos. Para sacarles partido, basta con elegir bien ;)

Ánimo a todos, no es una batalla perdida, ni mucho menos.

Rafa dijo...

En mi humilde opinión no se te da el cielo en una empresa nada más llegar, si no cuando lo alcanzas tú. Eso viene a ser más o menos como que una empresa como en la que estás te da los instrumentos, pero no las facilidades, y tu eres el que tienes que dar ese paso. En la vida puedes ser conformista o no porque para mi no hay medias tintas. En cuanto a la ingeniería del software creo que le queda mucho que recorrer. El día que un informático se dedique a pensar en que la reutilización y las herramientas de ayuda al desarrollo son necesarias para el desarrollo será el día en que cambiemos la mentalidad a lo que nos han enseñado y podamos comenzar a pensar en componentes, reutilización, reducción de costes, formación del equipo etc. ¿Conocéis algún arquitecto que no sepa interpretar planos? yo conozco muchos informáticos que no saben interpretar un diagrama de clases o simplemente captar los requisitos de un sistema.

ELL dijo...

Mi experiencia me indica que no sólo es culpa de nuestras empresas.
Los propios clientes son los que a la hora de recortar el alcance de un proyecto atacan primero a la documentación y a la fase de análisis,
a la que sólo acuden en caso que quieran cambiar de proveedor.Llevo 7 años y pico en este negocio, he pasado por varias empresas,
y siempre los clientes han sido demasiados permisivos con este tema. Incluso en algunas organizaciones te dan el análisis echo y sin posibilidad de replica.
Pienso que el cambio pasa por uno mismo, y exigirnos a nosotros y a nuestros equipos,
no sólo conocer las diferentes metodologías y herramientas sino ser proactivos en su uso.
Hay que mentalizar a nuestros clientes, gerentes, JP,...la importancia de crea
y MANTENER una serie de entregables mínimos en cuanto a documentacion y código y apoyarse en determinadas herramientas que existen.
No obstante, el día a día marca el desarrollo de un proyecto, y los imponderables surgen y casi nunca depende del equipo de trabajo.