ITnerante

Estudos de TI para Concursos Públicos

"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:

  • Programação em pares
  • Testes funcionais(TDD)
  • Refatoração
  • Integração contínua
  • Projeto simples

Processos

  • Planejamento
    • 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;
  • Projeto
    • 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.
  • Codificação
    • 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).
    • programação em pares
  • Testes
    • 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;
    • integração contínua;
    • os testes de aceitação(teste de cliente) são obtidos a partir das histórias dos usuários.

Processo - Extreme Programming

Visão geral do processo de desenvolvimento Extreme Programming

Práticas

  • 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.

Valores

  • 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.


Referência Bibliográfica
SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo. Pearson Addison-Wesley, 2007.

PRESSMAN, Roger S. Engenharia de Software, Sexta Edição. Editora MCGrawHill: Porto Alegre, 2010.

Exibições: 2396

Comentar

Você precisa ser um membro de ITnerante para adicionar comentários!

Entrar em ITnerante

Comentário de Washington Saraiva Santana em 17 setembro 2017 às 8:22

Ótimo Resumo!

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.

Comentário de Luciana Milhomem Peres em 20 abril 2014 às 17:21

Muito bom esse resumo, obrigada.

Comentário de Rodrigo avelar santos santana em 2 abril 2014 às 13:20

muito bom o resumo, valeu mesmo.

Comentário de Eduardo Cavalcante em 24 março 2014 às 19:07

muito bom cara, continue firme

Comentário de pedrogazzola em 11 novembro 2013 às 21:36

Bom resumo! Mandou bem!

© 2018   Criado por Walter Cunha.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço