Engenharia de Software - Agiliti - Treinamento e Desenvolvimento de Software

Engenharia de Software

Extreme Programming (XP) é uma metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da década de 90. Vem fazendo sucesso em diversos países, por ajudar a criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica que o habitual. Tais objetivos são alcançados através de um pequeno conjunto de valores, princípios e práticas, que diferem substancialmente da forma tradicional de se desenvolver software.

VALORES DO EXTREME PROGRAMMING

Todos que se envolvem com desenvolvimento de software têm um sentimento sobre aquilo que realmente importa. Uma pessoa pode achar que o que realmente importa é pensar cuidadosamente em todas as decisões de design concebíveis antes de implementá-las. Outra pode achar que importante mesmo é não ter nenhum tipo de restrições sobre sua liberdade pessoal.

O maior problema que eu encontro em relação ao que as pessoas "sabem" sobre desenvolvimento de software é que elas se concentram em ações individuais. O que realmente importa não é como uma pessoa se comporta, mas sim como os indivíduos se comportam como parte de uma equipe e como parte de uma organização.

Por exemplo, as pessoas são apaixonadas por estilos de codificação. Apesar de haver estilos que são sem dúvidas melhores que outros, a questão mais importante em relação a estilos de codificação é que a equipe como um todo escolha adotar um estilo em comum. Estilos de codificação muito peculiares e os valores revelados por eles, liberdade pessoal a qualquer custo, não ajudam a equipe a ter sucesso.

Se todos na equipe se concentrarem naquilo que é importante para a equipe, em que devem se concentrar? XP se baseia em cinco valores para guiar o desenvolvimento:

Comunicação

Coragem

Feedback

Respeito

Simplicidade

PRINCÍPIOS DO EXTREME PROGRAMMING

Princípios existem para servir de ponte entre valores e práticas. Princípios servem como guias que se aplicam a um domínio específico.

Valores são abstratos demais para guiar comportamentos. Documentos longos têm a intenção de comunicar, assim como diálogos. Qual é o mais efetivo? A resposta depende em parte do contexto e, em parte, de princípios intelectuais. Neste caso, o princípio do humanismo sugere que diálogos atendem à necessidade humana de conexão, portanto, é a forma de comunicação preferível, sem levarmos em conta outros fatores.

A comunicação escrita é intrinsecamente mais dispendiosa. Apesar de a comunicação escrita permitir alcançar uma audiência mais ampla, trata-se de uma comunicação de mão única. Conversas, por sua vez, permitem esclarecer questões, feedback imediato, troca de idéias e outras coisas que não são possíveis de serem feitas com documentos. Comunicação escrita normalmente é tida como fato ou rejeitada completamente. Nenhuma das duas opções incentiva aprimoramentos na comunicação.

Os princípios listados aqui não são os únicos possíveis para guiar o desenvolvimento de software. Outros princípios eventualmente guiarão suas práticas de desenvolvimento de software, mas estes são os que guiam o desenvolvimento de software em XP.

Valores indicam o propósito, aquilo em que acreditamos, a razão pela qual agimos de certa forma. Práticas, por sua vez, são nossas ações. Normalmente são específicas, enquanto princípios são genéricos e mais vagos. Princípios, por sua vez, procuram clarificar os valores dentro do contexto de desenvolvimento de software.

Práticas: aquilo que efetivamente fazemos no dia-a-dia. Identificar práticas é útil porque elas são claras e objetivas. Ou você escreve um teste antes do código ou não. Práticas também são úteis porque revelam um ponto de partida claro. Você pode começar escrevendo testes antes de codificar e obter benefícios dessa prática, antes mesmo de compreender o desenvolvimento de software de uma forma mais profunda.

Valores representam a essência daquilo que gostamos ou não a respeito de alguma coisa. Identificar valores é importante, pois sem eles, as práticas perdem sentido. Se tornam atividades feitas por fazer, sem um propósito bem definido. Portanto, valores revelam os propósitos das práticas.

Práticas servem como evidências dos valores. Por sua vez, valores são expressos em um nível tão alto, tão abstrato, que seria possível fazer qualquer coisa em nome de um determinado valor. Por exemplo, "escrevi esse documento de mil páginas porque valorizo comunicação".

Práticas são claras. Todo mundo é capaz de dizer se eu estive presente na reunião de pé de manhã. Agora, dizer se eu valorizo ou não comunicação é algo mais nebuloso. Existe um oceano entre valores e práticas. Valores são universais. Idealmente, meus valores no trabalho são os mesmos do restante da minha vida. Práticas, por outro lado, são completamente situadas. O valor feedback é expresso de formas completamente diferentes nas atividades de programar e trocar fraldas.

Princípios existem para servir de ponte entre valores e práticas. Princípios servem como guias que se aplicam a um domínio específico.

PRÁTICAS DO EXTREME PROGRAMMING

As práticas são vetores de onde você está para onde você pode chegar com XP. Em XP, você progride em direção a esse estado ideal de desenvolvimento eficaz.

Práticas em XP representam aquilo que você verá as equipes XP fazendo diariamente. Práticas por si só são estéreis. A menos que você dê algum propósito, dado por um conjunto de valores, elas não fazem muito sentido. Programação em par, por exemplo, não faz sentido como algo para simplesmente ir fazendo. Fazer par simplesmente para agradar o chefe é frustrante. Programação em par para comunicar, obter feedback, simplificar o sistema, capturar erros e aumentar sua coragem faz bastante sentido.

Práticas dependem da situação, do contexto. Se a situação muda, você seleciona práticas diferentes para abordar estas condições. Seus valores, por sua vez, não têm que mudar para se adaptar a uma nova situação. Alguns novos princípios podem vir a ser necessários quando se muda de domínio.

As práticas são descritas como coisas absolutas. Minha intenção é te motivar em direção à perfeição, prover objetivos claros e prover formas práticas para alcançá-los. As práticas são vetores de onde você está para onde você pode chegar com XP. Em XP, você progride em direção a esse estado ideal de desenvolvimento eficaz. Por exemplo, implantação diária talvez não faça sentido se você só colocar o sistema no ar uma vez ao ano. Implantar o sistema de forma bem sucedida com maior freqüência é uma melhoria, que ajuda a criar confiança para o próximo passo.

Aplicar uma prática é uma escolha. Acredito que as práticas tornam a programação mais eficaz. Essa é uma coleção de práticas que funcionam e funcionam ainda melhor quando aplicadas em conjunto. Elas foram usadas antes. Experimente XP com essas práticas como uma hipótese. Por exemplo, vamos tentar colocar o sistema no ar mais freqüentemente e ver se isso ajuda.

As práticas do XP não representam uma espécie de ápice na evolução do desenvolvimento de software. Elas são apenas uma estação comum na estrada para o aprimoramento. As práticas do XP tendem a funcionar bem em conjunto. Se você as adotar uma de cada vez, certamente perceberá benefícios. Quando elas começam a ser usadas em conjunto, você eventualmente vê melhorias dramáticas. A interação entre as práticas amplifica o efeito das mesmas.

As práticas foram divididas em duas partes: primárias e corolárias. As práticas primárias são úteis independente do que mais você estiver fazendo. Cada uma delas pode gerar um benefício imediato. Você pode começar seguramente com qualquer uma delas. As práticas corolárias tendem a ser difíceis de dominar sem antes colocar em uso as práticas primárias. O efeito amplificado obtido com as práticas em conjunto significa que há uma vantagem em adicionar as práticas tão rapidamente quanto possível.

Práticas Primarias

São práticas que você pode começar a adotar imediatamente de forma segura para melhorar seu esforço de desenvolvimento de software. Qual você deve adotar primeiro depende inteiramente de seu ambiente e o que você entende como sendo sua maior oportunidade de melhoria. Algumas pessoas precisam de planejamento porque não sabem o que precisa ser feito. Outros precisam de práticas relacionadas à melhoria de qualidade porque estão criando defeitos demais para serem capazes de ver o que está acontecendo.

Ambiente Informativo

Build de Dez Minutos

Ciclo Semanal

Ciclo Trimestral

Desenvolvimento Orientado a Testes

Design Incremental

Equipe Integral

Folga

Histórias

Integração Contínua

Programação em Par

Sentar-se Junto

Trabalho Energizado

Práticas Corolárias

As práticas corolárias são difíceis ou perigosas de serem implementadas antes de se adotar as práticas primárias. Se você começar a implantar o software diariamente, por exemplo, sem baixar a taxa de defeitos para algo muito próximo de zero (com programação em par, integração contínua e desenvolvimento orientado a testes), você terá um desastre nas mãos. Confie na sua intuição sobre o que é a próxima coisa que precisa ser aprimorada. Se algumas das práticas a seguir parecer apropriada, tente-a. Talvez funcione ou talvez você descubra que há mais trabalho a ser feito antes que você possa usá-las para aprimorar seu processo de desenvolvimento.

Análise da Raiz do Problema

Base de Código Unificada

Código Coletivo

Código e Testes

Continuidade da Equipe

Contrato de Escopo Negociável

Envolvimento do Cliente Real

Equipes que Encolhem

Implantação Diária

Implantação Incremental

Pagar Por Uso

Reunião em Pé