12/07/2018      Inovação

Metodologia ágil: Introdução ao Extreme Programming (XP)


Extreme Programming (XP) é um framework ágil de desenvolvimento de software que visa produzir software de maior qualidade e maior qualidade de vida para a equipe de desenvolvimento. O XP é o mais específico dos frameworks ágeis em relação às práticas de engenharia apropriadas para o desenvolvimento de software.

 

Quando é aplicável

As características gerais em que o XP é apropriado foram descritas por Don Wells em www.extremeprogramming.org:

• Alterar dinamicamente os requisitos de software

• Riscos causados por projetos de tempo fixo usando novas tecnologias

• Equipe de desenvolvimento pequena e co-localizada

• A tecnologia que você está usando permite testes unitários e funcionais automatizados

Devido à especificidade do XP quando se trata do conjunto completo de práticas de engenharia de software, existem várias situações em que você pode não querer praticar totalmente o XP. O post When is XP Not Appropriate no C2 Wiki é provavelmente um bom lugar para começar a encontrar exemplos onde você pode não querer usar o XP.

Embora você não possa usar toda a estrutura do XP em muitas situações, isso não deve impedi-lo de usar o maior número possível de práticas, considerando seu contexto.

 

Valores

Os cinco valores do XP são comunicação, simplicidade, feedback, coragem e respeito e são descritos com mais detalhes abaixo.

Comunicação

O desenvolvimento de software é inerentemente a um esporte de equipe que depende da comunicação para transferir conhecimento de um membro para todos os outros da equipe. O XP enfatiza a importância do tipo apropriado de comunicação - discussão face a face com o auxílio de um quadro branco ou outro mecanismo de desenho.

Simplicidade

Simplicidade significa "o que é a coisa mais simples que funcionará?" O objetivo é evitar o desperdício e fazer apenas coisas absolutamente necessárias, como manter o projeto do sistema o mais simples possível, para que seja mais fácil manter, suportar e rever.

Simplicidade também significa endereçar apenas os requisitos que você conhece; não tente prever o futuro.

Feedback

Através de feedback constante sobre seus esforços anteriores, as equipes podem identificar áreas para melhoria e revisar suas práticas. O feedback também suporta design simples. Sua equipe cria algo, reúne feedback sobre seu design e implementação e ajusta seu produto daqui para frente.

Coragem

Kent Beck definiu coragem como “ação efetiva diante do medo” (Extreme Programming Explained, p. 20). Essa definição mostra uma preferência por ações baseadas em outros princípios para que os resultados não sejam prejudiciais para a equipe. Você precisa de coragem para levantar questões organizacionais que reduzem a eficácia da sua equipe. Você precisa de coragem para parar de fazer algo que não funciona e tentar outra coisa. Você precisa de coragem para aceitar e agir sobre o feedback, mesmo quando é difícil de aceitar.

Respeito

Os membros de sua equipe precisam respeitar uns aos outros para se comunicar uns com os outros, fornecer e aceitar feedback que honre seu relacionamento e trabalhar juntos para identificar projetos e soluções simples.

 

Práticas

O núcleo do XP é o conjunto interconectado de práticas de desenvolvimento de software listadas abaixo. Embora seja possível fazer essas práticas isoladamente, muitas equipes descobriram que algumas práticas reforçam as outras e devem ser feitas em conjunto para eliminar completamente os riscos que você enfrenta frequentemente no desenvolvimento de software.

As práticas de XP mudaram um pouco desde que foram introduzidas inicialmente. As doze práticas originais estão listadas abaixo. Se você quiser mais informações sobre como essas práticas foram originalmente descritas, visite http://ronjeffries.com/xprog/what-is-extreme-programming/.

• Planejar jogando

• Pequenos lançamentos

• Metáfora

• Design simples

• Teste

• Refatoração

• programação em par

• Propriedade Coletiva

• Integração contínua

• 40 horas por semana

• Cliente no local

• Padrão de Codificação

 

Abaixo estão as descrições das práticas descritas na segunda edição do Extreme Programming Explained Embrace Change. Essas descrições incluem refinamentos baseados em experiências de muitos que praticam programação extrema e refletem um conjunto mais prático de práticas.

 

Sente junto

Como a comunicação é um dos cinco valores do XP, e a maioria das pessoas concorda que a conversa face a face é a melhor forma de comunicação, faça com que sua equipe se junte no mesmo espaço sem barreiras à comunicação, como as paredes dos cubículos.

 

Equipe inteira

Um grupo multifuncional de pessoas com as funções necessárias para um produto formam uma única equipe. Isso significa que as pessoas com uma necessidade, assim como todas as pessoas que desempenham algum papel na satisfação, precisam trabalhar em conjunto diariamente para realizar um resultado específico.

 

Espaço de trabalho informativo

Configure o espaço da sua equipe para facilitar a comunicação face a face, permitir que as pessoas tenham alguma privacidade quando precisarem e tornar o trabalho da equipe transparente entre si e para as partes interessadas fora da equipe. Utilize os canais de Informações para comunicar ativamente informações atualizadas.

 

Trabalho Energizado

Você é mais eficiente no desenvolvimento de software e em todo o trabalho de conhecimento quando está concentrado e livre de distrações.

O trabalho energizado significa tomar medidas para garantir que você seja capaz física e mentalmente de entrar em um estado focado. Isso significa que você não se sobrecarrega (ou deixa os outros trabalharem demais). Isso também significa manter-se saudável e mostrar respeito aos seus colegas de equipe para mantê-los saudáveis.

 

Programação em par

Programação em par significa que todo o software de produção é desenvolvido por duas pessoas sentadas na mesma máquina. A ideia por trás dessa prática é que dois cérebros e quatro olhos são melhores que um cérebro e dois olhos. Você obtém efetivamente uma revisão contínua de código e uma resposta mais rápida a problemas incômodos que podem impedir que uma pessoa morra em suas trilhas.

As equipes que usaram programação em par descobriram que isso melhora a qualidade e não ocupa o dobro do tempo, pois elas são capazes de solucionar problemas mais rapidamente e ficam mais focadas na tarefa, criando assim menos código para realizar a mesma coisa.

 

Histórias

Descreva o que o produto deve fazer em termos significativos para clientes e usuários. Essas histórias destinam-se a ser descrições curtas de coisas que os usuários desejam fazer com o produto, que podem ser usadas para planejar e servir como lembretes para conversas mais detalhadas quando a equipe começa a perceber essa história em particular.

 

Ciclo Semanal

O Ciclo Semanal é sinônimo de uma iteração. No caso do XP, a equipe se reúne no primeiro dia da semana para refletir sobre o progresso até o momento, o cliente escolhe as histórias que gostaria de entregar naquela semana, e a equipe determina como abordarão essas histórias. O objetivo até o final da semana é ter os recursos testados em execução que realizam as histórias selecionadas.

A intenção por trás do período de entrega em caixa é produzir algo para mostrar ao cliente em busca de feedback.

 

Ciclo Trimestral

O Ciclo Trimestral é sinônimo de um lançamento. O objetivo é manter o trabalho detalhado de cada ciclo semanal no contexto do projeto geral. O cliente define o plano geral da equipe em termos de recursos desejados em um determinado trimestre, o que proporciona à equipe uma visão da floresta enquanto ela está nas árvores e também ajuda o cliente a trabalhar com outras partes interessadas que podem precisar de uma ideia de quando os recursos estarão disponíveis.

Lembre-se de que, ao planejar um ciclo trimestral, as informações sobre uma determinada história estão em um nível relativamente alto, a ordem de entrega dos objetivos dentro de um Ciclo Trimestral pode mudar e as histórias incluídas no Ciclo Trimestral podem mudar. Se você puder revisitar o plano semanalmente após cada ciclo semanal, poderá manter todos informados assim que essas mudanças se tornarem aparentes para manter as surpresas no mínimo.

 

Folga

A ideia por trás da folga nos termos do XP é adicionar algumas tarefas ou histórias de baixa prioridade em seus ciclos semanais e trimestrais, que podem ser descartadas se a equipe levar mais tempo em tarefas ou histórias mais importantes. Em outras palavras, leve em consideração a variabilidade inerente das estimativas para garantir que você tenha uma boa chance de atender às suas previsões.

 

Construção de dez minutos

O objetivo da compilação de dez minutos é construir automaticamente todo o sistema e executar todos os testes em dez minutos. Os fundadores do XP sugeriram um período de tempo de 10 minutos porque se uma equipe tiver uma compilação que demore mais do que isso, é menos provável que ela seja executada com frequência, introduzindo assim um tempo maior entre os erros.

Essa prática incentiva sua equipe a automatizar seu processo de criação para que você tenha maior probabilidade de fazer isso regularmente e usar esse processo de criação automatizado para executar todos os seus testes.

Esta prática suporta a prática da Integração Contínua e é suportada pela prática do Desenvolvimento Dirigido por Testes.

 

Integração contínua

A Integração Contínua é uma prática em que as alterações de código são testadas imediatamente quando são adicionadas a uma base de código master. O benefício dessa prática é que você pode capturar e corrigir problemas de integração mais rapidamente.

A maioria das equipes teme a etapa de integração de código devido à descoberta inerente de conflitos e problemas resultantes. A maioria das equipes adota a abordagem “Se dói, evite o máximo de tempo possível”.

 

Praticantes do XP sugerem “se doer, faça mais vezes”.

O raciocínio por trás dessa abordagem é que, se você tiver problemas toda vez que integrar o código, e demorar um pouco para descobrir onde estão os problemas, talvez você deva se integrar mais frequentemente para que, se houver problemas, eles sejam muito mais fáceis de encontrar porque são menos alterações incorporadas na compilação.

Esta prática requer alguma disciplina extra e é altamente dependente do Desenvolvimento de Dez Minutos e Desenvolvimento Dirigido por Testes.

 

Test-First Programming

Em vez de seguir o caminho normal de:

desenvolver código -> escrever testes -> executar testes

A prática de Test-First Programming segue o caminho de:

Escrever teste automatizado -> Executar teste -> desenvolver código para fazer a passagem de teste -> executar teste -> repetir

Assim como na Integração Contínua, a Programação em Test-First Programming reduz o ciclo de feedback para que os desenvolvedores identifiquem e resolvam problemas, diminuindo assim o número de bugs introduzidos na produção

Comentários