Post

1 Star2 Stars3 Stars4 Stars5 Stars
Loading ... Loading ...

By SaltoNaComputação Agora vamos falar um pouco sobre o Extreme Programming (XP) que possui um conjunto bem definido de práticas e valores ágeis e que vem sendo utilizado por um grande número de adeptos. Abaixo fizemos uma breve explicação dessas práticas.Você que já trabalha com Agile vai perceber que muitas dessas práticas possivelmente já estão inseridas no seu dia-a-dia e outras podem enriquecer alguns processos existentes. Boa leitura!
Práticas Primárias
São aquelas que podem ser aplicadas imediatamente, trazendo melhorias imediatas para a equipe. As práticas primárias presentes no XP são:Sentar junto: A equipe de XP deve trabalhar num espaço amplo e juntos fortalecendo assim a comunicação, discutir em quadros brancos, trabalhar em pares, espalhar informações e gráficos nas paredes são formas de estimular a interação entre os membros da equipe.Time completo: A equipe de XP deve ser multidisciplinar. A equipe deve possuir desenvolvedores, analistas de teste, analista de negócio, clientes, especialista em banco de dados, especialista em interface gráficas, administradores de rede, dentre outros. Todos devem trabalhar com o mesmo objetivo, contribuindo para o bom andamento do projeto.

Área de trabalho informativa: A equipe deve transformar o ambiente de trabalho num reflexo do projeto. Seja com Kanban, histórias, gráficos, o observador deve ser capaz de ter uma evolução do projeto apenas andando pela área de trabalho.Trabalho energizado: O ritmo de trabalho não deve afetar o ritmo de trabalho do time. O número de horas para dedicação a um projeto deve ser definido de forma realista, hora-extra deve ser exceção, o time trabalha enquanto estiver energizado e produtivo.Programação em pares: com o intuito de promover um trabalho coletivo e colaborativo e melhorar a qualidade do código, os desenvolvedores trabalham em pares. Essa forma de trabalho aumenta o conhecimento da equipe, o compartilhamento de técnicas e competência.História: Feitas em pequenos cartões mais com o intuito de acompanhar as funcionalidades a serem desenvolvidas.Ciclo semanal: Essa prática sugere que o ciclo de iteração seja planejado a cada semana.Ciclo trimestral: As releases são planejadas a cada trimestre. A equipe se reúne com o cliente e partes interessadas do projeto para estabelecer o tema ou os temas que serão implementados no decorrer dos três meses.Folga: No plano deve haver tarefas pequenas e que possam ser removidas em casos de atraso.Buld em dez minutos: O build automático deve ser gerado em dez minutos. Builds devem ser automáticos, devem considerar o projeto inteiro, como código fonte e configurações de ambiente, deve executar todos os testes e ser rápido.Integração contínua: o repositório é compartilhado e os pares integram suas versões no final de cada tarefa após garantir que tudo está funcionando.Desenvolvimento dirigido por testes: Os testes automatizados devem ser escritos antes do código.Design incremental: os desenvolvedores devem implementar sempre um design mais simples com o mínimo de complexidade para atender as regras de negócios atuais, visando facilitar a manutenção e custos desnecessários com mudança no futuro.

Práticas CoroláriasSão mais difíceis de implementar, mostrando sua eficiência somente após domínio e experiência prévia com as práticas primárias.Envolvimento real com o cliente: faça com que as pessoas envolvidadas com o negócio e sistema façam parte do time. O cliente deve contribuir com as regras de negócio, definição de prioridades, testes de aceitação e estar próximo para que o time possa tirar dúvidas relacionadas as funcionalidades solicitadas.Implantação incremental: grandes implantações têm custo alto, implante um novo projeto aos poucos deixando o projeto antigo ainda em produção para diminuir riscos. Continuidade da equipe: equipes eficientes devem trabalhar juntas, o desenvolvimento de software deve levar em consideração o que as pessoas sabem, os relacionamentos e as conquistas em equipe.Diminuição da equipe: com a melhora da capacidade de produção da equipe, deve-se reduzir a equipe retirando um dos membros para que ele possa formar novas equipes. Análise de causa inicial: sempre que um defeito é encontrado conserte o problema e sua causa, visando que o erro não ocorra novamente e que o time não cometa-o novamente. O XP sugere que um teste de aceitação para o problema seja criado e que o sistema seja executado, que um teste unitário com menor escopo também reproduza o defeito. Após isso, deve-se corrigir o sistema e descobrir o porque de não ter sido codificado certo da primeira vez.Código compartilhado: o Time todo é responsável pelo sistema e o repositório é compartilhado, com isso o time cria uma ampla visão do todo e facilita em casos de refatoração.Código e testes: Os artefatos mantidos pela equipe são códigos e testes. O XP é contra a documentação que fica obsoleta com o tempo.Repositório de código unificado: O time deve possuir um repositório único. Quanto maior o número de versões concorrentes mais difícil de manter.Implantação diária: Novas versões do sistema devem ser liberadas toda noite. Assim o que está sendo feito pelo programador pode frequentemente ser testado pelo usuário.Contrato de escopo negociável: contratos devem fixar custo, tempo e qualidade, mas o escopo pode ficar aberto para negociações. O time de XP se adequa a mudanças que possam ocorrer com a evolução do sistema.

Pague-Pelo-Uso: a release é entregue e o cliente realiza o pagamento. O que ocorre com o uso dessa prática é o cliente querer adicionar mais tarefas a release para que o projeto possua o menor número de release e a equipe de desenvolvimento querer um número maior de releases.Por Liliana Carrha

Source: http://www.saltonacomputacao.com/2014/02/praticas-ageis-com-extreme-programming.html

Category: Agile, Extreme Programming

Você também pode querer ler

Comments are off for this post.