AMDD e TDD - Arquitetura, Modelagem e Desenvolvimento Ágil

Os princípios, mencionados no artigo Ciclo de Vida de Desenvolvimento de Sistemas Ágil, podem ser utilizados junto à outras metodologias, ou conceitos, para se criar um processo de desenvolvimento de sistemas. Um desses conceitos é a Modelagem de Desenvolvimento Dirigira (MDD em inglês). Esse conceito guia como agrupar os requisitos do projeto, como modelá-los e como arquitetar a solução para atender aos requisitos. Assim, ao ser utilizada sob o foco ágil nasce a Modelagem Ágil de Desenvolvimento de Sistemas (AMDD em inglês).

Esse conceito pode ser utilizado juntamente com diversas metodologias ágeis para completar o Ciclo de Vida do Desenvolvimento de Sistemas. Isto é, a metodologia escolhida suportará o planejamento do projeto bem como suas alterações, como criar o fluxo de comunicação e etc. E o AMDD proverá como realizar estas tarefas, do ponto de vista da equipe técnica. Isto é, como dividir o desenvolvimento em iterações, como criar e manter os documentos necessários para o projeto.

Agile Model Driven Development

A Figura acima - http://www.ambysoft.com/essays/agileLifecycle.html - apresenta as tarefas realizadas em cada iteração do projeto, a partir da iteração 0 – início do projeto. A caixa verde mostra as atividades da iteração 0. Nesta fase, os requerimentos iniciais são modelados assim como a arquitetura inicial do projeto, ambos em caráter de macro-visão.

O modelo, dos Requisitos Iniciais representa a lista de requerimentos que os clientes necessitam que o sistema possua ou execute. Esta lista é chamada de Product Backlog, e contém os requisitos, ordenados por prioridade – as prioridades representam quais requisitos retornam mais valor ao negócio –, e nortearão a equipe técnica a desenvolver e entregar os requisitos mais importantes primeiro, assim como a estimar a duração do projeto de maneira mais eficiente.

É importante ressaltar que esta lista pode ser alterada durante o projeto pelos clientes, com a inclusão, mudança ou retirada de algum requisito. Porém tais alterações são realizadas em momentos específicos, como veremos a seguir.

O modelo da Arquitetura Inicial representa a arquitetura que será utilizada pela solução em uma visão macro. Isto é, o modelo proverá qual tecnologia será utilizada, qual a linguagem de programação, banco de dados, se será Web ou Cliente-Servidor e etc. O detalhamento da arquitetura como componentes, seqüência ou classes serão modelado no início de casa iteração de Construção.

As caixas azuis representam as iterações de Construção, seguintes à iteração 0. Cada iteração de Construção possui a mesma estrutura. Isto é, cada uma das iterações começa, se desenvolve e termina através do mesmo processo.

Ao dividir o Product Backlog, criado na iteração 0, em sub-listas, uma nova lista será criada. Esta nova sub-lista chama-se Sprint Backlog.

O Sprint Backlog proverá ao time de desenvolvimento quais requisitos serão desenvolvidos durante a iteração atual. Ainda que o Sprint Backlog possa ser alterado pelos clientes, é primordial que este seja congelado, no início da iteração, de modo a estabilizar o trabalho da equipe técnica. Assim, se algum requisito, pertencente ao Sprint Backlog, necessitar de alterações, um novo requisito deve ser criado e priorizado para próxima iteração. Se esta alteração é realmente importante, os clientes devem escolher um outro requisito para ser substituído, ou projetado para uma próxima versão do produto.

A primeira atividade de cada umas das iterações de Construção é avaliar e validar o Sprint Backlog. Esta atividade está incluída na tarefa de Modelagem da Iteração. Esta atividade é muito importante, pois através dela é possível certificar que o prazo da iteração é viável e que seus requisitos são possíveis de serem desenvolvidos. Outro ponto é que este é o momento em que os clientes podem sugerir mudanças do escopo de maneira mais eficaz e com menos riscos para a qualidade do projeto.

Além disso, nesta atividade, o modelo da arquitetura é revisto e detalhado para incluir os itens necessários para o desenvolvimento da iteração atual.

A melhor maneira de se criar o Modelo de Tomada (Model Storming) é se reunir com a equipe técnica, por cerca de 30 minutos em média, e analisar todas as possibilidades de risco para o item e apontar a melhor estratégia de desenvolvimento. Esta tarefa é feita para cada item a ser desenvolvido na iteração atual.

A tarefa de Desenvolvimento Dirigido à Teste (TDD em inglês) adiciona a documentação e o desenvolvimento efetivo dos itens. TDD é um conceito que suporta estratégias de desenvolvimento de sistemas, onde o desenvolvedor primeiro constrói o teste que deve ser feito para validar o item desenvolvido e, em seguida, constrói o código fonte para atender os testes com sucesso.

De acordo com este conceito, o desenvolvedor cria o teste necessário para validar alguma funcionalidade e, em seguida, começa a desenvolver o fonte para implementar a funcionalidade. A idéia é criar o código fonte passo a passo – cerca de 10 linhas – sempre testando o código. A funcionalidade está criada com sucesso, quando os testes rodam com cucesso. A figura abaixo apresenta como o TDD funciona.

Test Driven Development

Se o TDD for bem implementado, os testes criados serão utilizados como a documentação técnica e o código certamente será bem executado. Entretanto, nem todas as funcionalidades do sistema deve ter um teste implementado. Somente códigos críticos ou complexos deveriam ter testes implementados. O desenvolvedor deve pensar se a funcionalidade é complexa o suficiente para requerer uma estratégia TDD.

Assim, no final de cada iteração, depois de todos os itens pertencentes ao Sprint Backlog serem desenvolvidos, o sistema estará pronto para ser entregue à equipe de Testadores para certificarem-se que o produto não possui problemas. Se tudo estiver bem, os clientes podem iniciar seus testes. Estes testes proverão um parecer se os requerimentos foram desenvolvidos como necessário e se eles estão satisfeitos com o sistema.

Se tudo estiver de acordo, o projeto segue paras as próximas iterações. Caso contrário, as mudanças necessárias são implementadas e testadas, conforme o ciclo de vida do projeto. 

Até o próximo post.