La ÚNICA y MEJOR manera de hacer software es imitando a arquitectos y cadenas de montaje, reconozcámoslo.

Han sido muchos muchos años intentando auto convencerme de que el software debía hacerse de otra manera. Pero hoy he de confesaros que mi búsqueda ha sido en vano, por fin lo veo claro, vi la luz: la única manera de que hagamos buen software es imitar a la industria automovilística o a los arquitectos cuando construyen casas. Ellos son los que saben, nos llevan siglos, aprendamos.
No quise verlo durante años, miré a otro lado, leí libros prohibidos, caminé por el límite del mal, tiempos perdidos, creí que nada nos haría cambiar, todo en vano, pero ahora sé la verdad, sí, sí, cuando yo planteaba que había otras maneras de hacer software estaba en un error, lo mejor inventado es el enfoque industrializador, el de cadena de montaje aplicado al software, la churrera. Ellos son los que saben, aprendamos.
Me empeñé, y me empeñé, y muchos decían que esas ideas, ¡esas elucubraciones mías!, eso de.. ¿hacer software sin usar el ciclo en cascada? ¿sin proyecto cerrado?, je, hacer software sin requisitos cerrados, ay, o que el software se puede hacer iterativamente (je, je, iterativamente)… Eran ideas de rockero antisistema. En aquellos momentos me sentí molesto, pero ahora lo veo: llevaban razón y lo decían por mi, nuestro, bien.
Así que, a partir de este momento, este blog va a cambiar para siempre, incluso haré auto-censura y mañana comenzaré a borrar todos los post que no piensen y compartan las «»nuevas»» ideas (si quieres quedarte con algún antiguo revolucionario, algún post prohibido, sólo tendrás hasta las 0:00 de hoy, mañana serán historia).
Las ÚNICAS ideas que desarrollaré a partir de ahora, las ÚNICAS que expondré en mis charlas, las ÚNICAS escribiré en mis libros y defenderé a partir de ahora serán las siguientes:
1 – Antes programar debe haber una documentación UML previa exhaustiva que evite errores posteriores. Todo debe estar mínimamente documentado antes de comenzar. ¿Te imaginas empezar una casa sin planos cerrados? Amigo, no seas tonto, no tires el dinero, cierra siempre el UML antes de empezar a tirar una línea.
2 – La única medida fiable del avance de un proyecto es contando líneas de código. Es más, deberíais medir la productividad del equipo según las líneas que programan por semana, como se hace en albañilería, por “metros de tapia construida por semana”.
3 – El proyecto cerrado es el único modelo que funciona. La licitación de obras públicas es ejemplo de ello, años nos llevan de experiencia, ¡aprendamos e imitémoslos!
4 – Necesitamos tener churreras de software, perdonar la expresión, pero tan popular como clara, no seremos una buena industria hasta que por un lado entren requisitos y por otro salga código.
5 – ¿Empezar a desarrollar sin tener un conjunto de requisitos cerrados y firmados? Error amigo, error. Y ¡claro que se pueden cerrar siempre los requisitos antes de empezar!, lo que pasa es que no le dedicáis tiempo, ¿acaso no lo hacen los fabricantes de automóviles?
6 – Los Gantt son la manera más eficiente, y única, que hemos inventado para gestionar proyectos software. Complementariamente, puedes utilizar los PERT y las rutas críticas. A ver, cómo te lo explico, proyectos enormes como los de construcción de barcos utilizan Gantt… ¿acaso están ellos en un error? No te engañes, usa Gantts.
7 – Lo que menos importa en un desarrollo son dos cosas: las personas y la calidad del software. Pensar de otra manera es… de rockero antisistema.
8 – Si quieres aumentar la productividad del equipo… añade más gente al proyecto. A equipo más grande más productividad. Ya lo dice el refrán, «burro grande ande o no ande», y los refranes son sabiduría. ¿Acaso no lo hacían así los egipcios construyendo las pirámides? ¿vas a poner tú ahora en duda a los egipcios? Y si eso lo compartes con un sistema de fichar a la entra y la salida mucho mejor, eso fue lo único que les falto a los egipcios, un sistema de fichar, pero tu ahora puedes motivar así a la gente.
Para los despistados por la Navidad, tener presente que este post fue escrito el día 28 de diciembre ¿ok? ya sabeis lo que pasa el 28 de diciembre.

• Acerca de
• Últimas entradas

Javier Garzás

Javier Garzás es Doctor (Ph.D) en Informática, con un
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.

Últimas entradas de Javier Garzás (ver todo)

• Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
• Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
• Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024