Metodologia XP (eXtreme Programming) – Comparativos entre as metodologias

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 SoftwareDesenvolvimento ágilXP (Extreme Programming)Desenvolvimento TradicionalModelo em cascata
Definição dos requisitosObrigató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 softwareOpcional. Surge informalmente durante o desenvolvimento do software.Obrigatório. E só se dá início ao término da definição dos requisitos.
DesenvolvimentoImplementa 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çãoParte 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

RISCODESCRIÇÃO
Alteração nos requisitosMudanças nos requisitos não previstas
Atrasos na especificaçãoEspecificações essenciais não disponíveis nos prazos
Documentação completaClientes que exigem documentação abrangente
Escopo fechadoContrato que define todas as atividades do projeto
Doenças e demissõesPerda de pessoas-chave em períodos cruciais
TreinamentoPerda de mão-de-obra para treinar novas pessoas
Mudanças gerenciaisGerenciamento organizacional com prioridades diferentes
Sistemas de premiaçãoIncentivo a desenvolvedores que apresentarem melhores resultados
Tamanho subestimadoTamanho 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

RISCODesenvolvimento ágil (XP)Desenvolvimento tradicional
Alteração nos requisitosBaixoAlto
Atrasos na especificaçãoBaixoAlto
Documentação completaAltoBaixo
Escopo fechadoAltoBaixo
Doenças e demissõesBaixoAlto
TreinamentoBaixoAlto
Mudanças gerenciaisBaixoAlto
Sistemas de premiaçãoAltoBaixo
Tamanho subestimadoBaixoAlto

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.

Metodologia XP (eXtreme Programming) – Comparativos entre as metodologias
Rolar para o topo