Durante muchos años he diseñado y desarrollado arquitecturas mediante metodologías tradicionales, en los que el análisis exhaustivo inicial era primordial y necesario.
La arquitectura global resultante era muy específica a los requerimientos iniciales de producto, sin tener en cuenta todos los cambios futuros que pudiesen aparecer a lo largo del tiempo, generando así una arquitectura rígida e incrementando la resistencia a cualquier cambio futuro. Teniendo en cuenta que cuanto mayor es el producto a desarrollar sin previas validaciones por parte del consumidor o cliente, mayor será la probabilidad de que los haya.
El desarrollo de producto en grandes lotes, con largos periodos de lanzamiento es la causa.
En cuanto tuve oportunidad de conocer y descubrir el mundo ágil, método lean y kaizen hace unos años, me convertí en un defensor de sus principios, ya que eran las soluciones a tantos problemas que experimenté en más de once años trabajando en metodologías tradicionales.
El cambio, ya no representaba un problema, sino una oportunidad de seguir creciendo y aprendiendo.
Esencialmente y desde el punto de vista de producto, debemos establecer el producto mínimo viable (MVP), que nos permita experimentar mediante split testing y entrar en el circuito de Crear-Medir-Aprender lo más rápido posible, para saber si pivotar la estrategia o perseverar en ella. Todo ello en pequeños incrementos de producto mediante sprints o iteraciones. Evitando en mayor medida el despilfarro de tiempo y recursos. Siguiendo así el método Lean Startup y adaptándose a la metodología ágil de proyectos.
Con respecto a la arquitectura, este tipo de método de desarrollo de producto es vital para fomentar las arquitecturas emergentes en el equipo mediante la arquitectura mínima viable (MVA) . Teniendo muy presente el principio YAGNI (You Ain’t Gonna Need It). Siendo así muchísimo más sencillo y flexible cualquier tipo de cambio de dirección o imprevisto.
La visión de la arquitectura en las metodologías ágiles cambia: ya no existe la figura de arquitecto de software tradicional como tal en un equipo de Scrum
Sin embargo, como comenta Charlie Alfred, en su post SCRUM and Architecture – Partners or Adversaries?: “la arquitectura es el aceite y el filtro que lubrica adecuadamente a Scrum”.
Es básico prestar atención progresiva al crecimiento de la arquitectura a lo largo del tiempo. Asegurando que se cumplan los principios de calidad/rendimiento/reutilización y evitar la posible complejidad que pudiese surgir para disminuir la posibilidad de generar deuda técnica o incidencias, planificando/ejecutando refactoring periódicos.
Los perfiles más experimentados en arquitectura deben orientar, guiar, advertir y aconsejar sobre posibles imprevistos, observando el crecimiento de la arquitectura, teniendo en cuenta toda su experiencia. Así como los perfiles más especializados en optimización de buscadores (SEO) nos guiarán en el desarrollo siguiendo la estrategia correcta y otros perfiles con otras habilidades en la construcción del producto, mediante técnicas como el pair programming o el mob programming. Fomentando así el aprendizaje del equipo.
En el mundo del conocimiento, como dijo Einstein: «todos somos ignorantes, lo que ocurre es que no todos ignoramos las mismas cosas».
La dificultad entonces para un correcto engranaje de Scrum reside en disgregar:
¿Cual es mi MVP?
¿Qué MVA aplicamos?
A menudo nos dejamos llevar por el pensamiento que algo mínimo, es poco. Pero no hay que pensar en cantidades, sino en el valor que estamos aportando, tanto a nivel de producto como técnico.
Lectura recomendada: Architecture Abstract