Atenção: esse artigo tem um vídeo complementar. Clique e assista!
Princípios, Padrões e Práticas para um Design Ágil – Parte 1
Na última parte deste artigo, veremos o fluxo de um projeto que adota XP e o que pode ser utilizado na definição da arquitetura do software, apresentando a visão que um arquiteto deve ter nas fases de um projeto ágil e as práticas que dão suporte na construção de um Design evolutivo. Por fim, é apresentada a prática de Desenvolvimento Dirigido a Testes, também conhecida como TDD, em conjunto com testes de Aceitação, que é utilizada para auxiliar o usuário a definir os critérios de aceitação durante a criação de suas estórias.
Para que serve:
Serve para arquitetos, analistas e desenvolvedores que desejam conhecer os valores por trás das metodologias ágeis e como funciona o Processo da Extreme Programming, uma das mais difundidas metodologias ágeis.
Em que situação o tema é útil:
O tema é útil para toda empresa ou time de desenvolvimento que quer implantar metodologias ágeis – como Extreme Programming – e/ou quer aplicar o uso de TDD auxiliado por testes de aceitação. O tema é importante também para arquitetos que desejam saber como lidar com questões de arquitetura de software em um processo XP e quais as práticas que auxiliam nestas questões.
Princípios, Padrões e Práticas para um Design Ágil – Parte 3:
A terceira e última parte deste artigo apresenta os valores do Manifesto Ágil e sua influência em métodos como Scrum e XP. Abordamos também como a Arquitetura de Software se enquadra no processo ágil e quais as práticas de Extreme Programming que auxiliam os desenvolvedores e arquitetos de software a evoluir um sistema atendendo aos requisitos do cliente e boas práticas de Design. Para finalizar, o artigo apresenta também a implementação de uma funcionalidade para um sistema fictício utilizando a prática de Test Driven Development (TDD) e Acceptance Test Driven Development (ATDD).
Na primeira e segunda parte desta série de artigos, publicados nas Edições 80 e 81, abordamos sobre fundamentos de arquitetura de software, padrões de projetos em uma arquitetura distribuída, analisamos como identificar sintomas de um software mal planejado, e como refatorar a sua aplicação para utilizar boas práticas de desenvolvimento OO.
Na última parte desta série, vamos analisar a fundo como funciona um Projeto XP, passando por todas as suas fases, e veremos também como adotar as práticas de engenharia da Extreme Programming para construir um software aplicando as melhores práticas de desenvolvimento OO utilizando TDD e testes de aceitação.
Abordaremos os valores destas metodologias através do Manifesto Ágil, apresentando de maneira clara como estes valores estão presentes na Extreme Programming. Analisaremos também, como a Arquitetura do Software é tratada em um projeto ágil e como algumas práticas do XP auxiliam na criação e evolução da Arquitetura. Por fim, vamos apresentar um estudo de caso onde implementaremos uma funcionalidade em um sistema fictício, mostrando desde a escrita da estória pelo cliente até sua implementação utilizando testes de aceite com o framework FitNesse e TDD.
O Manifesto Ágil
Nos últimos 10 anos vem emergindo um movimento que promove uma nova maneira de se desenvolver software, conhecido como Agile.
Este movimento tem ganhado muita força e notoriedade graças a Agile Alliance, uma organização sem fins lucrativos, formada por grandes nomes da comunidade de desenvolvimento de software, como Kent Beck, Alistair Cockburn, Ward Cunningham, Martin Fowler, Robert C. Martin, Ken Schwaber, entre outros.
Em 2001, estes profissionais, criadores de metodologias como Extreme Programming, Scrum e Feature Driven Development, se reuniram em um resort de esqui em Utah nos Estados Unidos, para discutir novas maneiras de se produzir software, de um modo menos burocrático, mais simples e focado em pessoas. Foi nesta reunião que nasceu o termo Desenvolvimento de Software Ágil, e mais importante, foi onde nasceu o Manifesto Ágil.
O Manifesto Ágil é uma declaração dos princípios que fundamentam o desenvolvimento ágil de software, expressos por meio de quatro valores fundamentais:
- Indivíduos e suas Interações acima de procedimentos e ferramentas;
- Software em funcionamento acima de documentação abrangente;
- A colaboração dos clientes acima da negociação de contratos;
- A capacidade de resposta a mudanças acima de um plano pré-estabelecido.
É importante frisar que o manifesto ágil não exclui em suas práticas o uso de ferramentas e outros elementos oriundos do desenvolvimento de software tradicional, mas que, dentro de uma escala, os valores que estão em negrito nos princípios acima, são mais importantes do que os valores que estão à direita.
O manifesto contempla ainda 12 princípios (veja o site na seção Links) que endossam seu conteúdo e que servem como fundamento para toda metodologia considerada ágil.
Extreme Programming
Extreme Programming (ou simplesmente XP) é uma metodologia ágil para desenvolvimento de software proposta por Kent Beck, ideal para times pequenos e médios, que lidam com projetos complexos, onde os requisitos são vagos ou mudam constantemente.
Além de ser um método prescritivo simples de desenvolvimento, com diversas práticas de engenharia, de acordo com Kent Beck, XP é uma filosofia de desenvolvimento de software, pois integra não só os valores expressos no manifesto ágil, mas também propõe valores como Comunicação, Feedback, Simplicidade, Coragem e Respeito.
O ciclo de um projeto XP é apresentado na Figura 1.
Figura 1. Fluxo de um Projeto XP (Adaptado de Don Wells).
Uma das premissas em um projeto XP é a participação efetiva do cliente junto à equipe de desenvolvimento, para que ambos possam trabalhar em conjunto com o objetivo de produzir um software que traga o máximo de valor para a empresa. Dentro deste contexto, no fluxo apresentado na Figura 1, podemos observar que um projeto XP inicia na Fase de Exploração, onde o cliente transmite a necessidade do projeto para o time de desenvolvimento, relatando a importância do mesmo para o negócio.
Nesta fase, é elaborada apenas uma projeção inicial da solução, sem focar nos detalhes de implementação, para que o time de desenvolvimento possa explorar soluções em potencial, reduzir o risco de problemas técnicos e aumentar a confiabilidade das estimativas das estórias do usuário (User Stories), o que auxilia o cliente a decidir se continua ou não com o projeto.
Conforme veremos ainda neste artigo, uma Estória do Usuário é a maneira como são documentados os requisitos do cliente, similar a um caso de uso com menos detalhes e de forma mais sucinta. Elas são estórias contadas pelo próprio usuário, onde são descritas as funcionalidades que ele quer que o sistema realize. Como complemento, em um projeto XP o usuário também descreve os critérios de aceite e as restrições de uma estória, que servirão posteriormente para auxiliar na criação dos testes de aceitação e na validação do que foi desenvolvido pelo time.
Com uma projeção da arquitetura em mãos, o projeto entra na Fase de Planejamento. No entanto, na transição entre estas etapas, baseado nas estórias que devem ser implementadas, o time de desenvolvimento pode criar uma metáfora para o sistema (System Metaphor). Esse sistema de metáfora é a maneira como o time dissemina o conhecimento sobre o sistema, utilizando uma linguagem comum que transmita a arquitetura adotada no projeto, de modo que qualquer membro consiga facilmente explicar o Design do mesmo para novas pessoas sem precisar de uma pilha de documentos. Em times que aplicam DDD (Domain Driven Design) uma boa metáfora de sistema serve como base para a criação da Linguagem Onipresente (Ubiquitous Language).
Após a criação da metáfora, o próximo passo é fazer o planejamento da release (Release Planning), que é realizado por meio de uma ou mais reuniões com todos os envolvidos no projeto, contando inclusive com a participação dos responsáveis pelo negócio. Durante as reuniões, as estimativas são feitas por uma prática conhecida como “Jogo do Planejamento”.
Nesta prática, é responsabilidade do time de desenvolvimento fazer uma estimativa (em pontos) de cada uma das estórias do usuário, contemplando a complexidade e o prazo de entrega. Para uma estimativa mais assertiva, também é importante que durante o jogo os envolvidos comuniquem os impactos técnicos de implementação dos requisitos. E por fim, criar as tarefas (técnicas) necessárias para atender a estória, como por exemplo, a criação de objetos no banco de dados, criação de web services, tarefas de teste, ou seja, todo trabalho técnico necessário para concluir a implementação da estória.
Caso haja questionamentos por parte do time, o cliente responsável deve estar presente para tirar qualquer dúvida referente à estória, priorizá-las de acordo com sua criticidade e importância para o negócio, e auxiliar o time a definir as datas para a release.
Ao final da(s) reunião(ões), o time terá em mãos o plano de release com os itens de menor e maior prioridade devidamente estimados, e com prazos acordados para a entrega da release. Este artefato será utilizado para planejar cada iteração, que deve durar de uma a três semanas. É importante frisar que este planejamento está sempre passando por modificações, como o próprio manifesto ágil ilustra, onde um de seus valores nos diz que responder às mudanças é mais importante do que seguir um plano (um cronograma, por exemplo), para melhor atender ao cliente.
Em seguida é feito uma breve reunião no início de cada iteração para detalhar as tarefas atribuídas ao time. Pode entrar nesta lista qualquer tarefa a ser desenvolvida, como as estórias de maior prioridade, bugs a serem resolvidos ou tarefas que não foram aprovadas em iterações anteriores, ficando esta decisão a critério do time e do cliente.
As estórias que devem entrar em cada iteração são escolhidas respeitando a velocidade de desenvolvimento do time (timebox). Essa velocidade é baseada na soma dos pontos de todas as estórias que o time conseguiu entregar na última iteração.
Uma vez iniciada a iteração, para promover e maximizar a comunicação entre os membros do time, é realizado diariamente uma Stand Up Meeting, uma reunião simples, de no máximo 15 minutos, cujo objetivo é fazer com que o time exponha os problemas, soluções e o trabalho realizado até o momento. Mediada por um dos membros, nesta reunião, como o próprio nome indica, todos ficam em pé e focam apenas no status report do projeto.
Ao final de cada iteração, se os testes de aceite (Acceptance Tests) foram realizados com sucesso e o usuário responsável pela estória aprovou o desenvolvimento, então é feito um pequeno release ( ...
