O que é Programação Extrema (XP) e Seus Valores, Princípios e Práticas?

Mmm

Agile 101

Introdução a Programação Extrema (XP)

Você está familiarizado com metodologias ágeis, mas Programação Extrema, XP na abreviação em inglês, ainda é meio que um mistério para você. Parece meio que extremo, e você não tem certeza se é para você. Não deixe que esse nome o desencoraje, no entanto. Você perderia muitas coisas boas. Este artigo lhe falará tudo o que você precisa saber sobre a programação extrema para que você também possa usá-la a seu favor.

O Que é Programação Extrema (XP)?

A programação extrema é uma metodologia de desenvolvimento de software que faz parte do que é conhecido coletivamente como metodologias ágeis. A XP é construída sobre valores, princípios e práticas, e seu objetivo é permitir que equipes pequenas e médias produzam software de alta qualidade e se adaptem a requisitos em evolução e mudança.

Extreme Programming Xp 1

O que diferencia a XP das outras metodologias ágeis é que a XP enfatiza os aspectos técnicos do desenvolvimento de software. A programação extrema é precisa sobre como os engenheiros trabalham, pois seguir práticas de engenharia permite que as equipes forneçam código de alta qualidade a um ritmo sustentável.

A programação extrema é, em poucas palavras, sobre boas práticas levadas ao extremo. Já que a programação em pares é boa, vamos fazer isso o tempo todo. Já que testar cedo é bom, vamos testar antes mesmo que o código de produção seja escrito.

Uma Breve História da Programação Extrema

A origem da XP remonta aos anos 90 quando Kent Beck — que mais tarde se tornaria um dos autores do Manifesto Ágil — a criou quando foi contratado para liderar a equipe do Sistema Compreensivo de Compensação da Chrysler.

Jim Highsmith
O projeto havia começado em 1993 e em 1996 não havia progredido muito. Como Beck era novo no gerenciamento de equipes, ele decidiu que o melhor curso de ação seria ensinar aos membros de sua equipe as técnicas e práticas que funcionavam para ele. Eles começaram a aplicar práticas como a programação em pares e o TDD com grande sucesso. Ron Jeffries — um amigo de Beck e outro autor do Manifesto Ágil — foi levado para treinar a equipe do C3.
Em 1999, Kent Beck formalizou as práticas, princípios e valores da XP em seu livro Extreme Programming Explained: Embrace Change.

Como a Programação Extrema (XP) Funciona?

A XP, ao contrário de outras metodologias, é muito opinante quando se trata de práticas de engenharia. Além das práticas, a XP é desenvolvida com base em valores e princípios. Os valores fornecem propósito às equipes. Eles atuam como um “norte” para guiar suas decisões de maneira de alto nível. No entanto, os valores são abstratos e muito difusos para uma orientação específica. Por exemplo: dizer que você valoriza a comunicação pode resultar em muitos resultados diferentes. As práticas são, de certa forma, o oposto de valores. Elas são concretas e pragmáticas, definindo as especificidades do que se deve fazer. As práticas ajudam as equipes a se responsabilizarem pelos valores. Por exemplo, a prática de Workspaces Informativas favorece a comunicação transparente e simples. Os princípios são diretrizes específicas de domínio que fazem a ponte entre as práticas e os valores.
Extreme Programming Overview

Image Src: LucidCharts

Valores da XP

Os valores da XP: comunicação, simplicidade, feedback, coragem e respeito. Vamos analisar cada um deles com mais detalhes.
Xp Values And Principles

Image Src: Alexsoft.com

Comunicação: A falta de comunicação impede que o conhecimento flua dentro de uma equipe. Muitas vezes, quando há um problema, alguém já sabe como resolvê-lo. Mas a falta de comunicação impede que eles aprendam sobre o problema ou contribuam para sua solução. Portanto, o problema acaba sendo resolvido duas vezes, gerando desperdício.
Simplicidade: Simplicidade significa que você sempre se esforça para fazer a coisa mais simples que funciona. Muitas vezes é mal compreendido e tomado como a coisa mais simples, ponto final, ignorando a parte “que funciona”. É também crucial lembrar que a simplicidade é altamente contextual. O que é simples para uma equipe é complexo para outra, dependendo inteiramente das habilidades, experiência e conhecimento de cada equipe.
Feedback: O feedback em metodologias de desenvolvimento de software mais tradicionais, como a software em cascata, muitas vezes é “muito pouco, muito tarde”. A XP, entretanto, abraça a mudança, e as equipes de XP se esforçam para receber feedback rápido e constante. Se houver a necessidade de corrigir o rumo, os XPers querem saber isso o mais rápido possível.
Xp Cycle

Image src: extremeprogramming.org

O feedback vem em muitos formatos e tamanhos. Quando você está programando em pares, os comentários de seus colegas são um feedback vital. Assim como as opiniões de outros membros da equipe sobre uma ideia, incluindo o cliente que, idealmente, é um membro da equipe.

Os testes são outra fonte de feedback precioso que vai além dos resultados dos testes. Se escrever testes é fácil ou difícil, o feedback também é. Se você está tendo dificuldades para escrever testes, seu projeto provavelmente é muito complexo. Ouça o feedback e simplifique seu design.

Algo que soa como uma grande ideia pode não funcionar tão bem na prática. Portanto, o código finalizado também é uma fonte de feedback, assim como um produto implantado.

Finalmente, tenha em mente que existe feedback demais. Se uma equipe gera mais feedback do que ela pode lidar, um feedback importante pode sair do radar. É essencial então, diminuir a velocidade e descobrir o que causa o excesso de feedback e corrigi-lo.

Coragem: Kent Beck define coragem como “ação eficaz diante do medo”. Como um engenheiro de software, você tem muito a temer e, portanto, muitas oportunidades para mostrar coragem.

É preciso coragem para falar a verdade, especialmente as desagradáveis — por exemplo, estimativas honestas. Dar e receber feedback também é preciso coragem. E é preciso coragem para evitar cair na falácia dos custos irrecuperáveis e descartar uma solução falhada que recebeu investimentos substanciais.

Respeito: Uma premissa fundamental da XP é que todos se preocupam com seu trabalho. Nenhuma quantidade de excelência técnica pode salvar um projeto se não houver cuidado e respeito. Toda pessoa é digna de dignidade e respeito, e isso inclui, é claro, as pessoas afetadas por um projeto de desenvolvimento de software. Quando você e os membros de sua equipe respeitam e se preocupam uns com os outros, o cliente, o projeto e seus futuros usuários, todos ganham.

Príncipios da XP

Os princípios fornecem orientações mais específicas do que valores. São diretrizes que iluminam os valores e os tornam mais explícitos e menos ambíguos.
Xp Principles

Image src: extremeprogramming.org

Por exemplo, com base apenas no valor da coragem, você poderia concluir que é aconselhável enfrentar uma grande mudança de uma só vez no programa. Entretanto, o princípio de Passos Curtos nos diz que grandes mudanças são arriscadas. Portanto, você quer favorecer as pequenas.
Humanidade: Humanos criam software para humanos, um fato que muitas vezes é negligenciado. Mas levar em conta as necessidades básicas humanas, os pontos fortes e fracos cria produtos que os humanos querem utilizar. E um ambiente de trabalho que lhe dá a oportunidade de realização e crescimento, o sentimento de pertencer, e segurança básica, é um lugar onde você leva mais facilmente em conta as necessidades dos outros.
Economia: Na XP, as equipes estão sempre atentas às realidades econômicas do desenvolvimento de software, avaliam constantemente os riscos econômicos e as necessidades do projeto. Por exemplo, eles implementariam histórias de usuários de acordo com seu valor comercial, ao invés de preocupações técnicas.
Benefício Mútuo: Seguindo a XP, você evita soluções que beneficiam uma parte em detrimento de outra. Por exemplo, especificações extensas podem ajudar outra pessoa a compreendê-lo, mas isso o afasta da implementação e o atrasa para seus usuários. Uma solução mutuamente benéfica é a utilização de testes de aceitação automatizados. Você recebe feedback imediato sobre sua implementação, seus colegas recebem especificações precisas em código, e os usuários recebem suas funcionalidades mais cedo. Além disso, todos recebem uma rede de segurança contra regressões.
Digi 1
Auto-similaridade: Se uma determinada solução funciona em um nível, ela também pode funcionar em um nível superior ou inferior. Por exemplo, a obtenção de feedback antecipado e constante está em jogo em vários níveis na XP.
  • em nível de desenvolvedor, os programadores recebem feedback de seu trabalho usando a abordagem test-first;
  • em nível de equipe, o canal de integração contínua integra, constrói e testa o código várias vezes ao dia;
  • em nível de organização, os ciclos semanal e trimestral permitem às equipes obter feedback e melhorar seu trabalho conforme necessário.
Melhoria: De acordo com o princípio da melhoria, as equipes não se esforçam pela perfeição em uma implementação inicial, mas por uma boa, e para então aprender e melhorar continuamente com o feedback de usuários reais.
Diversidade: Você e seus colegas de trabalho se beneficiam de uma diversidade de perspectivas, habilidades e atitudes. Tal diversidade muitas vezes leva a conflitos, mas tudo bem. Conflito e discordância são oportunidades para que ideias melhores surjam quando todos jogam pelos valores da coragem e do respeito. Coragem para expressar pontos de vista opostos, respeito para expressar aqueles de uma forma civilizada e empática. E tudo isso é um exercício de comunicação eficaz.
Reflexão: Grandes equipes refletem sobre seu trabalho e analisam como ser melhor. A XP oferece muitas oportunidades para isso. Não apenas em seus ciclos semanais e trimestrais, mas em cada prática que promove. Os sentimentos são importantes a serem considerados além da análise lógica. Seu instinto pode informá-lo antes que você possa raciocinar sobre algo. Assim como falar com pessoas não-técnicas, elas podem fazer perguntas que abrem possibilidades inteiramente novas.
Fluxo: As metodologias tradicionais de desenvolvimento de software têm fases discretas, que duram muito tempo e têm poucas oportunidades de feedback e correção de curso. Em vez disso, o desenvolvimento de software na XP ocorre em atividades que acontecem o tempo todo, em um consistente “fluxo” de valor.
Oportunidade: Os problemas são inevitáveis no desenvolvimento de software. Entretanto, cada problema é uma oportunidade de melhoria. Aprenda a olhar para eles dessa forma e é muito mais provável que você encontre soluções criativas, orientadas a objetivos que também servem para evitar que eles aconteçam novamente.
User Stories Sprints 2
Redundância: O princípio da redundância diz que, se um determinado problema é crítico, você deve empregar muitas táticas para combatê-lo. Pegue defeitos. Não há uma tática única que possa impedir que todos os defeitos escapem para a produção. Portanto, a solução da XP é empilhar um monte de medidas de qualidade. Programação de pares, testes, integração contínua. Cada um com uma única linha de defesa, juntos, uma muralha virtualmente impenetrável.
Falha: A falha não é um desperdício quando ela resulta em conhecimento. Agir e aprender rapidamente o que não funciona é muito mais produtivo do que a inação causada pela indecisão na escolha entre muitas opções.
Qualidade: Muitas vezes as pessoas pensam que existe um dilema entre qualidade e velocidade.
É o oposto: empurrar para a melhoria da qualidade é o que faz você ir mais rápido. Por exemplo, a refatoração — mudar a estrutura do código sem alterar seu comportamento — é uma prática que torna o código mais fácil de entender e de ser alterado. Como resultado, você se torna menos propenso a introduzir defeitos no código, o que lhe permite fornecer mais valor mais cedo, não tendo que corrigir bugs.
Passos Curtos: Grandes mudanças são arriscadas. A XP mitiga esse risco ao fazer mudanças em pequenas etapas, em todos os níveis. Os programadores escrevem o código em pequenos passos usando o desenvolvimento orientado por testes. Eles integram seu código à linha principal várias vezes ao dia, em vez de apenas a cada poucas semanas ou até mesmo meses. O projeto em si ocorre em ciclos curtos ao invés de fases de longa duração.
Responsabilidade Aceita: Na XP, a responsabilidade deve ser aceita, nunca atribuída. A responsabilidade deve ser acompanhada pela autoridade para tomar decisões sobre aquilo pelo qual você é responsável. O inverso também se aplica. Você não quer que as pessoas tomem decisões se elas não tiverem que viver com suas consequências

Similitudes e Diferenciadores

Como a XP difere das metodologias tradicionais, não ágeis?

A programação extrema, sendo parte de uma programação ágil, trata-se de abraçar e acolher mudanças em vez de seguir planos rígidos. Trata-se de um design iterativo em vez de um grande design inicial. A XP difere drasticamente das metodologias tradicionais — ou seja, cascata — ao evitar fases prolongadas.
  • Em vez de uma fase de planejamento, na XP você planeja no início de cada ciclo de desenvolvimento, que normalmente dura apenas uma semana.
  • Em vez de episódios de teste, você testa sua aplicação o mais rápido possível: isto é, antes que o código real seja implementado.
  • Em vez de implementar recursos isoladamente durante as longas fases de implementação e depois lutar para integrar suas contribuições à linha principal, você trabalha em pequenos trechos e integra esses trechos o mais frequentemente possível.

Qual é a diferença entre XP e as outras metodologias ágeis?

A programação extrema, por natureza, tem muito em comum com as outras metodologias ágeis, mas também é única entre elas. A maioria das outras metodologias de desenvolvimento não diz muito, ou mesmo nada, sobre como fazer o trabalho… a XP, por outro lado, é altamente opinante quando se trata disso e dá grande ênfase às práticas de engenharia de software.

Programação Extrema vs. Scrum

Scrum é um framework para ajudar as equipes a desenvolver projetos complexos de forma adaptativa. O Scrum não dita como os desenvolvedores devem trabalhar. A XP, como mencionado, coloca muita ênfase nas boas práticas da programação.
Scrum Process 1 1536X614 1

Além disso, a XP é obviamente sobre programação. O Scrum, por outro lado, pode ser aplicado a qualquer projeto que se beneficie de uma abordagem iterativa.

A XP aceita mudanças em seus componentes. As equipes são permitidas e até incentivadas a ajustar as práticas de acordo com suas necessidades específicas. O Scrum Guide, por outro lado, é inflexível ao afirmar que “Embora a implementação de apenas partes do Scrum seja possível, o resultado não é Scrum”.

Além disso, o Scrum é uma estrutura que você precisa preencher com metodologias e práticas para realizar o trabalho.

Isso significa que não só é possível usar XP e Scrum juntos, mas extremamente recomendado.

Principais Funções e Responsabilidades

De acordo com Kent Beck, uma equipe madura de XP não deve confiar em papéis rígidos, mas reconhecer que os papéis podem ser úteis para as equipes iniciantes, até que elas comecem a atrapalhar a colaboração. Dito isto, há alguns papéis comuns que as pessoas associam à XP:
  • Cliente: idealmente, deve haver um cliente real no local para responder perguntas, priorizar histórias de usuários ou colaborar com testes de aceitação. Quando isto não for possível, esta função poderia ser cumprida por um representante do cliente.
  • Programmers: iProgramadores: em uma equipe de XP, os programadores estimam o esforço necessário para completar tarefas e histórias, escrever testes automatizados e implementar as histórias.n an XP team, programmers estimate the effort needed to complete tasks and stories, write automated tests, and implement the stories.
  • Treinador: Não é necessário ter um treinador, e muitas equipes alcançaram sucesso sem um treinador. Entretanto, ter alguém com experiência em XP para treinar uma equipe pode garantir que os membros da equipe sigam as práticas, transforme-as em hábitos e não voltem aos velhos costumes.
  • Rastreador: Um rastreador rastreia as métricas de progresso da equipe e conversa com cada membro da equipe para identificar bloqueios no caminho e descobrir soluções. O rastreador calcula as métricas que indicam quão bem a equipe está se saindo, tais como velocidade e gráficos burndown, ou a equipe usa um scrum digital ou um quadro kanban que os calcula automaticamente.

Métodos e Técnicas

Métodos e técnicas são as práticas na XP. Eles se dividem em três grupos principais: engenharia de software, ambiente de trabalho e gerenciamento de projetos. Vamos começar com as práticas relacionadas à engenharia de software.

Engenharia de Software

Programação em Pares: Na XP, você escreve código em pares sentado em uma máquina. Você e seu par conversam um com o outro enquanto analisam, implementam e testam o recurso em que estão trabalhando. A programação em pares é particularmente eficaz na produção de código com menos defeitos, ao mesmo tempo em que é envolvente, divertida e cansativa.
Pair Programming 01
Build de Dez Minutos: Espera-se que o servidor de integração contínua construa o projeto inteiro — incluindo a execução de todos os testes automatizados — no máximo em dez minutos. Este limite serve para manter os testes enxutos e eficientes, ou seja, focados.
Programação Test-First: Na XP, você implementa suas funcionalidades usando a abordagem test-first, também chamada de desenvolvimento orientado a testes (TDD em inglês). O TDD consiste em desenvolver usando um ciclo simples:
  • você escreve um teste reprovado;
  • então, você escreve o código de produção para fazer o teste passar;
  • se necessário, você refatora o código de produção para torná-lo mais limpo e fácil de entender.

O TDD traz vários benefícios para a mesa.

Primeiro, o feedback. Se é difícil escrever um teste, o projeto que você vai fazer ou herdou, provavelmente é muito complexo e você tem que simplificá-lo. Segundo, o TDD permite que os programadores confiem no código que escrevem e cria um ritmo cíclico agradável, onde o próximo passo é sempre claro. Por último, mas não menos importante, o uso de TDD desde o início garante 100% de cobertura do código. O conjunto de testes torna-se então verdadeiramente uma rede de segurança para mudanças futuras, incentivando a refatoração do código e criando um círculo virtuoso de qualidade.
Design Incremental: A prática do design incremental significa que você deve investir no design da aplicação todos os dias, buscando oportunidades para remover a duplicação e fazer pequenas melhorias, alcançando o melhor design possível para o que o sistema precisa hoje.
Integração Contínua: Na XP, você integra seu trabalho ao repositório principal compartilhado muitas vezes ao dia, desencadeando uma build automática de todo o sistema. A integração o mais cedo possível e com a maior frequência possível reduz drasticamente o custo da integração, pois torna menos provável a fusão e a ocorrência de conflitos lógicos. Também expõe problemas do ambiente e de dependências.

Código Compartilhado (Propriedade Coletiva): A XP promove código compartilhado, ou propriedade coletiva: todo desenvolvedor é responsável por todo o código. Ele incentiva a troca de informações, reduz o fator ônibus da equipe e aumenta a qualidade geral de cada módulo, se considerarmos o princípio da diversidade.

Base de Código Única: A base de código única também é conhecida como “desenvolvimento baseado em troncos”. Isso significa que existe apenas uma única fonte de verdade. Portanto, ao invés de desenvolver isoladamente por longos períodos de tempo, você mescla suas contribuições para o fluxo único de forma antecipada e frequente. As bandeiras de funcionalidades ajudam a manter o uso de funcionalidades restrito enquanto elas não estão completas.
Implantação Diária: A implantação na produção pelo menos uma vez por dia é uma consequência lógica da integração contínua. Na verdade, hoje em dia, muitas equipes vão ainda mais longe e praticam a implantação contínua. Ou seja, toda vez que alguém se mescla à linha principal, a aplicação é implantada na produção.
Análise da Causa Raiz: Sempre que um defeito entra em produção, não apenas conserte o defeito. Certifique-se de compreender o que o causou em primeiro lugar, por que você e seus colegas de equipe não conseguiram evitar o erro. Em seguida, tome medidas para garantir que isso não volte a acontecer.

Ambiente de Trabalho

Sentar Juntos: Na XP, as equipes favorecem o trabalho em conjunto em um espaço aberto. Esta prática favorece a comunicação e o sentimento de pertencer a uma equipe.
Equipe Completa: Todos que são necessários para o sucesso do projeto fazem parte da equipe de XP. Isso é altamente contextual — diferente para cada equipe — e dinâmico, pode mudar dentro de uma equipe.
Espaços de Trabalho Informativos: Um espaço de trabalho informativo utiliza o espaço físico da equipe para exibir informações que permitem a qualquer pessoa saber, num relance, o progresso do projeto. Como isso é feito pode variar, desde anotações físicas e gráficos, até telas exibindo quadros e painéis Kanban a partir de um software de gerenciamento de projeto.
Trabalho Energizado: Na XP, você trabalha apenas enquanto puder fazer um trabalho energizado. As horas de trabalho devem ser limitadas a 40 por semana, no máximo

Gestão de Projetos

Histórias: Você escreve os requisitos do usuário em um formato conhecido como histórias de usuário. Uma história de usuário tem um nome curto e descritivo e também uma breve descrição do que deve ser implementado.
Slack: Ao planejar um ciclo, adicione tarefas menores que a equipe pode abandonar caso precise. Mais histórias podem sempre ser adicionadas se a equipe fornecer mais do que o necessário.
Ciclos (Trimestrais e Semanais): O desenvolvimento na XP acontece em dois ciclos principais: o ciclo semanal e o ciclo trimestral. Mais sobre isso na próxima seção.
Principais Reuniões, Ciclos, Cadências de Entrega: O desenvolvimento na XP acontece em dois ciclos principais: o ciclo semanal e o ciclo trimestral. Inicialmente, Kent Beck recomendou um ciclo de duas semanas, mas ele mudou isso na segunda edição de seu livro.
Ciclo Semanal: O ciclo semanal é o “pulso” de um projeto de XP. O ciclo começa com uma reunião onde o cliente escolhe quais histórias quer implementar durante a semana. Além disso, a equipe analisa seu trabalho, incluindo o progresso da semana passada, e pensa em como melhorar seu processo.
Ciclo Trimestral: A cada trimestre, a equipe reflete e identifica oportunidades de melhoria em seu processo. O cliente escolhe um ou mais temas para esse trimestre, juntamente com as histórias desses temas.

Como Começar com XP?

As habilidades técnicas e os hábitos de XP podem ser um desafio para aprender. Algumas das práticas podem parecer estranhas aos programadores que não estão acostumados a elas.
Agile Yellow
Para começar com a EXP, as equipes podem adotar uma prática principal de cada vez. Para decidir por onde começar, decida qual é o próximo objetivo que você quer alcançar. Escolha a prática que se alinha com esse objetivo. Por exemplo, se sua equipe precisa construir um senso de confiança, tanto no código como em outros membros da equipe, comece com a programação em pares e TDD. Se você precisar eliminar o risco associado a confiar demais em membros específicos da equipe, adote a propriedade coletiva do código.

Leitura Adicional

Uma questão que muitas vezes está na mente das equipes é o aparente custo de adotar práticas de XP – isso só é verdade a (muito) curto prazo, e os benefícios a médio e longo prazo superarão em muito os custos!

Vá ao eXtremo com a XP — o Agile dos Desenvolvedores.

A maioria dos frameworks e metodologias ágeis se concentra no gerenciamento de projetos ou produtos e na organização de pessoas e trabalho.
Extreme Programming

A XP é única em como ela chama a atenção para as boas práticas que outras metodologias ágeis deixam como um exercício para o usuário. Ou seja, você.

Significa que a XP é compatível com outras metodologias e ousamos dizer que adotar um framework Agile sem utilizar também o XP é insuficiente. Isso porque sem as práticas para ajudá-lo a agregar valor a um ritmo estável e sustentável, seu código se tornará cada vez menos adaptável à mudança e você acabará num dilema não passível de mudança.

Portanto, vá ao eXtremo e comece a adotar a XP. É o Agile dos desenvolvedores, que vai manter todos ágeis.

Medha Case Study

Check out Nimble Now!

Humanize Work. And be Nimble!

Request Demo