1/10/2019 10:03:51 AM

O que não é Extreme Programming!

Tecnologia extreme programming metodologia ágil agile

Conheça essa metodologia ágil que é voltada para times de pequeno a médio porte.

A cada dia que passa, é possível notar que o mercado está mais aquecido quando se trata de metodologias ágeis de desenvolvimento de software. Podemos observar também, o número crescente de organizações que estão passando por uma transformação digital ou que passaram por esta transformação nos últimos anos.

O uso de metodologias ágeis de desenvolvimento de software tem como objetivo melhorar a comunicação dos times, focando mais em indivíduos e interações do que em processos e ferramentas. Além disto, as metodologias ágeis se baseiam em entregas interativas e incrementais, promovendo uma melhor qualidade do que o cliente final recebe.

Scrum e kanban costumam ser as metodologias mais conhecidas e abordadas em eventos de TI, mas hoje, vamos falar um pouco sobre uma metodologia ágil que tem suas raízes bem fortes na engenharia de software, porém não é tão difundida no mercado: Extreme Programming (XP).

O XP foi desenvolvido por Kent Beck, Ward Cunningham e Ron Jeffries. Essa é uma metodologia ágil voltada para times de pequeno a médio porte, cuja as principais características são os requisitos vagos e que mudam frequentemente. A principal ideia do XP é a criação de softwares de alta qualidade, para isso, a codificação tem ênfase menor nos processos formais de desenvolvimento e possui uma maior disciplina de engenharia ágil para codificação e testes.  Os principais valores do XP são a comunicação, a simplicidade, o feedback, a coragem e o respeito. (WILDT; MOURA; LACERDA; HELM, 2018)

                Dentro do XP existe uma sinergia entre as práticas, valores e papéis pregados pela metodologia e muitas empresas, mesmo as que não a utilizam como um todo, acabam empregando algumas dessas práticas no seu dia a dia. Porém, nos meus 10 anos de experiência na área de TI, pude observar que muitos das empresas que aplicam essas práticas, acabam as utilizando de modo incorreto, e essa constatação me motivou a escrever esse artigo.

                A primeira prática que as empresas utilizam de uma forma incorreta é o jogo do planejamento. Nesta prática, a expectativa é envolver o cliente e os desenvolvedores para planejar as entregas.  A escrita de histórias, priorização e criação das estimavas são realizadas com o time e cliente juntos. Porém, o que acontece em muitas empresas é o não envolvimento do cliente nem do próprio time no planejamento. Existe um top down dos prazos e das entregas, ou seja, algum gestor realiza o planejamento das atividades, faz a estimativa e passa isso para o time, sem de fato ter um envolvimento das pessoas.

Porém, em todas as fases de aplicação de XP é necessário que se tenha envolvimento do cliente com o time, de preferência presencialmente. O cliente deve ser envolvido para ajudar a entender o problema, criar a solução, realizar feedbacks e priorizar as histórias. Mas é muito comum encontrarmos o seguinte cenário: uma pessoa conversa com o cliente e repassa para as demais pessoas da equipe todas as informações. Isso pode gerar um telefone sem fio, distorcendo o que foi passado pelo cliente. Muitas vezes, as informações que chegam no time são tão diferentes do que foi conversado com o cliente ao ponto de serem realizadas entregas distintas do que foi pensado e solicitado pelo cliente. Esse é apenas um dos exemplos do problema que pode ocasionar a utilização incorreta da prática cliente presente.

                Não poderia falar das práticas do XP sem falar do core da metodologia: projeto simples, testes automatizados e programação em pares. Nem sempre é fácil manter um projeto simples e um padrão aceitável de codificação do início ao fim de um projeto. Mas a simplicidade do código facilita o desenvolvimento e manutenção do sistema. Porém, é importante lembrar que tentar prever o futuro não vai de acordo com o que prega o XP. Então é importante pensar por partes, utilizando o conceito de MVP (Minimum Viable Product), no qual sempre é implementado primeiro o que mais agrega valor para o negócio. Aplicar o conceito de TDD (Test Driven Development), iniciando a codificação pelos testes para depois desenvolver a funcionalidade também vem de encontro com o que o XP prega, além de estabelecer uma meta de cobertura de testes e manter o código o mais próximo possível desta meta, com o objetivo de garantir a qualidade.

Essas duas práticas, aliadas com a utilização de programação em pares, tendem a melhorar muito a qualidade do que está sendo entregue. Na programação em pares, se espera que tenha um piloto e um co-piloto, ambos em um computador e focados na mesma tarefa, essa prática promove a revisão do código de forma continua, além de fomentar a discussão técnica da solução e nivelamento de conhecimento entre os membros do time. Mas as organizações estão de fato utilizando essas práticas da maneira como foram pensadas por Kent Beck, Cunningham e Jeffries?

Bom, a realidade que vejo em alguns projetos é que na primeira entrega o código está simples, padronizado, rodando testes com um nível aceitável de cobertura. Mas a partir do momento que começa a surgir a pressão por prazos, a qualidade vai sendo deixada de lado. Com isso, começam as gambiarras, códigos sem padronização, difíceis de dar manutenção e cheio de defeitos. Percebo que muitos líderes pensam que é uma perda de dinheiro realizar programação em par. E por que será que eles pensam isso? Noto, que existem dois motivos que levam os gestores a terem esse mindset. O primeiro deles é a falta de conhecimento sobre a prática, não vendo o valor agregado que traz para o dia a dia.  Outra situação comum é que a programação em pares não é levada a sério pelos desenvolvedores. É comum observar nas empresas um dos desenvolvedores focado e o outro disperso. Outro ponto comum ao observar as duplas pareando é que existe um conflito de interesses por parte de alguns desenvolvedores, no qual há uma disputa de conhecimento e ego, fazendo com que a prática não seja efetiva para melhorar a solução, mas pelo contrário, ocasione desentendimentos entre os envolvidos.

Ao utilizar XP se espera que ocorram entregas frequentes e pequenas. Com alto padrão de qualidade. Promovendo um feedback rápido do cliente, redução da taxa de defeitos. No entanto, em alguns times ainda ocorre o mesmo modelo de entrega dos projetos cascata, no qual é realizada apenas uma entrega no final do projeto. Isso não gera engajamento do cliente e muitas vezes são entregues várias funcionalidades sem sentido. Porém, como a entrega é realizada apenas no final, esses problemas são descobertos somente no final no projeto, gerando alto custo com retrabalho, desmotivação dos envolvidos, criação de expectativa e frustração do cliente por não receber as entregas interativas e incrementais e receber algo diferente do que esperava no final.

                Embora tenha sido uma das primeiras metodologias criadas e sempre focada em utilizar recursos que de fato melhorem a qualidade das entregas, dados do state of agile nos mostram que a cada ano que passa, está ocorrendo uma queda na utilização do XP nas organizações. O gráfico a seguir, nos mostra essa queda entre os anos de 2010 a 2017:

Fonte: http://stateofagile.versionone.com/


Comparado com as outras metodologias, podemos observar que apenas 1% do mundo está utilizando XP:

Fonte: http://stateofagile.versionone.com/ - tradução livre
 

E por que as empresas estão passando a utilizar menos o XP do que outras metodologias? O primeiro ponto, está muito vinculado com o mindset das organizações, que em boa parte das vezes está focada demais em prazo e custo, deixando em segundo plano o foco em qualidade. E quando estamos falando de XP, a qualidade vem acima de tudo. Então para as empresas que prezam demais por escopo e tempo, pode ser de fato inviável utilizar essa metodologia.  Outra visão do por que poucos estão utilizando XP, já era prevista pelo próprio Kent Beck, que afirmava que existem alguns estraga-prazeres que fazem a XP não funcionar: grandes times, clientes desconfiados, tecnologias que não suportam elegantemente as modificações". (Kent Beck).  Neste contexto, podemos concluir que XP não é metodologia que pode ser aplicada para todos os projetos. E quando aplicada, deve tentar seguir ao máximo o que é estabelecido para cada prática, caso contrário, os problemas dos projetos continuarão existindo mesmo com a utilização de uma nova metodologia.


 

Compartilhe: