Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Artigo Engenharia de Software 10 - Introdução à Programação Extrema (XP)
Artigo da Revista Engenharia de Software edição 10.
Metodologias Ágeis
Introdução à Programação Extrema (XP)
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:
Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Danilo Sato
Danilo Sato é Desenvolvedor, Coach e Consultor da ThoughtWorks UK. Com formação e mestrado em Ciência da Computação pelo IME/USP no tema Métodos Ágeis, é também fundador do Dojo@SP e membro da AgilCoop. Danilo já ministrou cursos sobre diversos assuntos relacionados a Métodos Ágeis e palestrou em di...
