1

XP Extreme Programming

#Desperte o potencial #Boas práticas
Rosemeire Deconti
Rosemeire Deconti

Introdução

Durante a Aceleração Global Dev #10 GFT ouvi falar sobre extreme programming. Como o tema foi novo para mim fiz pesquisas e compartilho o resultado com vocês.


Como de costume ao final deste artigo estão as referências que utilizei para criar este texto. Também utilizei muitas informações obtidas na Aceleração Global Dev #9 Avanade ocorrida em 12/06/2021.


Bons estudos e persistência para que o sucesso ser alcançado!


Neste link vocês encontram todos os artigos que publiquei na Digital Innovation One


Digital Innovation One - Lista de artigos publicados na DIO


Extreme programming = XP

XP é um apelido carinhoso de uma nova metodologia de desenvolvimento designada Extreme Programming, com foco em agilidade de equipes e qualidade de projetos, apoiada em valores como simplicidade, comunicação, feedback e coragem que nos submetem ao reconhecimento de que XP é uma metodologia baseada em comportamentos e atitudes.


AS BOAS PRÁTICAS DE XP


The Customer is Always Available (O cliente sempre disponível): Constante disponibilidade do cliente para colaborar em dúvidas, alterações, e prioridades em um escopo, ou seja, dando um dinamismo ativo ao projeto.


Metaphor (Uso de metáforas no projeto): Visando facilitar a comunicação da equipe, caso seja possível, é estabelecido o uso de metáforas em pontos chaves ao projeto como, por exemplo, a definição de um nome que seja comum à equipe e simbolize algo de fácil assimilação como, por exemplo: "Vamos chamar nosso projeto de "cartão de ponto", para um sistema que gerencie as batidas de ponto de funcionários, gerando o provisionamento financeiro e mensal para módulo de folha de pagamento".


Planning Game (Planejando o jogo): Entre o cliente e os técnicos são estimuladas reuniões usando quadros brancos, com o objetivo de captar e definir as "user stories" (estórias, que são textos claros ou diagramas com notação UML com as especificações de regras de negócios inerentes ao sistema) e também para poder estimar o tempo ideal das interações, o projeto como um todo, elaborar estratégias e tentar prever as contingências para projeto.


Small Releases (Pequenas versões): Conforme as interações são concluídas, o cliente recebe pequenas versões/releases do sistema, visando com que seja colocado em prática e validado aquilo que está sendo implementado. Isto também permite que mais cedo possam ser detectadas necessidades de alterações de requisitos no software.


Acceptance Tests (Testes de Aceitação): São definidos pelo usuário na fase inicial do projeto e são os critérios de aceitação do software conforme a estratégia de entrega e representa exatamente a métrica de aderência do software desenvolvido/implantado ao universo do cliente.


Test First Design (Primeiro os testes): Aplicados a partir de testes unitários do código produzido, além de serem preparados utilizando os critérios de aceitação definidos previamente pelo cliente. Garante também a redução de erros de programação e aumenta a fidelidade do código produzido ao padrão estabelecido para o projeto. Através da prática de testes unitários, definimos antes da codificação os testes dos métodos críticos do software ou métodos simples que podem apresentar alguma exceção de processamento.


Continuous Integration (Integração Contínua): Os diversos módulos do software são integrados diversas vezes por dia e todos os testes unitários são executados. O código não passa até obter sucesso em 100% dos testes unitários, facilitando, dessa forma, o trabalho de implementação da solução.


Simple Design (Simplicidade de Projeto): O código está, a qualquer momento, na forma mais simples e mais clara, conforme os padrões definidos pela equipe de desenvolvimento, facilitando a compreensão e possível continuidade por qualquer um de seus membros.


Refactoring (Refatoração - melhoria constante do código): A cada nova funcionalidade adicionada, é trabalhado o design do código até ficar na sua forma mais simples, mesmo que isso implique em "mexer" em um código que esteja em funcionamento. Claro que a prática de refatoração nem sempre é aceita, pois envolve questões como prazo e custo. Além disso, e essa prática em si pode ser minimizada caso o projeto esteja usando 100% de orientação a objeto, onde podemos criar códigos os mais genéricos e reutilizáveis possíveis, diminuindo o trabalho em caso de uma possível refatoração.


Pair Programming (Programação em dupla): Todo código de produção é desenvolvido por duas pessoas trabalhando com o mesmo teclado, o mesmo mouse e o mesmo monitor, somando forças para a implementação do código. À primeira vista pode parecer loucura, pois se imagina estar gastando dois recursos humanos ao mesmo tempo para fazer a mesma tarefa e sem possibilidade de avanço substancial no projeto. Mas na verdade, essa prática tem pontos positivos como:

  • Compartilhamento de conhecimento sobre das regras de negócio do projeto por todos da equipe de desenvolvimento;
  • Fortalece a prática de Propriedade Coletiva do Código;
  • Nivelação de conhecimento técnico dos programadores;
  • Elevação dos níveis de atenção ao código produzido, pois um “supervisiona” e orienta o trabalho do outro. Dessa forma, minimiza-se a possibilidade de erros no código, erros de lógica e produção de um código fora dos padrões estabelecidos pela equipe.


Move People Around (Rodízio de pessoas): As duplas de programação são revezadas periodicamente, com o objetivo de uniformizar os códigos produzidos, deixar todos os módulos do sistema com mesmo padrão de código/pensamento e compartilhar o código com todos da equipe.


Collective Code Ownership (Propriedade coletiva - O código é de todos da equipe): Uma vez aplicados a Programação em Dupla e o Rodízio de Pessoas, a equipe como um todo é responsável por cada arquivo de código. Não é preciso pedir autorização para alterar qualquer arquivo, mantendo claro, um padrão prático de comunicação da equipe.


Coding Standards (Padronização do código): Todo código é desenvolvido seguindo um padrão, qualquer que seja, mas toda equipe deve seguir o mesmo padrão. Dessa forma, todos da equipe terão a mesma visão do código.


40 Hour Week (Otimizando as jornadas de trabalho): Trabalhar por longos períodos é contraproducente. Portanto, sempre que possível, deve-se evitar a sobrecarga de trabalho de todos da equipe, criando condições favoráveis ao uso da carga normal de trabalho. É necessário deixar a equipe livre para relaxar, brincar, ou fazer o que bem entender para equilibrar o trabalho mental e físico.

Existe até uma frase que diz: trabalhe a 100% durante as 40 horas e descanse a 100% no resto. Se algum deles não for feito com 100%, um afetará o outro.


Referências

Programação extrema – Wikipédia, a enciclopédia livre (wikipedia.org)

Extreme programming - Wikipedia

Extreme Programming (XP): o que é e seus benefcios (objective.com.br)

eXtreme Programming: Conceitos e Práticas sobre eXtreme Programming (devmedia.com.br)

Extreme Programming Rules

0
12

Comentários (0)

Apaixonada por tecnologia e informação. Na área desde 1.984 e sem previsão de parada.

Brasil