Integrando XP as principais metodologias ágeis

Durante anos, a produção de software foi feita com base em modelos antigos que aparentemente funcionavam, pois no início da década de 80 a Business Week apresenta a manchete de capa “Software: A nova força propulsora” (PRESSMAN, 1995), mas este modelo não perdurou, pois ainda na década de 80, segundo Pressman, a Fortune trazia uma reportagem de capa dizendo “Uma crescente defasagem de software” (PRESSMAN, 1995), isso devido à falta de amadurecimento dos processos de desenvolvimento. A própria Business Week, que outrora trazia na capa um incentivo à indústria de software, no final da década de 1980 trazia o artigo avisando a gerentes sobre a possível armadilha de aquisição de software. A Newsweek trazia a pergunta “Podemos confiar em nossos softwares?” (PRESSMAN, 1995). Passado mais de 20 anos, o Standish Group trazia pesquisas apontando o insucesso da produção de software, pois menos de 20% dos projetos de software, na década de 1990, eram concluídos com sucesso. Esta crise levou ao descrédito das empresas de softwares no mundo todo e também tinha ocorrido nas indústrias em geral como, por exemplo, na indústria automobilística, metalúrgica, etc. A crise que na década de 1960 e 1970 fez surgir no Japão novos modelos de produção, entre eles a filosofia Just in time (JIT) e que consiste em uma proposta de reorganização do ambiente produtivo assentada no entendimento de que a eliminação de desperdícios visa o melhoramento contínuo dos processos de produção.

O JIT é a base para a melhoria da posição competitiva de uma empresa, em particular no que se refere aos fatores velocidade, qualidade e o preço dos produtos. Segundo Slack, Chambers e Johnston, Just in time (JIT) “significa produzir bens e serviços exatamente no momento em que são necessários – não antes para que não formem estoques e não depois para que seus clientes não tenham de esperar” (2009, p 482). Desta forma, o JIT visa atender à demanda instantaneamente, com qualidade e sem desperdício.

Ainda segundo SLACK, CHAMBERS e JOHNSTON (2009, p 487), três são as razões-chaves que definem o núcleo da filosofia JIT: “eliminação de desperdício, envolvimento dos funcionários na produção e o esforço de aprimoramento continuo”.

Com base no sucesso desta filosofia que Kent Beck, um dos signatários do manifesto ágil em 2001, criou na década de 90 o eXtreme Programming (XP) que, assim como o JIT, propõe que a produção deve ser realizada na hora exata, ou seja, evita-se gastar tempo, produzindo por antecedência.

O que é o XP?

O XP, segundo BECK (2000, p. Xi), é “uma metodologia leve para times de tamanho pequeno a médio, que desenvolva software em face a requisitos vagos que se modificam rapidamente”.

O XP é na verdade um dos modelos de engenharia de software ágil, que segundo Pressman: “A engenharia de software ágil combina filosofia com um conjunto de princípios de desenvolvimento. A filosofia defende a satisfação do cliente e a entrega de incremental prévio; equipes de projetos pequenas e altamente motivadas; métodos informais; artefatos de engenharia de software mínimos e, acima de tudo, simplicidade no desenvolvimento geral. Os princípios de desenvolvimento priorizam a entrega mais que a análise e projeto (embora essas atividades não sejam desencorajadas); também priorizam a comunicação ativa e contínua entre desenvolvedores e clientes”. (PRESSMAN, 2011)

Mas como funciona o XP?

O XP é um método sistêmico para desenvolvimento de software. O processo inicia por um plano geral, ou seja, entender o problema como um todo, mas sem muitos detalhes e, posteriormente, reparte o problema em partes, para dar início ao seu desenvolvimento.

Como adotar o XP?

Segundo Beck, pode-se utilizar três passos para a implementação do XP:

1. Escolha o pior dos problemas;
2. Resolva-o da maneira XP;
3. Quando ele não for mais seu problema, repita os passos 1 e 2 para o próximo problema.

Desta forma, utilize uma prática XP por vez, mas tenha em mente os seus valores, assim, é possível se adaptar ao XP, até ter sua implementação por completo no seu projeto.

O uso do XP é uma mudança no paradigma tradicional, o que pode implicar em confusão no início da sua implementação. A vontade de mudar é uma virtude, mesmo que confunda parte da empresa durante um tempo (COHN, 2011).

Esta mudança exige conhecer os valores, princípios e técnicas que fazem parte das bases do XP.

As bases do XP

O XP tem como base quatro valores: comunicação, simplicidade, feedback e coragem.

1. Comunicação: A má comunicação é motivo de insucesso em quase todo tipo de projeto, inclusive nos projetos de software. Logo, este é um dos valores mais importantes do XP, bem como das metodologias ágeis como um todo. Esta comunicação deve fluir constantemente através das técnicas a serem aplicadas no processo de desenvolvimento;
2. Simplicidade: Manter a simplicidade é difícil e é um dos princípios do XP advindos do JIT. Assim, faça a coisa mais simples que pode funcionar, mesmo assim, é um dos princípios mais difíceis de se alcançar, pois somos tentados a fazer algo complexo pensando no futuro, mas é importante lembrar que uma das filosofias do JIT é a eliminação de desperdício, assim, simplicidade é uma obrigação.
3. Feedback: Muito se fala em feedback na atualidade e aqui ele não é só necessário, como um dos princípios que fazem com que o XP tenha sucesso. Para isso, o uso do TDD passa a ser tão importante, além disso, é importante o feedback do cliente, por isso os ciclos curtos, a integração contínua etc.
4. Coragem: Este é o último valor do XP, mas não menos importante, pois é necessário ter coragem de jogar um código fora e iniciar do zero, coragem para mudanças. A comunicação nos dá coragem para a mudança, pois temos a noção das reais necessidades do cliente.

Com base nestes valores, temos os princípios do XP.

Os quatro valores geram os princípios básicos do XP, que segundo Kent Beck são:

1. Feedback rápido através de ciclos curtos (iteração de uma a duas semanas) e comunicação continua (com todos os envolvidos no processo);
2. Simplicidade presumida, onde deve-se tratar os problemas de forma simples, ou seja, evitar tratar o problema com complexidade, utilizando recursos que nunca serão utilizados, fazendo apenas o necessário;
3. As mudanças devem ser feitas de forma incremental. Grandes modificações normalmente trazem grandes problemas, então tratar a mudança com ciclos de mudanças curtos é mais eficiente e atende as bases sistêmicas do paradigma.
4. Alta qualidade: ninguém gosta de pessoas desleixadas, então a qualidade deve ser sentida não só pelo cliente, mas pela equipe. O teste não é uma opção, é uma obrigação.

Dos princípios e valores, temos então as quatro atividades básicas que é codificar, testar, ouvir e projetar.

Para atender aos seus princípios e valores durante as atividades, o XP utiliza práticas simples, como veremos a seguir e também na Figura 1.

• Jogo de planejamento: é a prática que define o escopo a ser desenvolvido na próxima iteração. Para esta definição de escopo é necessário priorizar as necessidades de negócio (ponto de vista do cliente) em conjunto com as estimativas técnicas (ponto de vista dos programadores). Se o planejamento for falho, atualize-o;
• Entregas frequentes: Durante a iteração de uma ou duas semanas, o que estiver com status de pronto deve ser entregue ao cliente, assim, a equipe recebe o feedback mais rapidamente. Não espere todo o projeto estar concluído, entregue frequentemente;
• Uso de metáforas: as metáforas devem guiar o desenvolvimento, através das histórias de usuário simplificada e compartilhada com todos;
• Projeto simplificado: Quanto mais simples for o projeto, mais rápido é seu desenvolvimento. Complexidades desnecessárias devem ser removidas sempre que forem descobertas, isso mantém o ritmo e a qualidade do produto;
• Testes: Tudo deve ser testado: programadores devem utilizar as práticas de TDD para melhorar a qualidade do produto;
• Refatoração: Outra prática necessária para melhorar o design e a qualidade do produto. Reestruturar o sistema, sem alterar o seu comportamento, removendo sempre que possível a duplicidade, melhorando e simplificando o que já existe e tornando-o mais flexível;
• Programação em pares: o desenvolvimento é guiado pela programação em par, ou seja, todo o sistema é implementado por dois programadores em uma única máquina;
• Propriedade coletiva: os códigos não têm um dono, ou seja, viu que precisa melhorar (refatorar)? Faça você mesmo e não espere pelos outros, pois todos podem modificar qualquer parte do código a qualquer momento;
• Integração contínua: se temos que entregar constantemente, é através da integração contínua que atingiremos este objetivo. Integre e atualize as versões do sistema várias vezes ao dia, cada vez que uma nova tarefa for concluída;
• Ritmo sustentável: A semana deve ser de 40 horas no máximo, ou seja, trabalhe no máximo oito horas por dia durante quatro dias, evite fazer hora extras, pois a produtividade é reduzida;
• Cliente presente: Precisamos de comunicação constante, desta forma, inclua sempre um cliente real no time;
• Padrões de codificação: Utilize padrões, assim os programadores escreverão seus códigos respeitando as regras e isso cria uma comunicação através do código.

Implementando o XP

Com as práticas já definidas, como é possível implementar o XP nas práticas de desenvolvimento?

O funcionamento do XP é simples, através do plano de planejamento, realizado com o Jogo de planejamento, realiza a iteração.

Na iteração é criado primeiro os testes e feita a codificação, é refatorado o código (prática denominada TDD), conforme pode ser visto na Figura 2.

A adoção do XP pode iniciar pelo TDD, prática que busca melhorar a qualidade e design do sistema e depois pelo jogo de planejamento, assim a equipe vai acostumando-se com as novas práticas. As práticas explanadas anteriormente proporcionam resultados quase que imediatos na qualidade geral do produto e a cada iteração a equipe torna-se mais extrema, até conseguir implementar o XP por completo.

A equipe XP é composta de dois a 10 (podendo ser 12, por exemplo) desenvolvedores. Conforme Beck, XP foi desenvolvida para funcionar em projetos com times de dois a 10 programadores, que não sejam severamente restringidos pelo ambiente computacional existente e nos quais boa parte da execução de testes possa ser feito em uma fração de dia. Por isso, evite equipes muito grandes.

Equipes com mais de 12 integrantes devem ser divididas em duas equipes, pois a comunicação começa a reduzir. Aqui entra um dos preceitos da agilidade: passar a valorizar mais os indivíduos e as interações entre eles mais do que processos e ferramentas (Manifesto Ágil), assim, equipes pequenas tem maior possibilidade de interagir entre si. Além disso, equipes menores são mais produtivas, segundo Cohn, equipes menores demandam menos esforço total para entregar um projeto de mesmo tamanho.

Ciclo de vida XP

O início do ciclo de vida XP se dá através da exploração, em que há um contato inicial da equipe com o que será desenvolvido, do programador com a tecnologia, do cliente com a escrita das histórias de usuário, etc.

A partir da exploração, vem a fase de planejamento, que tem como propósito definir, através de um acordo entre cliente e programador, o tempo de desenvolvimento, quais histórias tem maior e menor valor para o cliente e quais as dificuldades para se desenvolver tais histórias.

Na etapa de planejamento é feito o planejamento da iteração e as estimativas do sistema.

Com o plano pronto, se segue para a próxima fase, que é a iteração. Ela dura de uma a quatro semanas, segundo Back (alguns autores preferem de uma a duas semanas).

A primeira iteração normalmente é para a definição de arquitetura, assim, é importante que a equipe escolha as histórias que permitam criar o esqueleto do sistema como um todo na primeira iteração. Já nas iterações posteriores, desenvolve-se as histórias que tenham maior valor de negócio para o cliente.

Durante a iteração, ou seja, o ciclo de produção do sistema, é o momento em que o programador utiliza as práticas como TDD, integração contínua, teste de aceitação etc., buscando, neste ponto, ser eXtremo.

Ser eXtremo, no conceito do XP, é tornar as melhores práticas como um item obrigatório e não opcional, ou seja, a equipe vai garantir a qualidade, vai integrar continuamente, vai manter um feedback constante, vai possuir comunicação com o cliente etc. Isso ocorre, pois as práticas, se utilizadas em conjunto, resultam em produtos de alta qualidade e poucos defeitos, evitando-se assim o retrabalho, pois há provas de que o TDD leva a menos defeito. Dois estudos da Microsoft descobriram que o número de erros encontrados diminuiu entre 20% e 38% com o uso do TDD (Cohn, 2011, p. 180).

O XP busca a excelência técnica obrigatória para melhoria contínua do processo e esta faz com que a equipe torne-se perita nas melhores práticas de desenvolvimento, ou seja, torne-se extrema.

Sobre os papéis no XP

Bem, agora já sabemos os valores, princípios, práticas e como funciona o ciclo de vida XP, mas quais são os papéis dentro do XP?

Em XP cada colaborador do projeto é parte da Equipe.

Dentro de uma equipe, há sempre papéis, por exemplo, no Vôlei temos o levantador, a defesa e o atacante; no futebol temos defesa, meio de campo, goleiro etc., isso é normal em todos os times: um tem a função de apoio, outro de ataque e assim por diante. É um hábito antigo a separação por papéis e um bom treinador sabe inserir seu jogador na posição correta. No XP não é diferente, há papéis para os membros da equipe. São eles:

• Programador: segundo Back, ele é o coração do XP, pois o principal foco é a implementação. A diferença entre um programador em outras metodologias e no XP é que aqui ele precisa se preocupar com a comunicação, com o design do sistema, com os testes unitários, com ser eXtremo.
• Cliente: Se o programador é quem implementa, o cliente é quem sabe o que deve ser implementado, ou seja, é quem conhece o produto. O título de cliente é dado a pessoa responsável por escrever as histórias de usuário, por defender os interesses do cliente, por saber dar valor as histórias (valor do ponto de vista de importância ao negócio).
• Testador: Como o programador já fez os testes unitários, a tarefa do testador está relacionada aos testes funcionais e por sua execução frequente.
• Rastreador: Back afirma que o rastreador é a consciência da equipe, sendo o responsável por finalizar a iteração, por uma visão global do andamento do sistema, etc. Este papel necessita de habilidade de coleta de informação e boa comunicação interpessoal.
• Treinador: Assim como no vôlei temos um treinador, equipes XP possuem um treinador que é o responsável pelo processo como um todo e por manter o XP funcionando.
• Consultor: Não é obrigatório, mas quando há necessidade, equipes XP podem chamar um consultor ad hoc.
• O Chefão: este é o manda chuva, quem manda em tudo...

Ninguém tem maior importância no grupo, mas todos tem suas atribuições e devem buscar a qualidade total dos seus processos. O programador deve especializar-se na sua tarefa e deve ainda cultivar as boas práticas, como o uso de Design Patterns etc. Só assim a equipe vai se tornar uma equipe XP, uma equipe eXtrema.

Até aqui, percorremos um longo caminho nos valores, princípios, práticas e no ciclo de vida XP, mas é importante que se tenha em mente que a prática é essencial para o sucesso do XP.

Como programador, a utilização das técnicas torna o resultado mais eficiente, com menos erros, ou seja, com mais qualidade. Mas não é só o programador o foco do XP, mas toda a equipe, assim, o treinador deve estar preparado para treinar sua equipe, composta por clientes, programadores, testadores, para que possam obter bons frutos na utilização do XP. O treinador também deve perceber quando a equipe está ficando grande e ingerenciável, para iniciar o processo de divisão em duas equipes.

É o treinador que tem como função manter o XP funcionando quando alguém sai do padrão eXtremo, é ele que auxilia no retorno. Ele deve conhecer as teorias de gestão de equipe para poder utilizar todo o potencial da equipe nos projetos.

Apesar de ser um método ágil, o XP segue padrões. Conforme Beck, o XP é uma disciplina de desenvolvimento de software. É uma disciplina porque há certas coisas que precisam ser feitas para estar fazendo XP. Você não poderá escolher se escreverá ou não os testes – se não escrever, você não é eXtremo e ponto final.

A equipe XP mantém o sistema integrado e funcionando o tempo todo. Programadores escrevem todo o código de produção em pares, todos trabalham em conjunto para a excelência do produto. Eles codificam em um estilo consistente para que todos possam entender e melhorar todo o código conforme necessidade da equipe. O cliente mantém os programadores informados sobre suas necessidades, o treinador mantém a equipe coesa e o testador valida as funcionalidade. Tudo para que o resultado seja de alta qualidade.

Segundo Tenório e Valle, os processos dominantes no desenvolvimento de software foram: nas décadas de 60, 70 e 80 os Processos proprietários; entre 80 e 90 o CMM; entre 90 e 2000 o PMI, Asap, RUP e ISO; e neste século: XP, ASD e LD (2013).

Um ponto importante é que o XP pode ser implementado em conjunto com outras metodologias ágeis, como o Scrum, pois ambas seguem as bases do manifesto ágil:

• Os indivíduos e as interações são mais importantes do que os processos e as ferramentas;
• O software funcionando é mais importante do que uma documentação completa;
• A colaboração com os clientes está acima das negociações de contratos e;
• Respostas a mudanças estão acima de apenas seguir um plano.