especialistas en integración. mulesoft

UNA BUENA ARQUITECTURA FACILITA LA AGILIDAD

Nadie se propone diseñar mal software; más bien sucede lentamente con el tiempo.

Una estancia desordenada. Ningún diseñador se propuso crear este desastre. En su lugar, sucedió naturalmente con el tiempo, como el resultado de pequeñas decisiones malas, que destruyeron gradualmente este espacio.

Muchas personas, tratan de correlacionar la creación de software, con la construcción de una casa: ésto no sólo es incorrecto, sino que además, es peligroso.

 

Construir software no es como construir una casa. Es mas artístico que eso. La codificación es mas que seguir un diseño esquemático

 

¿Cómo construimos Casas?

Al crear una estructura, el diseñador y el constructor, son funciones separadas. En el software, la metáfora comienza a descomponerse.

  • Planos – Los planos de la construcción son muy detallados. Esto, está más alineado con el código fuente real, que con los diagramas del sistema.
  • Construcción – El acto de construir en el desarrollo de software, es completamente automatizado, se llama «el compilador»

 

El proceso de hacer software, es en realidad, mucho más como escribir un libro, que construir una casa. Es algo más «Ágil»

 

  • Lo primero que hace un autor, es crear un esquema de la historia, un plan o mapa de ruta.
  • Un autor entonces, sólo escribe, tratando de completar sus pensamientos.
  • Una vez que el pensamiento completo se formula, entonces el autor, realiza arreglos o revisiones.
  • Cuando está cómodo con sus ediciones, un autor, puede entonces enviar para la revisión editorial.
  • Finalmente, la historia alcanza un nivel de madurez, que el autor es capaz de compartir públicamente.

 

Una buena arquitectura facilita la agilidad

 

El manifiesto ágil; afirma que los procesos y las herramientas siguen siendo importantes con agilidad, pero los individuos y la interacción se valoran mucho más. La mayoría, sin embargo, interpretaron el manifiesto ágil, de manera incorrecta, asumiendo que los procesos no son necesarios …

 El manifiesto, también declara, «software de trabajo sobre documentación comprensiva», que ha llevado a la gente, a no ver la necesidad, de definir la arquitectura o hacer diseño de software. Esto, ha llevado a algunos conflictos entre Arquitectura y Agilidad.

El primer conflicto, es sobre la estructura del equipo: ¿ necesitamos un arquitecto de software dedicado?, o ,¿ todo el mundo es un arquitecto de software?

El principio 11 del manifiesto, afirma que «las mejores arquitecturas, requisitos y diseños emergen de los equipos auto-organizados». La buena noticia, es que el manifiesto menciona la arquitectura y el diseño. Conocemos casos de equipos exitosos, donde el rol de la arquitectura, se extendió entre los componentes, pero también , y muchos de ellos, donde no existía una clara responsabilidad de la arquitectura y el diseño; donde todo el mundo suponía, que alguien más, estaba cuidando de la arquitectura.

El segundo conflicto, tiene que ver con el proceso. Históricamente, ha habido una tendencia hacia el “primero, grandes diseños”, donde la gente, trató de «entender todo» para definir un plan. El diseño evolutivo, intentó proporcionar una solución, haciendo un cierto diseño. Pero, es difícil cambiar el software, cuando la arquitectura resulta ser incorrecta: la refactorización puede ser costosa.

 

Los bloques de cimientos básicos tienden a funcionar mejor, si están integrados desde el principio.

 

Para solucionar los problemas con la arquitectura, necesitamos entender lo que realmente es ágil. La definición central propuesta:

Moviéndose rápido, abrazando el cambio, liberando a menudo, obteniendo retroalimentación.

 

«Agile» es un enfoque ligero, para ofrecer software, basado en una mentalidad y cultura, de mejora continua.

El principio 9 del manifiesto afirma, que «la atención continua a la excelencia técnica y al buen diseño aumenta la agilidad». Una buena arquitectura permite agilidad.

 

La agilidad, es un requisito «no funcional» o «de calidad».

 

No se tratará, de crear un estado final perfecto, un marco o una arquitectura completa. Se necesita, un punto de partida para el equipo y lo que se está construyendo, de modo que se avance, en la manera correcta.

 

Juntos como equipo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *