Extreme Programming(XP) - ITnerante
Postado por Kauan Mocelin em 1 novembro 2013 às 15:29
"Trata-se de uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança" – Kent Beck Segue as seguintes diretrizes:
Testes funcionais(TDD)
membros técnicos da equipe realizam a atividade de ouvir a fim de entender o ambiente de negócios do software;
cada história escrita pelos usuários é colocada em uma ficha; o cliente atribui um valor a essa ficha de acordo com o valor de negócio global do recurso ou função;
os membros da equipe avaliam as fichas e atribuem um custo(medido em semanas para desenvolvimento), se esse custo for maior que 3 semanas, então é solicitado aos clientes que realizem a decomposição das histórias em partes menores;
novas histórias podem ser escritas a qualquer momento;
oferece um guia de implementação para uma história a medida que é escrita(nada mais, nada menos);
utilização de cartões CRC(classe-responsabilidade-colaborador); identificam e organizam as classes orientadas a objetos relevantes para o incremento de software corrente;
se um grave problema de projeto for encontrado, recomenda-se a criação imediata de um protótipo operacional dessa parte do projeto(solução pontual) com objetivo de reduzir os riscos para quando a verdadeira implementação iniciar.
antes da codificação, desenvolve-se uma série de testes de unidade que exercitarão cada uma das histórias que serão incluídas na iteração(TDD).
os testes criados devem ser implementados utilizando uma metodologia que permita a automatização, isso encoraja a estratégia de testes de regressão toda vez que o código for alterado;
os testes de aceitação(teste de cliente) são obtidos a partir das histórias dos usuários.
Visão geral do processo de desenvolvimento Extreme Programming
Metáfora: conta uma história fazendo uma analogia com o funcionamento do sistema, facilitando a comunicação entre os interessados.
Projeto simples: o código deve estar na forma mais simples possível de modo que passe por todos os testes e atenda todos os requisitos.
Pequenas versões: entrega de pequenos releases(pedaços) de software funcionando para os clientes aproximadamente a cada duas semanas, passando confiança ao cliente sobre o progresso geral.
Refatoração: o código deve ser constantemente melhorado, tornando-o mais simples e mais genérico, removendo redundâncias e duplicidades.
Programação em Pares: os programadores trabalham em pares, checando(validando) mutuamente o trabalho realizado, preferencialmente alternando os pares de modo que todos os membros da equipe possam trabalhar juntos. Utilizam a mesma estação de trabalho.
Propriedade coletiva do código: todos são responsáveis por todo o código e qualquer pessoa está autorizada a realizar mudanças nele, visa integrar a equipe e evitar a formação de ilhas de conhecimento.
Padrão de codificação: todo código é desenvolvido de acordo com um estilo e formato consistente(padrão).
Ritmo sustentável: cada programador deve trabalhar no máximo 40h semanais.
Reuniões em pé: reuniões rápidas e diárias com a equipe, para discutir apenas o essencial(máximo 15 minutos de duração).
Cliente sempre presente: o cliente com conhecimento sobre o negócio, deve estar disponível fisicamente em tempo integral para a equipe do projeto.
Desenvolvimento Orientado a testes(TDD): uma estrutura de testes unitários automatizada é criada e os testes são escritos antes mesmo das funcionalidades serem implementadas. Evita a criação de código viciado, pois o teste será elaborado com um direcionamento se realizado após a implementação do código.
Integração contínua: os diversos módulos são integrados o mais cedo possível, para evitar problemas de integração no futuro. Depois de qualquer integração, todos os testes unitários devem ser realizados novamente(Teste de regressão).
Planejamento incremental: requisitos são registrados como histórias dos usuários e priorizados para serem incluídos em uma determinada iteração, de acordo com o tempo disponível e sua prioridade relativa.
Comunicação: métodos para rapidamente construir e disseminar conhecimento.
Simplicidade: encoraja a equipe começar sempre pela solução mais simples que seja funcional e atenda as necessidades imediatas sem se preocupar com demandas futuras.
Feedback: do cliente, do sistema e da equipe.
Coragem: para projetar para hoje(Projeto Simples), reconhecendo que demandas futuras podem mudar completamente, ocasionando retrabalho em relação ao projeto e ao código implementado.
Respeito: respeito da equipe, do cliente e dos usuários.
SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo. Pearson Addison-Wesley, 2007.
Comentário de Washington Saraiva Santana em 17 setembro 2017 às 8:22
Comentário de Ilton Baracho .´. em 27 junho 2016 às 13:02
Questão - Fundação BIO-RIO –IFRJ 2015 - TÉC. ADM. EM EDUCAÇÃO
A abordagem orientada a objetos denominada "Extreme Programming – XP" constitui uma das metodologias ágeis que inclui um conjunto de regras e práticas que ocorrem no contexto de quatro atividades de arcabouço, indicadas na figura abaixo (é a mesma figura do artigo, só que substituídas pelas palavras ALFA, BETA, GAMA e DELTA) .
As fases ALFA, BETA, GAMA e DELTA são denominadas respectivamente:
(A) Requisitos, Planejamento, Projeto e Codificação.
(B) Planejamento, Projeto, Codificação e Teste.
(C) Testes, Requisitos, Projeto e Codificação.
(D) Planejamento, Requisitos, Codificação e Teste.
(E) Requisitos, Testes, Planejamento e Codificação.
Gab: B.
Comentário de Ilton Baracho .´. em 27 junho 2016 às 12:34
Parabéns ! Ótimo Post. Bem colocado as referências, valorizam e dão credibilidade a postagem. Só faltou as páginas das referências.