Conciliando arquitetura com agilidade:
ARQUITETURA ÁGIL!
Bruno Ambrozio
São Paulo, 19 de Maio de 2012.
INTRODUÇÃO
A arquitetura de um determinado produto é o alicerce que garante a estrutura necessária para o todo. Seja ele um carro, uma casa, uma embarcação, uma aeronave ou um sistema de software.
Software é tratado como um cisne negro junto ao âmbito arquitetural, ou seja, uma incerteza, um segmento do qual não se sabe o fim real. Diferente de se criar um carro, onde se sabe exatamente qual é o produto desejado. O mesmo se aplica para uma casa, embarcação ou aeronave, conforme exemplificado.
Descrever e orientar profissionais da área de análise e desenvolvimento de sistemas a implantar técnicas ágeis no processo de arquitetura de softwares.
O ponto crucial é evitar toda formalidade. Focar no produto final daquela atividade, não é como você cria o modelo, se você esta usando Astah para gerar Unified Modeling Language (UML), AgileDraw ou rascunhando em papeis com imagens aleatórias, mas o quão útil ele será. Do contrário, não tem porque fazê-lo.
Breno Barros no artigo “Arquitetura ágil em seu processo de desenvolvimento de software” (2011, p. 11) pauta bem a questão de que a modelagem ágil foca no conteúdo ao invés de formatação, ela é natural e simples de entender, precisa ser fácil de ser representada em qualquer ferramenta e deve estimular a percepção.
A melhor modelagem é aquela que é de fácil compreensão por todos envolvidos no projeto.
Um exemplo muito interessante demonstrado por Eduardo Guerra em seu artigo “Arquitetura em ambientes ágeis” (2011, p. 14), é a Arquitetura Cartoon. O arquiteto faz um desenho livre para representar a arquitetura, onde além das figuras geométricas tradicionais, existem elementos visuais que representam componentes bem definidos.
Por exemplo, ao invés de um cilindro deitado para representar uma fila, usar uma imagem de uma fila de pessoas de fato, evitando a necessidade de estereótipos. Ao olhar para esta imagem, você sabe que é a representação de uma fila, você não precisa ler a descrição para tal. Agiliza o processo de analise continua.
Além disto, é preciso que ela esteja em fácil acesso e que qualquer alteração, seja de percepção rápida por todos os membros envolvidos.
Muitos modelos tradicionais colocam a documentação em aplicações especificas gerenciadoras de projeto acopladas a arquitetura, que dificulta o acesso retardando o processo evolutivo do projeto. Um Wiki, na em uma área dedicada da intranet, as vezes é a melhor opção.
Trabalhar de forma ágil deve ser um processo maturo, pois do contrário pode se tornar um grande problema escalar.
A arquitetura deve ser gerada sob demanda, mas precisa ter a sua base pré-definida e pautada em conceitos que garantam a flexibilidade da aplicação, para que possa lidar como mudanças grandes junto ao segmento do negócio.
Ela (arquitetura) deve ser encarada em um primeiro momento, como um projeto a parte, tratada com interações para segmentá-la bem, de modo que possa evoluir no decorrer do desenvolvimento.
Deve-se documentar o necessário, de forma clara e de fácil interpretação.
REFERÊNCIAS BIBLIOGRÁFICAS
A arquitetura de um determinado produto é o alicerce que garante a estrutura necessária para o todo. Seja ele um carro, uma casa, uma embarcação, uma aeronave ou um sistema de software.
Software é tratado como um cisne negro junto ao âmbito arquitetural, ou seja, uma incerteza, um segmento do qual não se sabe o fim real. Diferente de se criar um carro, onde se sabe exatamente qual é o produto desejado. O mesmo se aplica para uma casa, embarcação ou aeronave, conforme exemplificado.
Portanto, a arquitetura previamente planejada junto a tradicional engenharia é sem dúvidas eficazes para estes segmentos. Entretanto, focando em software, sabemos que o entregue ao final na maioria das vezes não é o planejado no inicio. Não porque ele foi mal construído, ou os profissionais envolvidos são ruins, justamente ao contrário, segue-se um plano, mas não se conta com a evolução do negócio para o qual ele esta segmentado.
Atualmente nota-se uma grande adesão a metodologias ágeis para o desenvolvimento de projetos de software, isto tem contribuído muito para diminuir as frustrantes estatísticas apontadas por varias fontes de estudos como The Standish Group - Chaos Report, Ambysoft entre outros. Levantamentos estes que apontam sistemas cuja construção foi mal sucedida muitas vezes por problemas arquiteturais.
As metodologias ágeis pregam os princípios do Manifesto Ágil, do qual podemos destacar "Software em funcionamento mais que documentação abrangente", onde apesar da existência da documentação, o funcionamento deve ser priorizado.
Metodologias ágeis têm contribuído muito para arquitetura de sistemas de software. Práticas como o Test Driven Development (TDD) implicam em softwares de qualidade, com código desacoplado e classes bem segmentadas de escopo definido promovendo escalabilidade (Guerra 2011, p. 4).
Porém, estas práticas não garantem a flexibilidade a mudanças de escopo, ponto este que tem sido o gargalo de muitos projetos. Outra prática que ajuda é a refatoração continua, mas que não supre todas as necessidades quando a mudança é de grande escala.
Neste artigo, será abordado este tema que tem sido o calcanhar de Aquiles para muitos projetos de software, a conciliação de arquitetura com agilidade.
OBJETIVO
Descrever e orientar profissionais da área de análise e desenvolvimento de sistemas a implantar técnicas ágeis no processo de arquitetura de softwares.
- Arquitetura com planejamento eficaz
Arquitetar um software, junto as tradicionais metodologias de desenvolvimento implica em inúmeros pontos de falha, destacando-se a grande quantidade de documentação, muitas vezes inúteis, conhecidas como write-only.
Períodos extremamente longos de analise, levantamento de requisitos complexos, todo um trabalho de especificação que na maioria das vezes não representam o cenário real daquele momento, muito menos o cenário futuro, quando o desenvolvimento esta ocorrendo ou finalizado.
Por outro lado, softwares embasados em metodologias ágeis têm resultados melhores, são funcionais e de qualidade, entretanto muitas vezes ainda, com uma arquitetura fraca, pois peca-se no planejamento eficaz (diferente de desnecessário).
O planejamento é essencial para um projeto de software de modo que ele seja escalar, flexível a mudanças, coeso e tenha funcionalidades desacopladas.
Falar de planejamento prévio pode parecer voltar a modelos tradicionais, mas o ponto aqui não é definir um processo inflexível, mas sim um núcleo com resiliência e forte o suficiente para lidar com o decorrer de todo o projeto.
Assim como o projeto em sí, a definição arquitetural prévia pode (e deve) seguir uma metodologia incremental. Definindo possibilidades, elaborando mecanismos palpáveis, construindo protótipos para testá-la para então, seguir com o projeto.
Todo este processo pode ser dividido em pequenas tarefas, que vão desde levantar as possibilidades a executar testes segmentados, cujos quais, delineados em fazes simples como “a fazer”, “fazendo” e “pronto”.
Ou seja, é preciso ter um primeiro momento para definir a base do sistema de software, de modo que no decorrer do desenvolvimento, as funcionalidades possam ser criadas de modo incremental, sob demanda, conhecido como just-in-time.
Subindo mais o nível de analise, surge uma questão:
- Como de fato, organizar, segmentar e executar esta tarefa macro?
A resposta é:
- Modelando!
- Modelagem ágil
A modelagem de software é fundamental, mas para evitar as citadas documentações write-only é preciso ser ágil com esta tarefa.
O ponto crucial é evitar toda formalidade. Focar no produto final daquela atividade, não é como você cria o modelo, se você esta usando Astah para gerar Unified Modeling Language (UML), AgileDraw ou rascunhando em papeis com imagens aleatórias, mas o quão útil ele será. Do contrário, não tem porque fazê-lo.
Breno Barros no artigo “Arquitetura ágil em seu processo de desenvolvimento de software” (2011, p. 11) pauta bem a questão de que a modelagem ágil foca no conteúdo ao invés de formatação, ela é natural e simples de entender, precisa ser fácil de ser representada em qualquer ferramenta e deve estimular a percepção.
A melhor modelagem é aquela que é de fácil compreensão por todos envolvidos no projeto.
Um exemplo muito interessante demonstrado por Eduardo Guerra em seu artigo “Arquitetura em ambientes ágeis” (2011, p. 14), é a Arquitetura Cartoon. O arquiteto faz um desenho livre para representar a arquitetura, onde além das figuras geométricas tradicionais, existem elementos visuais que representam componentes bem definidos.
Por exemplo, ao invés de um cilindro deitado para representar uma fila, usar uma imagem de uma fila de pessoas de fato, evitando a necessidade de estereótipos. Ao olhar para esta imagem, você sabe que é a representação de uma fila, você não precisa ler a descrição para tal. Agiliza o processo de analise continua.
- Documentação
Tanto a documentação da arquitetura adotada quanto do projeto como um todo, deve seguir os mesmos princípios citados na modelagem ágil.
Além disto, é preciso que ela esteja em fácil acesso e que qualquer alteração, seja de percepção rápida por todos os membros envolvidos.
Muitos modelos tradicionais colocam a documentação em aplicações especificas gerenciadoras de projeto acopladas a arquitetura, que dificulta o acesso retardando o processo evolutivo do projeto. Um Wiki, na em uma área dedicada da intranet, as vezes é a melhor opção.
CONCLUSÃO
À medida que as práticas ágeis vão se desenvolvendo ao longo dos anos, cada vez mais a arquitetura tem se ramificado no decorrer dos projetos.
Trabalhar de forma ágil deve ser um processo maturo, pois do contrário pode se tornar um grande problema escalar.
A arquitetura deve ser gerada sob demanda, mas precisa ter a sua base pré-definida e pautada em conceitos que garantam a flexibilidade da aplicação, para que possa lidar como mudanças grandes junto ao segmento do negócio.
Ela (arquitetura) deve ser encarada em um primeiro momento, como um projeto a parte, tratada com interações para segmentá-la bem, de modo que possa evoluir no decorrer do desenvolvimento.
Deve-se documentar o necessário, de forma clara e de fácil interpretação.
REFERÊNCIAS BIBLIOGRÁFICAS
BARROS, Breno. Arquitetura ágil em seu processo de desenvolvimento de software. São Paulo: MundoJ, ed. Mundo, n50, ano IX, 2001-. Bimestral. ISSN 1679-3978.
GUERRA, Eduardo. Arquitetura: a Peça que Faltava nos Métodos Ágeis. São Paulo: MundoJ, ed. Mundo, n50, ano IX, 2001-. Bimestral. ISSN 1679-3978.
GUERRA, Eduardo. Arquitetura em ambientes ágeis. São Paulo: MundoJ, ed. Mundo, n50, ano IX, 2001-. Bimestral. ISSN 1679-3978.
AMBLER, Scott. 2011 IT Project Success Rates Survey Results, 2011. Disponível em: http://www.ambysoft.com/surveys/success2011.html. Acesso em 24 mar. 2012.
Manifesto for Agile Software Development. Disponível em:
http://www.agilemanifesto.org/. Acesso em 24 mar. 2012.
The Standish Group Report. Disponível em:
http://www.projectsmart.co.uk/docs/chaos-report.pdf. Acesso em 24 mar. 2012.
Nenhum comentário:
Postar um comentário