De que se trata o artigo: Neste artigo são apresentadas algumas evidências que motivaram o surgimento dos métodos ágeis, explicando seus valores e princípios, com ênfase na Programação Extrema, um dos métodos ágeis que mais recebeu atenção nos últimos anos.
Para que serve: Para gerentes, tomadores de decisão e membros de uma equipe de desenvolvimento de software, este artigo apresenta uma introdução detalhada sobre métodos ágeis de desenvolvimento de software, mostrando as evidências que levaram ao seu surgimento e abordando de forma ampla alguns dos métodos ágeis mais conhecidos, focando principalmente na Programação Extrema (XP).
Em que situação o tema é útil: Para quem já ouviu falar mas ainda não se aprofundou nos assuntos relacionados a métodos ágeis, Scrum, Lean ou XP. O artigo aborda uma ampla gama de assuntos, como: evidências, origens, metodologias, valores, princípios, práticas e formas de adoção.
Nos últimos anos, os métodos ágeis de desenvolvimento de software ganharam importância em diversos segmentos da indústria de software. Assim como os métodos tradicionais, os métodos ágeis têm por objetivo construir sistemas de alta qualidade que atendam às necessidades dos usuários. A principal diferença está nos princípios utilizados para atingir tal objetivo.
Os métodos ágeis apresentam uma abordagem bastante pragmática para o desenvolvimento de software. Planos detalhados são feitos apenas para a fase atual do projeto. Para fases futuras, os planos são considerados apenas rascunhos que podem se adaptar a mudanças conforme o time aprende e passa a conhecer melhor o sistema e as tecnologias utilizadas.
Neste artigo são apresentadas algumas evidências que motivaram o surgimento dos métodos ágeis, explicando seus valores e princípios, com ênfase na Programação Extrema, um dos métodos ágeis que mais recebeu atenção nos últimos anos.
Evidências
No desenvolvimento de software, é comum que os requisitos mudem enquanto a implementação ainda está acontecendo. Kajko-Mattson et al. mostram que cerca de 40% a 90% do custo durante o ciclo de vida de um projeto é gasto na fase de manutenção [1]. Muitas empresas e times de desenvolvimento acham que mudanças são indesejáveis, pois acabam com todo o esforço gasto no planejamento. No entanto, os requisitos geralmente mudam conforme o cliente vê o sistema sendo implantado e em funcionamento. É muito difícil criar um plano no início do projeto que consiga prever todas as mudanças sem gastar muito esforço, tempo e dinheiro.
Boehm chegou a afirmar que “encontrar e arrumar um defeito no software após a entrega custa cerca de 100 vezes mais do que encontrá-lo e arrumá-lo nas fases iniciais de design” [2]. Essa foi uma das principais justificativas para os métodos tradicionais gastarem mais tempo nas fases de análise de requisitos e design, apesar do próprio Boehm ter sugerido o desenvolvimento iterativo ao invés da “produção do produto completo de uma vez” [3]. Em 2001, num artigo de Boehm e Basili, houve uma redução no pessimismo ao perceber que, para sistemas pequenos, o fator era mais próximo de 5:1 ao invés de 100:1 e que, mesmo para sistemas grandes, boas práticas arquiteturais poderiam reduzir de forma significativa o custo da mudança, encapsulando as áreas de mudança em partes pequenas e fatoradas [4].
Poppendieck [5] sugere que a principal razão das mudanças no desenvolvimento de software é que o processo de negócio ao qual o software está atrelado evolui constantemente. Construir flexibilidade para acomodar mudanças arbitrárias é muito caro e pode ser um desperdício. Segundo Johnson [6], 45% das funcionalidades implementadas num sistema típico não são utilizadas nunca e 19% são raramente utilizadas. A melhor estratégia é evitar generalizações desnecessárias e fazer com que o sistema seja flexível apenas nas áreas mais propícias à mudança [7].
A maioria dos estudos de caso na indústria apontam para uma taxa relativamente alta de fracassos nos projetos de software [8]. No clássico relatório do Standish Group de 1994, o CHAOS Report [9], 37% dos fatores relacionados aos projetos em dificuldade estavam relacionados aos requisitos. O mesmo relatório de 2003 aponta que apenas 52% das funcionalidades são entregues em um projeto [10]. Outro estudo de classificação de defeitos aponta os requisitos como principal categoria de defeitos, com 41% [11]. “Nós queremos estabilizar os requisitos, mas eles não são estáveis” [12].
O Manifesto Ágil
Em fevereiro de 2001, um grupo formado por 17 desenvolvedores experientes, consultores e líderes da comunidade de software se reuniu em Utah para discutir idéias e procurar uma alternativa aos processos dirigidos a documentação e às práticas adotadas nas abordagens tradicionais da Engenharia de Software e gerência de projetos. Dessa reunião surgiu o Manifesto do Desenvolvimento Ágil de Software [13], que destaca as diferenças com relação às abordagens tradicionais e define seus valores:
- Indivíduos e interações são mais importantes que processos e ferramentas;
- Software funcionando é mais importante que documentação completa e detalhada;
- Colaboração com o cliente é mais importante que negociação de contratos;
- Adaptação a mudanças é mais importante que seguir um plano.
Apesar da importância dos itens à direita, os métodos ágeis dão mais valor para os itens destacados à esquerda. Além dos quatro valores básicos, o manifesto ágil também apresenta 12 princípios que auxiliam a difusão de suas idéias:
- A maior prioridade é a satisfação do cliente por meio da entrega rápida e contínua de software que traga valor;
- Mudanças nos requisitos são aceitas, mesmo em estágios avançados de desenvolvimento. Processos ágeis aceitam mudanças que trarão vantagem competitiva para o cliente;
- Software que funciona é entregue freqüentemente, em períodos que variam de semanas a meses, quanto menor o tempo entre uma entrega e outra melhor;
- As pessoas relacionadas ao negócio e os desenvolvedores devem trabalhar juntos no dia a dia do projeto;
- Construa projetos formados por indivíduos motivados, fornecendo o ambiente e o suporte necessário e confiando que realizarão o trabalho;
- O modo mais eficiente e eficaz de transmitir informações dentro e fora do time de desenvolvimento é a Comunicação face a face;
- A principal medida de progresso é software funcionando;
- Processos ágeis promovem o desenvolvimento em um ritmo sustentável. Os investidores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante;
- Cuidar continuamente da excelência técnica e do bom design ajuda a aprimorar a agilidade;
- Simplicidade - a arte de maximizar a quantidade de trabalho não necessário - é essencial;
- Os melhores requisitos, arquiteturas e design surgem de equipes auto-gerenciadas;
- Em intervalos regulares, o time reflete sobre como se tornar mais eficiente, refinando e ajustando seu comportamento apropriadamente.
Essas características trazem dinamismo para o desenvolvimento, motivação para o time e informações mais precisas sobre a verdadeira situação do projeto para o cliente. Enquanto as abordagens tradicionais têm um enfoque mais preditivo, os métodos ágeis são adaptativos.
O manifesto ágil apresenta uma nova filosofia para o desenvolvimento de software. Sob seus valores e princípios aparecem diversas abordagens mais específicas, com diferentes idéias, comunidades e líderes. Cada comunidade forma um grupo distinto, porém todas seguindo os mesmos princípios. É comum inclusive a troca de conhecimento e práticas entre membros de diferentes comunidades, formando um eco-sistema em torno de diversos métodos, detalhados a seguir com maior ênfase na Programação Extrema.
Scrum
Desenvolvida nas décadas de 80 e 90 por Ken Schwaber, Jeff Sutherland, e Mike Beedle [14], o Scrum se concentra mais nos aspectos gerenciais do desenvolvimento de software, propondo iterações de duas semanas ou 30 dias (chamados Sprints) com acompanhamento diário por meio das Reuniões em Pé (ou stand-up meetings). Por dar menos ênfase aos aspectos técnicos, é geralmente combinada com práticas propostas por XP e compatível com certificações de qualidade como CMMI ou ISO 9001 [15].
Lean Software Development
Com base no Sistema de Produção da Toyota [16][5, 7]: “Elimine Desperdícios”, “Inclua a Qualidade no Processo”, “Crie Conhecimento”, “Adie Comprometimentos”, “Entregue Rápido”, “Respeite as Pessoas” e “Otimize o Todo”.
Família Crystal
Alistair Cockburn propõe uma família de métodos por acreditar que diferentes abordagens são necessárias para equipes de tamanhos diferentes [17]. Apesar disso, todos os métodos dessa família compartilham propriedades como: entrega freqüente, Reflexão e Comunicação. Outra parte importante dos métodos da família Crystal é o que Cockburn chama de habitabilidade (habitability): o mínimo de processo necessário para que a equipe consiga ter sucesso.
Feature Driven Development (FDD)
Desenvolvida por Peter Coad e Jeff de Luca no final da década de 90, a FDD define duas fases compostas por 5 processos bem definidos e integrados: a fase de concepção e planejamento, composta por “desenvolver um modelo abrangente”, “construir uma lista de funcionalidades” e “planejar por funcionalidade”; e a fase iterativa de construção, composta por “detalhar por funcionalidade” e “construir por funcionalidade” ...
