Esse artigo faz parte da revista Engenharia de Software 20 edição especial. Clique aqui para ler todos os artigos desta edição

Imagem

Metodologias Ágeis

Métodos Ágeis de Desenvolvimento de Software

 

De que trata o artigo: Neste artigo são apresentados o histórico, o conceito, os valores e os princípios que norteiam os Métodos Ágeis, assim como são descritos os métodos mais frequentemente utilizados pelas organizações. Também são exploradas as suas limitações, as indicações de aplicação e os resultados obtidos por empresas que já os adotaram. Por fim, são discutidos os fatores críticos de sucesso de projetos de desenvolvimento de software conduzidos com o uso desses métodos.

 

Para que serve: Apresentar uma visão abrangente sobre o cenário atual envolvendo metodologias ágeis.

 

Em que situação o tema é útil: Conhecer metodologias ágeis é cada vez mais importante na medida em que lidamos cada vez mais com projetos de características diferenciadas que exigem, muitas vezes, abordagens não tradicionais de desenvolvimento.

 

Como uma resposta às crescentes pressões por inovação em prazos cada vez mais reduzidos, às necessidades de constantes mudanças de requisitos e ao mau desempenho de grande parte dos projetos de desenvolvimento de software, houve um movimento na comunidade de desenvolvimento de software que deu origem aos Métodos Ágeis. Posteriormente, o conceito-base deste movimento evoluiu, de uma abordagem técnica para o âmbito gerencial, criando um novo enfoque de gerenciamento de projetos – o Gerenciamento Ágil de Projetos.

Neste artigo são apresentados o histórico, o conceito, os valores e os princípios que norteiam os Métodos Ágeis, assim como são descritos os métodos mais frequentemente utilizados pelas organizações. Também são exploradas as suas limitações, as indicações de aplicação e os resultados obtidos por empresas que já os adotaram. Por fim, são discutidos os fatores críticos de sucesso de projetos de desenvolvimento de software conduzidos com o uso desses métodos.

Definição e Origem dos Métodos Ágeis de Desenvolvimento de Software

Os Métodos Ágeis de Desenvolvimento de Software surgiram como uma reação aos métodos clássicos de desenvolvimento[1] e do reconhecimento da necessidade premente de se criar uma alternativa a estes “processos pesados”, caracterizados pelo foco excessivo na criação de uma documentação completa (BECK, et al, 2001). Em meados dos anos 90, integrantes da comunidade de desenvolvimento de software começaram a questionar estes processos, julgando-os pouco efetivos e, muitas vezes, impossíveis de serem colocados em prática (HIGHSMITH, 2002).

Sintetizando o pensamento deste grupo, Highsmith (Ibid.) menciona que a indústria e a tecnologia sofrem modificações tão aceleradas que acabam por “atropelar” os métodos clássicos. Highsmith et al (2002) ainda acrescentam que os clientes, na maioria das vezes, são incapazes de definir de forma clara e precisa, os requisitos do software, logo no início de um projeto de desenvolvimento, o que inviabiliza a adoção dos métodos clássicos em muitos projetos.

Como resposta a esta situação, muitos especialistas criaram métodos próprios para se adaptar às constantes mudanças exigidas pelo mercado e às indefinições iniciais dos projetos. O agrupamento desses métodos deu origem à família dos Métodos Ágeis de Desenvolvimento de Software. Sendo assim,

 

“[...] os Métodos Ágeis podem ser considerados uma coletânea de diferentes técnicas e métodos, que compartilham os mesmos valores e princípios básicos, alguns dos quais remontam de técnicas introduzidas em meados dos anos 70, como os desenvolvimentos e melhorias iterativos” (COHEN et al, 2003, p.2).

 

De fato, Cockburn e Highsmith (2001a) já haviam afirmado que a maioria das práticas propostas pelos Métodos Ágeis não tem nada de novo e que a diferença recai principalmente sobre o foco e os valores que os sustentam.

Segundo Cohen et al (2003), um dos primeiros questionamentos aos métodos clássicos de desenvolvimento de software foi feito por Schwaber, criador do Scrum. Para entender melhor os métodos clássicos de desenvolvimento de software baseados no SW-CMM, Schwaber (2002) elaborou um estudo junto aos cientistas da DuPont, que tinha por objetivo responder a seguinte pergunta: “Por que os processos definidos e defendidos pelo SW-CMM não promovem entregas consistentes”? Após analisarem seus processos de desenvolvimento de software, os cientistas chegaram à conclusão que, apesar do SW-CMM buscar a consistência, a previsibilidade e a confiabilidade dos processos de desenvolvimento de software, muitos destes processos ainda eram, de fato, imprevisíveis e impossíveis de serem repetidos. A explicação para tal recaía na complexidade dos processos propostos pelo SW-CMM, na conseqüente dificuldade de aplicação e também na necessidade de mudanças constantes e difíceis de serem antecipadas.

Schwaber (op. cit.) percebe que para que o desenvolvimento de software seja realmente ágil, deve-se aceitar as mudanças, ao invés de dar foco extremo à previsibilidade. Quase que simultaneamente, outros especialistas no assunto chegam à conclusão de que métodos que respondam às mudanças, tão rapidamente quanto estas venham a surgir e que incentivem a criatividade, são a única maneira de enfrentar e gerenciar os problemas do desenvolvimento de software em ambientes complexos (COCKBURN; HIGHSMITH, 2001a, SCHWABER, 2002).

Neste mesmo período, modelos de processos aplicados a outras indústrias, começam a ser analisados para servir como fonte de inspiração ao aprimoramento do processo de desenvolvimento de software (POPPENDIECK, 2001). O Modelo Toyota de Produção[2] foi alvo de atenção especial: enquanto as unidades fabris americanas trabalhavam a 100% de sua capacidade e mantinham grandes volumes de inventário de matérias-primas e de produtos acabados, a fábrica da Toyota mantinha o nível de estoque suficiente para um dia de operação e produzia somente o necessário para atender aos pedidos já colocados. Este modelo traduzido no princípio da Lean Manufacturing, visava à utilização mais eficiente dos recursos e a redução de qualquer tipo de desperdício e estava totalmente alinhado à filosofia da Administração da Qualidade Total[3], criada pelo Dr. Edwards Deming (POPPENDIECK, 2001; FERREIRA et al, 2002). Deming (1990) acreditava que as pessoas desejavam fazer um bom trabalho e que os gerentes deveriam permitir que os trabalhadores do chão de fábrica tivessem autonomia para a tomada de decisões e a resolução de problemas. Além disso, estimulava o estabelecimento de uma relação de confiança com os fornecedores e defendia uma cultura de melhoria contínua dos processos e dos produtos. Enquanto as unidades fabris japonesas geravam produtos cada vez melhores e mais baratos, as fábricas americanas não conseguiam fazer o mesmo.

Com base nesta avaliação, Poppendieck (2001) listou 10 práticas que tornavam a Lean Manufacturing tão bem-sucedida e que, em seu entendimento, poderiam ser adaptadas e aplicadas ao desenvolvimento de software:

1.    Eliminação de gastos – eliminar ou reduzir diagramas e modelos que não agregam valor ao produto final;

2.    Minimização de inventário – minimizar artefatos intermediários, como documentos de requisitos e de desenho;

3.    Maximização do fluxo – utilizar o desenvolvimento iterativo para redução do prazo de entrega do software;

4.    Atendimento à demanda – atender às mudanças de requisitos;

5.    Autonomia aos trabalhadores – compartilhar a documentação e dizer aos programadores “o que” precisa ser feito e não “como” deve ser feito;

6.    Atendimento aos requisitos dos clientes – trabalhar perto dos clientes, permitindo que eles mudem suas opiniões ou seus desejos;

7.    Fazer certo da primeira vez – testar o quanto antes e refazer o código se necessário;

8.    Abolição da otimização local – gerenciar o escopo de forma flexível;

9.    Desenvolvimento de parceria com os fornecedores – evitar relações conflitantes, tendo em mente que todos devem trabalhar juntos para gerar o melhor software;

10. Cultura de melhoria contínua – permitir que o processo seja melhorado, que se aprenda com os erros e se alcance o sucesso.

 

Highsmith (2002) afirma, que de forma independente, Kent Beck e Ron Jeffreis percebem a importância dos princípios defendidos por Poppendieck (2001) durante um projeto de desenvolvimento de software na Chrysler e criam o  projeto Extreme Programming  (XP), um dos Métodos Ágeis de maior expressão atualmente. Simultaneamente, outras histórias começam a ecoar pelo mundo, como a vivenciada por Alistair Cockburn, que entrevistando profissionais do IBM Consulting Group, percebe que equipes de projetos bem-sucedidos se desculpavam por não ter seguido os processos formais, por não utilizar as ferramentas de alta tecnologia e por ter “simplesmente” trabalhado de forma próxima e integrada, enquanto membros de projetos malsucedidos afirmavam ter seguido as regras e processos e que não entendiam o que havia dado errado. Com base nesta experiência, Cockburn desenvolveu o Crystal Method, outro Método Ágil (HIGHSMITH, 2002).

Face ao exposto, percebe-se que o mundo do desenvolvimento de software passa por uma importante transformação: os métodos clássicos são vistos como não adequados a todas as situações e os especialistas reconhecem a necessidade de criação de novas práticas, orientadas a pessoas e flexíveis o suficiente para fazer frente a um ambiente de negócio dinâmico (COCKBURN; HIGHSMITH, 2001a). Os principais desafios enfrentados e que devem ser endereçados pelos novos métodos de desenvolvimento de software são assim sumarizados por Cockburn e Highsmith (Ibid.):

1.    A satisfação dos clientes passar a ter precedência frente à conformidade aos planos;

2.    As mudanças sempre ocorrem – o foco deixa de ser como evitá-las e passa a ser como abraçá-las e como minimizar o seu custo ao longo do processo de desenvolvimento;

3.    A eliminação das mudanças pode significar menosprezar condições importantes do negócio, ou seja, pode levar ao insucesso de uma organização;

4.    O mercado espera um software inovador, com alta qualidade, que atenda aos requisitos do negócio e que esteja disponível em prazos cada vez menores.

Manifesto para o Desenvolvimento Ágil de Software

No início de 2001, criadores e representantes dos chamados Métodos Ágeis de Desenvolvimento de Software – Extreme Programming, Scrum, Dynamic Systems Development Method, Adaptative Software Development, Crystal Methods, Feature-Driven Development, Lean Development, entre outros – se reuniram nos Estados Unidos para discutir alternativas aos tradicionais “processos pesados” de desenvolvimento de software (BECK et al, 2001). Estes especialistas foram enfáticos em dizer que não eram contra métodos, processos ou metodologias, sendo que muitos até mencionaram o desejo de resgatar o verdadeiro significado e a credibilidade destas palavras. Defendiam a modelagem e a documentação, mas não em excesso. Planejavam, mas reconheciam os limites do planejamento e da previsibilidade num ambiente turbulento (BECK et al, 2001).

A essência deste movimento é a definição de novo enfoque de desenvolvimento de software, calcado na agilidade, na flexibilidade, nas habilidades de comunicação e na capacidade de oferecer novos produtos e serviços de valor ao mercado, em curtos períodos de tempo (HIGHSMITH, 2004, p. xix). Como agilidade deve-se entender “a habilidade de criar e responder a mudanças, buscando a obtenção de lucro, em um ambiente de negócio turbulento” (HIGHSMITH, 2004, p. 16); ou ainda, “a capacidade de balancear flexibilidade e estabilidade” (Id., 2002). A agilidade não deve ser vista como falta de estrutura, mas está diretamente relacionada à capacidade de adaptação a situações diversas e inesperadas. Highsmith (2004, p. 16) enfatiza que a ausência de estrutura ou de estabilidade pode levar ao caos, mas que estrutura em demasia gera rigidez.

Como resultado do encontro, foi criada a Agile Alliance[4], sendo publicado o Manifesto para Desenvolvimento Ágil de Software ou o Manifesto for Agile Software Development (BECK et al, 2001), cujo conteúdo[5] é apresentado abaixo:

 

Nós estamos descobrindo melhores maneiras para desenvolver software, praticando e auxiliando os outros a fazê-lo. Através deste trabalho nós valorizamos:

-       Os indivíduos e suas interações acima de processos e ferramentas;

-       Software em produção acima da documentação exaustiva;

-       Colaboração do cliente acima da negociação de contratos;

-       Respostas às mudanças acima da execução de um plano.

Ou seja, embora haja valor nos itens à direita, nós valorizamos mais os itens à esquerda.”

 

Segundo Cohen et al (2003, p. 6), este Manifesto tornou-se a peça-chave do movimento pelo desenvolvimento ágil de software, uma vez que reúne os principais valores dos Métodos Ágeis, que os distingue dos métodos clássicos de desenvolvimento.

Além do Manifesto, foram definidos os princípios que regem a maioria das práticas dos chamados Métodos Ágeis de Desenvolvimento de Software (AGILE ALLIANCE, 2005).  Estes princípios são apresentados na Tabela 1 abaixo, de acordo com a ordem originalmente proposta.

 

Princípios

1.  Nossa maior prioridade é satisfazer o cliente através da entrega rápida e contínua de um software de valor

2.  Pessoas de negócio e programadores devem trabalhar juntos, diariamente, ao longo de todo o projeto

3.  Aceite as mudanças de requisitos, mesmo que numa etapa avançada do desenvolvimento

4.  Entregue novas versões do software frequentemente

5.  O software em funcionamento é a medida primária de progresso do projeto

6.  Construa projetos com pessoas motivadas. Ofereça a elas o ambiente e todo o apoio necessários e acredite em sua capacidade de realização do trabalho

7.  As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas

8.  O método mais eficiente e efetivo de distribuir a informação para e entre uma equipe de desenvolvimento é a comunicação face a face

9.  Processos ágeis promovem desenvolvimento sustentado

10. A atenção contínua na excelência técnica e num bom projeto aprimora a agilidade

11. Simplicidade é essencial

12. Equipes de projeto avaliam seu desempenho em intervalos regulares e ajustam seu comportamento de acordo com os resultados

...