Extreme Programming: metodologia de desenvolvimento ágil de software

O que XP resolve? - Apresentação

Olá pessoal, sejam muito bem-vindos a Alura, meu nome é Vinicius Dias e eu vou guiar você nesse treinamento de eXtreme Programming ou XP para nós que vamos ser bastante íntimos dessa metodologia.

E antes de qualquer coisa sim, XP é uma metodologia, só que ao invés de já começar de cara falando sobre o que é essa metodologia, nós vamos entender quais problemas essa metodologia resolve, nós vamos entender como essa metodologia é organizada através dos papeis, através de valores, princípios e práticas.

E nós vamos entender bastante a fundo sobre esses valores, vamos passar por todos os valores que são cinco e como eles podem resolver os problemas que nós vamos encontrar.

Nós vamos ver também como o XP pode se integrar com outras metodologias ágeis, como Scrum, Kanban, então nós vemos que isso é possível e até comum e depois de pegar toda essa base teórica nós vamos ver bastante a parte prática.

Então nós vamos passar por cada uma dessas seções, gestão, projeto, planejamento e codificação, entendendo na prática cada uma dessas práticas que o XP sugere.

Nós vamos ver que o XP não necessariamente inventou essas práticas, mas ela sugere o uso de várias práticas por saber que já dá certo.

Então é um treinamento bastante interessante mas relativamente extenso, então se durante ele você ficar com qualquer dúvida, não hesite, você pode abrir uma dúvida no fórum que eu tento responder pessoalmente sempre que possível, mas quando eu não consigo, a nossa comunidade de alunos, moderadores e instrutores é muito solícita e com certeza alguém vai conseguir te ajudar.

Bom, mais uma vez seja muito bem-vindo, e te espero no próximo vídeo para nós começarmos a entender quais problemas o XP resolve.

O que XP resolve? - Motivos de falha

Bem-vindos de volta e antes de nós falarmos especificamente sobre o XP, sobre o eXtreme Programming e entender o que que é esse nome bonito, vamos falar sobre alguns probleminhas que esse tal de XP resolve, então nós vamos falar sobre alguns problemas, alguns motivos para projetos falharem.

Então, por que os projetos falham? O que que causa a falha de um projeto? E antes de qualquer coisa vamos falar bem rápido o que eu quero dizer com falhar.

Pode ser simplesmente não ter entrega mais, o projeto deixar de existir, pode ser o cliente cancelar o contrato, pode ser um projeto que ainda existe, ele continua tendo entregas só que as entregas são tão custosas e demoradas que elas só são mantidas por motivos contratuais, por motivos de ser muito caro cancelar o contrato, então quando ninguém esta satisfeito com um projeto ele obviamente falhou.

Então vamos entender alguns dos motivos para o projeto falhar, porque, claro, existem vários motivos e cada um dos motivos tem várias soluções, mas nós vamos passar por alguns dos motivos que o XP resolve, os motivos de falha que o XP vem para corrigir.

Então vamos lá, aqui são alguns desses motivos, de novo, existem vários, aqui eu só selecionei alguns como o cliente estar distante do projeto, nós tentarmos adicionar aquele toquezinho final, uma cereja no bolo, testes só no final do projeto e as vezes só de forma manual, trabalho empurrado com a equipe de desenvolvimento tendo que fazer tudo muito rápido, dívidas técnicas que podem inclusive ser um problema gerado pelo trabalho empurrado.

Então vamos passar um a um entendendo o que quer dizer na prática esse problema.

Imagina um cenário que particularmente comigo já aconteceu bastante, você recebe uma especificação, você como desenvolvedor ou uma pessoa que está na equipe de desenvolvimento, recebe uma especificação, só que está faltando algum detalhezinho ali, você está com uma dúvida, você não entendeu muito bem uma parte, o que acontece, óbvio.

E o que você faz? Normalmente nós perguntamos para a equipe de análises, para a equipe de projetos, para alguma parte da equipe que está próxima de nós, mas que conhece o projeto em si, a parte de negócios, só que essa equipe não sabe tudo, ninguém sabe tudo, nenhuma pessoa do mundo sabe tudo, isso não existe.

Então nesse cenário essa equipe vai ter que se comunicar com o cliente para saber exatamente o que que o cliente quer nesse ponto que teve uma ambiguidade.

Então isso gera um atrito, isso gera um problema na comunicação relativamente grande, nós vamos ter um espaço muito grande para ter erros, para ter uma falha de comunicação e inclusive, além do tempo entre a equipe de desenvolvimento receber essa resposta, o cliente vai responder para a equipe de negócios e a equipe de negócios vai responder para o desenvolvedor e nesse meio tempo nós podemos ter perda de informação.

Então fica entrando no ciclo de tentativa e erro também não é algo nada legal, porque o que acontece? O cliente vai demorar para responder, eu acho que isso aqui vai ser dessa forma então vou implementar aqui e você manda para a validação, o cliente diz, não, não é isso que eu queria e você tenta de novo, não, não é isso.

Então isso pode ser fatal para o projeto, pode fazer com que entregas demorem demais, contratos sejam rompidos, enfim, isso parece algo tão bobinho mas é um problema bastante grande.

Cereja do bolo, isso aqui eu também já vi acontecer demais, o que acontece? Tanto a equipe de desenvolvimento quanto qualquer outra equipe quanto o cliente possuem expectativas, o desenvolvedor espera que tenha alguém pronto para tirar as dúvidas dele, a pessoa que está desenvolvendo espera que tenha acesso as ferramentas e as tecnologias necessárias para resolver o problema, o cliente espera que o problema dele seja resolvido, é só isso que ele quer, ele não quer nada a mais.

Então imagina um cenário que comigo já foi muito comum, eu já participei de equipes que faziam muito isso, nós estamos desenvolvendo uma funcionalidade, o cliente solicitou um relatório com as colunas A, B e C, só que nós estamos atolados por diversos problemas e nós vamos acabar atrasando isso.

E como nós vamos atrasar o que eu vou fazer? Poxa, eu vou adicionar além das colunas A, B e C, eu vou colocar as colunas X e Y para o cliente ficar um pouco mais feliz que ele vai achar que eu atrasei por isso e todo mundo fica feliz, não, não é isso, se o cliente quisesse a coluna X e a coluna Y ele teria pedido, o cliente quer a coluna A, a coluna B e coluna C, então é isso que tem que ser entregue.

As expectativas tem que ser atingidas e nada além disso, o cliente quer que o problema dele seja resolvido no menor tempo possível, então ficar adicionando esse toquezinho final, a cereja do bolo pode gerar sérios problemas.

Quem nunca ficou refatorando o mesmo código, ficou melhorando aquele mesmo código durante um tempão e acabou perdendo o prazo da entrega? Então isso é algo, infelizmente, bastante comum.

E quem nunca ouviu aquela frase, está desenvolvido já, essa feature está pronta só falta testar, ou então, pior ainda, poxa, para que que eu vou testar? Realmente precisa testar? Se sobrar tempo nós testamos, nós vemos isso no final, quando estiver pronto nós testamos.

Só que isso é um enorme problema, desenvolver sem criar testes automatizados é antiético, é o equivalente um cirurgião não lavar a mão antes de fazer uma cirurgia, é inaceitável, nós precisamos ter a etapa de testes junto com a etapa de desenvolvimento, não são processos separados, esses processos de desenvolvimento e teste devem ser vistos como um só.

Testar só no final como nós costumamos dizer ou pior, testar de forma manual é antiético, é algo que não é aceitável e nós não podemos aceitar esse tipo de cenário, testes são parte do desenvolvimento e são muito importantes.

E quem nunca ouviu uma frase parecida com essa também da equipe de vendas chega para nós ou o chefe mesmo, o presidente da empresa chega, olha nós fechamos um novo contrato aqui e o sistema tem que estar pronto semana que vem, conto com vocês.

O que que acontece? Num cenário desses, onde a equipe de desenvolvimento não participou do planejamento da parte de estimativas, o que vai acontecer? Vai desenvolver tudo a toque de caixa, de forma muito rápido um sistema sem qualidade, vai ter um monte de problema no futuro, vai ter uma péssima experiência para a equipe de desenvolvimento, ninguém vai ficar feliz com isso, vai entregar vários problemas que vão ter que ser resolvidos depois pela mesma equipe que não vai estar nada contente de novo.

Então essa forma de trabalho gera muitos problemas por si só, isso é um problema que gera vários outros, então obviamente como todos os outros que nós temos falado, durante esse treinamento com práticas do XP, nós vamos aprender a resolver como mitigar esse tipo de problema.

E por último mas não menos importante do que eu quero falar aqui, eu já ouvi muito essa frase também, esse sistema é legado, você está no sistema antigo, pode fazer de qualquer jeito só para entregar.

O que acontece? Naquele momento você vai acabar fazendo rápido, tudo bem, vou fazer de qualquer jeito e na semana seguinte surge um novo problema naquele seu código de qualquer jeito e isso já vai levar mais tempo para corrigir e uma outra parte que outra pessoa que desenvolveu de qualquer jeito também, quando precisar de uma correção vai precisar de mais tempo ainda para corrigir aquilo.

Então as dívidas técnicas elas deterioram a produtividade ao longo do tempo, ao longo do tempo quanto mais problemas você deixa lá de qualquer jeito, quanto menos você liga para a qualidade, mais prejudicada vai ser a produtividade da equipe.

Então o que que é dívida técnica? Nós vamos falar um pouco mais sobre isso, mas basicamente dívida técnica é aquele código mal feito que você faz, aquela dependência que você deixa de atualizar, é algo que você deixa a desejar para o seu projeto de forma técnica, por isso, dívida técnica, existem diversos termos formais para isso, mas basicamente é algo que você poderia ter feito melhor mas deixou para lá.

Então nós já entendemos um pouquinho de alguns problemas que o XP vem para resolver, nós já falamos sobre alguns motivos para um projeto falhar, só que agora vamos entender o que que é esse tal de XP na prática eXtreme Programming é o que? No próximo vídeo nós falamos sobre isso.

O que XP resolve? - Conhecendo a metodologia

Bem-vindos de volta, então vamos entender na prática o que que é esse tal de XP, o eXtreme Programming, então baseado nesse slide, conhecendo a metodologia você já deve estar pensando, ok, então XP é uma metodologia.

E sim, XP é uma das possíveis metodologias ágeis, então a ideia do XP, é fazer com que de forma ágil você consiga desenvolver software com qualidade, se comunicando bem e seguindo vários valores, princípios, práticas, que nós vamos falar com muito mais detalhe, só que antes de entender realmente a fundo, na prática, com termos reais, vamos ver uma definição formal do que que é esse tal de XP.

Então eu vou parar e eu vou ler para você, programação extrema, eXtreme Programming ou simplesmente XP, é considerado uma metodologia ágil pois se ajusta bem as pequenas e médias equipes em desenvolvimento de software com requisitos vagos e em constante mudança.

Isso aqui foi uma definição que eu retirei e eu honestamente não entendo absolutamente nada do que isso aqui quer dizer, por definições formais, eu, Vinícius nunca consigo aprender.

Mas vamos para uma definição prática, o que que é XP realmente, XP, como está escrito aqui, uma metodologia ágil e basicamente, a ideia de XP é te prover ferramentas necessárias, é te ensinar a usar ferramentas necessárias para que você consiga desenvolver software se adaptando a mudanças de forma muito tranquila e se você conhece metodologias ágeis sabe que esse é um dos pontos do manifesto ágil, que é se adaptar a mudanças mais do que seguir um plano.

Então nós vamos falar bastante sobre planejamento também, mas toda a ideia por trás do XP é desenvolver software com muita qualidade se adaptando muito bem as mudanças, essa é a ideia do eXtreme Programming.

E o eXtreme Programming, essa metodologia traz para nós um conjunto de valores, princípios e principalmente práticas e essas práticas vão tornar o processo de desenvolvimento, vão tornar a programação em si bem mais efetiva e eficaz se adaptando de forma mais fácil as mudanças, mantendo a qualidade de desenvolvimento de software.

Então focando muito nessa parte aqui, XP basicamente é uma metodologia que fornece, que te traz um conjunto de valores, princípios e práticas e vamos focar bastante na parte das práticas.

Mas então como será que surgiu esse tal de XP, de onde que veio isso? Eu vou supersimplificar a história e vou deixar um para saber mais com um referência ou duas para você dar uma lida sobre a história do XP.

Mas basicamente quatro feras, Kent Beck, Ron Jeffries, Ward Cunningham e Martin Fowler, eles participaram de um projeto que tinha alta complexidade, era algo bastante complexo de desenvolver e tinha muito risco, tinha muita coisa em jogo lá, dinheiro, muito dinheiro rolando, enfim, era um projeto arriscado, vamos dizer assim.

E para garantir que tudo ia dar certo, que tudo ia correr bem eles seguiram, eles concordaram entre si em seguir uma série de práticas e sugestões que já tinham se provadas de sucesso anteriormente.

Então um exemplo aqui e eu já vou te dar um spoiler de uma das práticas, teste antes mesmo do desenvolvimento, criar um teste antes de criar funcionalidade ou bug, já era sabido naquela época e já existiam especificações, já existiam documentos falando sobre isso, estudos sobre isso de que criar o teste antes mesmo da funcionalidade trazia vantagens.

Então o que eles fizeram? Pegaram essa prática e aplicaram ao extremo, daí o nome eXtreme Programming, o que que eles faziam? Todas as funcionalidades e correções de bugs iam ter o teste criado antes.

Então essa é uma só das práticas que nós vamos ver, mas eles pegaram várias práticas e aplicaram ao extremo, eles realmente seguiram aquilo a risca e no final desse projeto tudo deu certo realmente, ele foi entregue dentro do prazo, os clientes ficaram bastante satisfeitos e com isso surgiu o primeiro livro sobre XP.

E nesse primeiro livro tinha um probleminha, inicialmente a metodologia era pensada para equipes bem pequenas de 12 a 14 pessoas, mais ou menos.

Só que em 2004, o que é relativamente recente, o Kent Beck e a sua esposa Cynthia, lançaram uma segunda edição desse livro adaptando um pouco, tornando mais inclusivo, abrangente, flexível, fazendo com que times de qualquer tamanho consiga aderir a todas essas ideias do eXtreme Programming.

Então voltando para aquela ideia do conjunto do que é o XP, XP possuí cinco valores, alguns princípios e várias práticas.

Vinícius, por que que o cinco tem o número ali e os princípios e práticas não? A metodologia como qualquer metodologia ágil sofre mudanças ao longo do tempo, então em algumas literaturas você vai ver 14 princípios e 17 práticas, em outras tiram uma prática, adiciona outra, mudam o princípio, então eu preferi não colocar um número aqui mas basicamente, em várias literaturas você vai encontrar 14 princípios, 17 práticas.

Então vamos dar uma olhada aqui no que que eu quero dizer com isso, primeiro, os valores, eu não vou entrar em detalhes porque nós vamos ter um capítulo só sobre isso, mas basicamente os valores do XP são comunicação, simplicidade, feedback, coragem e respeito.

E quando nós lemos assim parece algo muito conceitual, eu me lembro a primeira vez que eu li um livro de XP que eu fiquei pensando, cara, eu sou programador, eu não quero aprender como respeitar alguém, eu sou uma pessoa respeitosa, eu fui bem educado, eu não quero ler sobre isso, eu quero ler sobre práticas de código.

Só que conforme eu fui lendo, eu fui entendendo como isso se aplica a nossa vida como pessoas que desenvolvem software, então, embora quando nós batamos o olho assim pareça algo muito conceitual, nós vamos entender o que isso quer dizer dentro de uma equipe de desenvolvimento.

Mas, falando sobre os princípios que o XP preza, que são alguns, nós vamos prezar sempre pela humanidade, todas as pessoas em uma equipe de desenvolvimento XP, são humanas, são pessoas, elas têm os seus problemas e nós precisamos entender, nós não podemos exigir mais do que o possível.

Nós prezamos pela economia, o que isso quer dizer? Utilizar da melhor forma possível os recursos disponíveis para entregar o maior valor possível, se nós só temos uma equipe de quatro pessoas desenvolvendo, essa equipe de quatro pessoas desenvolvendo vai ser econômica, vai entregar só o que é necessário, vai entregar o que gera mais valor para que todo mundo seja beneficiado.

E falando nessa parte de todo mundo ser beneficiado, outro princípio é o de benefício mútuo, todo mundo precisa ser beneficiado, o cliente precisa receber a solução para o problema dele, o desenvolvedor precisa utilizar as tecnologias necessárias, inclusive aprender receber a gratificação por isso, a bonificação, todo mundo precisa ser beneficiado num projeto.

O princípio de auto semelhança basicamente diz que se algo já funcionou nós vamos implementar de forma semelhante, nós não vamos reinventar a roda, vamos dizer assim, mantendo simplicidade, então se algo funciona vamos com os devidas adaptações fazer de forma semelhante.

E trazendo isso não só para o código mas para nós, se alguém realiza determinada prática que eu sei que funciona, eu vou trazer para mim e tentar aplicar isso e se eu sei que algo funciona para mim, eu mantenho fazendo isso de forma a sempre buscar a melhoria.

Que é o próximo princípio, a busca pela melhoria é constante quando nós falamos de equipes extremas, de equipes que seguem o eXtreme Programming, o XP.

Nós precisamos sempre melhorar, seja em quesitos técnicos ou em quesitos pessoais mesmo, como pessoa, para que nós estejamos de novo ligado com aquele primeiro princípio como humanos, como pessoas que nós estejamos em conexão com o nosso time.

Esses dois pontos, diversidade e reflexão são bem conceituais, onde, através da diversidade nós conseguimos trazer pessoas com backgrounds diferentes, com conhecimentos diferentes para uma equipe e cada um vai poder agregar de uma forma diferente, isso é muito rico, isso é muito enriquecedor para a equipe.

E reflexão, nós sempre precisamos botar a mão na consciência e analisar os resultados para entender o que deu certo, como nós podemos melhorar o que deu certo, o que não deu certo, porque não deu certo, então isso é um princípio do XP, nós sempre precisamos refletir sobre o que está acontecendo.

Um dos princípios é seguir um fluxo, nós vamos falar sobre planejamento, mas através de um fluxo bem definido nós conseguimos entregar mais valor com menos recursos, atendendo aquela economia.

E toda a diversidade deve ser vista como uma oportunidade, seja de aprender, de melhorar o projeto, enfim, de corrigir um problema que nós não sabíamos que existia, então nós sempre devemos ver os problemas como oportunidades.

Redundância é o fato de nós estarmos pronto para algum tipo de problema que está diretamente ligado ao princípio de falha, nós precisamos estar preparado para caso alguma falha aconteça nós reagirmos a isso.

Então quando nós falamos de redundância, pode ser na parte técnica, como por exemplo, ter backups ou na parte conceitual, nós nos adaptarmos, nos planejarmos de novo quando algo dá errado.

Então esse é um princípio que se junta muito com o princípio de estar preparado para falhas, falhas vão acontecer, nós temos que estar pronto para isso de forma técnica, como eu falei, tendo backups, tendo código versionado, enfim, mas também como pessoas, nos temos que estar pronto para falhar, para errar receber um feedback disso e entender como melhorar.

Qualidade é um ponto que vai estar em praticamente todas as práticas do XP, qualidade é um ponto crucial, é um dos principais princípios do XP, então nós sempre vamos prezar pela qualidade, não só da equipe de desenvolvimento como pessoas, como equipe em si, mas também da parte técnica, do código, da nossa infraestrutura, qualidade é essencial.

E nós vamos seguir o princípio de dar passos pequenos para ir melhorando e adicionando novas funcionalidades que nós, inclusive, quando falamos de práticas específicas esses passos pequenos são levados a sério.

E aceitação da responsabilidade é um dos também principais princípios porque numa equipe XP não existe o erro da fulana, do ciclano, existe o erro da equipe, então se alguma coisa deu errada a equipe vai assumir a responsabilidade e resolver aquele problema, sem ficar apontando o dedo.

Então, esses princípios levam a algumas práticas e essas práticas são o que vão guiar todo esse treinamento, através da aplicação dessas práticas nós vamos atender os princípios sempre sendo guiados por aqueles valores resolvendo os problemas que nós já vimos.

Então aqui nós temos diversas práticas e nós vamos passar por cada uma dessas nesse treinamento, nós vamos falar sobre a parte de gestão, a organização de projetos, planejamento e vai focar bastante nessa parte que eu enxergo como crucial do XP, que é a codificação, sem o código nada do restante funciona, nada do restante existe, então nós precisamos e o XP dá bastante atenção para o código, para a codificação.

Então agora que nós já entendemos isso tudo, já entendemos o que é o XP, vamos voltar um pouquinho para a parte conceitual e falar a fundo o que são aqueles cinco valores, então vamos falar sobre cada um dos valores só que antes mesmo de falar sobre os valores repara aqui que tem uma prática muito interessante.

Essa segunda prática é o de time coeso, poxa, se eu vou ter um time coeso eu preciso saber qual é o papel de cada pessoa dentro do meu time para ter realmente um time coeso, então antes mesmo de falar sobre valores, que tal nós batermos um papo sobre uma equipe XP, sobre o time.

Sobre o curso Extreme Programming: metodologia de desenvolvimento ágil de software

O curso Extreme Programming: metodologia de desenvolvimento ágil de software possui 144 minutos de vídeos, em um total de 55 atividades. Gostou? Conheça nossos outros cursos de Agilidade em Inovação & Gestão, ou leia nossos artigos de Inovação & Gestão.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• O que XP resolve?
• Valores
• Gestão e projeto
• Planejamento
• Codificação
• Melhorando e informando