La historia del desarrollo de software puede entenderse como la búsqueda constante de mejores formas de afrontar un problema que apareció casi al mismo tiempo que los propios ordenadores: construir sistemas cada vez más grandes y complejos sin perder el control sobre ellos. En los primeros años de la informática, programar consistía principalmente en conseguir que una máquina ejecutara correctamente una serie de instrucciones. A medida que los sistemas crecieron, esa visión dejó de ser suficiente, porque ya no bastaba con conseguir que el código funcionara: también era necesario encontrar formas sistemáticas de organizar, desarrollar y mantener sistemas cada vez más complejos.

Cuando empecé a estudiar arquitectura de software, una de las cosas que más me costaba era entender qué significaba exactamente cada una de las cajas que aparecían en los diagramas. Una caja podía representar un módulo, un componente, un servicio, un proceso o incluso un servidor. Con las flechas ocurría algo parecido: podían representar una dependencia, una llamada, un mensaje o una relación entre el software y la infraestructura.

Después de leer Software Architecture in Practice, de Len Bass, Paul Clements y Rick Kazman, encontré una clasificación que me resulta bastante útil para poner un poco de orden en todo esto. Los autores hablan de tres categorías de estructuras arquitectónicas: estructuras de módulos, estructuras de componentes y conectores y estructuras de asignación.

En desarrollo de software es habitual asumir que las releases forman parte natural del proceso de Scrum; que ocurren al final de un sprint, que agrupan todas las historias planificadas o que representan el último estado del flujo de trabajo. Sin embargo, esta asociación es más cultural que real. Aunque lo parezca, las releases no dependen de Scrum, ni del estado de tus historias, ni de lo que hayas decidido planificar en un sprint.

La batalla entre producción y calidad no es exclusiva del desarrollo de software; se da en todas las industrias. En la manufactura, por ejemplo, Henry Ford revolucionó la producción con la línea de ensamblaje, permitiendo fabricar automóviles a una velocidad sin precedentes. Sin embargo, este enfoque sacrificaba la personalización y, en algunos casos, la durabilidad de los vehículos. En la industria de la moda, las marcas de fast fashion logran lanzar nuevas colecciones en semanas, pero a menudo a costa de la calidad de los materiales y la sostenibilidad.

En el desarrollo de software, esta tensión también existe: algunos desarrolladores priorizan la entrega rápida de funcionalidades, mientras que otros se enfocan en la solidez y estabilidad del código. Como Product Owner, tu papel es comprender estos dos enfoques y gestionarlos adecuadamente para el éxito de tu proyecto.