Estoy acostumbrado a hacer un plan de arquitectura durante el inicio del proyecto. En un proceso ágil, parece que la arquitectura se está realizando o mejorando durante las iteraciones.¿El modelo de arquitectura de software al inicio del proyecto se considera como un enfoque ágil?
Los agilistas no están de acuerdo con la planificación y la arquitectura. XP tiende a abogar sin arquitectura (o poco) por adelantado (es decir, diseño planificado), pero personas como Martin Fowler say they do planned design maybe 20% of the time. El Capítulo 14 de XP Explained (Kent Beck) tiene una buena articulación de la filosofía de diseño de XP.
Michael Keeling has a good explanation about why agilists (and others) disagree. Él dice que preste atención a dos dimensiones: su conocimiento sobre las soluciones y su conocimiento sobre los problemas. Cuando conoce muchas soluciones en este campo (por ejemplo, sistemas web), es más probable que postergue la planificación. Pero cuando nadie ha construido un Mars Rover antes, usted hace más planificación. Para mí, esto explica por qué los ingenieros en diferentes situaciones hacen cosas diferentes, sin embargo, lo que cada uno hace es racional.
Chapter 3 of my book on software architecture se dedica a responder la pregunta "¿Cuánta arquitectura debe hacer?" En resumen, la respuesta es "Hacer arquitectura hasta que los riesgos se salgan de tu radar". Si no le preocupa la escalabilidad o la seguridad, no se moleste en planificarlos. Pero si le preocupa la auditabilidad (por ejemplo, el cumplimiento normativo), luego trabaje en ello hasta que crea que lo ha manejado, o puede manejarlo utilizando un diseño evolutivo. Ese capítulo está disponible para descarga gratuita.
Si está siendo ágil, debe evitar meter un montón de diseños iniciales en un Iteration Zero. Dicho de otra manera, si su Iteration Zero tiene tres meses de diseño, no es realmente muy ágil.
Su pregunta es específicamente sobre modelos de arquitectura, solo una de las cosas que haría en el diseño planificado. Los modelos son un medio para un fin (el final es un sistema en ejecución). Usados bien, pueden ayudarlo a reducir riesgos, pero nadie estará contento al final del proyecto si tiene un gran modelo y ningún sistema.
Digamos que desde el principio usted ya sabía que hay una función de auditoría para el sistema, ¿lo planearía temprano o lo haría cuando entrara en vigencia? ¿Ahorraría tiempo si lo planifica temprano? – h3n
Los arquitectos tienden a poner los requisitos en dos categorías: requisitos funcionales y requisitos de atributos de calidad (también conocidos como no funcionales o extrafuncionales). Intenté usar la auditabilidad como un requisito de atributo de calidad en lugar de una característica. A su pregunta, si planea o no, mi opinión es que debe planificar cosas que le preocupa que no funcionen, de lo contrario, diseñarlas/construirlas sobre la marcha. Lamentablemente, no hay una buena investigación empírica, por lo que es solo una opinión. Lea el ensayo de Keeling: cuanto más experimentado sea, más éxito tendrá sin planificación. –
Técnicamente, una arquitectura debe cruzar las iteraciones, ya que una arquitectura dice que así es como vamos a escalar o así haremos la comunicación, etc. Durante el desarrollo solo construyes lo que necesitas para esa iteración. Si no necesita escalar, no incluya esa parte de la arquitectura en su proyecto. Como parte de Agile es utilizar pruebas, si necesita volver a visitar ese código más tarde para hacerlo escalar, mientras que incluirá retrabajo, debe tener la confianza para realizar esos cambios y las recomendaciones arquitectónicas actuales para escalar.
Depende, necesita tener una vaga idea de hacia dónde se dirige para llegar allí, de modo que puede comenzar con un Walking Skeleton y pulir las partes individuales sobre la marcha, pero igualmente no lo hace quiere tomar decisiones too soon. Entonces, puede comenzar con un diagrama de arquitectura que contenga ciertas entidades, pero no especifica su implementación concreta hasta que haya evaluado cada una por turno.
+1 para "necesita tener una vaga idea de a dónde va usted en orden para llegar allí "y" no quiere tomar decisiones demasiado pronto ". – eglasius
Ágil no significa ningún plan en absoluto.
Crea el sprint 0 que consistirá en configurar el entorno de desarrollo y los objetivos de arquitectura.
Mantenerlo simple al principio, va a pagar a largo plazo.
+1 para 1 y 3. – eglasius
Lo mismo podría decirse de la planificación y otras actividades del proyecto. Tiene que hacer un poco de la general en cualquiera de esas actividades para poner en marcha el proyecto, pero no debe profundizar en los detalles que se abordan mejor/pertenecen a cada iteración.
Es de vital importancia tener una idea muy clara de lo que trata el proyecto a un nivel muy alto desde el principio. Si ese no es el caso, el primer esfuerzo que hay que hacer es eso. Lo mismo debe hacerse para la arquitectura, estamos hablando de muy poco tiempo aquí, con las personas correctas involucradas que pueden marcar la diferencia al comenzar a construir una cosa completamente incorrecta.
Como usted está haciendo todo lo anterior en un nivel extremadamente alto, que, naturalmente, obtendrá un montón de nueva información tanto de alto nivel como progresa cada iteración. También tenga en cuenta que podría haber identificado desde el principio que asegurarse de que se puede hacer algo en absoluto es esencial para saber si el proyecto puede funcionar. Esto impacta el enfoque en el equipo y las acciones que se deben hacer para asegurar que sea un proyecto saludable.
Voy a cerrar esta pregunta como fuera de tema porque la gestión de proyectos no está relacionada con el tema. Estas preguntas deben formularse en [https://pm.stackexchange.com/](https://pm.stackexchange.com/) – BDL