o jogo de planejamento

o planejamento XP aborda duas questões-chave no desenvolvimento de software: prever o que será realizado até a data limite, e determinar o que fazer a seguir. A tónica é colocada na condução do projecto – que é bastante simples – e não na previsão exacta do que será necessário e do tempo que irá demorar–, o que é bastante difícil., Há duas etapas chave de planejamento em XP, abordando estas duas questões:

planejamento de lançamento é uma prática em que o cliente apresenta as características desejadas para os programadores, e os programadores estimam sua dificuldade. Com as estimativas de custos em mãos, e com conhecimento da importância das características, O cliente estabelece um plano para o projeto. Os planos iniciais de lançamento são necessariamente imprecisos: nem as prioridades nem as estimativas são realmente sólidas, e até que a equipe comece a trabalhar, não saberemos o quão rápido eles irão., Mesmo o primeiro plano de lançamento é preciso o suficiente para a tomada de decisões, no entanto, e as equipes do XP revisam o plano de lançamento regularmente.

iteração planejamento é a prática pela qual a equipe é dada direção a cada duas semanas. As equipes XP constroem software em “iterações” de duas semanas, entregando software útil em execução no final de cada iteração. Durante o planejamento da iteração, o cliente apresenta os recursos desejados para as próximas duas semanas. Os programadores os dividem em tarefas, e estimam seu custo (em um nível de detalhe mais fino do que no planejamento de lançamento)., Com base na quantidade de trabalho realizado na iteração anterior, a equipe se inscreve para o que será realizado na iteração atual.estes passos de planeamento são muito simples, mas fornecem informações muito boas e um excelente controlo de direcção nas mãos do cliente. A cada duas semanas, a quantidade de progresso é inteiramente visível. Não há “noventa por cento feito” no XP: uma história de recurso foi concluída, ou não foi., Este enfoque na visibilidade resulta em um pequeno paradoxo: por um lado, com tanta visibilidade, o cliente está em posição de cancelar o projeto se o progresso não for suficiente. Por outro lado, o progresso é tão visível, e a capacidade de decidir o que será feito a seguir é tão completa, que os projetos XP tendem a fornecer mais do que é necessário, com menos pressão e estresse.

testes do cliente

como parte da apresentação de cada característica desejada, o cliente XP define um ou mais testes de aceitação automatizados para mostrar que a funcionalidade está funcionando., A equipe constrói esses testes e os utiliza para provar a si mesmos, e ao cliente, que o recurso é implementado corretamente. Automação é importante porque na imprensa de tempo, os testes manuais são ignorados. É como apagar as luzes quando a noite fica mais escura.

As melhores equipas XP tratam os seus testes ao cliente da mesma forma que fazem testes programadores: uma vez que o teste é executado, a equipa mantém-no a correr correctamente a partir daí. Isto significa que o sistema só melhora, sempre avançando, nunca recuando.,

pequenas versões

equipas XP praticam pequenas versões de duas formas importantes:

primeiro, a equipa liberta o software em execução, testado, fornecendo o valor de negócio escolhido pelo cliente, cada iteração. O cliente pode usar este software para qualquer finalidade, seja avaliação ou até mesmo lançamento para os usuários finais (altamente recomendado). O aspecto mais importante é que o software é visível, e dado ao cliente, no final de cada iteração. Isto mantém tudo aberto e tangível.

Em segundo lugar, as equipes XP lançam para seus usuários finais com freqüência também., XP web projects lançamento tão frequentemente quanto diariamente, em house projects mensal ou mais frequentemente. Mesmo produtos embalados por encolhimento são enviados tão frequentemente quanto trimestral.

pode parecer impossível criar boas versões muitas vezes, mas equipes do XP estão fazendo isso o tempo todo. Veja integração contínua para mais sobre isso, e note que essas versões freqüentes são mantidas confiáveis pela obsessão da XP com testes, como descrito aqui em testes de clientes e Desenvolvimento Orientado a testes.

Design simples

equipas XP constroem software para um design simples mas sempre adequado., Eles começam simples, e através de testes programadores e melhorias de design, eles mantêm-no assim. Uma equipe XP mantém o projeto exatamente adequado para a funcionalidade atual do sistema. Não há movimento desperdiçado, e o software está sempre pronto para o que vem a seguir.

Design in XP is not a one-time thing, or an up-front thing, it is an all-the-time thing. Há passos de design no planejamento de lançamento e iteração, além de equipes se engajam em sessões de design rápido e revisões de design através de refactoring, através do curso de todo o projeto., Em um processo iterativo incremental, como programação extrema, um bom design é essencial. É por isso que há tanto foco no design ao longo de todo o desenvolvimento.

Pair Programming

todo o software de produção em XP é construído por dois programadores, sentados lado a lado, na mesma máquina. Esta prática garante que todo o código de produção é revisado por pelo menos um outro programador, e resulta em melhor design, melhor teste e melhor código.

pode parecer ineficiente ter dois programadores fazendo “um trabalho de programador”, mas o inverso é verdadeiro., A pesquisa sobre a programação de pares mostra que emparelhamento produz um código melhor em aproximadamente o mesmo tempo que programadores trabalhando sozinhos. Isso mesmo: duas cabeças são mesmo melhores que uma!

alguns programadores objetam emparelhar programação sem nunca tentar. É preciso alguma prática para fazer bem, e você precisa fazer bem por algumas semanas para ver os resultados. Noventa por cento dos programadores que aprendem a programação em pares preferem-no, por isso recomendamos-o a todas as equipas.o emparelhamento, além de fornecer um melhor código e testes, também serve para comunicar conhecimento em toda a equipe., Como troca de pares, todos recebem os benefícios do conhecimento especializado de todos. Os programadores aprendem, suas habilidades melhoram, eles se tornam mais valiosos para a equipe e para a empresa. Emparelhar, mesmo fora do XP, é uma grande vitória para todos.

Test-Driven Development

Extreme Programming is obsessed with feedback, and in software development, good feedback requires good testing. Top XP teams practice “test-driven development”, working in very short cycles of adding a test, then making it work., Quase sem esforço, as equipes produzem código com quase 100% de cobertura de teste, o que é um grande passo em frente na maioria das lojas. (Se seus programadores já estão fazendo testes ainda mais sofisticados, mais poder para você. Continua assim, só pode ajudar!)

não é suficiente para escrever testes: você tem que executá-los. Também aqui a programação extrema é extrema. Estes “testes programadores”, ou “testes unitários” são todos coletados em conjunto, e cada vez que qualquer programador libera qualquer código para o repositório (e os pares tipicamente liberam duas vezes por dia ou mais), cada um dos testes programadores deve ser executado corretamente., Cem por cento, a toda a hora! Isso significa que os programadores recebem feedback imediato sobre como eles estão fazendo. Além disso, estes testes fornecem suporte inestimável à medida que o projeto de software é melhorado.

melhoria do Design (Refactoring)

a programação extrema centra-se na entrega de valor de negócio em cada iteração. Para realizar isso ao longo de todo o projeto, o software deve ser bem projetado. A alternativa seria abrandar e, em última análise, ficar preso., Assim XP usa um processo de melhoria contínua do design chamado Refactoring, do título do Livro de Martin Fowler, “Refactoring: Improving the Design of Existing Code”.

o processo de refactoração centra-se na remoção da duplicação (um sinal seguro de mau design), e no aumento da “coesão” do Código, reduzindo o “acoplamento”. Alta coesão e acoplamento baixo têm sido reconhecidos como as marcas de código bem projetado por pelo menos trinta anos. O resultado é que as equipes XP começam com um design bom e simples, e sempre têm um design bom e simples para o software., Isto permite-lhes manter a sua velocidade de desenvolvimento e, de facto, aumentar a velocidade à medida que o projecto avança.

Refactoring é, naturalmente, fortemente suportado por testes abrangentes para ter certeza de que à medida que o projeto evolui, nada é quebrado. Assim, os testes do cliente e os testes programadores são um fator ativador crítico. As práticas XP apoiam-se mutuamente: são mais fortes em conjunto do que separadamente.

Integração Contínua

equipas de programação extremas mantêm o sistema totalmente integrado em todos os momentos. Nós dizemos que as construções diárias são para wimps: as equipes XP constroem várias vezes por dia., (Uma equipe XP de quarenta pessoas constrói pelo menos oito ou dez vezes por dia!)

O benefício desta prática pode ser visto pensando em projetos que você pode ter ouvido sobre (ou mesmo ter sido uma parte de) onde o processo de construção era semanal ou menos frequentemente, e geralmente levou a “inferno de integração”, onde tudo quebrou e ninguém sabia por que.a integração pouco frequente conduz a problemas graves num projecto de software., Em primeiro lugar, embora a integração seja fundamental para o envio de um bom código de trabalho, a equipe não é praticada nele, e muitas vezes é delegada a pessoas que não estão familiarizadas com todo o sistema. Em segundo lugar, o código pouco frequentemente integrado é – eu diria normalmente – um código de buggy. Problemas surgem em tempo de integração que não são detectados por nenhum dos testes que ocorrem em um sistema não integrado. Em terceiro lugar, o fraco processo de integração leva a um longo bloqueio de código., O código congela significa que você tem longos períodos de tempo em que os programadores podem estar trabalhando em recursos shippable importantes, mas que esses recursos devem ser retidos. Isso enfraquece sua posição no mercado, ou com seus usuários finais.

Code Ownership

em um projeto de programação extrema, qualquer par de programadores pode melhorar qualquer código a qualquer momento. Isto significa que todo Código recebe o benefício da atenção de muitas pessoas, o que aumenta a qualidade do código e reduz defeitos., Há um outro benefício importante assim: quando o código é de propriedade de indivíduos, recursos necessários, geralmente são colocadas no lugar errado, como um programador descobre que ele precisa de um recurso em algum lugar no código que ele não possui. O proprietário está muito ocupado para fazê-lo, então o programador coloca o recurso em seu próprio código, onde ele não pertence. Isso leva a código feio, difícil de manter, cheio de duplicação e com baixa (ruim) coesão.a propriedade coletiva poderia ser um problema se as pessoas trabalhassem cegamente em código que não entendessem., O XP evita estes problemas através de duas técnicas chave: o programador testa erros de captura, e a programação em pares significa que a melhor maneira de trabalhar em código desconhecido é fazer par com o especialista. Além de garantir boas modificações quando necessário, esta prática espalha conhecimento em toda a equipe.

código padrão

XP equipes seguem um padrão de codificação comum, de modo que todo o código no sistema parece ser escrito por um único – muito competente-indivíduo., As especificidades da norma não são importantes: o que é importante é que todo o código pareça familiar, em apoio à propriedade coletiva.

Metaphor

equipas de programação extremas desenvolvem uma visão comum de como o programa funciona, que chamamos de “metáfora”. No seu melhor, a metáfora é uma simples descrição evocativa de como o programa funciona, como “este programa funciona como uma colmeia de abelhas, saindo para o pólen e trazendo-o de volta para a colmeia” como uma descrição para um sistema de recuperação de informação baseado em agentes.às vezes, uma metáfora suficientemente poética não surge., Em qualquer caso, com ou sem imagens vívidas, equipes XP usa um sistema comum de nomes para ter certeza de que todos entendam como funciona o sistema e onde procurar para localizar a funcionalidade que você está procurando, ou para encontrar o lugar certo para colocar a funcionalidade que você está prestes a adicionar.

ritmo sustentável

equipas de programação extremas estão nele a longo prazo. Eles trabalham duro, e a um ritmo que pode ser sustentado indefinidamente. Isto significa que eles trabalham horas extras quando é eficaz, e que normalmente trabalham de forma a maximizar a produtividade semana dentro e semana fora., Hoje em dia, sabe-se muito bem que os projectos da death march não são produtivos nem produzem software de qualidade. As equipas XP estão nisto para ganhar, não para morrer.

conclusão

programação extrema é uma disciplina de desenvolvimento de software baseado em valores de simplicidade, Comunicação, feedback e coragem. Ele funciona reunindo toda a equipe na presença de práticas simples, com feedback suficiente para permitir que a equipe veja onde eles estão e sintonize as práticas para sua situação única.