METODOLOGIA ÁGIL XP

Prévia do material em texto

METODOLOGIA ÁGIL XP
Bases do XP:	
O XP tem como base quatro valores: comunicação, simplicidade, feedback e coragem.
1. Comunicação: A má comunicação é motivo de insucesso em quase todo tipo de projeto, inclusive nos projetos de software. Logo, este é um dos valores mais importantes do XP, bem como das metodologias ágeis como um todo. Esta comunicação deve fluir constantemente através das técnicas a serem aplicadas no processo de desenvolvimento;
2. Simplicidade: Manter a simplicidade é difícil e é um dos princípios do XP advindos do JIT. Assim, faça a coisa mais simples que pode funcionar, mesmo assim, é um dos princípios mais difíceis de se alcançar, pois somos tentados a fazer algo complexo pensando no futuro, mas é importante lembrar que uma das filosofias do JIT é a eliminação de desperdício, assim, simplicidade é uma obrigação.
3. Feedback: Muito se fala em feedback na atualidade e aqui ele não é só necessário, como um dos princípios que fazem com que o XP tenha sucesso. Para isso, o uso do TDD passa a ser tão importante, além disso, é importante o feedback do cliente, por isso os ciclos curtos, a integração contínua etc.
4. Coragem: Este é o último valor do XP, mas não menos importante, pois é necessário ter coragem de jogar um código fora e iniciar do zero, coragem para mudanças. A comunicação nos dá coragem para a mudança, pois temos a noção das reais necessidades do cliente.
Com base nestes valores, temos os princípios do XP.
Os quatro valores geram os princípios básicos do XP, que segundo Kent Beck são:
1. Feedback rápido através de ciclos curtos (iteração de uma a duas semanas) e comunicação continua (com todos os envolvidos no processo);
2. Simplicidade presumida, onde deve-se tratar os problemas de forma simples, ou seja, evitar tratar o problema com complexidade, utilizando recursos que nunca serão utilizados, fazendo apenas o necessário;
3. As mudanças devem ser feitas de forma incremental. Grandes modificações normalmente trazem grandes problemas, então tratar a mudança com ciclos de mudanças curtos é mais eficiente e atende as bases sistêmicas do paradigma.
4. Alta qualidade: ninguém gosta de pessoas desleixadas, então a qualidade deve ser sentida não só pelo cliente, mas pela equipe. O teste não é uma opção, é uma obrigação.
Dos princípios e valores, temos então as quatro atividades básicas que é codificar, testar, ouvir e projetar.
Para atender aos seus princípios e valores durante as atividades, o XP utiliza práticas simples, como veremos a seguir e também na Figura 1.
Figura1.Práticas XPPráticas Organizacionais
Práticas em Equipes
Práticas em pares
· Jogo de planejamento: é a prática que define o escopo a ser desenvolvido na próxima iteração. Para esta definição de escopo é necessário priorizar as necessidades de negócio (ponto de vista do cliente) em conjunto com as estimativas técnicas (ponto de vista dos programadores). Se o planejamento for falho, atualize-o;
· Entregas frequentes: Durante a iteração de uma ou duas semanas, o que estiver com status de pronto deve ser entregue ao cliente, assim, a equipe recebe o feedback mais rapidamente. Não espere todo o projeto estar concluído, entregue frequentemente;
· Uso de metáforas: as metáforas devem guiar o desenvolvimento, através das histórias de usuário simplificada e compartilhada com todos; A intenção da metáfora é oferecer uma visão geral do sistema, em
· um formato simples, que possa ser compartilhada por clientes e programadores. Uma analogia entre o sistema que está sendo desenvolvido e um sistema, não necessariamente de software, que todos entendam, com o objetivo de obter um “vocabulário comum” para a posterior criação de nomes de classes, subsistemas, métodos, etc. 
Um exemplo de metáfora pode ser visto em, onde o sistema C3 payroll de folha de pagamento é descrito como uma linha de montagem onde várias partes referentes às horas trabalhadas vão sendo montadas até construir o cheque de pagamento do funcionário. A metáfora conforme dito em também pode ser vista como uma forma simples de arquitetura do sistema, numa linguagem compreensível tanto por clientes como programadores.
· Projeto simplificado: Quanto mais simples for o projeto, mais rápido é seu desenvolvimento. Complexidades desnecessárias devem ser removidas sempre que forem descobertas, isso mantém o ritmo e a qualidade do produto;
· Testes: Tudo deve ser testado: programadores devem utilizar as práticas de TDD ( Desenvolvimento Orientado por Testes )para melhorar a qualidade do produto;
· Refatoração: Outra prática necessária para melhorar o design e a qualidade do produto. Reestruturar o sistema, sem alterar o seu comportamento, removendo sempre que possível a duplicidade, melhorando e simplificando o que já existe e tornando-o mais flexível;
· Programação em pares: o desenvolvimento é guiado pela programação em par, ou seja, todo o sistema é implementado por dois programadores em uma única máquina (Um escreve e outro observa e verifica se tem erro);
· Propriedade coletiva: os códigos não têm um dono, ou seja, viu que precisa melhorar (refatorar)? Faça você mesmo e não espere pelos outros, pois todos podem modificar qualquer parte do código a qualquer momento;
· Integração contínua: se temos que entregar constantemente, é através da integração contínua que atingiremos este objetivo. Integre e atualize as versões do sistema várias vezes ao dia, cada vez que uma nova tarefa for concluída;
· Ritmo sustentável: A semana deve ser de 40 horas no máximo, ou seja, trabalhe no máximo oito horas por dia durante quatro dias, evite fazer hora extras, pois a produtividade é reduzida;
· Cliente presente: Precisamos de comunicação constante, desta forma, inclua sempre um cliente real no time;
· Padrões de codificação: Utilize padrões, assim os programadores escreverão seus códigos respeitando as regras e isso cria uma comunicação através do código.
Implementando o XP
O funcionamento do XP é simples, através do plano de planejamento, realizado com o Jogo de planejamento, realiza a iteração.
Na iteração é criado primeiro os testes e feita a codificação, é refatorado o código (prática denominada TDD), conforme pode ser visto na Figura 2.
Figura 2. Funcionamento do XP
A adoção do XP pode iniciar pelo TDD, prática que busca melhorar a qualidade e design do sistema e depois pelo jogo de planejamento, assim a equipe vai acostumando-se com as novas práticas. As práticas explanadas anteriormente proporcionam resultados quase que imediatos na qualidade geral do produto e a cada iteração a equipe torna-se mais extrema, até conseguir implementar o XP por completo.
A equipe XP é composta de dois a 10 (podendo ser 12, por exemplo) desenvolvedores. Conforme Beck, XP foi desenvolvida para funcionar em projetos com times de dois a 10 programadores, que não sejam severamente restringidos pelo ambiente computacional existente e nos quais boa parte da execução de testes possa ser feito em uma fração de dia. Por isso, evite equipes muito grandes.
Equipes com mais de 12 integrantes devem ser divididas em duas equipes, pois a comunicação começa a reduzir. Aqui entra um dos preceitos da agilidade: passar a valorizar mais os indivíduos e as interações entre eles mais do que processos e ferramentas (Manifesto Ágil), assim, equipes pequenas tem maior possibilidade de interagir entre si. Além disso, equipes menores são mais produtivas, segundo Cohn, equipes menores demandam menos esforço total para entregar um projeto de mesmo tamanho.
Ciclo de vida XP
O início do ciclo de vida XP se dá através da exploração, em que há um contato inicial da equipe com o que será desenvolvido, do programador com a tecnologia, do cliente com a escrita das histórias de usuário, etc.
É nessa fase em que as primeiras histórias de usuário são levantadas e o projeto arquitetônico da aplicação é iniciado. As histórias de usuário são frases curtas escritas pelo cliente que explica uma funcionalidade que o software deve ter (HENRAJANI, 2007). Ainda na fase de exploração são levantados os requisitos e implementados oscenários de teste. Os cenários de testes serão utilizados na fase de manutenção e antes da fase de produção. Já os requisitos por sua vez serão abordados durante os planos de versão.
A partir da exploração, vem a fase de planejamento, que tem como propósito definir, através de um acordo entre cliente e programador, o tempo de desenvolvimento, quais histórias tem maior e menor valor para o cliente e quais as dificuldades para se desenvolver tais histórias.
Na etapa de planejamento é feito o planejamento da iteração e as estimativas do sistema.
Com o plano pronto, se segue para a próxima fase, que é a iteração. Ela dura de uma a quatro semanas, segundo Back (alguns autores preferem de uma a duas semanas).
A primeira iteração normalmente é para a definição de arquitetura, assim, é importante que a equipe escolha as histórias que permitam criar o esqueleto do sistema como um todo na primeira iteração. Já nas iterações posteriores, desenvolve-se as histórias que tenham maior valor de negócio para o cliente.
Durante a iteração, ou seja, o ciclo de produção do sistema, é o momento em que o programador utiliza as práticas como TDD, integração contínua, teste de aceitação etc., buscando, neste ponto, ser eXtremo.
Ser eXtremo, no conceito do XP, é tornar as melhores práticas como um item obrigatório e não opcional, ou seja, a equipe vai garantir a qualidade, vai integrar continuamente, vai manter um feedback constante, vai possuir comunicação com o cliente etc. Isso ocorre, pois as práticas, se utilizadas em conjunto, resultam em produtos de alta qualidade e poucos defeitos, evitando-se assim o retrabalho, pois há provas de que o TDD leva a menos defeito. 
O XP busca a excelência técnica obrigatória para melhoria contínua do processo e esta faz com que a equipe torne-se perita nas melhores práticas de desenvolvimento, ou seja, torne-se extrema.
Papéis no XP
Em XP cada colaborador do projeto é parte da Equipe.
É um hábito antigo a separação por papéis e um bom treinador sabe inserir seu jogador na posição correta. No XP não é diferente, há papéis para os membros da equipe. São eles:
· Programador: segundo Back, ele é o coração do XP, pois o principal foco é a implementação. A diferença entre um programador em outras metodologias e no XP é que aqui ele precisa se preocupar com a comunicação, com o design do sistema, com os testes unitários, com ser eXtremo.
· Cliente: Se o programador é quem implementa, o cliente é quem sabe o que deve ser implementado, ou seja, é quem conhece o produto. O título de cliente é dado a pessoa responsável por escrever as histórias de usuário, por defender os interesses do cliente, por saber dar valor as histórias (valor do ponto de vista de importância ao negócio).
· Testador: Como o programador já fez os testes unitários, a tarefa do testador está relacionada aos testes funcionais e por sua execução frequente.
· Rastreador: Back afirma que o rastreador é a consciência da equipe, sendo o responsável por finalizar a iteração, por uma visão global do andamento do sistema, etc. Este papel necessita de habilidade de coleta de informação e boa comunicação interpessoal.
· Treinador: Assim como no vôlei temos um treinador, equipes XP possuem um treinador que é o responsável pelo processo como um todo e por manter o XP funcionando.
· Consultor: Não é obrigatório, mas quando há necessidade, equipes XP podem chamar um consultor ad hoc.
· O Chefão: este é o manda chuva, quem manda em tudo...
Ninguém tem maior importância no grupo, mas todos tem suas atribuições e devem buscar a qualidade total dos seus processos. O programador deve especializar-se na sua tarefa e deve ainda cultivar as boas práticas, como o uso de Design Patterns etc. Só assim a equipe vai se tornar uma equipe XP, uma equipe eXtrema.
A equipe XP mantém o sistema integrado e funcionando o tempo todo. Programadores escrevem todo o código de produção em pares, todos trabalham em conjunto para a excelência do produto. Eles codificam em um estilo consistente para que todos possam entender e melhorar todo o código conforme necessidade da equipe. O cliente mantém os programadores informados sobre suas necessidades, o treinador mantém a equipe coesa e o testador valida as funcionalidade. Tudo para que o resultado seja de alta qualidade.
Segundo Tenório e Valle, os processos dominantes no desenvolvimento de software foram: nas décadas de 60, 70 e 80 os Processos proprietários; entre 80 e 90 o CMM; entre 90 e 2000 o PMI, Asap, RUP e ISO; e neste século: XP, ASD e LD (2013).
Um ponto importante é que o XP pode ser implementado em conjunto com outras metodologias ágeis, como o Scrum, pois ambas seguem as bases do manifesto ágil:
· Os indivíduos e as interações são mais importantes do que os processos e as ferramentas;
· O software funcionando é mais importante do que uma documentação completa;
· A colaboração com os clientes está acima das negociações de contratos e;
· Respostas a mudanças estão acima de apenas seguir um plano.
Bibliobrafia:
https://www.devmedia.com.br/integrando-xp-as-principais-metodologias-ageis/30989
Referências
· BECK, Kent. et. al. MANIFESTO ÁGIL. 2001.
· BECK, Kent. Programação extrema explicada: acolha as mudanças. Porto Alegre: Bookman, 2010.
· COHN, Mike. Desenvolvimento de Software com Scrum: Aplicando métodos ágeis com sucesso. Porto Alegre:Bookman, 2012.
· COURTOIS, Alain; PILLET, Maurice; MARTIN-BONNEFOUS, Chantal. Gestão da Produção: para uma gestão industrial ágil, criativa e cooperante. Lisboa: Lidel, 2007.
· PRESSMAN, Roger S. Engenharia de Software. São Paulo: Campus, 1995.
· SLACK, Nigel; CHAMBERS, Stuart; JOHNSTON, Robert. Administração da produção. São Paulo: Atlas, 2009.
· SOMMEVILLE,Ian; Engenharia de software.8º. ed. São Paulo: Addison Wesley, 2007.
· TENÓRIO; Fernando G., VALLE; Rogerio. Fábrica de Software. Rio de Janeiro: Editora FGV, 2013.