2
Giovane Mendes Costa
INTRODUÇÃO
• A indústria de software passou por grandes transformações e
grandes desafios, entre eles, desenvolver software com qualidade no menor tempo possível;
• Nesse período a Engenharia de Software passa a ser valorizada com o intuito de ajudar a aumentar a qualidade dos softwares e atender as exigências do mercado;
• Apesar da adoção de técnicas de Engenharia de Software, ainda
eram poucos os projetos que conseguiam obter sucesso e respeitar os prazos e orçamentos previstos.
INTRODUÇÃO
• Pesquisa realizada pelo Standish Group International em 1994,
apontava que apenas 16,2% dos projetos, obtinha sucesso levando em conta: prazo, orçamento e necessidades atendidas;
• Em 2002, após a adoção da Engenharia de Software, o percentual dos projetos que obtiveram sucesso subiu para 34%, ou seja, aumento de mais de 100% em oito anos;
• Os principais motivos para baixa taxa de sucesso:
• Tempo elevado em cada fase do projeto, não acompanhado as mudanças dos requisitos;
• Falta de conhecimento da sua real necessidade por parte do cliente; • Linearidade no desenvolvimento do projeto;
O QUE É XP?
• Sigla para Extreme Programming;
• Metodologia Desenvolvida na década de 90 por Kent Beck;
• É uma Metodologia de Desenvolvimento com foco na Agilidade;
• Baseia-se em valores como: simplicidade, comunicação, feedback e coragem;
• Enfatiza o trabalho em equipe, onde, gerentes, clientes e desenvolvedores são todos parceiros iguais em uma equipe colaborativa;
• Concebida com o intuito de desenvolver software difícil, de qualidade e no prazo combinado.
O QUE É XP?
• Kent definiu XP como: “Uma maneira leve, eficiente, de baixo risco, flexível, previsível, científica e divertida de desenvolver software”;
• Assemelha-se a um enorme quebra-cabeças, onde pequenas peças formam uma grande imagem;
• Valoriza a utilização de boas práticas e valores e não apenas algumas ideias e mudanças;
FLUXOGRAMA
PARTICULARIDADES
• Feedback antecipado, concreto e contínuo pelos ciclos curtos;
• Sua abordagem incremental de planejamento gera um plano geral para evoluir com o decorrer do projeto;
• Implementação de forma flexível das funcionalidades, respondendo às necessidades do projeto;
• Monitoramento dos testes visando o progresso do desenvolvimento e permitindo a detecção de erros de forma rápida;
• Confiança na colaboração dos desenvolvedores com habilidades comuns;
• Práticas que combinam com os instintos de curto prazo dos programadores com os interesses de longo prazo do projeto.
COMO FAZER XP?
• A XP foi desenvolvida para ser aplicada em projetos com times de 2 a 10 programadores;
• Os colaboradores não precisam estar restringido pelo ambiente computacional.
• A execução e os testes devem ser realizados em pouco tempo no dia; • Apesar de irritar algumas pessoas, todas as técnicas da XP são tão velhas quanto a própria programação;
VALORES
• Os valores são as diretrizes da XP, eles ajudarão a guiar a equipe e ajudar a decidir as prioridades da metodologia;
• Para um projeto utilizar XP, ele deverá respeitar e seguir todos os valores;
• Caso alguns dos valores não sejam seguidos, isso implicará em dizer que o projeto não utiliza XP;
• Os valores utilizados pela XP são: • Feedback;
• Comunicação; • Simplicidade; • Coragem.
FEEDBACK
• O cliente aprende com o sistema que utiliza e assim pode sugerir à equipe modificações e reavaliar suas necessidades;
• O cliente conduz o desenvolvimento do seu produto, estabelece e informa aquilo que é realmente importante;
• O desenvolvedor retorna ao cliente o seu entendimento sobre o que o cliente deseja, informando-o sobre os riscos, estimativas e sugerindo alternativas;
• O cliente deve está em contato permanente com a equipe, principalmente depois do último feedback passado.
COMUNICAÇÃO
• Para que o Feedback seja possível é necessário uma boa comunicação;
• A XP prega que essa comunicação deve ser feita de forma direta e eficaz, agilizando os assuntos a serem tratados;
• É recomendado que essa comunicação seja feita face-a-face, evitando mal entendidos e dúvidas entre as partes;
• Para que isso seja possível é necessária a disponibilização do cliente ou a presença do mesmo no ambiente de trabalho;
• A comunicação agiliza o processo além de fortalecer o relacionamento interpessoal;
• Pessoas introvertidas não são aconselháveis para as equipes de XP.
SIMPLICIDADE
“Se simplicidade é bom, sempre deixe o sistema com o projeto mais simples que suporte a funcionalidade atual”.
• É necessária desde o primeiro momento com o cliente para que ele possa aprender e conseguir dar o feedback necessário à equipe;
• Ser simples não é o mesmo que ser fácil. Nem sempre a solução mais simples será a mais fácil de ser implementada.
• Codificar com simplicidade significa deixar o código mais legível para que qualquer outro membro da equipe possa dar continuidade;
• Simplicidade significa codificar o necessário para que um requisito seja atendido e entregue ao cliente;
• Neste processo, a simplicidade também deve ser respeitada pelo cliente;
CORAGEM
• Ser um cliente XP não é fácil.
• O programador sabe como programar e o cliente deve saber o que programar.
• O cliente precisa saber tomar decisões. Dizer o que é mais
importante, o momento de realizar uma modificação e o momento de mudar de ideia.
• O programador precisa de coragem para modificar qualquer parte do código que não tenha sido implementada por ele;
• O programador precisa de coragem para dizer “não” quando
necessário, ou dizer que o projeto vai demorar mais do que o estimado por causa das novas solicitações;
CORAGEM
• O processo de desenvolvimento requer coragem para: • Desenvolver de forma incremental;
• Manter o sistema simples;
• Fazer os desenvolvedores trabalharem em pares; • Expor códigos a todos os membros da equipe; • Propor adoção de um novo processo;
• Colocar desenvolvedores e clientes frente-a-frente; • Apostar em seus colaboradores aumentando a sua responsabilidade;
PRÁTICAS
“Os valores somados às Práticas formam um conjunto de atividades que devem ser seguidas pela equipe que desejar usar XP”.
• Cliente presente ou disponível; • Jogo de Planejamento;
• Stand up Meeting;
• Programação em dupla; • Refactoring;
• Desenvolvimento guiado por testes; • Código coletivo;
PRÁTICAS
• Design simples; • Metáfora; • Ritmo sustentável; • Integração contínua; • Releases curtosCLIENTE PRESENTE
OU DISPONÍVEL
“A ausência do cliente pode significar sérios riscos ao projeto”
• O XP prega que o cliente faz parte do processo de desenvolvimento do projeto e por isso deve estar envolvido em todas as etapas;
• Estórias são bem vindas quando visam ilustrar o entendimento de cada funcionalidade.
• Na presença do cliente a validação do entendimento do requisito pode ser realizada e a equipe pode receber o feedback necessário, criando ciclos rápidos e precisos.
JOGO DE PLANEJAMENTO
• Assegura que a equipe gastará maior tempo naquilo que gere o máximo de valor para o cliente;
• É o momento em que o cliente solicita as funcionalidades através de estórias e a equipe estima o custo de cada uma;
• A equipe estima o tempo para que o cliente priorize o que é necessário;
• A XP utiliza uma unidade de medida chamada Ponto, que refere-se a um dia de trabalho ideal do desenvolvedor;
STAND UP MEETING
• Reunião rápida pela manhã;
• Duração de cerca de 20 minutos; • Preferencialmente em pé;
• Objetiva atualizar a equipe sobre o que foi implementado no dia anterior e trocar experiências a cerca dos problemas enfrentados; • Durante a reunião é decidida as estórias a serem implementadas, bem como os responsáveis por cada uma delas;
PROGRAMAÇÃO EM DUPLA
• A XP exige que todo e qualquer código implementado no projeto seja efetuado em dupla;
• Evita a demora na detecção e correção dos erros;
• Facilita a troca de experiências, sugestão de soluções, conhecimento das regras de negócio e o nivelamento de conhecimento entre a dupla; • O desenvolvedor que não está utilizando o teclado e mouse
supervisiona e revisa o código do parceiro;
• Apesar de parecer perda de recurso, o método pair programming é preferido por cerca de 90% dos desenvolvedores;
REFACTORING
• Ao contrário de outras metodologias, a XP prega que todo código mal escrito, duplicado, lento ou sem padronização deve ser alterado;
• Todo programador que encontrar este tipo de código deve realizar as alterações necessárias sem modificar o comportamento do mesmo; • Todo programador tem a possiblidade de melhorar o código;
DESENVOLVIMENTO
GUIADO POR TESTES
• Todo código implementado deve coexistir com um teste automatizado;
• Garante o pleno funcionamento da nova funcionalidade;
• É baseado nesses testes que o desenvolvedor terá coragem para modificar um código já existente;
• São separados em dois tipos: Teste de Unidade e de Aceitação;
• O teste de unidade verifica se cada resultado gerado por uma classe está correto;
• O teste e aceitação verifica se o resultado de uma classe atende a uma funcionalidade de forma correta.
CÓDIGO COLETIVO
“A parte do projeto de responsabilidade de uma única pessoa impossibilita que outra torne-se conhecedora da mesma”.
• Ao contrário do modelo tradicional, onde é comum dividir tarefas e delegar responsáveis por cada uma delas, a XP não responsabiliza pessoas unitárias;
• A programação em dupla torna possível o rodízio de desenvolvedores
bem como o conhecimento do código;
• Todo dupla tem acesso e liberdade para alterar qualquer parte do código a qualquer momento sem qualquer tipo de aviso;
• Essa prática torna o código revisado e caso não esteja claro torna possível o refactoring.
PADRÕES DE
DESENVOLVIMENTO
• Todo o código desenvolvido pela equipe, deve ser padronizado; • A padronização deve ser definida desde do início do projeto;
• Cada dupla deve conseguir ler e interpretar o código de forma rápida; • Recomenda-se que utilize-se a padronização da comunidade da
linguagem de desenvolvimento;
• O código deve parecer que foi escrito por uma única e competente pessoa;
DESIGN SIMPLES
• Assim como tudo em XP, o design do projeto deve ser o mais simples possível;
• Evita que o custo de uma alteração no sistema cresça exponencialmente ao longo do projeto;
• Evita especulações e implementações que não terão utilidades para o cliente;
• Em XP, o custo de uma alteração deve crescer lentamente e se estabilizar ao longo do projeto;
• Os avanços nas linguagens, as práticas de desenvolvimento, a orientação à objetos e os ambientes de desenvolvimento ajudam a deixar o código mais simples, legível e passível de alteração a
METÁFORA
“Falar as coisas assim como elas são nem sempre ajudam a entender. É necessário utilizar Metáforas”.
• Em XP o uso de metáforas é tratado como obrigação;
• Evite repetir a mesma coisa várias vezes, a utilização de analogias facilita o entendimento das pessoas;
• As analogias ajuda a fixar os assuntos entre as partes;
• Criar boas metáforas exige criatividade e desenvolvimento de ideias, esteja bem condicionado fisicamente e mentalmente para realizar tias atividades;
RÍTMO SUSTENTÁVEL
“Trabalho deve ser deixado no trabalho! Trabalhe a 100% durante as 40 horas e descanse a 100% no resto”.
• A maioria dos projetos não são finalizados a tempo;
• Desenvolvedores são levados a trabalharem até tarde e sacrificarem seus finais de semana;
• Sobrecarga de trabalho gera perda de concentração, queda de rendimento, aumento no índice de erros dos desenvolvedores; • XP proíbe que os desenvolvedores trabalhem até tarde;
• Sugere um ritmo sustentável de 40h semanais; • Visa o bem-estar físico e mental da equipe.
INTEGRAÇÃO CONTÍNUA
• O projeto é divido em módulos;
• Cada módulo do projeto deve estar interligado com os demais; • Os módulos não devem ser responsabilidades individualizadas; • Módulos individualizados são mais propícios a erros de integração; • Compilações devem ser realizadas várias vezes ao dia;
RELEASES CURTOS
• Assim que as integrações vão sendo realizadas, novas versões (releases) do projeto vão sendo entregues ao cliente;
• Facilita a detecção de novas funcionalidades;
• Agiliza a detecção de falhas pois vão sendo avalidadas no mesmo momento;
• Visam gerar valor econômico imediato ao cliente, já que na maioria dos casos o cliente só começa a ter benefícios do sistema quando ele já está quase finalizado.
EQUIPE XP
“Em uma equipe XP existem papeis a serem desempenhados por um ou mais desenvolvedores”.
Gerente de Projeto: Responsável pelos assuntos administrativos e por
manter um forte relacionamento com o cliente e a equipe. Ele deve filtrar os assuntos sem importância aos desenvolvedores bem como as
implementações futuras;
Coach: Responsável pelas questões técnicas do projeto bem como os processos de desenvolvimento, valores e práticas de XP;
EQUIPE XP
Analista de Teste: Responsável por garantir a qualidade do sistema através de testes escritos. Ele deve ajudar o cliente a escrever os casos de testes e no final de cada iteração verificar se o software atende todos os casos de testes
.
Recomenda-se que esta pessoa não seja um desenvolvedor, para evitar uma visão tendenciosa já que não conhece o código desenvolvido. O analista de teste deve ter uma visão muito parecida com a do cliente e em muitos projetos esta pessoa acaba exercendo o papel de redator técnicoRedator Técnico: Pessoa responsável em documentar o sistema, evitando um forte trabalho dos desenvolvedores neste tipo de atividade, permitindo uma maior dedicação ao trabalho de codificação.
Esta pessoa deve estar em plena sintonia com os desenvolvedores e cliente para que a documentação reflita o código escrito e as regras de
EQUIPE XP
Desenvolvedor: Pessoa responsável em analisar, projetar e codificar o sistema. No XP não existe diferença entre analista, projetista e programador uma vez que em vários momentos do projeto o desenvolvedor estará exercendo alguma destas atividades.
Naturalmente existem níveis distintos de desenvolvedores dentro de uma equipe, mas com as práticas do XP, como pair programming, a tendência é a equipe se tornar uniforme em suas habilidades.
