Uma Visão Geral de Diferentes Métodos Ágeis

 

Nesse artigo vamos apresentar uma visão geral de alguns métodos ágeis de gestão de projetos de desenvolvimento de software. O leitor poderá notar que praticamente todos esses métodos usam rodadas (sprints, ciclos, iterações) de trabalho para criar partes menores de um produto maior e completo. A escolha e priorização dessas partes menores – criadas em cada rodada - leva sempre em consideração o que é mais útil, prioritário e gera mais valor para os clientes.

As abordagens ágeis aqui tratadas e descritas nesse artigo em suas linhas gerais, parecem provar que existe uma diversidade de ideias e preferências presentes no campo da engenharia de software e do gerenciamento de projetos. Mas, como na frase de Bob Marley, essas diferenças não derrubam o ágil, ao invés disso, ajudam a levantá-lo.

 

“Seja diferente:

Não derrube.

Ajude a levantar...”

(Bob Marley)

Scrum – Dentro desse método ágil, um projeto é divido em ciclos chamados de Sprints. Um Sprint representa um Time Box (período de tempo, tipicamente de 2 a 4 semanas) dentro do qual um conjunto de atividades deve ser executado. Tudo que vai ser implementado em um projeto é mantido em uma lista de itens chamada de Product Backlog. No início de cada Sprint, faz-se uma Sprint Planning Meeting (reunião de planejamento do Sprint), em que o Product Owner prioriza os itens do Product Backlog e a equipe seleciona os itens que serão implementados durante o Sprint que se inicia.

Os itens alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog. Para tratar do que foi feito no dia anterior, identificar gargalos e priorizar o trabalho do dia que se inicia, a equipe realiza uma reunião chamada Daily Scrum Meeting. Ao final de um Sprint é realizada uma reunião de revisão chamada de Sprint Review Meeting, na qual a equipe apresenta os itens implementados e o projeto é avaliado com relação aos seus objetivos. Finalmente, é também realizada uma reunião de retrospectiva, chamada de Sprint Retrospective Meeting, para avaliar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar.

Os principais papéis no Scrum são o Product owner, que define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings, o Scrum Master, que é o responsável por facilitar o trabalho de toda a equipe, principalmente no que diz respeito à compreensão dos conceitos do Scrum, e a equipe (Scrum Team) que trabalha com os itens priorizados do  Product Backlog  e se compromete a entregá-los ao final de um Sprint.

XP (eXtreme Programming) – É um método ágil no qual o desenvolvimento de software é feito em iterações de curto período de tempo (1 ou 2 semanas) onde a equipe desenvolve um conjunto de funcionalidades. No início da iteração os desenvolvedores e clientes se reúnem para priorizar as funcionalidades. Essa reunião chama-se jogo de planejamento e nela já devem estar criadas as User Stories (Estórias de Usuário). Se uma estória for muito grande, deverá ser dividida em tarefas com menor duração. O planejamento é importante para que sempre se faça o que é mais importante e prioritário. O XP segue um conjunto de práticas que auxiliam no alcance de um projeto bem sucedido e incluem, por exemplo, o cliente sempre presente, programação em par, metáforas, TDD, refatoração, código coletivo, padronização de código, design simples, integração contínua e releases curtos. No XP também são adotadas reuniões diárias de curta duração, feitas com as pessoas de pé, para alinhamento do projeto e discussão de problemas, chamadas de Stand Up Meetings (Reunões de Pé).

Users Stories (Estórias de Usuário) são escritas pelos clientes com “coisas que o software precisa fazer”, substituindo documentos detalhados de requisitos e são usadas para criar estimativas de tempo para a reunião de planejamento além de auxiliar na criação dos critérios de testes de aceitação.

Spike Solutions se refere ao uso do programa mais simples possível para explorar soluções potenciais. É usado para determinar quanto trabalho será necessário para resolver ou contornar um problema de software.

Programação em par – Dois programadores fazendo o trabalho juntos em um único computador para revisão do código, redução de falhas e melhoria da qualidade.

Metáforas – São elementos usados no computador que simulam “coisas” que existem no mundo físico (lixeira, porta, janela, pasta, etc). As metáforas melhoram a comunicação e o entendimento de partes do código que executam determinadas funções representadas por elementos do mundo físico com os quais os desenvolvedores e clientes estão familiarizados.

TDD (Test Driven Development ou Desenvolvimento Orientado à Testes) – Primeiro se escrevem os testes, antes de implementar o sistema (conjunto de componentes integrados). Cada componente é testado individualmente para garantir sua correta operação. Depois disso, os componentes são integrados para formar o sistema e então testados, buscando-se encontrar erros que resultem de interações não previstas nos testes individuais.

Refatoração – Uma técnica usada pelas equipes para melhorar continuamente a estrutura do código quando uma nova funcionalidade é introduzida, tornando-o mais claro e fácil de ser compreendido, mas sem mudar o comportamento das funcionalidades.

Código coletivo – Isso significa que o código fonte não tem dono e ninguém na equipe de desenvolvedores precisa solicitar permissão para modificar o mesmo.

Padronização de código – Isso significa que existe um jeito certo de fazer as coisas no projeto e todos na equipe devem seguir essas regras definidas para desenvolver o software.

Integração contínua – Isso significa que não se deve esperar muito tempo (1 semana ou mais) para integrar uma nova funcionalidade com a versão atual do sistema.

Releases curtos – Isso significa que os releases são pequenos pedaços do produto que está sendo desenvolvido no projeto.

DSDM (Dynamic Systems Development Method) – É uma metodologia ágil de desenvolvimento de software iterativa e incremental que enfatiza o envolvimento constante do usuário. Assim sendo, em cada rodada no método, partes do software (funcionalidades ou componentes funcionais do sistema) vão sendo entregues.

É importante ter a compreensão que para iniciar o ciclo de desenvolvimento iterativo no DSDM o projeto precisa estar construído em uma base sólida, com fundamentos que incluem, por exemplo, um estudo de viabilidade e um plano geral de desenvolvimento.

A estrutura de trabalho do DSDM possui fases que são descritas a seguir:

Pré-Projeto: Essa fase deve garantir que os projetos estejam prontos para começar com base no objetivo e nas metas de negócios.

Antes de iniciar a construção das funcionalidades, o projeto no DSDM considera que deve ser feita uma análise de viabilidade e também deve ser elaborada uma análise do negócio. Como resultado se obtém o relatório de viabilidade, a lista de requisitos do sistema e o plano geral de desenvolvimento.

Após a conclusão destas duas fases, o sistema é desenvolvido iterativamente e incrementalmente, em um modelo evolucionário que considera o seguinte:

Iteração do modelo funcional: Tem foco na criação, a partir dos requisitos identificados no estágio anterior, de protótipos funcionais que determinam as funcionalidades a serem implementadas, que resultarão desta iteração. Isso feito, a lista de requisitos é atualizada, removendo-se os itens entregues e refazendo a lista de prioridades dos requisitos remanescentes.

O sistema é construído exatamente de acordo com o design e as funções consolidadas e integradas nos protótipos.

Na fase de implantação, ocorre a entrega das funcionalidades (ou componentes funcionais do sistema) desenvolvidas, devidamente prontas e funcionando para utilização pelos usuários finais. Inclui também o treinamento dos usuários e a entrega da documentação do projeto relacionada às funcionalidades que estão sendo entregues.

Pós-Projeto: Esta fase garante a eficiência e eficácia do projeto, através de manutenções, melhorias e ajustes.

FDD (Feature Driven-Development) – é um método ágil e iterativo para desenvolvimento de software que combina gestão de projetos com boas práticas de engenharia de software. No FDD o projeto é dividido em “features” (funcionalidades) definidas como pequenas partes de um projeto completo.

No FDD é feito um mapeamento sobre que partes do software os desenvolvedores serão capazes de criar, dividindo as solicitações maiores e complexas em uma série de conjuntos menores e, em seguida, é elaborado um plano que estabelece como concluir cada um desses conjuntos menores ao longo do tempo.

Os principais papéis do FDD são os seguintes:

Gerente de Projetos (Project Manager) – É o administrador do projeto, que faz os relatórios de progresso e gerencia o orçamento, os equipamentos, os recursos, etc.

Arquiteto Chefe (Chief Architect) – É o responsável pelo design geral do sistema.

Gerente de Desenvolvimento (Development Manager) – É o membro da equipe que lidera as atividades de desenvolvimento do dia-a-dia.

Programador Chefe (Chief Programmer) – É um programador experiente que já passou algumas vezes por todo o ciclo de vida de desenvolvimento de software.

Proprietários de classe (Class Owners) - São desenvolvedores que estão trabalhando como membros de pequenas equipes de desenvolvimento sob a orientação de um Programador Chefe.

Especialistas em Domínio (Domain Experts) - São usuários, patrocinadores, analistas de negócios, ou todos esses especialistas combinados, conhecidos por possuir a base de conhecimento na qual os desenvolvedores dependem e confiam para entregar o sistema correto.

O FDD é multifuncional, iterativo e altamente colaborativo e possui cinco (5) etapas básicas:

Desenvolver um modelo geral – Com orientação do Arquiteto Chefe, a equipe desenvolve um modelo geral que serve de base para a criação da lista de funcionalidades a ser desenvolvida no projeto.

Construindo a lista de funcionalidades - Usando o modelo da etapa anterior, a equipe ou o Programador Chefe constrói uma lista de funcionalidades considerando o que será útil para os usuários e poderá ser concluído ao longo de um cronograma de liberação de funcionalidades.

Planejamento por funcionalidade - Os planos são colocados na ordem em que as funcionalidades serão implementadas. As equipes são então selecionadas para desenvolver cada conjunto de funcionalidades.

Design por funcionalidade - Nesse estágio, o Programador Chefe escolhe as funcionalidades para o desenvolvimento e faz a alocação destas para as equipes. Geralmente, uma equipe deve contar com as seguintes funções/papéis: Gerente de Projeto, Arquiteto Chefe, Gerente de Desenvolvimento, Especialista de Domínio, Proprietário de Classe e Programador Chefe.

Construindo por funcionalidade - As equipes trabalham para fazer a codificação das funcionalidades, os testes e a documentação completas de cada funcionalidade. As funcionalidades concluídas pela equipe e avaliadas pelo cliente são liberadas.

Embora os métodos sejam diferentes, há muitas semelhanças entre eles.

É perfeitamente possível notar que nos métodos estudados existe a ideia da rodada de trabalho, em que partes menores vão sendo feitas e incorporadas para formar um todo. Os nomes dessas rodadas de trabalho (Sprint, ciclo, iteração) podem variar de método para método, mas a filosofia é nitidamente comum à todos.

A duração dos Sprints, ciclos ou iterações é de poucas semanas. Além disso, a maior parte dos métodos ágeis foi idealizada para o trabalho com equipes pequenas.

Há uma etapa de avaliação inicial que tem como propósito a tarefa de responder as seguintes perguntas: - O que vamos fazer? Como vamos dividir esse problema grande em partes menores? As respostas ajudam a criar a lista de funcionalidades do software que será desenvolvida.

Outro aspecto presente em quase todos os métodos aqui apresentados é que, ao invés de elaborar um plano completo e que abranja todo o projeto, o planejamento é feito para cada rodada de trabalho. Se analisarmos em linhas gerais, será possível notar que no Scrum esse plano é o planejamento do Sprint (Sprint Planning). No XP existe o chamado jogo de planejamento que utiliza as estórias de usuário, os critérios dos testes de aceitação e elabora o plano da iteração. No FDD o planejamento é feito por funcionalidade, uma vez que os planos são colocados na ordem em que as funcionalidades serão implementadas.

Outro ponto que merece ser destacado é que cada método, a sua maneira, permite que seja criado um fluxo contínuo de desenvolvimento de software.

Espero que você leitor que me acompanha tenha gostado desse conteúdo. Deixe seu comentário. Bem, é isso aí. Até a próxima!