Metodologia XP (eXtreme Programming) – Comparativos entre as metodologias

Por / Extreme Programming

Esta série de artigos sobre Metodologia XP de desenvolvimento é uma versão compacta do trabalho de conclusão de curso (TCC) onde o título original da monografia em que foi baseada esta série é:

O USO DA METODOLOGIA XP NO DESENVOLVIMENTO DE SOFTWARE E OS IMPACTOS NA GESTÃO DE RISCOS

Toda semana, sempre às segundas-feiras, postaremos uma parte ou capítulo da monografia, o que totalizará 10 semanas de postagens. No capítulo de hoje faremos um comparativo entre a metodologia XP e o modelo em cascata com base nos estudos que fizemos ao longo desta série de artigos.

Sumário do artigo “Metodologia XP”:

Comparativos entre a metodologia XP e o modelo em cascata

O estudo de caso a seguir tem como desafio demonstrar as principais diferenças acerca da aplicação das metodologias no que tange às questões sobre eficiência e eficácia no desenvolvimento. Sendo o enfoque desse estudo a flexibilidade da metodologia para com os processos e o suporte que ela proporciona para as principais questões na gestão de riscos em projetos de software.

Metodologia XP ( eXtreme Programming )

Comparativo sobre processos

Para Pompilho (2002), a metodologia de desenvolvimento tradicional é composta de uma regra rígida onde as fases do projeto devem ter uma sequência, e uma fase dá início ao término da outra, portanto, o teste que no desenvolvimento XP ocorre a todo momento, no modelo em cascata só irá ocorrer no final. Percebe-se então, na tabela 2 como XP é flexível deixando o engenheiro de software verificar quais etapas serão importantes e quais artefatos serão utilizados.

Tabela 2 – Comparativo entre os processos da XP e do modelo em cascata

Ciclo de vida do um Software Desenvolvimento ágilXP (Extreme Programming) Desenvolvimento TradicionalModelo em cascata
Definição dos requisitos Obrigatório. Os requisitos são atualizados ao longo do desenvolvimento. Obrigatório. É gerada uma versão que servirá de base para todos os itens a seguir.
Projeto de software Opcional. Surge informalmente durante o desenvolvimento do software. Obrigatório. E só se dá início ao término da definição dos requisitos.
Desenvolvimento Implementa os incrementos (user stories) levantados junto ao cliente. Implementa sequencialmente cada funcionalidade que o projetista especificou no projeto.
Teste de sistema É feito um plano de teste antes da implementação que vão sendo executados freqüentemente. O teste é feito apenas pela equipe de desenvolvimento no final do projeto.
Implantação Parte do software vai sendo implantada até concluir todos os requisitos. O software só é entregue ao usuário quando estiver totalmente pronto.

Adaptado de: Pompilho (2002)

Comparativo sobre a gestão de riscos

Segundo Sommerville (2007), desenvolver software é uma atividade arriscada e todo gerente de projeto deve obrigatoriamente prever os riscos que podem afetar o desenvolvimento e a qualidade do software. Os tipos de riscos dependem da complexidade e do ambiente de desenvolvimento. No entanto, alguns riscos são considerados universais pela comunidade de Engenharia de Software e alguns deles são descritos na Tabela 3.

Tabela 3 – Riscos comuns em projetos de Software

RISCO DESCRIÇÃO
Alteração nos requisitos Mudanças nos requisitos não previstas
Atrasos na especificação Especificações essenciais não disponíveis nos prazos
Documentação completa Clientes que exigem documentação abrangente
Escopo fechado Contrato que define todas as atividades do projeto
Doenças e demissões Perda de pessoas-chave em períodos cruciais
Treinamento Perda de mão-de-obra para treinar novas pessoas
Mudanças gerenciais Gerenciamento organizacional com prioridades diferentes
Sistemas de premiação Incentivo a desenvolvedores que apresentarem melhores resultados
Tamanho subestimado Tamanho do sistema bem maior que o estimado

Adaptado de: Sommerville (2007); Teles (2006)

Baseando-se no que foi estudado até o momento sobre Desenvolvimento Tradicional e Desenvolvimento Ágil, foi possível empiricamente montar a tabela abaixo, dando níveis de Alto e Baixo nas questões levantadas por Sommerville (2007) e Teles (2006).

Tabela 4 – Comparativo entre o grau de risco nas metodologias tradicionais e na XP

RISCO Desenvolvimento ágil (XP) Desenvolvimento tradicional
Alteração nos requisitos Baixo Alto
Atrasos na especificação Baixo Alto
Documentação completa Alto Baixo
Escopo fechado Alto Baixo
Doenças e demissões Baixo Alto
Treinamento Baixo Alto
Mudanças gerenciais Baixo Alto
Sistemas de premiação Alto Baixo
Tamanho subestimado Baixo Alto

Adaptado de: Sommerville (2007); Teles (2006)

Na análise feita no comparativo sobre gestão de riscos, nota-se que:

  1. As boas práticas de: Cliente presente, Releases e iterações e Jogo de planejamento fazem com que a metodologia XP seja mais aconselhável para projetos de espoco variável em que os requisitos ainda não estão bem definidos e que podem sofrer alterações durante o projeto, seja por mudanças gerenciais na equipe do cliente ou mesmo por ele não conhecer ao certo a dimensão exata do sistema. Além disso, a XP consegue reduzir problemas de treinamento e perda de mão-de-obra devido às boas práticas de Código coletivo e Programação em par, que proporciona a todos da equipe (inclusive aos novatos), treinamento constante e conhecimento satisfatório sobre todas as partes do sistema.
  2. Em contrapartida, a XP não é aconselhável em projetos que o cliente exija uma documentação completa do sistema logo no início do projeto, uma vez que equipes XP priorizam colocar o sistema em funcionamento ao invés da documentação abrangente. Outro risco para projetos que utilizam a XP é a premiação (muitas vezes financeira) para membros da equipe de desenvolvimento que apresentarem melhor desempenho. Essa prática trás um sentimento de competição dentro da equipe e os levam a comportamentos individualistas e, sem duvida a XP é um ambiente de cooperação, e não há espaço para esse tipo de competição (TELES, 2006).

Continue lendo essa série de artigos sobre em Metodologia XP ( eXtreme Programming ) – Conclusões, Bibliografia e Download

Observação: Todos as referências serão creditadas no último artigo da série.