2008-10-14 12 views
7

¿Cómo se asegura de que el proyecto se construya con decisiones de diseño "buenas" que permitan una arquitectura de software flexible?¿Cómo se controla la arquitectura en un proyecto ágil?

¿Cómo se balancea entre dejar completamente la arquitectura a los equipos en un lado, y dejar que toda la arquitectura controle a unas pocas personas del otro lado?

¿Tiene un "grupo de arquitectura", "etiqueta de arquitectura" o cosas por el estilo?

Respuesta

5

Un requisito previo para los enfoques ágiles es una arquitectura que ya sabe cómo usar.

Si la arquitectura no está bien definida y completamente entendida, realmente no se puede adoptar un enfoque ágil.

Necesita tener algunos picos técnicos que muestren cómo funciona la arquitectura y cómo encajarán las distintas piezas. Puede hacer estos son sprints preliminares, pero no conducirán directamente a un lanzamiento para los usuarios. Son un caso especial, requerido para llegar a una arquitectura que puede usar.

Una vez superado este esfuerzo de "comprender la arquitectura", puede comenzar a ejecutar sprints que conducen directamente a lanzamientos para los usuarios.

4

Podría explicar cómo lo haría, pero this lo dice mejor que yo.

0

Lo manejo haciendo un poco de planificación inicial; en general, tengo experiencia previa con una aplicación similar para ayudar con esto. Si no, haré una exploración en el espacio para tener una idea. Una vez que se haya diseñado una arquitectura básica, comenzaré a desarrollarla teniendo en cuenta mis historias priorizadas. Luego, me refactoro a medida que avanzo para abordar deficiencias o errores en la arquitectura.

1

En mi experiencia, la mejor manera de hacerlo es contar con desarrolladores/arquitectos experimentados trabajando en los proyectos que impulsan la visión de la arquitectura día a día.

Sugeriría que depende del desarrollador en el proyecto controlar la arquitectura y asegurarse de que todo el nuevo trabajo coincida con ella.

0

Sin hacer un gran diseño por adelantado, generalmente hay un diseño básico que se aplica a cada proyecto. Por lo general, esto define las capas básicas a respetar en el diseño de la aplicación. La mayoría de las decisiones de diseño las toma cada desarrollador.

Nuestro proceso de desarrollo se basa en ráfagas cortas de desarrollo con una frecuente revisión por pares. La calidad de la decisión de arquitectura de cada desarrollador se valida en el momento de la revisión por pares. Esto también incluye la validación de que el código sigue la arquitectura del producto .

Según el tipo de proyecto y las herramientas disponibles, también utilizamos herramientas como macker para validar automáticamente la integridad del pastel de capas.

2

También recomendaría leer el documento Is Design Dead de los cazadores de vacas, por lo que entiendo sus argumentos si considera todas las prácticas ágiles como un todo, entonces obtiene libertad para hacer grandes cambios y así puede desarrollar una arquitectura.

La refabricación funciona más eficazmente con interacción continua, las pruebas se mejoran con TDD y la integración continua ... Podría continuar. Las 'arquitecturas' en evolución solo son limitadas si no puede realizar los grandes cambios necesarios para corregir 'errores'.

Además, creo que usted tiene un arquitecto como parte interesada en el proyecto, ellos contribuyen historias de usuarios que a su vez se entregan de vuelta al arquitecto.

Esta es también una buena manera de utilizar la programación de pares con el arquitecto que trabaja como parte del par. En este contexto, el arquitecto no es tanto una persona dedicada más un sombrero que un miembro del equipo de desarrollo usa durante la programación de los pares.

Creo que XP no disminuye el papel del arquitecto (y la arquitectura) simplemente pone la responsabilidad de todos los miembros del equipo para entregar y extiende el costo durante la vida del proyecto.

[editar]

por otros comentarios No tenga miedo de un poco de planificación por adelantado, itteration cero es un buen momento para tratar de trazar un poco de un plan, apenas no llegar a estrictos acerca de la entrega a una hora específica escala.

Cuestiones relacionadas