Agile Archtecture

Acredito que todos concordamos que a arquitetura de um sistema é a principal responsável pela facilidade de manutenção corretiva e evolutiva, quanto melhor feito, mas fácil será para achar bugs, incrementar funcionalidades, etc. Por esse motivo é muito comum que seja gasto um tempo considerável na sua elaboração.

Já participei de desenvolvimento de sistemas em que as primeiras fazes do cronograma foram dedicados praticamente a arquitetura, mas como lidar com isso em ambientes de desenvolvimento ágil, entregando softwares funcionando logo nas primeiras iterações.

Alguns times falam do Sprint 0, nesse sprint a entrega serão praticamente poucos pontos, uma vez que a principal preocupação será na montagem das bases do sistema, escolha de frameworks e modelagem, e coisas de "infraestrutura". Acredito que essa abordagem seja muito interessante para times recém formados. Nesses times ainda é necessário formar o conhecimento comum base, ou seja, quais frameworks são normalmente utilizados nos projetos, como e onde são colocadas as classes e as camadas do sistema, etc. Para times que já estão a algum tempo juntos isso é mais natural, as coisas simplesmente fluem pela equipe.

Tenho experimentado uma abordagem Top-Down na arquitetura do sistema utilizando metodologias ágeis e acredito que está dando um bom resultado. Nessa abordagem, a arquitetura do sistema irá surgir conforme o sistema se desenvolve e não haverá a necessidade de um Sprint 0. Esse tipo de abordagem deve ser tomada com cuidado, integração continua e time fluente são alguns dos requisitos para dar certo.

Vamos explicar mais. Imagine a seguinte requisição:

1. "Preciso listar o total das vendas por dia da semana em um determinado período."

 A primeira coisa que vem a cabeça é, pelo menos para mim: "vou precisar de um método que me traga todas as vendas em um determinado período". Apesar de correta a ideia, ela está errada. Quando a coisa é encarada por esse lado não estamos nos preocupando em realmente atender o que deve ser entregue, mas em como pegar os dados para atender o requisito.

Isso pode soar estranho, mas a primeira coisa a pensar é em como o dado deverá ser exibido porque isso pode mudar completamente a forma de recuperar as informações para apresenta-lo. O pensamento no momento do desenvolvimento deverá ocorrer de cima para baixo. Vamos supor que estamos construindo esse requisito para um sistema desktop swing, poderíamos começar assim:

public class JReport extends JPanel {

    public  JReport(Period period, Sales sales){

        for(PeriodEntry pEntry : period){

             JPeriodValue jpValue = new JReriodValue(sales.totalFor(pEntry));

             this.add(jpValue); 

        }

    }

}

Estamos nesse caso começando pela classe de apresentação. Note que nesse momento eu ainda não criei nenhuma classe das que declarei no modelo, a IDE irá adicionar um erro no lugar informando que ela ainda não existe. Mas imagine comigo, se quando você cria-las, fizer correto, esse código irá funcionar independente do que haja nas classes da qual ele depende. Já estamos modelando o sistema.

Com as IDEs modernas, basta um ou dois cliques que todas as dependências serão criadas, dai basta apenas preenche-las.

Iremos ver mais no próximo post.