Desde que el mundo es mundo existe la discusión sobre si la informática es una ingeniería o no, sobre si el ciclo de vida de un proyecto debe ser así o asá, incluso desde hace un tiempo se habla (y se discute) sobre si el código fuente es el diseño o no. Incluso aquí hemos discutido sobre puentes que se prueban con camiones. Me llama mucho la atención la tendencia de muchas empresas a industrializar el mundo del desarrollo en base a factorías de software y herramientas varias, basadas en analogías incompletas.
Y no es que el objetivo no sea completamente legítimo teniendo en cuenta nuestro porcentaje de éxitos en los proyectos informáticos, simplemente parece que demasiadas veces no se entiende esta profesión. El 80% (apreciación personal, si el lector quiere cambiar el número, que lo cambie) de los documentos que se escriben en un proyecto no se leen jamás en detalle y, lo que es peor, los que se leen normalmente no se actualizan a lo largo de la vida del proyecto. Yo no voy a pedir que no se escriba documentación, pero quizás no lo estemos haciendo de la forma adecuada, o quizás el ámbito de actuación de ese deseo de industrialización sea escaso, limitándose a la parte de construcción/programación.
No quiero decir que el cliente tenga que aprender a programar, pero decidme si no tendría sentido un escenario dónde las “pruebas” se escribieran directamente de una forma técnica (es decir, que se puedan instrumentalizar directamente). ¿No debería un analista funcional escribir un test de integración en la herramienta de pruebas definida para tal uso, de la misma manera en la que en los proyectos de ingeniería se utiliza directamente el Autocad desde el diseño hasta probar cosas?. ¿No ganaríamos todos con ello?. Por una parte se estaría haciendo un diseño de interfaces (interfaces de programación/apis) con sentido para el negocio (notar la palabra “diseño” de “diseño de interfaces”), por otra el analista tendría claro que lo que él ha escrito es lo que se está probando, y lo que es más, podría automatizar esa prueba (una vez se haya desarrollado).
Esto tampoco es nuevo, es lo que siempre se ha llamado Test Driven Development y que ha recibido recientemente nuevas vueltas de tuerca como el Behaviour Driven Development, pero es algo fundamental en el mundo de factorías y subcontratación que tenemos (o quieren que tengamos) hoy en dia, dónde cada vez hay más niveles y más problemas para transmitir la información entre ellos (¿hace falta el experimento de pasar un mensaje al oído del compañero y ver como acaba?).
Sin embargo lo que vivimos es lo contrario. Herramientas milagrosas cuyo resultado siempre hay que retocar y toneladas (bueno, entre 0 y N) de documentación que nadie lee ni actualiza. ¿Por qué?. Porque programar lo puede hacer un mono o porque, como he oído últimamente, se trata de describir todo para que al programador no le quede lugar a la interpretación. Es discutible si somos capaces de describir todo -o incluso algo- de una forma coherente, pero aún así estaríamos queriendo traducir el lenguaje natural, impreciso y arbitrario, en un lenguaje técnico (el código fuente), teniendo ademas en cuenta que esto se produce en situaciones que habitualmente conllevan una importante carga de estrés (con poco tiempo para nada, y menos para leer y escribir con detalle ni hacer pruebas).
En una ingeniería cada nivel es capaz de entender el material técnico al detalle que se les pide. Tanto el cliente, como los ingenieros que lo diseñan, como la gente que está al pie de la máquina son capaces de mantener el flujo de la información técnica, por mucho que acaben cargando el puente con camiones. Sin embargo parece que los informáticos queremos ser más listos, llegando incluso a pasarnos de listos a la luz del pírrico porcentaje de éxito de nuestros proyectos.
Y este ejemplo aplicado a las pruebas es aplicable a muchas más cosas. Interface de usuario, listado de funcionalidad, etc. Ya hemos tratado este tema en el pasado también de una forma u otra (por ejemplo: la interface es lo primero). Renunciamos al prototipo (esqueleto vacío) como herramienta de discusión porque preferimos copia y pegar de una oferta que gastar unas horas en entendernos realmente con el cliente.
Obviamente en esta profesión hay sitio para todos y ni pretendo hacer un alegato para alzar a los geeks al poder ni menospreciar todo lo que no sea programación. Simplemente tenemos que encontrar un lenguaje común que minimice los problemas de interpretación. Y si en algo podemos estar de acuerdo es que el lenguaje natural y las toneladas de documentos escritos en él no pueden ser nuestra lingua franca.
El problema, en parte, lo tiene la carrera por conseguir cmmi (y demás certificaciones) a toda costa, metiendo a presión unos procedimientos que no casan con el verdadero trabajo de la empresa.
Joer, mira si estoy deacuerdo contigo que llevo un tiempo buscando como solucionar, almenos en parte, ese problema y lo estoy llamando Yanged
De momento no he escrito nada concreto pues no me atrevo mucho. Me gustaria hacer lo que hicieron con Second life (primero miro si puedo ganar algun durillo con esto y luego lo pongo open-source) pero he publicado alguna imagen del IDE de Yanged (http://blogs.sistes.net/Garito/images/ArbolYanged.png)
En fin no se si esto podria ser del interes de alguien pero el tema que tratas aqui es justo lo que me movio a dejar mi puesto de consultor y desarrollar mi idea (Yanged)
Saludos
“Obviamente en esta profesión hay sitio para todos y ni pretendo hacer un alegato para alzar a los geeks al poder ni menospreciar todo lo que no sea programación” Yo creo que evidentemente no se trata de eso, hay muchísimas labores que hacer dentro de un proyecto software que no son programación, pero en este país existe mucha tendencia a relegar la programación a una tarea para “monos amaestrados”, a huir de esto como de la quema y a tomar decisiones clave en proyectos software sin tener ni idea ya no de programación sino de aspectos básicos del desarrollo software. Evidentemente todo el personal que no puede escribir líneas de código tiene que hacer algo, y la solución es escribir documentación (que esta se lea o no parece no ser relevante, si quisieran que alguién la leyera no serían tochos de 500 páginas). Personalmente opto por la documentación escueta y lo más integrada con el código que sea posible, aunque muchas veces es obligatorio documentar de otra manera (como tu jefe no se va a leer tú código en la vida, hay que hacer patente a que te dedicas, icluso te lo exigen).
Mi respuesta es: No.
Como tu bien dices: “En una ingeniería cada nivel es capaz de entender el material técnico al detalle que se les pide”.
Pero la nuestra es una ingeniería demasiado joven, aun en pañales y donde en los cargos altos reinan muchos personajes oportunistas que no dominan este mundo, que tampoco parece que tengan un interés real ni motivación por hacerlo y que van imponiendo sus “ideas” sobre el desarrollo y gestión de proyectos software.
Siempre he pensado que hemos llegado demasiado pronto, que la cosa cambiará dentro de 10-20 años cuando los de nuestra generación y venideras con una buena formación y experiencia ocupen esos cargos, pero también con empresas como la vuestra, una empresa pequeña sí pero con la motivación y talento para hacer las cosas bien.
Porque yo al igual que tú, no pienso que la forma de hacer las cosas bien sean estas software factory con el logo del CMMI en la puerta, donde se enseña a programadores novatos a hacer Oes con canutos y arrastrar documentos infumables que nadie lee, ni siquiera el que los actualiza, donde los analistas emplean un gran % de su tiempo con las diferentes herramientas de gestión para cargar hasta los 10 minutos que se ha ido a tomar un café y donde los que deciden los procesos no han trabajado en un proyecto software que tuviera éxito sin echar 1000 horas extra (=por encima de la estimacion) en su vida.
En cuanto a la documentación, yo como vosotros, abogo por una documentación útil, reducida y generada a partir del código dentro de lo posible. Ésto, más talento, más motivación son el camino o al menos el que yo quiero seguir.
Un saludo.
Una frase que define el estado de la informática: Hay demasiado quijote en el mundo del software.
Algunos puntos:
- si la documentación queda desfasada quiere decir que no se debería haber generado. Sólo debe escribirse aquella documentación que sea de trabajo.
hay muchísimas herramientas y procesos que desconocemos que son sumamente útiles. Un ejemplo: si habéis utilizado herramientas de gestión de requisitos y trazabilidad (tipo DOORS), no sabréis cómo habéis vivido sin ella antes.
aplicar la CMMI no presupone un coste adicional (siempre y cuando se aplique bien). Pero claro, normalmente tiende a complicar los procesos porque, si no, quien vivirá de ellos ¿? :-D
Incluso, algunos recién licenciados tienen problemas para distinguir entre patrones arquitectónicos, de diseño o Idioms. E incluso, no saben qué es un interfaz en Java.
Y cuando vas rascando te das cuenta que no es culpa de una ingeniería inmadura, sino que los ingenieros que la aplican son inmaduros, dentro de un mercado inmaduro con un entorno académico más inmaduro aún. Y ése si es un gran problema de la informática.
Vaya tostón he soltado. Siento haberme extendido.
Saludos y buenas fiestas
Estoy con Julio al 100%.
Pero la industria está cambiando poco a poco y cada vez hay más clientes que discuten las características técnicas del proyecto, frameworks que se van a utilizar, etc., lo cual es un placer desde el punto de vista del desarrollador. Lo gracioso es que en esas ocasiones quien no se entera de lo que se está hablando es el director de proyectos o el de cuentas :-P, pero también estos se están actualizando a marchas forzadas.
@jaikio Solo un par de puntos:
Lo de las herramientas de gestión de requisitos suena a las “herramientas milagrosas” que citaba Alberto. Creo que la conversación útil esta un nivel por encima de las aplicaciones a utilizar, en el contexto de cómo conseguimos que toda la cadena de compra/venta de IT tenga un conocimiento uniforme de lo que se debe realizar y cuales son los objetivos que se pretenden alcanzar. Las soluciones actuales pierden, de manera intencionada o no -lo cual sería otro interesante debate-, gran parte de ese conocimiento según se sube Y/O baja en dicha cadena. El debate de fondo tiene más que ver con donde se encuentran las razones para que esto suceda y que sustitutivo podemos presentar a documentos de requisitos y especificaciones funcionales que nos permita a todos (desde el cliente, hasta el programador) compartir un mismo léxico de la manera en la que lo hacen un supermercado -> un comercial de una empresa de cámaras de frío industrial -> el ingeniero industrial que la diseña -> la empresa que fabrica los componentes -> y las personas que la ensamblan. Siempre y cuando coincidamos en que el desarrollo IT es un proceso industrial (algo que yo a titulo personal no comparto :-).
Obviamente existen personas poco formadas en el sector, pero estamos hablando del problema que se les presenta incluso a las personas altamente cualificadas. Damos por descontado que aquellas que suman el insulto a la injuria se encuentran con aún más problemas.
Si entendemos en la metáfora del Quijote, al personaje utópico, febril en su fervor por lo que le interesa, capaz de arriesgarse por problemas de los que podría huir, que piensa que otras personas pueden necesitar su ayuda y se dispone a prestarla, que sigue adelante de acuerdo con sus principios más allá de lo que los demás consideramos “seguro”, etc. creo que no solo el mundo del software, sino el mundo en general necesita más Quijotes.
@Alejandro HR No estoy seguro de que tenga sentido que un cliente especifique las herramientas que se deben utilizar. No creo que la mayor parte de ellos (obviamente siempre hay excepciones) estén capacitados o incluso cómodos tomando esa decisión. Creo que el razonamiento de Alberto apuntaba mas bien a la capacidad de especificar los requerimientos de las aplicaciones y como hacerlos. Esto si que es algo que todos los clientes pueden -y deberían- hacer.
Perdonad pero el entorno academico no esta inmaduro, los principios basicos de los años 60 en compiladores, sistemas oeprativos, lenguajes orientados a objetos, inteligencia artificial, todavia no han sido superados.
El lenguaje cobol y el batch, sigue mandando en las grandes empresas a pesar de que no se enseña en la universidad, razones tendran pero no laborales.
Los ingenieros y licenciados informaticos, siguen programando; a pesar de que existen numerosos modulos de FP dedicados solo a informatica de gestion y o sistemas.Vamos moscas a cañonazos.
Los informaticos creemos que sabemos de todo, en medicina hay especilistas, en abogacia tambien, en ingeniera tambien.
Sabes de todo no sabes de nada.
El arreglar los problemas a las 19:00 o 20:00 horas, tomando cervezas entre jefes y comerciales es lo que vuelve locos a los tecnicos.
No se si me ganaré la enemistad de todos pero yo veo el otro lado de la moneda. Por un lado me encuentro profesionales que reclaman autonomía y autoridad para decidir cómo debe hacerse un diseño y que no todo se lo documente. Pero que luego cuando entregan “churros” impresentables que ni de lejos justifican el tiempo empleado se escudan en que la documentación no era “detallada”. Es fácil pedir que cada uno tenga su parcela pero luego muchos no quiere asumir la responsabilidad que eso significa ¿No somos ingenieros y se supone que eso significa algo? (buenos, sois).
Por otro lado tanto argumentar sobre las otras ingenierías… Yo tengo más amigos fuera de la informática que dentro y la verdad es que allí es igual. Claro que un puente no se hace igual, como tampoco se hace igual el software de un banco o de un avión. Pero en los “pequeños” proyectos de ingeniería industrial pasa lo mismo, revisas la documentación y no coincide con la realidad, hay una buena aproximación pero de lo planeado a la realidad también han tenido que improvisar y luego nadie actualiza la documentación. Hay chapuzar e intrusismo. ¿Cuantos proyectos de instalación eléctrica o de red habéis visto hechos por el electricista de turno? Yo unos cuantos, a veces iban bien :/
En todo caso estos argumentos no significan que no esté plenamente de acuerdo contigo en que hay aún un terreno para avanzar en lograr un estándar de comunicación y de separación adecuada entre roles. Y de cara a documentar, no conozco DOORS, ya se que debería, pero las nuevas plataformas web con wikis de fondo están empezando a seducirme para tratar de tener todo documentado y actualizado a través del único método que conozco: tener una única fuente de trabaja. Así si algo cambia está inmediatamente documentado.
lboisset, estoy de acuerdo contigo. Sin duda los propios profesionales tenemos nuestra parte de culpa en la situación, pero ese era el tema de otro post XD (¿Qué le pasa a esta profesión?).
En todo caso, coinciendo contigo, yo siempre he apostado por aplicar en la empresa la responsabilidad y la autoridad (aunque no siempre lo cumpla, sobre todo lo segundo), entendiendo por responsabilidad asumir las consecuencias nuestras propias decisiones al nivel que sea, y lo segundo por exigir que se asuman esas responsabilidades (no por un simple ‘ordeno y mando’).
También coincido en que en todas partes cuecen habas, pero no me negaras que cuando alguién va a fabricar un tornillo (perdón por la reducción al absurdo), todos son capaces de comunicarse sin recurrir a “coge un trozo de metal, estíralo, házle una espiral y pone un cabezón para apretarlo con una palanquita” XD.
Como comento, lamentablemente no tengo la solución (ni a esto ni a casi nada), pero si sirve para reflexionar, pues mejor que mejor.
BTW, sobre los wikis…. yo lo intenté con ellos hace un par de años… el resultado es mejorable, pero no le hecho la culpa del todo a la herramienta.
Más bien apunto no tanto a las herramientas o programas de desarrollo (que en muchos casos los elige el desarrollador), sino a por ejemplo, utilizar frameworks específicos sobre un proyecto en el que el cliente quiere seguir haciéndolo evolucionar, permitiendo incluso cambiar de empresa a mitad de proyecto. Uno de los problemas que se plantea con los proyectos a largo plazo en algunas empresas es el hecho de que terminan “casándose” con quien desarrolla sus aplicaciones. El hecho de que el cliente tenga la capacidad de elegir la pauta sobre la que se desarrollará el proyecto es para garantizar su posible continuidad por parte de otra empresa sin tener que rehacer todo el trabajo. Por otro lado, les permitiría disponer de varias empresas desarrollando diferentes módulos y asegurarse de su compatibilidad.
Si bien estoy de acuerdo en que la mayoría no tienen conocimientos suficientes como para ni tan siquiera nombrar Cairngorm, en ocasiones, sus departamentos técnicos sí que los tienen. Obviamente, esto no encaja con el perfil de muchos clientes, debe tratarse de una empresa o multinacional con un volumen de desarrollo medio-alto.
Un poco off topic, pero no mucho, comentar que últimamente estoy utilizando esta herramienta, http://www.serena.com/products/prototype-composer/home.html , que me da una visión bastante completa de la gestión del proyecto, incluyendo la parte de “el interfaz es lo primero”.
Saludos