2009-12-12 20 views
7

¿Cómo encaja una especificación de arquitectura formal con el desarrollo ágil, si es que lo hace?Desarrollo y arquitectura ágiles

Estoy pensando específicamente en Scrum, que no hace mención de una arquitectura entre los artefactos oficiales.

¿Acabas de dejar que la arquitectura evolucione "accidentalmente" (por así decirlo), lo especifiques informalmente, o hay espacio para hacer algo como un 4 + 1 por adelantado, antes de armar tu primer backlog de producto?

Respuesta

14

Agile se describe a menudo como "solo haga lo que necesita hacer ahora, y puede refactorizar más adelante si se necesitan más cosas".

Esto es bastante engañoso. Se puede leer como "abordar algo rápidamente ahora, y luego averiguar cómo actualizarlo para hacer más cosas en el futuro". Lo cual conducirá a un mundo de dolor y deuda técnica.

Para cualquier sistema que necesite un diseño. Para sistemas pequeños/simples, este diseño puede estar en su cabeza, pero aún debe pensar antes de comenzar sobre qué hará el sistema y cuál es la mejor manera de hacerlo.

En mi humilde opinión, la forma correcta de incluir el diseño en un enfoque ágil es diseñar lo suficiente ahora que sabe lo que se espera que haga el sistema en última instancia, y los trazos generales que describen cómo lo hará. Propóngale un diseño lo suficientemente flexible para que no quemes ningún puente. Pero no pierda el tiempo escribiendo una especificación formal detallada para cada tuerca y tornillo. Diseñe hasta un nivel en el que sepa dónde y cómo se integrará un subsistema, pero puede tratarse como una "caja negra" que en sí misma puede diseñarse solo cuando necesita implementarlo.

El desarrollo ágil no debe excluir una arquitectura formal; simplemente significa que solo debe diseñar lo suficiente de la arquitectura formal para que todos los bits encajen bien cuando haya terminado, y desarrolle los detalles más pequeños de ese diseño solo cuando y como se necesiten. A veces eso significa que todavía necesita un diseño bastante detallado por adelantado.

+0

además de la respuesta de calidad anterior: Haga que su diseño sea una definición de los requisitos ya que el usuario los vería. Esto le ayuda a visualizar el modelo de dominio mientras se enfoca en el usuario y eventualmente en la interfaz de usuario (que debería ser primordial en cualquier proyecto de software). –

1

Depende de su alcance. Podría ser un dado, podría ser un campo verde. La arquitectura suficiente, justo a tiempo. Necesita algo para poder escribir sus primeras pruebas, hacer una integración continua.

Es un documento, ¿quién lo va a necesitar y qué hacer?

  • su equipo necesita algo para describir dónde colocar la funcionalidad y dónde se realizan las pruebas;
  • cuando tienes que hacer crecer tu equipo al chico nuevo puede gustarle una introducción;
  • comercialización puede necesitar bellas imágenes;
  • alguien podría tener que comprar e instalar hardware y software; ...
1

Scrum es principalmente una técnica de gestión de proyectos, esa es la razón por la que no menciona la arquitectura.

Tanto como sea posible, la arquitectura se define de forma incremental. La implementación realizada de extremo a extremo en lugar de capa por capa ayuda en ese sentido: lleva a implementar una parte en cada capa.

Las decisiones de arquitectura pueden ser difíciles de revertir, por lo que tienen que ser bien tomadas y tomadas en el último momento responsable, cuando se tiene más conocimiento del sistema y de las necesidades del cliente.

No hay una gran necesidad de una especificación formal.

0

Agile no pone tanto énfasis en la arquitectura como debería. Esto reduce la probabilidad de que el software sea utilizable en el futuro. La Metodología de Game of Thrones aprende de las ventajas y limitaciones de Agile; crea un software que es más "a prueba de futuro" y escalable. Digital Animal escribió este artículo para establecer esta metodología. http://digitalanimal.com/blog/slaying-the-agile-dragon-the-game-of-thrones-methodology/

Cuestiones relacionadas