Metodologia de desenvolvimento Xp

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Metodologia de desenvolvimento X.P.
EXTREME PROGRAMMING
O xp é uma metodologia de desenvolvimento de software com a intenção de melhorar a resposta do software e de alta qualidade com os requisitos voláteis dos consumidores. 
Tornando-se um tipo de procedimento Agile, promove lançamentos frequentes em pequenos ciclos de desenvolvimento. Isso introduz checkpoints e melhora a produtividade de uma forma que podem ser adoptadas as novas exigências de clientes.
Alguns aspectos positivos do XP são :
O teste de unidade de todo o código
Evitar a programação de recursos até que seja necessário
Requisitos do cliente voláteis melhor compreendida
Clareza e simplicidade em código
Algumas desvantagens:
A comunicação frequente entre os programadores e até mesmo com o consumidor
Requisitos instáveis
Pode aumentar o risco de desmoronamento do escopo devido à falta de documentação completa requisitos
As quatro variáveis de um sistema
Na Extreme Programming, são consideradas quatro as variáveis que estão presentes no desenvolvimento de um projeto:
6
O planejamento dentro da XP é feito sempre da mesma maneira: Os clientes/gerentes escolhem o valor de três destas variáveis, e a equipe de desenvolvimento projeta o valor consequente da quarta variável
Interação entre as variáveis
É muito difícil encontrar uma relação ideal entre o peso de cada variável, sendo que a redução nos valores aceitáveis de uma nem sempre causam a mesma variação positiva em outra.
•Custo – poucos recursos para um projeto podem trazer sérios prejuízos para as demais variáveis, pois com um orçamento muito apertado normalmente não se consegue contar com a equipe que se gostaria, e isto pode trazer problemas para a efetiva resolução do problema do cliente.
•Tempo – um prazo maior para a entrega final do sistema aumenta a qualidade e o escopo do mesmo, dentro de um limite. Por outro lado, caso o prazo seja muito pequeno, prejudica-se o escopo da aplicação.
•Qualidade – Pode-se ter ganhos pequenos (dias ou semanas) sacrificando a qualidade em alguns pontos do projeto, como por exemplo definindo-se um número menor de unit tests para uma classe, a fim de poupar tempo de programação. Contudo, esta prática não é recomendável, pois este ganho tende a desaparecer na medida em que a baixa qualidade pode causar problemas que tomarão tempo para serem corrigidos.
•Escopo – um escopo menor pode melhorar a qualidade, pois se tem menos tarefas para serem desenvolvidas, e também reduz o prazo e o custo.
As variáveis custo e tempo normalmente são decisão do cliente, pois é dele a decisão sobre quando precisa do sistema implementado e qual o valor que está disposto a pagar por isto.
A variável qualidade não deve ser sacrificada. Portanto, normalmente a variável sobre a qual a equipe de desenvolvimento acaba tendo o controle é sobre o escopo. Isto deve ficar claro desde o início do projeto, tanto para o cliente quanto para o desenvolvedor.
Os papéis de cada membro de uma equipe de XP
Para tornar possível o controle de um projeto de XP, faz-se necessário conhecer os membros de uma equipe de desenvolvimento que utiliza esta metodologia.
É importante salientar que pessoas podem ocupar mais de um papel dentro da equipe, e que como a modelagem, o projeto e o desenvolvimento são feitos por todos a todo instante, os papéis de engenheiro de software e de analista de sistemas não existem neste tipo de equipe da maneira pela qual se está acostumado a ver.
Os papéis dentro da XP são:
Customer 
É quem define o sistema. O cliente é parte ativa de uma equipe XP, pois ele deve estar a todo momento fornecendo feedback sobre o desenvolvimento, escrevendo Stories, testes de aceitação e sendo o responsável pela aprovação do sistema, iteração por iteração. Também é função deste membro da equipe decidir sobre prioridades e eventualmente decidir sobre redução no escopo da iteração a fim de que a mesma seja entregue no prazo. Ocasionalmente este papel pode apresentar uma divisão, tendo um membro exclusivamente destinado a executar e dar retorno sobre os testes de aceitação. Neste caso, o mesmo é chamado de Acceptance Tester.
Programmer
É o responsável por todo o planejamento, projeto e implementação do sistema. Entre suas principais atribuições estão: fornecer estimativas para as user stories, definir engeneering tasks a partir das mesmas, estimar estas como se fossem stories, implementar os unit tests, implementar o programa em si e assegurar que o mesmo seja aprovado em todos os testes.
Coach 
É o responsável pelo gerenciamento da equipe. Ele deve sempre motivar a equipe a não perder o foco, a não abandonar as técnicas e deve auxiliar a equipe em tudo que for possível. Ele também é o responsável pela negociação com o cliente quanto ao escopo de cada iteração e pela coordenação do planning game.
Tracker 
É o membro da equipe que faz o acompanhamento e medição das tarefas sendo implementadas, sendo responsável pelas métricas. Ele deve coletar os dados e publicar os resultados para toda a equipe e repassar qualquer problema imediatamente para o coach.
Release Plan
O Release Plan é o plano de desenvolvimento gerado a partir das sessões de planning game. Neste plano estão definidas quais as stories farão parte de cada iteração dentro da release, qual o desenvolvedor responsável por cada story e a estimativa de prazo.
Um termo importante dentro do planejamento de projetos XP é velocity. A velocity é a relação entre funcionalidades entregues e as funcionalidades planejadas por cada desenvolvedor. Para medir a velocity de cada desenvolvedor, deve ser feita a medição em uma iteração. Se um desenvolvedor não teve tempo suficiente, seu load factor foi estimado muito baixo para aquele período. Por outro lado, se ele não teve tarefas suficientes seu load factor estimado foi muito alto. Combinando o load factor de todos os desenvolvedores se obtém a velocity.
Métricas
Toda metodologia de desenvolvimento deve fornecer ao seu gerente condições para avaliar o andamento do projeto, através de medições de qualidade (tanto do produto quanto do processo de desenvolvimento) e prazos. Estas medições são conhecidas no desenvolvimento de sistemas como métricas. 
As métricas mais importantes na XP são:
Número de funcionalidades entregues comparado ao número de funcionalidades prometidas. O coach pode, durante o desenvolvimento de uma iteração, ir verificando o quão próximo do seu encerramento ela está, baseando-se na velocity de cada story. A XP prega que se deve sempre trabalhar baseado na quantidade de dias gastos até o momento e na quantidade de dias que o desenvolvedor acha que ainda vai precisar, e não com percentual de compleição da tarefa.
Velocity 
Quantidade de horas trabalhadas por semana por desenvolvedor. Esta métrica é importante para medir a qualidade interna do trabalho, pois como prega a XP trabalhar longos períodos por muito tempo é contraproducente.
40 Hour Week
Quantidade de Unit Tests por classe, também é uma métrica de qualidade interna de trabalho, pois serve para medir o quão testado está um sistema.
Test Coverage of the Code 
Quantidade de testes de aceitação do projeto como um todo.
Acceptance Test Coverage 
Percentual de testes de aceitação aprovados para cada iteração enviada, em relação ao total de testes de aceitação da mesma.
Acceptance Test Pass
Quantidade de erros encontrados pelo usuário para cada classe multiplicado pelo tempo que cada um levou para ser corrigido. Para fazer o cálculo, atribui-se pontos para cada unidade de tempo gasta. Por exemplo, 1 ponto se for corrigido em até meia hora, dois pontos se levar até 2 horas e quatro pontos por turno adicional de serviço, etc.
Baseado nestas métricas, o coach pode ajustar a qualquer momento o projeto, tanto na questão de prazos e estimativas quanto no quesito de qualidade, sugerindo um maior número de unit tests, por exemplo, se verificar que os indicadores Acceptance Test Pass e Relative Bug Density começarem a demonstrar
muitos problemas de qualidade.
Relative Bug Density 
Tracking
Tracking é o acompanhamento, a medida das métricas dentro da metodologia XP. O tracker deve, uma ou duas vezes por semana, coletar os dados relativos às métricas escolhidas para acompanhamento pelo coach e elaborar os gráficos de medida correspondentes às mesmas.
Este trabalho deve ser o menos invasivo possível, a fim de não burocratizar o processo de desenvolvimento e de não gerar perda de produtividade por parte da equipe de desenvolvedores. Por este motivo, qualquer ferramenta que auxilie o tracker na sua tarefa deve ser integrada ao dia-a-dia da equipe.
O XP tem como seus princípios básicos o feedback rápido, a simplicidade, a ideia de abraçar mudanças, fazer um trabalho de qualidade e aceitar mudanças incrementais.
Uma frase onde Vinícius Teles fala na TDC 2008 é muito interessante onde ele demonstra claramente que a simplicidade é fundamental no projeto, e a frase que ele diz é:
"Na hora do desenvolvimento do software, para aplicar os princípios e valores, o XP sugere uma série práticas porque há uma grande confiança na união entre elas pois os pontos fracos de cada uma são cobertos pelo ponto forte das outras."
As práticas são as seguintes:
O desenvolvimento é feito em iterações semanais. No início da semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades. Essa reunião recebe o nome de Jogo do Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores as estimam. O cliente é essencial neste processo e assim ele fica sabendo o que está acontecendo e o que vai acontecer no projeto. Como o escopo é reavaliado semanalmente, o projeto é regido por um contrato de escopo negociável, que difere significativamente das formas tradicionais de contratação de projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produção.
Jogos de Planejamento(Planning Game): 
A liberação de pequenas versões funcionais do projeto auxilia muito no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando. As versões chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP.
Pequenas Versões(Small Releases): 
Procura facilitar a comunicação com o cliente, entendendo a realidade dele. O conceito de rápido para um cliente de um sistema jurídico é diferente para um programador experiente em controlar comunicação em sistemas em tempo real, como controle de tráfego aéreo. É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto.
Metáforas(Metaphor): 
Simplicidade é um princípio da XP. Projeto simples significa dizer que caso o cliente tenha pedido que na primeira versão apenas o usuário "teste" possa entrar no sistema com a senha "123" e assim ter acesso a todo o sistema, você vai fazer o código exato para que esta funcionalidade seja implementada, sem se preocupar com sistemas de autenticação e restrições de acesso. Um erro comum ao adotar essa prática é a confusão por parte dos programadores de código simples e código fácil. Nem sempre o código mais fácil de ser desenvolvido levará a solução mais simples por parte de projeto. Esse entendimento é fundamental para o bom andamento do XP. Código fácil deve ser identificado e substituído por código simples
Projetos Simples(Simple Design): 
A equipe de desenvolvimento é formada pelo cliente e pela equipe de desenvolvimento.
Time Coeso(Whole Team): 
São testes construídos pelo cliente e conjunto de analistas e testadores, para aceitar um determinado requisito do sistema.
Testes de Aceitação(Customer Tests): 
Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.
Ritmos Sustentáveis(Sustainable Pace): 
Reuniões em pé para não se perder o foco nos assuntos, produzindo reuniões rápidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe.
Reuniões em pé(Stand-up Meeting): 
O código fonte não tem dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema.
Posses Coletivas(Collective Ownership): 
É a programação em par/dupla num único computador. Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de defeitos. Com isto busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado.
Programações em Pares(Pair Programming): 
A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.
Codificação(Coding Standards): 
Primeiro crie os testes unitários (unit tests) e depois crie o código para que os testes funcionem. Esta abordagem é complexa no início, pois vai contra o processo de desenvolvimento de muitos anos. Só que os testes unitários são essenciais para que a qualidade do projeto seja mantida.
Desenvolvimento Orientado a Testes(Test Driven Development): 
É um processo que permite a melhoria continua da programação, com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente. Refabricar melhora a clareza (leitura) do código, divide-o em módulos mais coesos e de maior reaproveitamento, evitando a duplicação de código-fonte;
Refatoração(Refactoring): 
Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da programação.
Integração Contínua(Continuous Integration): 
Esquema das praticas do X.P.
Comparação entre scrum e extreme programming:
O SCRUM, como é um método ágil, e os métodos ágeis acabam tendo varias semelhanças, contatos ou pontos em comum, ele tem um forte relacionamento com o XP como por exemplo, eles tem a raiz fundamentada em um manifesto ágil.
O SCRUM é uma forma de gestão ampla para projetos que não depende da área de conhecimento. Já o XP tem sua aplicação mais restrita, focada basicamente no mundo de desenvolvimento de sistemas de softwares.
Entretanto, quando usamos o SCRUM como forma de gestão e para criação de sistemas de software, muitas das práticas contidas no XP são de grande competência, como por exemplo a criação de testes automatizados ou o uso de refatoração de código para que um trecho de código funcional seja alterado buscando um ganho de qualidade e garantindo que a manutenção futura seja simplificada.
Alunos:
Felipe Augusto Martins Moura
Jorge Henrique
João Victor da Silva Couto