Você provavelmente já ouviu falar em diversas metodologias e frameworks de desenvolvimento ágil como Kanban e Scrum. Mas você já ouviu falar sobre Extreme Programming, ou XP?
O XP visa desenvolver um software de alta qualidade e de maneira ágil, conduzindo isso por meio da implementação de valores, práticas e princípios no ambiente de trabalho. Tenho trabalhado com a metodologia há algum tempo e posso dizer que, apesar de assustar num primeiro momento, ela tem diversas vantagens no longo prazo.
Ficou interessado em saber como o XP funciona? Eu te explico nos próximos parágrafos.
O que é Extreme Programming?
Apesar de não muito conhecido pelos brasileiros, o Extreme Programming foi criado por Kent Beck, que mais tarde seria um dos autores do Manifesto Ágil, na década de 90. Essa metodologia é responsável pela criação de artefatos familiares como histórias do usuário e tem como uma da suas prática a programação em par.
As equipes que adotam XP acreditam que, ao dominar um conjunto mínimo de práticas,elas serão mais bem-sucedidas e terão experiências de desenvolvimento de software mais satisfatórias.
O termo “extremo” se refere à execução dessas práticas com máxima eficiência e não necessariamente a práticas radicais; apesar de que algumas pessoas podem ver certas práticas como extremas. A filosofia do XP é que a excelência na execução dessas práticas levará a uma melhoria significativa na qualidade do software e na experiência geral da equipe.
Premissas da metodologia
É importante entender que no XP, assume-se que você se vê como parte de uma equipe, idealmente com objetivos claros e um plano de execução bem definido. Mas não só isso, que você deseja trabalhar em conjunto e que a mudança pode ser feita de forma barata usando esta metodologia.
Extreme Programming tem um grande foco em developers, sendo assim, pressupõe que as pessoas desenvolvedoras desejam crescer, melhorar suas habilidades e seus relacionamentos. XP assume que estão dispostos a fazer mudanças para atingir essas metas. Sendo sincero, implementar essas mudanças pode não ser trivial, mas se paga no longo prazo.
Como o Ken Beck afirma no livro, a implementação do XP necessitará de ajustes regulares, é como dirigir um carro. Segundo ele:
“Dirigir um carro não é colocar o carro na direção certa. Dirigir é prestar atenção constantemente, fazer uma pequena correção desta maneira, uma pequena correção daquela maneira.”
– Ken Beck
Valores, práticas e princípios
Conforme mencionado, a implementação do Extreme Programming se alicerceia em valores, práticas e princípios.
Práticas são coisas que você de fato realiza no seu dia a dia, elas por si só não têm grande valor. Porém, ao serem unidas a valores, passam a ter um propósito e podem levar um time ao sucesso.
A união de suas práticas com seus valores é feita por meio de princípios, diretrizes gerais para a vida.
Valores
Valores são como raízes, elas são a base para a árvore poder crescer. Quando mais bem estabelecidas as raízes, mais forte e fincada será a árvore.
De uma maneira mais informal, os valores que carregamos são as causas da maneira como agimos em diversas situações, gostamos delas ou não.
Para XP, existem 5 valores-base:
- Comunicação: movimento sem comunicação não traz progresso;
- Simplicidade: busque eliminar complexidade desnecessária;
- Feedback: não espere a perfeição, mas busque a melhoria. As equipes XP se esforçam para gerar o máximo de feedback possível, o mais rápido possível;
- Coragem: falar a verdade, agradável ou não, promove a comunicação e a confiança. Descartar soluções que falham e buscar novas encoraja a simplicidade. A coragem de buscar respostas reais e concretas gera feedback;
- Respeito: os membros devem se preocupar uns com os outros e com o que estão fazendo.
Práticas
De acordo com XP, as práticas dependem da situação. Ou seja, se a situação mudar, você escolhe práticas diferentes para atender a essas condições. Seus valores, por outro lado, não se alteram para se adaptar a uma nova situação.
Existem práticas primárias e secundárias. Uma vez que a implementação das primeiras é bem estabelecida, pode-se começar a implementar as demais.
Práticas primárias
- Sentar juntos: quanto mais tempo frente a frente você tem, mais humano e produtivo é o projetoj
- Equipe completa: 12 é o número de pessoas que podem interagir confortavelmente umas com as outras em um dia, ou seja, um limite máximo para um time. Com mais de 150 pessoas em uma equipe, você não consegue mais reconhecer os rostos de todos os envolvidos;
- Ambiente de trabalho informativo: auadro de atualização, kanban, etc. Algo para uma rápida visualização e entendendo do trabalho;
- Trabalho energizado: trabalhe apenas pelo tempo que puder ser produtivo e apenas pelo tempo que puder sustentar;
- Pair Programming (Programação em Par): desenvolvedores trabalham lado a lado sempre, o que evita a necessidade de revisão de código;
- Histórias de usuário (User Stories): descrição informal e em linguagem natural das características de um sistema de software, escritas pela perspectiva do usuário;
- Ciclo semanal: revisão do progresso semanalmente, selecionar histórias para o próximo ciclo e divisão das histórias em tarefas;
- Ciclo trimestral: definição de um planejamento orientado por resultados (outcome-drive roadmap) a cada trimestre;
- “Afroxe” (Slack): adicione algumas tarefas ou histórias de baixa prioridade em seus ciclos semanais e trimestrais que podem ser descartadas se a equipe ficar atrasada em tarefas ou histórias mais importantes;
- Compilação (Build) de 10 minutos: compilar automaticamente todo o sistema e executar todos os testes em dez minutos. Incentiva a automatização do processo de compilação para que seja mais provável que você faça isso regularmente e use esse processo para executar todos os testes;
- Integração contínua (Continuos Integration): as alterações de código são testadas imediatamente quando adicionadas a uma base de código maior. O benefício dessa prática é que você pode detectar e corrigir problemas de integração mais cedo;
- Programação orientada a testes (Test-First Programming): siga o processo de: escrever um teste automatizado → executar teste → desenvolver código para passar no teste → executar teste → repetir;
- Design incremental: o design evolui com a implementação e os requisitos emergentes do sistema.
Práticas secundárias
- Envolvimento real do usuário: se o seu produto gerar valor para os usuários, eles podem estar dispostos a estar sempre envolvidos;
- Deployment incremental: releases pequenas e frequentes, assim que o trabalho em uma tarefa é concluído, ela é integrada a todo o sistema;
- Continuidade da equipe: o valor no desenvolvimento de software é criado não apenas pelo que as pessoas sabem e fazem, mas também por seus relacionamentos e pelo que fazem juntas;
- Encolhimento de equipes: à medida que uma equipe cresce em capacidade, mantenha sua carga de trabalho constante, mas reduza gradualmente seu tamanho. As pessoas que saírem formarão outros times;
- Análise de causa raiz: sempre que um problema for encontrado após o desenvolvimento, elimine-o e também sua causa;
- Código compartilhado: a menos que a equipe desenvolva um senso de responsabilidade coletiva, ninguém será responsável e a qualidade se deteriorará. A integração contínua é outro pré-requisito importante para a propriedade coletiva;
- Código e testes: além dos unit tests, testes automatizados para determinar se a funcionalidade desenvolvida funciona corretamente, realize testes com cliente para verificar se de fato resolve a dor;
- Base de código único: desenvolva em um único lugar e faça deploy em vários dispositivos simultaneamente, sem a necessidade de criá-los individualmente;
- Daily Deployment (Deploy Diário): qualquer lacuna entre o que está na plataforma do developer e o que está em produção é um risco;
- Contrato de escopo negociado: caso seja uma fábrica de software, tenha contratos que estabeleçam tempo, custos e qualidade, mas que exijam uma negociação contínua do escopo do produto ou sistema;
- Pagamento por usuário (pay-per-user): cobre por cada vez que o sistema é usado, o dinheiro é o feedback final (lembre-se que foi escrito na década de 90).
Lembre-se que valores trazem propósito para as práticas e práticas trazem prestação de contas para os valores.
Princípios
Como mencionado, eles fazem a união entre as práticas e valores. Ao todo são 14 princípios:
- Humanidade: o que as pessoas precisam para serem bons desenvolvedores? Segurança básica, realização pessoal, pertencimento, crescimento na carreira, boas relações;
- Economia: certifique-se de que o que você está fazendo tem valor comercial, atende às metas da empresa e às necessidades do negócio;
- Benefício mútuo: busque práticas que beneficiem ao time e usuários;
- Auto-semelhança: uma estrutura ou solução que funciona em um contexto, não necessariamente funcionará em outro. Entretanto, pode ser um bom ponto de partida;
- Melhoria: o ciclo é fazer o melhor que puder hoje, buscando a consciência e a compreensão necessárias para fazer melhor amanhã. Não significa esperar a perfeição para começar;
- Diversidade: pense em várias maneiras de resolver problemas e implementar as soluções. O conflito é o companheiro inevitável da diversidade;
- Reflexão: boas equipes não apenas fazem seu trabalho, mas também pensam em como estão trabalhando e por que estão trabalhando;
- Fluxo: entregue um fluxo constante de software que gere valor, envolvendo-se em todas as atividades de desenvolvimento simultaneamente. Implemente incrementos menores de valor cada vez com mais frequência;
- Oportunidade: conscientemente transforme cada problema em uma oportunidade: uma oportunidade de crescimento pessoal, aprofundamento de relacionamentos e software aprimorado;
- Redundância: o custo da redundância é mais do que pago pela economia de não ter o desastre;
- Falha: a falha não é um desperdício, mas transmite conhecimento;
- Qualidade: garanta que o que é desenvolvido tem bons níveis de qualidade;
- Baby Steps: “qual é o mínimo que você poderia fazer que é reconhecidamente na direção certa?”
- Responsabilidade Assumida: a responsabilidade não pode ser atribuída; só pode ser aceita e abraçada.
Extreme Programming e Product Managers
Nesse momento você provavelmente está pensando em duas coisas:
- “Uau! Quanta coisa, não sei se lembro da metade.”
- “Como um Product Manager entra no meio disso tudo?”
Lembre-se que você poderá sempre revisitar esse material, e como o próprio Ken Beck afirma, a implementação do XP necessita de ajustes regulares, não acontece do dia para noite.
Extreme Programming é escrito por developers e focado em developers. Algumas relações com outros cargos são mencionados no livro, mas rapidamente. O que você enquanto Product Manager precisa ter em mente é que o verdadeiro valor do XP vem primordialmente das suas práticas, como:
- Pair Programming (Programação em Par);
- Programação Orientada a Testes (Test-First Programming);
- Análise de causa raiz;
- Integração Contínua (Continuous Integration);
- Deployment Incremental;
Adotando práticas como essas, pode ter certeza de que a senioridade do time vai crescer na totalidade. Não só você, mas sim todos no time estarão constantemente avaliando se o que é desenvolvido de fato valor para o usuário e para o negócio.
Conclusão
Você deve ter percebido que XP é bastante técnico em alguns momentos, focando-se muito em quem escreve o código. Por isso, convencer quem não tem essa perspectiva do seu valor, pode ser um trabalho difícil.
Caso algum ponto acima faça sentido para você, não precisa ir a sua liderança amanhã e sugerir mudar completamente como sua empresa desenvolve. Mas você pode refletir sobre os valores e, especialmente, as práticas do XP, analisando o que pode fazer sentido para a sua realidade.
Se você se interessou e quer se aprofundar no tema, recomendo buscar materiais em inglês, conversar com alguém que trabalha ou já trabalhou com XP e até mesmo ler o livro Extreme Programming Explained.
Se quiser trocar uma ideia sobre Extreme Programming no dia a dia e como Product Managers se encaixam nisso tudo, me chama no LinkedIn.
Leia também:
