Rumo a uma arquitectura Agile

A arquitectura de software é o esqueleto de qualquer sistema. É a arquitectura que define o comportamento do sistema no que toca aos requisitos, tanto funcionais como não-funcionais. Ao passo que o modelo em cascata é rígido, o modelo ágil é mais flexível às alterações dos requisitos e essas alterações podem implicar a própria arquitectura. Uma arquitectura Agile permite a expansão sustentável do sistema de forma gradual, simples e actualizável à medida que o projecto se torna mais complexo.

Enquanto que a arquitectura é uma actividade que ocorre uma vez no modelo em cascata com datas de início e fim bem definidas, numa abordagem ágil a arquitectura é um processo contínuo sem uma data de fim estipulada. Portanto, em Agile a arquitectura pode ser regularmente sujeita a alterações.
As alterações a um projecto são aplicadas através do desenvolvimento iterativo e incremental. No Scrum estas iterações são os chamados sprints (duram entre duas a quatro semanas). Qualquer alteração é celeremente discutida e, dada a focalização da framework na colaboração entre a equipa, toda a questão é imediatamente resolvida entre os seus membros. Uma vez que a arquitectura é o esqueleto, é muito sensível à mudança. A alteração à plataforma terá impacto em várias iterações e, no limite, levará à reengenharia do projecto.

Principais responsabilidades do arquitecto tradicional

Focar-se no todo

Deve considerar como é que o sistema vai ficar dentro de alguns meses (ou anos) e também deve considerar os sistemas envolvidos e a comunicação entre eles.

Ser orienteado à compliance

Deve ter em consideração as questões de compliance como sejam leis, licenças ou standards.

Produzir blueprints

Documentos e diagramas que descrevem a arquitectura sob várias perspectivas. Estes são os entregáveis usados para a implementação do sistema.

Não precisa de muita experiência prática

O que o arquitecto tem de fazer é produzir os entregáveis para a equipa de desenvolvimento. Ainda que tenha experiência como developer, o seu papel está mais focado na orientação da equipa na construção do sistema desenhado.

Principais responsabilidades do arquitecto Agile

Ponderar o equilíbrio entre o agora e a visão global

Tem de pensar no que está a acontecer durante o desenvolvimento e enquadrá-lo com a visão global de todo o sistema.

Experiência prática

É também developer e trabalha na implementação do sistema, o que lhe permite avaliar os resultados das decisões de arquitectura de forma directa.

Produzir protótipos para tomar decisões informadas

Um protótipo ou uma prova de conceito podem revelar se uma decisão é ou não fazível e como afecta o sistema. É um trabalho colaborativo de comunicação com a equipa e não uma tarefa isolada.

Focar-se na sustentabilidade

As decisões são feitas para conseguir uma arquitectura sustentável, uma que suporta o sistema a longo prazo. Competências pessoais essenciais são o sentido de responsabilidade e a empatia. Enquanto membro da equipa, experimenta em primeira mão os resultados das suas decisões, o que aumenta a sua responsabilidade face à abordagem em cascata, na qual as decisões transitam para a equipa que as implementa.

Duração de uma arquitectura de software Agile

O importante da arquitectura é saber quando é que tem que começar, porque no modelo Agile não há um momento pré-determinado para se começar uma fase. Tipicamente usa-se o sprint #0, um sprint especial para configuração do ambiente de desenvolvimento e tomada de decisões fundamentais como linguagens de programação, plataforma, base de dados, etc. Para evitar deslizes no período de tempo destinado a estas actividades é previamente acordada uma data de fim (iteração de duração idêntica às iterações regulares) para então se dar início aos sprints normais.
Dificilmente a arquitectura estará pronta quando os sprints seguintes começarem, mas a definição de uma arquitectura ágil é um processo contínuo. Não é possível por de pé um sistema sem garantir que a arquitectura o suporta.

Agile teams don't necessarily create agile software architectures.
But a good architecture enables agility.

~Simon Brown

Princípios Determinantes

Para não complicar demasiado as coisas na elaboração da arquitectura (que podem custar caro ao desenvolvimento), há dois princípios a seguir na tomada de decisões:

• Keep It Simple, Stupid (KISS)
• You Aren’t Gonna Need It (YAGNI)

Estes dois princípios fazem pensar se determinada feature ou decisão é realmente necessária naquele momento. Se pode ser adiada, a arquitectura mantém-se simples e fácil de gerir mais tempo, mas sem cair no erro de deixar tudo para a última da hora sob pena de tudo se tornar mais complicado, porque

we should take decisions not in the last possible moment,
but rather in the most responsible one.

Ao preparar uma decisão relativa à arquitectura, é aconselhável fazer pequenas preparações que não levem muito tempo se o grau de certeza é elevado e, claro, discutir com os colegas de equipa, não fosse a comunicação directa um dos pilares da framework.

Documentação

Numa abordagem ágil do processo de desenvolvimento de software, assim como são usadas iterações para fazer o código, também podem ser usadas iterações para gerir e manter a documentação. Começa-se pelos aspectos mais importantes do sistema e vai-se adicionando mais informação de forma contínua ao longo das iterações. Não existem ferramentas específicas para produzir documentação no mundo Agile. Podem ser desenhos num quadro branco, post-it, documentos de texto ou wikis por exemplo. Para manter os diagramas é preferível uma ferramenta como o Microsoft Visio ou o draw.io, mas existem outras ferramentas.



Relacionado: Metodologias ágeis e documentação






fonte: infoQ.com

Licença CC BY-SA 4.0 Silvia Pinhão Lopes, 2.2.16