A programação extrema (XP) é uma metodologia ágil de gestão de projetos que visa a velocidade e a simplicidade com ciclos de desenvolvimento curtos. A XP usa cinco valores orientadores, cinco regras e 12 práticas de programação. A estrutura é rígida, mas o resultado desses sprints altamente focados e integrações contínuas pode resultar em um produto de qualidade muito superior.
Se o termo programação extrema evoca imagens mentais dos X games e dos esportes de ação, você não está muito longe. A programação extrema (XP) é, de fato, uma maneira bastante extrema de programar. Semelhante a outros métodos de desenvolvimento de software ágil, a XP usa desenvolvimento adaptável e orientado a testes para a engenharia de software. Mas, ao contrário de outros métodos, a programação extrema tem regras rígidas e valores orientadores que regem a forma como o trabalho é realizado.
A programação extrema é uma metodologia ágil de gestão de projetos que visa a velocidade e a simplicidade com ciclos de desenvolvimento curtos e menos documentação. A estrutura do processo é determinada por cinco valores orientadores, cinco regras e 12 práticas XP (que detalharemos mais adiante neste artigo).
Como outros métodos ágeis, a XP é uma metodologia de desenvolvimento de software dividida em sprints de trabalho. As estruturas ágeis seguem um processo iterativo: você conclui e revisa a estrutura após cada sprint, aprimora-a para obter a máxima eficiência e a ajusta às mudanças nos requisitos. Semelhante a outros métodos ágeis, o design da XP permite que os desenvolvedores respondam às histórias dos clientes, adaptem-se e mudem em tempo real. Mas a XP é muito mais disciplinada, usando revisões de código frequentes e testes de unidade para fazer alterações rapidamente. Também é altamente criativa e colaborativa, priorizando o trabalho em equipe durante todas as etapas de desenvolvimento.
Experimente a Asana gratuitamenteO Scrum é outro tipo comum de metodologia Agile, gerido por um mestre do Scrum. Semelhante à XP, o Scrum executa sprints de histórias de usuários para desenvolver novos recursos de produtos ou software. No entanto, a XP é mais rígida do que o Scrum, com regras e diretrizes estritas que incentivam o contato constante entre os desenvolvedores e o cliente. Além disso, é possível usar o Scrum em qualquer processo que exija iteração e informações do cliente, enquanto a programação XP é mais restrita.
As origens da XP remontam ao final da década de 1990, quando Kent Beck a criou para gerir o desenvolvimento de um sistema de software de folha de pagamento para a Chrysler chamado projeto C3. A meta da XP era (e ainda é) remover a resistência à mudança de código nos projetos de desenvolvimento. Em métodos de desenvolvimento de software mais tradicionais, muitas vezes você deixa o código em paz depois de escrito (exceto para depuração). Com a XP, o código é examinado com tanto cuidado que os desenvolvedores podem decidir reescrevê-lo inteiramente após uma única iteração.
Como a programação extrema se concentra no desenvolvimento de software, ela normalmente é usada apenas por equipes de engenharia. Mesmo em equipes de software, ela só funciona em determinadas configurações. Para tirar o máximo proveito da programação extrema, é melhor usá-la quando você:
Gerencia uma equipe menor. Devido à sua natureza altamente colaborativa, a XP funciona melhor em equipes menores, com menos de 10 pessoas.
Estiver em contato constante com os clientes. A XP incorpora os requisitos do cliente em todo o processo de desenvolvimento e até depende deles para testes e aprovações.
Tem uma equipe adaptável que pode abraçar a mudança (sem ressentimentos). Pela sua própria natureza, a programação extrema muitas vezes exige que toda a equipe descarte o seu trabalho árduo. Há também regras que permitem que outros membros da equipe façam alterações a qualquer momento, o que não funciona se os membros da equipe levarem isso para o lado pessoal.
Tenham amplo conhecimento dos aspectos técnicos da programação. A XP não é para iniciantes. É preciso ser capaz de trabalhar e fazer alterações rapidamente.
O ciclo de vida da XP incentiva a integração contínua, na qual o membro da equipe se integra quase constantemente, com a frequência de uma vez por hora ou por dia. Mas o ciclo de vida completo se divide da seguinte forma:
Extrair o trabalho inacabado das histórias de usuário
Priorizar os itens mais importantes
Iniciar o planejamento iterativo
Incorporar um planejamento honesto
Manter uma comunicação constante com todas as partes interessadas e capacitar a equipe
Liberar o trabalho
Receber feedback
Retornar à fase de planejamento iterativo e repetir conforme necessário.
A programação extrema é orientada por valores. Em vez de usar motivadores externos, a XP permite que a equipe trabalhe de maneira menos complicada (focando na simplicidade e na colaboração em vez de em projetos complexos), tudo com base nesses cinco valores.
Antes de iniciar qualquer trabalho de programação extrema, pergunte-se: qual é a coisa mais simples que também funciona? A parte “que funcione” é um diferencial fundamental: a coisa mais simples nem sempre é prática ou eficaz. Na XP, o foco está em fazer o trabalho mais importante primeiro. Isso significa que você está procurando um projeto simples que sabe que pode realizar.
A XP depende de reatividade rápida e comunicação eficaz. Para que funcione, a equipe precisa ser aberta e honesta uns com os outros. Quando surgirem problemas, espera-se que você se manifeste. A razão para isso é que outros membros da equipe muitas vezes já terão uma solução. E, se não tiverem, vocês chegarão a uma solução mais rápido como grupo do que sozinhos.
Leia: Como melhorar a comunicação da equipe: 6 estratégias e dicasComo outras metodologias ágeis, a XP incorpora histórias de usuários e feedback diretamente no processo. O foco da XP é produzir o trabalho de forma rápida e simples, e depois compartilhá-lo para obter feedback quase imediato. Assim, os desenvolvedores estão em contato quase constante com os clientes durante todo o processo. Na XP, você lança-se versões frequentes para obter insights com antecedência e frequência. Ao receber feedback, você adaptará o processo para incorporá-lo (em vez do projeto). Por exemplo, se o feedback reduzir o tempo de atraso desnecessário, você ajustaria o processo para que um par de desenvolvedores melhorasse o tempo de atraso em vez de ajustar o projeto como um todo.
Leia: Não gosta de dar feedback? Estas 20 dicas são para vocêA XP exige uma certa dose de coragem. Espera-se que você sempre forneça atualizações honestas sobre o seu progresso, o que pode ser bastante vulnerável. Se você perder um prazo na XP, o líder da equipe provavelmente não vai querer discutir o motivo. Em vez disso, você diria a ele que perdeu o prazo, assumiria a responsabilidade e voltaria ao trabalho.
Se você é um líder de equipe, sua responsabilidade no início do processo XP é definir a expectativa de sucesso e definir o que é “concluído”. Muitas vezes, há pouco planejamento para o fracasso porque a equipe se concentra no sucesso. No entanto, isso pode ser assustador, porque as coisas nem sempre saem conforme o planejado. Mas, se as coisas mudarem durante o processo XP, espera-se que a equipe se adapte e mude com elas.
Considerando o quanto a XP prioriza a comunicação e a honestidade, faz sentido que o respeito seja importante. Para que as equipes se comuniquem e colaborem de forma eficaz, elas precisam ser capazes de discordar. Mas há maneiras de fazer isso com gentileza. O respeito é uma boa base que leva à gentileza e à confiança, mesmo na presença de muita honestidade. Para a programação extrema, as expectativas são:
Respeito mútuo entre os clientes e a equipe de desenvolvimento.
Respeito mútuo entre os membros da equipe.
Reconhecimento de que todos na equipe trazem algo valioso para o projeto.
Os valores da programação extrema são os aspectos mais filosóficos. As regras, por outro lado, são os usos práticos de como o trabalho é feito. Você precisará de ambos para administrar uma equipe XP eficaz.
Nas etapas de planejamento da XP, você determina se o projeto é viável e se é o mais adequado para a XP. Para isso, você analisará:
As histórias de usuário, para ver se elas correspondem ao valor da simplicidade, e verificar se o cliente está disponível para o processo. Se a história de usuário for mais complexa ou for feita por um cliente anônimo, provavelmente não funcionará para a XP.
O valor de business e a prioridade do projeto para garantir que ele esteja alinhado com o princípio de “realizar o trabalho mais importante primeiro”.
Em que estágio de desenvolvimento você está. A XP é melhor para o desenvolvimento em estágio inicial e não funcionará tão bem para iterações posteriores.
Depois de confirmar que o projeto é viável para a XP, crie um cronograma de lançamentos, mas tenha em mente que você deve lançar cedo e com frequência para obter feedback. Para fazer isso:
Divida o projeto em iterações e crie um plano para cada uma delas.
Defina prazos realistas e um ritmo sustentável.
Compartilhe as atualizações à medida que elas acontecem, o que capacita a sua equipe a ser honesta e transparente.
Compartilhe atualizações em tempo real que ajudem a equipe a identificar, adaptar e fazer alterações mais rapidamente.
Use uma ferramenta de gestão de projetos para criar um quadro Kanban ou um cronograma para acompanhar o progresso em tempo real.
Um dos principais elementos da XP é o espaço físico. Os puristas da XP recomendam usar um espaço de trabalho aberto onde todos os membros da equipe trabalhem em uma sala aberta. Como a XP é muito colaborativa, você se beneficiará de ter um espaço onde possa se reunir fisicamente. Mas isso nem sempre é prático nos dias de hoje. Se você trabalha em uma equipe remota, considere usar uma plataforma que incentive o trabalho assíncrono para colaboração remota. Dessa forma, todos os membros podem continuar a trabalhar no projeto juntos, mesmo que não estejam fisicamente juntos.
Como em outros métodos ágeis, use reuniões diárias em pé para fazer o acompanhamento e incentivar uma comunicação constante e aberta. É recomendável usar um ciclo semanal e um ciclo trimestral. Durante o ciclo trimestral, você e a equipe analisarão as histórias que orientarão o trabalho. Você também estudará o seu processo XP, procurando lacunas ou oportunidades para fazer alterações. Em seguida, você trabalhará em ciclos semanais, cada um começando com uma reunião com o cliente. O cliente escolhe a história de usuário na qual deseja que os programadores trabalhem naquela semana.
Como gerente ou líder de equipe, o seu foco será manter o progresso do trabalho, medir o ritmo, realocar os membros da equipe para resolver bugs ou problemas à medida que surgirem, ou alterar o processo XP para se adequar ao seu projeto e iteração atuais. Lembre-se de que a meta da XP é ser flexível e agir, portanto, o seu trabalho estará altamente focado no trabalho atual da equipe e será reativo a quaisquer mudanças.
Quando estiver começando com a programação extrema, comece com o design mais simples possível, sabendo que as iterações posteriores o tornarão mais complexo. Não adicione funcionalidades iniciais nesta fase para mantê-la o mais simples possível.
As equipes que usam a metodologia XP geralmente usam cartões de classe-responsabilidade-colaboração (CRC) para mostrar como cada objeto no design interage. Ao preencher cada campo do cartão, você terá uma interação visual de todas as funções à medida que elas se relacionam e interagem. Os cartões CRC incluem:
Classe (coleção de objetos semelhantes)
Responsabilidades (relacionadas à classe)
Colaboradores (classe que interage com esta)
Os CRC são úteis para estimular o processo e detectar possíveis problemas. Independentemente de como você projeta, é importante usar um sistema que reduza possíveis gargalos. Para isso, certifique-se de procurar proativamente por riscos. Assim que surgir uma ameaça potencial, designe um ou dois membros da equipe para encontrar uma solução caso a ameaça ocorra.
Leia: Processo de gestão de riscos em seis etapas clarasUm dos aspectos mais singulares da XP é que você permanecerá em contato constante com o cliente durante todo o processo de programação. Essa parceria permite testar e incorporar feedback em cada iteração, em vez de esperar até o final de um sprint. Mas as regras de programação são bastante rígidas na XP. Algumas dessas regras incluem:
Todo o código deve atender aos padrões de codificação.
Usar um teste de unidade para definir os requisitos e desenvolver todos os aspectos do projeto.
Programação em dupla: dois desenvolvedores trabalham juntos simultaneamente no mesmo computador. Isso não aumenta o tempo, mas usa o dobro do foco para produzir resultados da mais alta qualidade.
Usar integrações contínuas para adicionar novos códigos e testá-los imediatamente.
Apenas um par pode atualizar o código a qualquer momento para reduzir erros.
Propriedade coletiva do código: qualquer membro da equipe pode alterar o código a qualquer momento.
Você deve fazer testes durante todo o processo de programação extrema. Todo o código precisará passar por testes de unidade antes de ser lançado. Se forem descobertos bugs durante esses testes, serão criados novos testes adicionais para corrigi-los. Mais tarde, você configurará a mesma história de usuário em que esteve trabalhando em um teste de aceitação. Durante esse teste, o cliente analisa os resultados para ver como você traduziu a história do usuário no produto.
Para aprimorar ainda mais o processo, a XP também usa um conjunto de 12 práticas ao longo do processo. Elas se baseiam no manifesto Agile, mas são adaptadas para atender às necessidades da XP:
O jogo do planejamento: o planejamento XP é usado para orientar o trabalho. Os resultados do planejamento devem ser o que se espera alcançar, quando isso deve acontecer e o que será feito a seguir.
Testes do cliente: quando você conclui um novo recurso, o cliente desenvolve um teste de aceitação para determinar o quão próximo ele está da história de usuário original.
Lançamentos pequenos: a XP usa lançamentos pequenos e rotineiros para obter insights ao longo do processo. Muitas vezes, os lançamentos vão direto para os clientes, embora possam acontecer internamente.
Design simples: o sistema XP foi projetado para a simplicidade, ou seja, você produzirá apenas o que é necessário e nada mais.
Programação em dupla: toda a programação é feita por um par de desenvolvedores que trabalham lado a lado. Não há trabalho individual na programação extrema.
Desenvolvimento orientado a testes (TDD): a dependência da obtenção de feedback exige testes intensivos. Por meio de ciclos curtos, os programadores lançam testes automatizados e reagem imediatamente.
Refatoração: é aqui que você prestará atenção aos detalhes mais minuciosos da base de código, removendo duplicatas e certificando-se de que o código seja coeso. Isso resulta em designs bons e simples.
Propriedade coletiva: qualquer dupla de programação pode alterar o código a qualquer momento, independentemente de quem o desenvolveu. A XP produz código em equipe, e o trabalho de todos é mantido nos mais altos padrões coletivos.
Integração contínua: as equipes de XP não esperam por iterações concluídas, elas se integram constantemente. Muitas vezes, uma equipe XP fará integrações várias vezes ao dia.
Ritmo sustentável: a intensidade dos trabalhos de XP exige que você defina um ritmo sustentável. As equipes devem decidir quanto trabalho podem produzir dessa maneira por dia e por semana, e usar isso para definir os prazos de trabalho.
Metáfora: a metáfora é, literalmente, uma metáfora. Ela é decidida em equipe e usa a linguagem para descrever como a equipe deve funcionar. Por exemplo, somos formigas trabalhando coletivamente para construir o formigueiro.
Padrão de codificação: as equipes XP seguem um padrão. Da mesma forma que os redatores precisam assumir a voz de uma marca para que pareça que a mesma pessoa está sempre escrevendo, os desenvolvedores XP codificam da mesma maneira unificada para que pareça que um único desenvolvedor está escrevendo.
A esta altura, você provavelmente já percebeu que a programação extrema é, bem, extrema. O processo é rigoroso e altamente estruturado, mas os resultados podem valer a pena. O processo de desenvolvimento exclusivo da XP, que incorpora o feedback dos clientes e a programação intensa e colaborativa, resulta em um software de alta qualidade.
Simplifique o planejamento e a gestão da XP com ferramentas de gestão do trabalho que se atualizam e se adaptam em tempo real, assim como o seu trabalho.
Experimente a Asana gratuitamente