Como conciliar agilidade e arquitetura de software

A adoção de práticas ágeis no desenvolvimento de software, iniciada após o manifesto ágil, publicado em 2001, aumentou o número de “projetos ágeis” rapidamente, fazendo com que os pensamentos presentes nesse documento atingissem boa parte das organizações que produzem software.

Hoje, em grande parte das empresas, há inúmeros projetos autoproclamados ágeis. É como se qualquer projeto com pouca (leia-se nenhuma) documentação e algumas práticas relacionadas fosse elevado ao patamar oficial de “projeto ágil” e, assim, acabasse de forma rápida, boa e barata.

Entretanto, aqueles que têm algum tempo de experiência sabem como terminam esses projetos: geralmente da pior maneira possível. O principal problema nesses casos de fracasso é a falta de conhecimento sobre como os princípios do manifesto ágil moldam as práticas mais comuns do desenvolvimento ágil e isso traz a ilusão de que a simples adoção ou remoção de determinadas práticas elevam um projeto ao status de ágil.

Nesse contexto, uma das principais práticas elegíveis para remoção, por aqueles que não entendem a essência da agilidade, é diminuir ou, em casos mais extremos, acabar com a documentação.

Ainda hoje, um dos maiores mal-entendidos sobre agilidade está relacionado a isso, pois boa parte das pessoas associam documentação a burocracia e a falta dela a agilidade.

Porém, é importante entender que a documentação, em especial o documento de arquitetura de software, é um artefato de extrema importância ao desenvolvimento de software por vários motivos; dentre eles, a definição formal da arquitetura do sistema e a possibilidade de fornecer um entendimento base comum a todos os membros da equipe. Basicamente, o documento de arquitetura de software descreve a arquitetura do sistema como um todo, referindo-se a restrições, organização, padrões e responsabilidades de módulos e componentes.

Arquitetura de software e documentação são assuntos que andam ou deveriam andar relacionados, pois boa parte do sucesso de um sistema é devido a sua arquitetura. Atributos como coesão, acoplamento e modularidade, por exemplo, são tratados no âmbito arquitetural e essas decisões arquiteturais deveriam ser documentadas para propagar o conhecimento entre os envolvidos e interessados no sistema. Sendo assim, um projeto considerado ágil, para alcançar a alta qualidade técnica, não pode abrir mão da documentação.

Embora seja comum o pensamento de pouca ou nenhuma documentação em projetos ágeis, esse tipo de pensamento é um equívoco e para contornar essa situação, os próximos tópicos mostrarão como conciliar arquitetura de software e agilidade, de forma a manter o projeto bem documentado sem abrir mão da agilidade.

Agilidade em desenvolvimento de software

Agilidade em desenvolvimento de software representa um conjunto de ideias e práticas que surgiram há muito tempo por influência de alguns membros relevantes da comunidade de desenvolvimento. Essas ideias começaram a evoluir a partir do manifesto ágil, uma série de princípios lançados no ano de 2001 com o objetivo de simplificar e mudar a forma como os projetos de software eram encarados.

Os principais pontos levantados pelo manifesto ágil foram:

· Indivíduos e interação entre eles mais que processos e ferramentas;

· Software em funcionamento mais que documentação abrangente;

· Colaboração com o cliente mais que negociação de contratos;

· Responder a mudanças mais que seguir um plano.

Dentro desses pontos, há uma série de princípios que fornecem diretrizes que guiam os métodos ágeis como um todo (veja a seção Links). Entretanto, o próprio manifesto concorda que não há uma verdade absoluta nesses princípios, pois diz que “estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo”, ou seja, boas práticas para o desenvolvimento de software podem surgir a qualquer momento e, do mesmo modo, podem ser substituídas ou complementadas por outras ainda melhores.

Neste contexto, os princípios ágeis basicamente fornecem uma série de valores nos quais práticas eficazes de desenvolvimento de software são baseadas.

As considerações levantadas pelo manifesto ágil descrevem o que é mais valoroso no desenvolvimento de software em relação a outras ideias também consideradas valorosas (geralmente) em processos formais, como em “software em funcionamento mais que documentação abrangente”. É muito importante destacar que isso não significa que uma documentação abrangente não tenha valor. Apenas que software em funcionamento tem mais valor do que uma documentação abrangente, o que faz todo sentido. Afinal, de que adianta ter uma documentação abrangente e um software que não funciona? Entretanto, muita gente interpreta essas premissas do manifesto ágil de forma equivocada, pensando que deve-se ter software funcional e nenhuma documentação.

Com o passar do tempo, essas ideias de agilidade pautadas no manifesto ágil tomaram conta do cenário de desenvolvimento de software corporativo. As promessas de rapidez, qualidade e redução de custos tornaram os métodos ágeis bastante atraentes pelos olhos de gerentes e diretores. Entretanto, desde de que as ideias do manifesto ágil ganharam notoriedade e passaram a fazer parte do dia a dia dos desenvolvedores, seus princípios foram, na maioria das vezes, interpretados de forma errônea. Assim, não é raro encontrar “ambientes ágeis” em que as crenças de que documentação não é um artefato necessário são levadas a sério.

Pensar que a adoção de métodos ágeis implica na eliminação da documentação é um grande equívoco. O processo ágil, que tem como base os princípios do manifesto ágil, é o resultado do confronto entre ambientes sem processos e ambientes com processos formais. O objetivo é encontrar um meio-termo que estabeleça um processo suficiente para o desenvolvimento do software. Adotar um método ágil não significa abandonar processos e muito menos a documentação, mas infelizmente é comum a adoção de algumas práticas ágeis em detrimento de outras, tornando o processo ágil em questão quase um “não processo”.

Mas é verdade que métodos ágeis demandam menos documentação. Como os métodos ágeis são orientados a pessoas e não a processos, tem-se um ambiente de maior colaboração (teoricamente deveria ser assim), sendo possível, dessa forma, a eliminação de muitos documentos cujo propósito sejam apenas para comunicação interna.

Sendo assim, métodos ágeis não eliminam toda a documentação e o principal documento em um projeto de software, o documento de arquitetura de software (DAS), definitivamente não deve ser removido dos artefatos do projeto. Nesse ponto, torna-se necessário entender como conciliar a arquitetura de software com a agilidade.

Para muitos desavisados esses dois temas são opostos, quando na verdade arquitetura deveria andar de mãos dadas com agilidade; do contrário, um ambiente ágil sem controle arquitetural torna-se caótico e em ambientes caóticos a produtividade tem níveis muito baixos, fazendo com que a adoção de um método ágil perca o sentido. Diante disso, os próximos tópicos irão se concentrar em como a arquitetura de software e a agilidade podem complementar-se mutuamente, a fim de encontrar o meio termo ideal em um ambiente com processo pouco formal, mas devidamente organizado.

Métodos preditivos e métodos adaptativos

“Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.”. Esse é um dos princípios do manifesto ágil; preceito este que abre espaço para uma nova consideração: a diferença entre métodos ágeis (métodos adaptativos) e métodos formais (métodos preditivos).

Os métodos preditivos, como o nome sugere, são métodos que predizem com antecedência o que deverá acontecer. No cenário de um processo formal, os requisitos são levantados, documentados, analisados, uma solução técnica é projetada sobre os requisitos e, por fim, o software é desenvolvido com base no projeto. O exemplo clássico é o famigerado processo em cascata (waterfall). No entanto, todas essas fases estão presentes tanto nos processos formais (preditivos) quanto nos processos ágeis (adaptativos). O que torna um método adaptativo é o conceito de iteração em ciclos menores por todas as fases do processo de desenvolvimento.

Em vez de passar por um longo processo contemplando as fases de um processo de desenvolvimento de software, métodos ágeis passam por todas as fases repetidas vezes, em ciclos menores. Isso torna os métodos ágeis mais adaptativos que preditivos. Cabe aqui ilustrar esse conceito, comparando o processo formal com o processo ágil, conforme mostra a Figura 1. É interessante observar como os métodos ágeis englobam o processo formal e o transformam em um processo adaptativo por meio das iterações.

abrir imagem em nova janela

Figura 1. Processos ágeis englobam processos formais de forma iterativa.

De forma geral, a previsibilidade em projetos de desenvolvimento de software não é possível, pois os requisitos são imprevisíveis, estão sempre mudando e variam conforme o ambiente no qual o software em questão está inserido. Regras governamentais, concorrência, alterações no padrão de consumo dos clientes, são todos fatores que influenciam os requisitos. Entretanto, apesar desse cenário e do fato do software ser imprevisível, isso não significa que não se possa controlar o seu desenvolvimento.

Para controlar o desenvolvimento de software em um ambiente ágil e adaptativo é preciso saber o que está pronto, qual a situação atual, o que se tem definido e o que precisa mudar. Nesse caso, a melhor maneira para se obter esse status é por meio de um mecanismo que diga a situação atual em curtos intervalos de tempo: o desenvolvimento iterativo.

Desenvolver iterativamente significa produzir versões funcionais do sistema final a cada iteração. Essas versões intermediárias devem possuir um subconjunto dos recursos definidos até o momento para o sistema em questão. Além disso, essas versões devem seguir o mesmo padrão de qualidade aplicados à versão final. Esse método é bastante eficaz, pois não há melhor forma para testar a realidade de um projeto do que a imposição de entrega de software funcional. Neste modelo, cada release de software funcional é um marco e responde às questões que precisam ser respondidas para se controlar o desenvolvimento do software em um ambiente adaptativo e ágil.

A base dos métodos ágeis é o desenvolvimento iterativo. Dessa forma, eles se tornam adaptáveis a mudanças no projeto. Entretanto, adaptabilidade sem organização não é ágil, é um processo ad hoc. Embora muitos projetos sejam classificados por seus membros como ágeis e adaptativos, eles não são de fato, pois pecam na interpretação dos princípios ágeis, especialmente no quesito documentação, onde virou quase unanimidade a ideia errada de que agilidade e documentação não se misturam. Diante disso, os próximos tópicos abordarão a conciliação de agilidade com arquitetura de software, trazendo à tona as principais ideias sugeridas pelos pensamentos ágeis.

Conciliação de agilidade e arquitetura de software

A conciliação da arquitetura de software com a agilidade tem se tornado um tema recorrente em debates da comunidade de desenvolvimento e, até o presente momento, não há respostas conclusivas sobre como deve ser a relação entre esses dois tópicos. Uma das ideias mais difundidas é a de que a arquitetura de software não deve ser ignorada. Tanto é que uma das principais diretrizes do RUP, um processo de software precursor dos métodos iterativos, é definir a arquitetura o mais cedo possível.

Talvez um dos pontos que mais causem confusão em relação à adoção de métodos ágeis e a aproximação com a arquitetura de software seja o mal entendimento do que os princípios ágeis querem dizer e qual o papel de cada membro em um projeto ágil de software.

A fim de contribuir com este entendimento, os próximos tópicos irão expor as ideias por trás dos princípios ágeis, elucidar sobre os papéis dos membros em projetos ágeis e buscar a aproximação desses pontos com a arquitetura de software.

Mitos sobre arquitetura vs. agilidade

Equipes ágeis tendem a criar e manter pouca documentação em comparação às equipes com processos mais tradicionais. Este é o principal ponto de conflito entre arquitetura de software e agilidade e também o que causa o maior número de equívocos.

Na comunidade de desenvolvimento existem alguns mitos quando se fala em adotar métodos ágeis e manter a arquitetura de software. Essas ideias deixam claro quais são os principais pontos de divergência entre arquitetura e agilidade, elencadas na Tabela 1.

Tabela 1. Mitos sobre arquitetura de software e sua união com agilidade.

O entendimento da Tabela 1 é o ponto de partida para a conciliação entre arquitetura de software e agilidade. As ideias apresentadas deixam claro que os pontos de divergência são falácias, que caem por terra ao se analisar e entender realmente a natureza da arquitetura de software ou do processo de software (no caso, um processo ágil).

A maioria das pessoas possui um conhecimento muito superficial sobre boa parte dos assuntos que acredita dominar, e não é diferente com agilidade e arquitetura de software, tendo em vista os mitos mais comuns que foram apresentados anteriormente.

As ideias enraizadas atualmente são de que métodos ágeis dispensam documentação e de que a arquitetura de software é burocrática e exige muita documentação, quando na verdade nenhuma destas ideias está correta.

Quando se entende realmente a natureza da arquitetura de software e das metodologias ágeis, essas falácias deixam de fazer sentido e a conciliação entre ambas passa a ser não apenas plausível, como necessária. Sendo assim, os próximos tópicos têm por objetivo apresentar a conciliação da arquitetura com a agilidade corroborando a realidade exposta na Tabela 1.

O papel do arquiteto em um projeto ágil

Para aproximar a arquitetura de software dos métodos ágeis, nada mais justo do que começar pelo arquiteto de software e suas responsabilidades em um projeto ágil.

Andrew Johnson, da AgileArchitect.org, escreveu que “em um projeto ágil, o arquiteto tem como principal responsabilidade levar em conta a mudança e complexidade, enquanto os desenvolvedores focam na próxima entrega” (veja na seção Links The Role of Agile Architect).

Além disso, Mike Cohn, em Succeeding with Agile, comenta sobre “non-coding architect” (arquitetos de software que não codificam, apenas criam diagramas) e enfatiza que o arquiteto ideal é aquele que contribui com o time.

Essa contribuição a que Cohn se refere é a codificação, ou seja, o arquiteto em um projeto ágil deve colocar as mãos na massa. Sendo assim, de acordo com o exposto anteriormente, chega-se à conclusão de que o arquiteto, em um projeto ágil, tem o papel de codificar os elementos mais complexos do software, levando-se em conta as mudanças.

É importante frisar a consideração feita anteriormente sobre as mudanças que o software possa ter. Note como a definição de Johnson, sobre o papel do arquiteto, coloca como principal responsabilidade deste a consideração a mudanças que possam ocorrer no software. Isso acontece devido ao fato de métodos ágeis serem adaptativos, ou seja, orientados pelas mudanças.

São as mudanças que guiam o que deverá ser feito para as próximas releases. Nesse caso, o arquiteto de software, em um ambiente ágil, deve estar inserido na arquitetura do software conhecendo a fundo o código e ele mesmo participando da codificação.

Essa prática torna as decisões e mudanças arquiteturais mais rápidas e condiz com o fato dos métodos ágeis aceitarem mudanças a qualquer momento, independente dessas mudanças impactarem ou não na arquitetura.

Um dos princípios do manifesto ágil prega exatamente o seguinte: “Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.”. Esse princípio corrobora a importância das atribuições propostas para arquitetos de software em métodos ágeis comentadas anteriormente, tal como a consideração a mudanças como uma das principais responsabilidades.

Após entender o papel do arquiteto de software em um projeto ágil, o próximo tópico abordará práticas ágeis para se definir a arquitetura do projeto, como lidar com um dos artefatos arquiteturais de maior importância, o documento de arquitetura de software e como conciliar a criação e manutenção desse documento com métodos ágeis.

Definindo a arquitetura de software de modo incremental

A definição da arquitetura em um ambiente ágil pode traçar os rumos que o projeto irá tomar. A arquitetura sinaliza se o projeto será um caso de sucesso ou se irá definhar até o completo fracasso.

Todo software possui uma arquitetura, que pode ser criada de modo intencional, quando é feito um projeto arquitetural com o auxílio de diagramas, ou de modo acidental, quando o desenvolvimento parte direto para a codificação, sem a preocupação explícita com tais conceitos.

A importância da arquitetura de software e a forma como surge um projeto arquitetural, seja ele intencional ou não, são comentadas com mais detalhes no artigo “Conformação Arquitetural: sincronizando o código e a arquitetura do projeto” (veja a seção Links), mas de uma maneira geral, a importância da arquitetura de software diz respeito às bases sobre as quais o projeto será construído, a fim de organizar de forma coesa os módulos e componentes de um sistema, com o objetivo de facilitar a implementação e manutenção do mesmo.

Em qualquer ambiente é desejável se ter um projeto de software fácil de implementar e manter, mas em ambientes ágeis essa necessidade é maior devido à natureza do processo, que é voltada a mudanças.

No caso de métodos ágeis, a arquitetura deve ser, mais do que nunca, projetada considerando o contexto de negócio no qual o software está inserido e possíveis mudanças que possam ocorrer. Sendo assim, é necessário adotar os princípios e práticas ágeis no momento de modelar, desenvolver e evoluir uma arquitetura.

Uma prática difundida para o projeto arquitetural ágil é a Agile Model Driven Development (AMDD), que como o nome sugere, é a versão ágil do Model Driven Development (MDD).

O MDD é uma prática de desenvolvimento de software onde o projeto é elaborado de forma extensiva por meio de modelos antes de se partir para o código fonte (veja o BOX 1).

A diferença entre MDD e AMDD é a quantidade de modelos criados antes da codificação. No AMDD, onde os princípios ágeis são aplicados, em vez da criação de modelos representando todo o sistema, são criados modelos apenas para satisfazer os próximos esforços de desenvolvimento. Dessa forma, tem-se uma arquitetura definida de modo incremental.

A Figura 2 mostra o ciclo de vida do AMDD, que, basicamente, ilustra a modelagem arquitetural durante o ciclo de vida do projeto. A ideia é desenvolver a arquitetura de forma incremental, seguindo os moldes dos processos ágeis. No diagrama apresentado, cada uma das caixas representa uma atividade de desenvolvimento.

Figura 2. Ciclo de vida do AMDD.

Na abordagem AMDD, a primeira iteração (Iteration 0: Envisioning) tem por objetivo iniciar a previsão da arquitetura e inclui duas subatividades: previsão dos requisitos iniciais e previsão da arquitetura inicial. O objetivo nesta iteração é identificar o escopo de alto nível para a arquitetura de acordo com os requisitos iniciais, incluindo uma visão arquitetural para esse determinado momento contendo um modelo de alto nível dos requisitos e um modelo de alto nível arquitetural, sem se preocupar com especificações detalhadas.

A previsão arquitetural, dependendo do processo adotado, pode ser a fase de concepção (RUP) ou ocorrer antes do primeiro sprint (Scrum). O importante é que a previsão arquitetural seja feita antes das iterações de desenvolvimento. O diagrama também indica a medida de tempo comumente utilizada para as subatividades.

No caso da previsão dos requisitos iniciais e previsão da arquitetura inicial, a medida de tempo é em termos de dias.

As demais atividades podem ocorrer durante qualquer iteração de desenvolvimento (Iteration 1..n: Development) e têm a medida de tempo em termos de horas ou minutos. Isso faz com que a arquitetura seja evolutiva e possa ser replanejada durante as demais iterações de desenvolvimento.

A ideia é se trabalhar de uma “maneira JIT” (Just in Time), fazendo somente o necessário naquele momento para o projeto continuar progredindo, lembrando que sempre é possível voltar atrás para mudar.

O AMDD traz para o projeto arquitetural um processo em moldes ágeis para se definir e implementar a arquitetura. Da mesma forma, o documento de arquitetura de software pode ser criado e mantido seguindo as diretrizes desta abordagem.

Enfim, a conciliação

Um dos pensamentos do manifesto ágil é o de que código funcionando é mais importante do que documentação, mas isto não significa que a documentação deve ser eliminada ou ignorada, como foi exposto nos tópicos anteriores. O ideal é responder a seguinte pergunta antes de sair criando artefatos ou documentos: “Quem vai usar isto? É útil?”.

Em relação à ideia de que arquitetura de software é burocrática, é preciso deixar claro que arquitetura de software não é um processo de software. Afinal, é o processo de software adotado no projeto que é responsável por fornecer o caminho dos artefatos que devem ou não ser criados e como utilizá-los.

Independentemente do processo utilizado no projeto de software, a arquitetura estará presente, seja de modo acidental (quando existe simplesmente pelas decisões de implementação) ou intencional (quando há preocupação com sua elaboração e manutenção).

Sintetizando a conciliação de arquitetura de software e agilidade, chegamos à conclusão de que a arquitetura não pode ser encarada como um processo de software a ponto de ter artefatos e documentos criados sem utilidade: ela deve respeitar o processo. Sendo assim, em métodos ágeis, a arquitetura deve ser evolutiva, como manda o processo.

A arquitetura deve refletir o projeto atual e acolher as mudanças, pois métodos ágeis aceitam mudanças a qualquer momento. E o mais importante é entender que todo software possui uma arquitetura, seja ela intencional ou não, sendo o ideal que ela seja intencional.

A conciliação da arquitetura de software com a agilidade é muito importante para o sucesso do projeto e para que o produto desenvolvido seja de qualidade. Sabendo disso, a principal forma para conseguir essa aproximação é conhecendo o propósito de cada uma e tratá-las como realmente o são, isto é, arquitetura como disciplina para organizar software e agilidade para tratar do processo, isto é, como disciplinas complementares.

Além dos conceitos analisados neste artigo, há muito a se explorar sobre o tema, especialmente sobre AMDD e como transformá-lo em AMDA para a criação de arquiteturas de forma incremental em um processo ágil por meio de procedimentos e ferramentas padronizados.