Agile se enfoca en desarrollar códigos viables a partir de pequeñas historias de usuarios. La programación en pareja alienta a los desarrolladores a formar parejas, a involucrarse activamente entre sí para encontrar la mejor solución para el problema. El diseño y el código se revisan y refinan activamente, hasta que alcanzan un estado en el que todos confían en que el software se puede mantener y es robusto para los clientes.
Agile transforma el mecanismo de comando y control, donde los arquitectos dictan cuál debe ser el diseño, en un proceso democrático que otorga a todos la autonomía para diseñar el sistema. Esto lleva a la pregunta, ¿sigue siendo relevante un arquitecto de software en Agile? ¿Agile transforma lentamente el papel de un arquitecto en algo más?
Gran pregunta y definitivamente algo que no parece abordarse muy bien en el material estándar que existe. No pretenderé tener todas las respuestas, ya que todavía estamos luchando con esto nosotros mismos, pero definitivamente todavía existe la necesidad de un rol de arquitecto en un entorno ágil. Es casi definitivamente diferente al papel típico en un enfoque más en cascada, pero sigue ahí. Parece que, en un entorno ágil, el rol del arquitecto se involucra mucho más en la parte de preparación del trabajo pendiente. Son un candidato principal para hacer prototipos rápidos y otras investigaciones para ayudar a dividir grandes historias de usuarios en otras más pequeñas que se ajusten a un sprint. Como propietario de un producto, muchas veces tengo una historia de usuario que es demasiado grande para caber en un sprint pero no es t claro desde una perspectiva empresarial cómo desglosarlo. Aquí es donde parece ser muy beneficioso involucrar al equipo de entrega para ayudar. Durante las reuniones de preparación del trabajo atrasado del equipo, habrá una discusión sobre las posibles formas de abordar el problema y, muchas veces, será necesario realizar más investigaciones sobre estas alternativas o algunos prototipos antes de poder tomar una decisión. Aquí parece ser donde el rol del arquitecto encaja mejor en Agile.
En un entorno de varios equipos donde hay una gran cantidad de código compartido, esto podría ser suficiente carga para garantizar que un arquitecto dedicado trabaje con el equipo del propietario del producto para ayudar a proporcionar este tipo de comentarios que garanticen la coherencia entre los equipos. En cualquier caso, como siempre, el objetivo del prototipado y la investigación es obtener el conocimiento justo para poder tomar una decisión y avanzar. Cualquier código de ese esfuerzo debe descartarse y el conocimiento debe compartirse de otra manera. Esta podría ser una documentación liviana, podrían ser algunos diagramas simples, podría ser simplemente una conversación. En términos generales, si fue lo suficientemente complicado como para justificar la investigación, probablemente sea lo suficientemente complicado como para justificar cierto nivel de documentación, siempre que no se use como un traspaso y acompañe una discusión.
Sí, la arquitectura es vital y sí a todo -y muy bien dicho- segundo párrafo, cambia las relaciones y el rol.
Las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados.
Todos los sistemas tienen arquitectura. Las herramientas, los marcos y los proyectos anteriores pueden hacer el 80 % de la arquitectura sin que te des cuenta, pero la ignorancia no es felicidad . La entrega rápida y ágil es sostenible no solo durante unos pocos sprints, sino durante meses, incluso años, si y solo si el tipo de arquitectura correcto sustenta el diseño.
Los sistemas no se reescriben debido a fallas funcionales. Se reescriben debido a fallas en las cualidades del software (NFR): rendimiento, seguridad, mantenibilidad u otros". En otras palabras, debido a fallas arquitectónicas. (Creo que la cita es de Bass, Clements, Kazman, "Software Architecture in Practise" ).
sigue siendo una pregunta abierta y larga. Aquí están los esfuerzos de 3 personas:
Creo que la Arquitectura de Software implica planificar los Componentes trabajando juntos. Los proyectos ágiles también necesitan planificación, sin esto no puedo ver un final exitoso.
Creo que de manera ágil, esta planificación no necesita generar documentos excesivos. Pero la planificación de la arquitectura sigue siendo necesaria.
La pregunta, creo, es realmente doble. ¿Cómo encaja el concepto de arquitectura en ágil y existe la necesidad de un rol dedicado o asignado para realizar el trabajo?
Creo firmemente que para proyectos complejos, la planificación y definición de la arquitectura es fundamental para el éxito a largo plazo. Hay aspectos funcionales cruzados, como el rendimiento, que son difíciles de agregar después de manera iterativa con una vista de solo sprint por sprint.
El papel del arquitecto parece variar de una empresa a otra, pero las responsabilidades comunes suelen ser mucho más profundas que definir la arquitectura de un solo proyecto. Aseguran que se sigan las mejores prácticas, la consistencia entre los proyectos, asegurando que un proyecto se ajuste al panorama general dentro de una organización, etc.
Entonces, ¿tiene que existir un arquitecto? Depende de tu empresa/negocio. Si tiene una infraestructura compleja con muchos proyectos que deben coexistir y recibir apoyo a largo plazo, es probable que necesite un arquitecto o un equipo de arquitectos. Si es una empresa pequeña con un número limitado de proyectos de desarrollo, tal vez la necesidad sea mucho menor.
Al igual que cualquier otra habilidad especializada en un equipo, ¿hay suficiente trabajo para justificar un recurso dedicado o simplemente distribuir el trabajo y vivir sin el enfoque de un especialista?
Creo que esto también podría expresarse como "¿encaja el diseño en Agile?"
A medida que desarrolla un producto, la arquitectura, el diseño y la implementación cambian en cada versión. Cuánto depende de las necesidades del proyecto y de la capacidad del equipo para comprender el alcance de la solución general. Solo crea un componente arquitectónico o cambia el diseño en función de las necesidades, no de "qué pasaría si". necesito. De esa manera, si el alcance cambia, o si no agrega eso, proporciona suficiente valor para enviar, entonces tiene la opción de enviar.
En mi experiencia, los proyectos ágiles se benefician mucho más de tener arquitectos fuertes y con mucha experiencia como parte del proyecto para que puedan tomar decisiones más informadas sobre "cuándo" se necesitan las cosas y "qué se puede cortar para hacer las cosas más simples pero aún funcionales". Además, tener desarrolladores con sólidas habilidades inherentes de diseño y experiencia puede trabajar con la incertidumbre en torno al diseño cambiante y en constante transformación en un proyecto Agile.
Que un "arquitecto único" tome la decisión desaparece. Algunos equipos discuten "esto es necesario todavía" y tener algunas personas experimentadas que brindan contexto y algunas personas sin experiencia para desafiar las suposiciones implícitas parece proporcionar una buena combinación.
Entonces, no creo que transforme SW Architecture como disciplina o práctica :-)
Creo que el diseño sigue siendo esencial, independientemente del mecanismo utilizado para entregar la solución. Debe haber límites, especialmente en términos de definir el alcance de una solución, y particularmente en torno a las interfaces, la integración y simplemente evitar desviarse en el espacio que otros proyectos están tratando de cubrir; de lo contrario, un PM / gerente de producto fuerte podría tomar el desarrollo en serio. una dirección que es completamente incorrecta para la organización o empresa que necesita la solución.
Un simple ejemplo puede aclarar lo que quiero decir. Considere una empresa que tiene un sistema de informes de gestión bien diseñado e integrado basado en una herramienta reconocida, que funciona con bases de datos estándar de la industria. Dentro de esa empresa hay un pequeño desarrollo que usa una base de datos diferente, diferentes estándares de datos y duplica parte de la funcionalidad de otras aplicaciones empresariales (incluida alguna información de administración). No es un problema... para el equipo del proyecto. Pero es un problema para la organización, ya que ahora tiene múltiples versiones de la "verdad", y nadie sabe con certeza cuál es la correcta, porque nunca estarán perfectamente alineados. ¿Por qué ha sucedido esto? - porque no había nadie validando el diseño o estableciendo parámetros para que los desarrolladores permanecieran dentro.
Entonces, sí, la arquitectura de software es muy relevante en Agile, especialmente en entornos integrados, complejos y de tamaño empresarial. Pero también abogaría por un diseño adecuado en cualquier desarrollo, ya que siempre vale la pena mantener al menos un ojo en el premio que está buscando, así como crear el código para su próxima iteración.
Todd A. Jacobs