Processos de Desenvolvimento Ágeis VI - XP - eXtreme Programming - Programação Extrema

Olá sejam bem-vindos ao canal engenharia de software com ênfase o m Eu sou professor ganes Guedes e eu já atuo na área de modelagem de software há vários anos eu tenho quatro livros publicados sobre o assunto e eu já ministrei diversas palestras e cursos técnicos utilizando a linguagem uml na aula de hoje eu vou dar continuidade ao tema sobre processos de desenvolvimento de software mais exatamente eu vou continuar falando sobre processos de desenvolvimento ágeis dessa vez abordando o processo XP ou extreming programming então vamos iniciar a nossa aula Então essa é a sexta aula sobre

processos de desenvolvimento ágeis como eu falei hoje nós vamos abordar o processo extreming programming ou programação extrema o antes de iniciar a aula é importante destacar que muito do conteúdo apresentado aqui foi inspirado retirado do livro de engenharia de software do professor Raul vatis slavic e também de outras fontes como o Roger presman e o Ian summerville além de outros conteúdos Mas vamos iniciar Então Xp é um método ágil que se baseia em uma série de valores princípios práticas e regras nós vamos estudar eh a maioria desses princípios antes nós vamos começar falando sobre os

papéis existem essencialmente quatro papéis principais no XP o primeiro se refere aos clientes na verdade clientes não pode não se referir somente a a pessoa que paga pelo pelo produto mas também partes interessadas ã ou seja usuários Chaves que tem conhecimento profundo sobre uma determinada faceta da empresa sobre um determinado setor um determinado departamento sobre um determinado processo então eles têm conhecimento como as coisas funcionam e e são então profissionais das quais se pode retirar muito informação e muitos requisitos sobre o software Então por esse motivo se espera que os os clientes tenham Auto engajamento

com o processo de desenvolvimento Esse Na verdade é um princípio prescrito pela maioria senão todos os processos de desenvolvimento ágeis mas ele é um um princípio um tanto problemático porque usuários chave são muito caros para a empresa eles têm muito conhecimento e eles são muitas vezes imprescindíveis paraa empresa ela não pode dispensar eles por muito tempo então não é um princípio muito fácil de se conseguir de qualquer forma os clientes eles devem criar as histórias de usuário histórias de usuário basicamente se referem a requisitos funcionais elas determinam que funções os clientes desejam que o software

ofereça para eles então eles escrevem cartões onde eles dizem eu como um determinado papel ã desejo que o software faça tal coisa para que eu obtenha tal benefício eles também fornecem pareceres ou seja feedbacks contínuos a respeito se o software está funcionando corretamente se o produto está atendendo as necessidades dele se as se as iterações se as entregas estão eh estão satisfazendo o cliente estão no caminho certo isso também é um princípio essencial para o XP deve haver muito parecer e eles também tomam as decisões de negócio relacionadas ao projeto nós temos os programadores ou

desenvolvedores que são os que codifica o produto eles também produzem testes de unidade o XP se baseia muito em testes Ele trabalha com desenvolvimento dirigido a testes ou test driv development eles implementam as histórias do usuário Executa os testes de unidade e também fazem muitas vezes a integração do código nós temos o papel de rastreador ou gerente que não é exatamente um gerente ã como se entende normal ente mas ele desempenha muitas tarefas de um gerente na verdade esse papel não é realmente obrigatório mas é bastante útil ele tem o papel ele tem o nome

de Tracker ou rastreador porque ele determina se o projeto está no caminho certo ele tenta rastrear a posição do projeto então o papel de rastreador ele pode ser assumido por um dos desenvolvedores ele tenta facilitar a comunicação entre os clientes e os programadores eles organizam as reuniões mediam as discussões e acompanham o progresso do projeto e nós temos o papel de treinador também é um papel opcional mas pode ser útil quando a equipe tem pouca experiência com a filosofia ágil Então pode se chamar alguém de fora que tem experiência nisso ele pode ou não fazer

parte da equipe pode ou não se envolver no desenvolvimento e basicamente ele ajuda a equipe a a se adaptar à filosofia ensina a melhor como utilizar as práticas XP eh passa um pouco de sua experiência paraa equipe bom eu vou falar sobre o ciclo de vida do XP aqui eu estou me baseando principalmente no presman mas também em outros autores na verdade aqui Essas são as quatro principais fases Mas vocês vão encontrar alguns autores que preconizam mais fases então nós temos as fases de planejamento ou jogo de planejamento projeto codificação e testes aqui nós temos

uma figura representando o ciclo de vida do XP então Aqui nós temos cada uma das quatro principais fases eh onde nós temos a fase de planejamento que possui as fases de iniciação de requisitos possui as tarefas executa as tarefas de iniciação de requisitos eh produção de histórias de usuário priorização de histórias de usuário estimação das histórias do usuário e seleção das histórias do usuário Para uma determinada iteração então alguns autores afirmam que a iniciação de requisitos na verdade é uma fase independente certo onde se tenta compreender os requisitos do software e mesmo como organização funciona

nós temos também a fase de projeto onde ela preconiza que o projeto deve ser o mais simples possível então nessa fase são produzidos cartões CRC Esse é basicamente um dos poucos artefatos obrigatórios dessa fase embora outros modelos de software como diagram de sequência diagramas de classe possam ser produzidos e também se for necessário se alguma história for considerada complexa pode se produzir protótipos operacionais para ajudar a compreender a sua complexidade e conferir se ela foi compreendida corretamente depois nós temos a fase de codificação onde como o nome diz as histórias são codificadas as iterações são

hã executadas código é produzido Então se produzem testes unitários o software é codificado por duplas de programadores Esse é um princípio do XP são executados os testes unitários e o código é integrado depois nós temos a fase de testes onde os testes unitários podem ser executados novamente se executam testes de integração para ver se todos os módulos todas as classes todas as histórias de usuário estão funcionando bem Integradas H são executados testes de validação para ver se o código realmente eh satisfaz os requisitos solicitados e finalmente se são executados testes de aceitação com o cliente

onde o cliente vai baseado nas histórias de usuário verificar se realmente o software está ã fazendo o que foi solicitado o que é necessário Ahã depois se verifica se for encontrado erros ou são necessárias grandes melhorias ou ainda se a aquele essa parte do ciclo de desenvolvimento ainda tem iterações então se volta para o projeto caso contrário se entrega as funcionalidades e se verifica ainda existem entregas Então se planeja um novo conjunto de histórias para a próxima para o próximo conjunto de interações e se repete todo esse ciclo se não existirem mais entregas então o

produto ele é finalizado bom vamos falar um pouquinho sobre cada uma das fases então o planejamento ou jogo de planejamento ele se inicia com a atividade de ouvir ah alguns aores cham essa atividade de exploração e considera uma fase independente basicamente corresponde a engenharia de requisitos em particular a etapa de iniciação de requisitos ah Embora tenha análise obviamente Ah e especificação momento que as histórias São escritas eh ele permite a equipe entender o ambiente de negócio e fornece uma percepção Ampla sobre os resultados esperados depois existe ainda continuando no planejamento ah as partes interessadas então

elas define as histórias de usuários e as escrevem em cartões como eu falei uma história de usuário identifica um requisito funcional uma função que deve ser fornecida pelo software e como eu já disse antes ela identifica uma pessoa eu como determinado papel que ela está assumindo gerente ã ah secretário etc papel que tá assumindo no momento quero que o software faça tal coisa com o objetivo de que ele me retorne tal que eu que eu alcance tal resultado ah as partes interessadas eles também priorizam as histórias se baseando no seu valor de negócio para as

partes eh e aí a equipe ela atribui um tempo para essas histórias normalmente em termos de semanas desenvolvimento ã se as histórias tiverem mais que três semanas elas devem ser divididas em histórias menores e se elas forem muito curtas então elas devem ser fundidas com outras histórias ainda no planejamento os clientes escolhem as histórias que apresentam maior valor para serem implantadas numa interação ou num conjunto de interações isso é chamado de planejamento de interação e esse processo ele vai se repetir até C as interações e o tempo para cada interação deve levar cerca de 3

semanas de uma A TR semanas depois nós temos a fase de projeto que trabalha com princípio Kiss ou seja keep it Simple ou seja simplicidade eles devem fazer se recomenda que o projeto seja o mais simples possível se evitar complexidade o máximo possível Ah se Recomendo o uso de cartões CRC que são abreviatura de classe responsá habilidade de colaboração para tentar identificar e organizar as classes necessárias E qual é o comportamento eh esperado por seus objetos ã se uma história for complexa se recomenda a criação de um protótipo operacional com objetivo de reduzir o risco

eh para quando realmente for feita a implementação eh e for feita a implementação quando realmente a implementação for iniciada e também para validar as estimativas originais eh também durante a fase de projeto se for considerado necessário podemse produzir diagramas o ML diagramas de classe eventualmente até diagramas de caso de uso diagram de sequência diagramas de de comunicação h e outros diagramas quando isso for considerado necessário mas deve-se manter o princípio quis sempre tentar manter a simplicidade depois nós temos a codificação que é a codificação priamente dita mas ah XP se baseia no desenvolvimento dirigido a

testes o test driv and development Então antes de se codificar Qualquer coisa se produzem testes para aquela funcionalidade para aquela história para aquela unidade eh se parte do princípio que se se não se é capaz de testar uma história uma funcionalidade então não se é capaz de desenvolvê-la então ao elaborar o teste se entende melhor o que precisa ser codificado eh Então somente a parte no momento que as elabora que os testes são elaborados Então as histórias são realmente codificadas por pares de programadores a programação é feita em duplas o que pode parecer estranho ã

inicialmente Além disso os testes eles são executados antes de haver qualquer código Isso é para isso vai vai vai ocorrer um erro mas isso é proposital é para deixar claro que uma nova funcionalidade uma nova história está sendo adicionada e também no momento que se utilizarem ferramentas eh automatizadas e testes Isso é para fazer uma regressão de testes e garantir que nenhum erro está sendo inserido eh nenhum erro novo está sendo inserido no que já foi desenvolvido ainda na na durante a codificação o código ele vai sendo desenvolvido e na medida que ele vai sendo

concluído ele ele deve ser integrado ao trabalho de outras duplas eh isso pode ser feito diariamente por uma equipe de integração específica ou pela própria dupla e a integração ela deve ser o mais contínua possível e isso ajuda a evitar problemas de compatibilidade de interfaceamento eh de Evita que ocorram eh problemas Quando os módulos forem sendo integrados e se houver algum erro eh é o erro encontrado rapidamente ah depois nós temos a fase de testes os testes de unidade eles podem e devem ser executados novamente como eu falei eh deve-se utilizar ferramentas que permitam automatizar

esses có esses esses testes e que isso permita fazer teste de regressão Então sempre que houver uma modificação de código se executa todos os códigos nova todos os testes novamente para verificar se não foi inserido um erro novo ã também são feitos testes de integração e de validação e finalmente se passa pros testes de aceitação ou teste de cliente em que o cliente faz o teste final para garantir que realmente o as novas funcionalidades a nova entrega está sendo está correta e está sendo útil para ele ã e esses testes de acção eles são desenvolvidos

são criados a a partir das histórias usuário alguns princípios do XP alguns dos principais valores do XP simplicidade Como já se falou ah deve-se fazer uma o código o projeto o mais simples possível somente se desenvolve o que for realmente necessário e não algo que se pensa que talvez no futuro possa ser necessário ser é considerado perd de tempo respeito deve haver respeito entre os membros da equipe e entre a equipe e o cliente isso é um princípio para deixar a equipe satisfeita no momento que a respeito a equipe trabalha melhor e consegue se comunicar

melhor consegue tirar dúvidas melhor entre si então o projeto progride mais então se não houver respeito a comunicação falhará e o o projeto também comunicação ela é essencial no XP então ã os clientes e as partes contrárias precisam expressar o que realmente necessitam então precisa haver muita comunicação essa comunicação precisa ser de qualidade e preferencialmente presencial eh feedback ou Parecer Então deve haver pareceres constantes por meio das partes interessadas o mais constante possível mais rápido possível para evitar que haja falhas de comunicação falhas de compreensão se houverem falhas elas precisam ser corrigidas rapidamente para diminuir

o custo de sua correção e nós temos também um valor que se chama coragem a coragem diz respeito a mudanças mudanças irão ocorrer então deve-se ser coragem para aceitar as mudanças inevitáveis por pior que sejam elas não podem ser ignoradas Elas têm que ser encaradas o mais rápido possível e não se deve tentar eh ignorar elas por estarem fora do Contrato ou por serem muito difíceis É preciso coragem para encarar as mudanças um outro princípio feedback Aliás o a partir dessas desses valores Existem os principais os principais princípios básicos do XP que são feedback rápido

ou Seja Constante validação Por parte dos clientes simplicidade ou presumir simplicidade evitar complexidades necessária fazer somente o necessário mudanças incrementais as mudanças são bem-vindas mas são feitas aos poucos abraçar as mudanças as mudanças devem ser consideradas positivas trabalho de alta claridade o código deve seguir padrões o projeto deve seguir padrões ele deve ser bem feito deve ser constantemente refatorado então não se deve fazer código projeto de maneira rápid só para satisfazer o cliente ou para ganhar um tempo de forma a curto prazo porque o sacrifício de qualidade vai cobrar um preço muito alto a médio

e longo prazo e priorização de funcionalidades eu preciso determinar Quais são as funcionalidades essenciais para o cliente de estabelecer um produto mínimo viável para garantir que o essencial será desenvolvido se problemas ocorrerem vou falar sobreum umas práticas XP Então dentro do jogo de planejamento ou planning game ah a equipe se recomenda que a equipe se reúna com o cliente para priorizar as funcionalidades Isso deve ser feito semanalmente eh o cliente deve identificar as principais necessidades E a equipe responsável por estimar o que pode ser implementado naquele ciclo ao final de um ciclo as funcionalidades precisam

ser entregues ao cliente e esse é o modelo adaptativo em oposição aos contratos rígidos pode haver um contrato mas ele mas deve haver flexibilidade deve haver negociação com o cliente porque os requisitos provavelmente mudarão metáfora metáfora diz respeito a saber se comunicar com o cliente na linguagem dele então isso implica que é preciso compreender a linguagem técnica do cliente compreender a linguagem utilizada na área em que o software vai ser implantado isso é essencial para a comunicação correta então é necessário compreender a linguagem do cliente e se comunicar com o cliente na linguagem que ele

entende equipe Coesa então o cliente ele faz parte da equipe de desenvolvimento a equipe ela deve deve se respeitar deve se comunicar deve se ajudar Ah e ela deve Como já foi falado no na prática anterior saber se comunicar com o cliente reuniões em pé ou stand up meeting são todas as reuniões Ou pelo menos a maioria delas deve ser feita em pé porque Elas costumam assim ser mais rápidas e objetivas não se perde tempo muitas vezes é recomendado que elas sejam feitas após o almoço projeto Simples então não se deve projetar algo desnecessário pode

se fazer projeto pode modelos mas somente Se eles forem realmente necessários e não se deve projetar algo que talvez não vá ser usado Então se atende o que foi solicitado sem procurar sofisticação desenvolve-se o que é preciso não o que se acha que for que poderá ser ser necessário tá projeto simples não necessariamente é projeto fácil e nem sempre um projeto simples é o mais fácil de implementar e projeto fácil não quer dizer deve-se projetar o que é necessário da melhor maneira possível um projeto fácil ele pode não atender as necessidades ou pode gerar problemas

de arquitetura versões pequenas ou small release então Eh deve-se entregar constantes versões e isso permite ao cliente testar as funcionalidades de maneira contínua ritmo sustentável então deve-se trabalhar com um número de horas eh razoável não se deve sobrecarregar a equipe horas extras em geral não são produtivas elas até podem funcionar um ou dois dias mas se forem constantes na verdade a produção vai cair eh nós temos a posse coletiva é uma outra prática ou collective ownership e significa que o códo não pertence a um desenvolvedor específico todo mundo é dono do código Então ninguém precisa

pedir permissão para modificar o código padrões de codificação ou coding standards então devem se estabelecer e seguir os padrões de codificação Isso facilita a posse coletiva porque se todos codificar do mesmo jeito utilizando os mesmos padrões parece que o código foi escrito uma pessoa somente uma pessoa e não uma equipe programa s em pares per programing que pode ser o conceito estranho eu mesmo demorei um pouco para aceitar esse conceito então a programação é feita por duas pessoas Então pode parecer um desperdício de de recurso mas existem estudos que dizem que a programação feita por

pares ela é tão produtiva ou até mais se as pessoas trabalharem separado ah embora existam autores que discordem disso o par ele é é composto de um programador deve ser composto por um programador experiente e um aprendiz mas pode ser composto por duas pessoas de mesmo nível E quem deve utilizar o computador quem deve codificar é a pessoa com menos experiência e enquanto que o a pessoa com mais experiência deve auxiliar eh ensinar boas práticas ensinar padrões de codificação esse tipo de coisa dessa forma o código ele poderá ser verificado por pelo menos duas pessoas

e isso reduz a possibilidade de erros testes de aação customer tests Então são testes planejados e conduzidos pel equipe em conjunto com cliente para verificar se os se os requisitos foram realmente atendidos esses testes se baseiam nas histórias de usuário e outra prática é o desenvolvimento orientado a testes ou test driv development ou desenvolvimento dirigido a testes também é uma outra tradução ah basicamente antes de programar qualquer coisa deve se criar um teste para aquele código então Eh se baseia no princípio que se não se é possível eh elaborar um teste então o código a

o o requisito daquele código está muito confuso e ele precisa ser revisto ele está complexo demais se não se pode testar não se pode codificar Esse é o princípio então primeiro se produz o teste depois se codifica refatoração refactory então a refatoração deve ser constante tanto a nível de projeto como a nível de código o projeto e o código precisa ser constantemente revisto então isso garante que a complexidade do código se mantenha em um nível gerenciável que seja possível alterá-lo mantê-lo evoluí-lo e é um investimento que trará benefícios a médio e longo prazo Embora tenha

um certo custo a curto prazo integração contínua continuous integration e sempre que uma funcionalidade estiver disponível tiver sido concluída ela precisa ser integrada ao produto porém não pode ser feito ao mesmo tempo ou seja não pode duas dois ou mais pares de programadores integrarem o seu código ao mesmo tempo porque isso pode causar conflitos pode causar problemas pode causar comportamento emergente e a integração é feita por um de cada vez falar um pouquinho sobre as regras de planejamento Então a primeira escrever histórias de usuário Como já foi dito elas devem ser escritas pelos usuários já

que elas representam as funções que o software irá oferecer a eles então como eu falei uma história do usuário ela tem três partes basicamente o usuário se identifica identifica o papel que ele estar assumindo quando ele utilizar as funções então eu como gerente eu como vendedor eu como tal função queria assumir quero que o software me eh ofereça tal recurso para que eu obtenha tal objetivo ã Como já foi falado elas serve de base para definição de teste de aceitação ah a equipe é responsável por estimar se a história pode ser implementada em uma duas

ou três semanas se eh foi estimado que o tempo é maior do que isso talvez essa seja uma história Épica que precisa de ser melhor detalhada ou que ela precise ser dividida em histórias melhor menor hum menores e se uma história tiver menos que uma semana então implica que ela é que ela é muito pequena que talvez ela Deva ser combinada fundida a outras histórias uma outra regra de planejamento o planejamento de entregas cria o cronograma de entregas então é feito uma reunião de planejamento de entregas para determinar o projeto como um todo e os

técnicos nessa reunião tomam decisões técnicas e os administradores tomam decisões de negócio Ah ainda Cada história precisa ter o seu tempo de desenvolvimento estimado em termos de semana de programação ideais deve-se priorizar as histórias mais importantes do ponto de vista do cliente para em último caso ter o mínimo produto viável se algo der errado ã as histórias elas são agrupadas em iterações que devem ser planejadas somente pouco tempo antes delas serem iniciadas um uma outra regra faça entregas pequenas frequentes as entregas devem ocorrer semanalmente Ou no máximo de duas em duas semanas ah existe a

prática de entregas diárias Mas isso pode ser um pouco exagero e pode sobrecarregar o cliente ã e a função do cliente determinar se a entrega será posta em operação Ah outra regra o projeto é dividido em iterações as interações duram cerca de uma a duas semanas elas precisam ser planejadas pouco antes de ser iniciadas não adianta planejar com antecedência porque elas podem mudar ã então isso permite a sintonização com as mudanças não se deve implementar funcionalidades de outras iterações isso é proibido se implementa somente as funcionalidades que foram escolhidas para aquelas iterações e pronto os

prazos precisam ser cumpridos e a produtividade precisa ser acompanhada se os prazos não puderem ser cumpridos então ah é preciso convocar uma reunião extra para que algumas funcionalidades precisem ser repassadas para outras outros ciclos as tarefas devem ser concluídas não se deve deixar nada para trás nada inacabado uma outra regra o planejamento da interação inicia cada interação Então se seleciona as histórias de usuário mais importantes as que forem tiverem maior nível de priorização e eventualmente funcionalidades que falharam nos testes elas são divididas então em tarefas de programação as tarefas elas são escritas em cartões da

mesma forma que as histórias de usuário e são estimadas são determinados quanto tempo vai demorar para concluir cada tarefa e nós temos também diversas regras de gerenciamento primeira regra de equipe um espaço de trabalho aberto e dedicado então Não Devem haver Barreiras físicas de forma a melhorar a comunicação é preciso haver uma área para reuniões em pé a equipe deve os membros da equipe devem ser eh se sentir respeitados e acolhidos para que a comunicação flua eles devem se sentir satisfeitos com seu trabalho para que possam se Dedicar se sentir incentivados a desenvolver um bom

um bom produto deve se definir uma jornada sustentável deve ter um número máximo de horas para desenvolvimento trabalhar além dessa jornada padrão não é uma boa prática isso acaba cansando o o desenvolvedor e baixando a sua moral eh se há atrá de projeto então é melhor replanejar as tarefas em último caso se estabeleceu um mínimo produto viável se entrega o que os requisitos mais importantes mas não adianta tentar sobrecarregar eh os desenvolvedores se entrega o mínimo eh suficiente para o cliente e se planeja uma segunda versão então deve-se descobrir a velocidade ideal da equipe e

se ater a essa velocidade não adianta tentar comparar com equipes mais experientes o que ten mais rapidez cada equipe tem a sua velocidade própria e deve se fazer planos realistas não adianta se planejar para desenvolver muito e não conseguir atingir esse objetivo se inicia cada dia com uma reunião em pé às vezes essa reunião Pode ser feita ao meio-dia ã talvez nem todos os membros possam contribuir mas todos devem ouvir ã o tempo da reunião deve ser breve deve se manter um mínimo de pessoas o mínimo de tempo nas reuniões e as reuniões elas são

feitas para manter as pessoas sincronizadas basicamente cada membro eh deve informar o que conseguiu fazer no dia anterior o que ele pretende fazer nesse momento e no dia de hoje e quais são as dificuldades que ele está enfrentando quanto as dificuldades se houver um gerente se houver um Tracker ele deve procurar auxiliar o desenvolvedor a superar essas dificuldades ah a velocidade do projeto é medida Então se estimam quantos pontos de história de usuário ou pontos de tarefas de programação são desenvolvidas em cada iteração eh em cada planejamento os clientes seleciona um conjunto de histórias de

usuário eh o número de total de pontos dessas histórias deve ser próximo da Estimativa de velocidade do projeto que Foi estabelecido na regra anterior eh isso também vale paraos programadores com relação às tarefas de programação as pessoas devem ser movidas é uma outra regra eo significa que as pessoas podem assumir eh papéis diversos podem assumir funções diversas podem eh desenvolver código um pouco fora da sua área de expertise basicamente isso tem o objetivo de que a equipe aprenda entre si que o conhecimento seja compartilhado que não haja dependência de um funcionário específico ou um grupo

específico deles porque eles podem sair da empresa pode ser transferidos para outra equipe pode acontecer riscos Ahã se houver necessidade de conhecimento especializado Então deve ser contratar um consultor um outro princípio uma outra regra é que o XP deve ser consertado quando ele for inadequado basicamente se algo não funciona ele para para uma equipe específica para uma organização específica Então deve ser mudado deve ser feita adaptações as regras devem ser seguidas até que se perceba que elas precisam ser alteradas todos os desenvolvedores devem saber o que se espera deles e o que eles o o

que eles podem esperar dos outros desenvolvedores e para garantir isso deve existir regras agora V falar de regras de projeto simplicidade isso já isso já foi falado keep it Simple mantém isto Simples então o projeto deve ser o mais simples possível porque isso permite que ele ser executado mais rapidamente do que se for complexo O problema é que a simplicidade ela pode ser subjetiva e difícil de ser medida então é função da equipe decidir o que é simples claro que a simplicidade depende um pouco da complexidade do projeto uma outra regra escolha uma metáfora de

então uma metáfora é uma forma de explicar o funcionamento do do software explicar o objetivo do software de maneira o mais simples possível para quem está fora do projeto por exemplo para pessoas que precisam ingressar na equipe quando o projeto já está em andamento a a compreensão sobre o software não deve depender de muita documentação embora às vezes isso seja inevitável deve utilizar usar nomes significativos de variáveis de métodos e padrões de nomeação de elementos do programa devem ser devem ser escolhidos e seguidos para que isso Facilite a reutilização de parte do código deve-se usar

cartões CRC durante as reuniões as reuniões de projeto ah basicamente os cartões eles determinam as responsabilidades e colaborações entre os objetos então cada membro vai receber um conjunto de cartões que vão representar instâncias de diferentes classes então uma atividade pode ser uma operação ou uma consulta ela vai ser simulada e cada dono de um cartão vai anotar as responsabilidades do objeto no lado esquerdo do cartão e as colaborações que o objeto pode oferecer no lado direito do cartão eh também pode haver modelagem uml por meio do diagrama de sequência ou de comunicação ou de classes

H eventualmente de outros diagramas um umr Se isso for considerado necessário ah deve-se criar soluções afiadas chamadas spikes hum com um intuito de reduzir riscos Isso é uma outra regra então no momento que se identificam riscos de projeto razoavelmente graves então eles devem ser explorados de maneira definitiva e exclusiva eh deve-se buscar uma solução uma boa solução para o problema que foi identificado então um Spike ele vai ser o desenvolvimento ou o teste projetado para analisar e preferencialmente resolver um determinado risco caso o risco se mantenha então é preciso colocar um par de programadores uma

dupla eh durante um determinado período trabalhando exclusivamente para para examinar esse risco e tentar mitigar o seu Impacto Ah uma outra regra nenhuma funcionalidade é adicionada antes da hora mesmo que haja tempo não se adicionam funcionalidades necessárias porque o desenvolvedor achou que seria fácil fazer essa funcionalidade naquele momento e que acreditando que isso deixaria o sistema melhor isso ainda está dentro do conceito do keep it Simple não se faz nada além do eh estritamente necessário é um princípio ágil é maximizar a o o quantidade de trabalho não feito então ã se desenvolver o que é

não é necessário naquele momento muitas vezes é jogar tempo fora e requisitos futuros só pode ser considerados quando is for exigido pelo cliente deve-se utilizar deve-se evitar usar um projeto antigo e ruim só porque ele funciona e devee tentar remover redundâncias eliminar funcionalidades necessárias melhorar projetos antigos melhorar o código constantemente sempre que isso for possível e nós temos as regras de codificação o cliente deve estar sempre disponível isso é difícil de conseguir mas o cliente precisa estar disponível ao longo de todo processo de desenvolvimento deve ser um especialista no domínio não adianta ser um estagiário

não adianta ser um funcionário com pouca experiência ele é responsável por criar as histórias de usuário priorizá-las e negociar sua inclusão e interações o código deve ser escrito de acordo com os padrões estabelecidos Como já foi falado antes então os padrões de codificação eles servem para manter o código no mesmo estilo no mesmo numa mesma forma de codificação que ajude a compreender o código por toda equipe e que ele seja passível de ser melhorado refatorado constantemente Ah então Isso facilita a posse coletiva do código deve se escrever os testes de unidade primeiro Como já foi

já foi falado XP trabalha com conceito de desenvolvimento orientado a testes então primeiro se produz o teste depois se codifica isso ajuda a compreender o que precisa ser feito e a produzir um código melhor H estranhamente o tempo para escrever o teste e o código é o mesmo que se gastaria para escrever apenas o código então no final eh é produzido mais no mesmo tempo e se produz um código de melhor qualidade e isso permite eh que os códigos eles sejam eh refeitos eh no momento em que eles foram desenvolvidos por meio de uma ferramenta

autom Então se houver uma mudança é feito uma regressão de testes todos os testes são executados novamente para garantir que não foi incluído um erro no que já est funcionando o código deve ser produzido em duplas isso é um conceito um pouco estranho e às vezes considerado muito caro mas parece que na maioria das vezes funciona então duas pessoas trabalhando em um computador produzem tanto código quanto duas pessoas trabalhando separadamente segundo os os Defensores dessa dessa regra embora exista exist são autores que discordem Ah também se afirma que a qualidade do código é melhor e

se eu recomenda que haja um programador mais experiente mas eh não deve haver uma relação eh tutor aprendiz os programadores eles devem ser considerados iguais uma outra regra só um par faz integração de código cada vez para evitar problemas de integração ã duas partes do sistema que nunca foram testadas juntas se forem Integradas ao mesmo tempo isso pode causar problemas pode causar problemas de comportamento emergente eh incompatibilidades erros diversos deve haver versões claramente definidas do produto e deve estabelecer turnos de integração cada dupla integra na sua vez e nunca ao mesmo tempo a integração deve

ser frequente as integrações devem ser feitas em intervalos de tempo regulares e pequenos não se deve postergar postergar a integração Porque isso pode ah agravar o problema e também eh fazer com que haja falhas de comunicação e que pessoas comecem a trabalhar conversões desatualizadas do sistema Deve existir um computador exclusivo para integração isso permite que os programadores vejam quem está integrando o software naquele momento ã o resultado da Integração precisa passar pro teste de unidade diga para garantir que haja estabilidade em cada em cada versão ã se os testes de unidade falharem Então essa unidade

precisará ser depurada e se a atividade demorar muito se a atividade de integração demorar muito tempo então Isso demonstra que aquela unidade ela precisa de depuração e não é o momento de ser integrada ainda então a a integração precisa ser abortada e se deve retornar a sistema à última versão estável então a gente precisa de ferramentas para gerenciamento de configurações e mudança eh e controle de versões hã outra regra a posse do código deve ser coletiva não deve haver gargalos porque alguém é dono do código todos precisam ser autorizados a modificar consertar alterar refatorar as

partes do sistema hã deve-se sempre desenvolver os testes de unidade para o código mesmo que quando ele mesmo seja um novo código que ele esteja sendo modificado é preciso fazer sempre testes de unidade antes de codificar E no momento que não existe um dono de determinadas partes do sistema isso diminui o impacto quando algum membro da equipe for transferido ou pedido emissão e nós temos as regras de teste como já foi falado todo o código deve ter teste de unidade isso é um dos princípios mais importantes do XP então testes de unidade eles favorecem a

posse coletiva do código então evita que algum erro Novo seja inserido ã o código eh deve passar pelos testes de unidade novamente antes de ser entregue isso garante que a a funcionalidade tenha sido implementada corretamente E isso também os testes de unidade também permitem a refatoração porque eles protegem o código de mudanças eh nas de mudanças que foram consideradas indesejadas Para uma determinada funcionalidade Ah quando houver um erro de funcionalidade então eh deve ser criados testes para identificar um erro de funcionalidade então para isso é é preciso que sejam criados testes de aceitação para proteger

o sistema Ah e os clientes devem explicar claramente o que estava errado e o que eles esperam que seja modificado ã os testes de aceitação eles são executados com frequência e os resultados eles devem ser publicados ah como já foi falado antes os testes de citação eles são criados a partir de história do usuário ã as histórias usuri elas vão ser traduzidas em testes de aceitação esses testes são do tipo funcional e representam uma ou mais funcionalidades que foram explicitamente declaradas pelos clientes e os testes da citação eles podem ser automatizados de maneira que eles

possam ser executadas muitas vezes uma outra agora vou falar sobre as vantagens do XP entregas rápidas tinas XP adota um ciclo de desenvolvimento bastante curto muito mais curto que a maioria dos outros métodos ágeis então isso permite que a equipe entregue incrementos funcionais em períodos de tempo curtos então o produto ele vai estar em em constante evolução então o cliente ele já recebe algumas funcionalidades que ele pode ir utilizando ele já pode ver resultados tangíveis isso torna ele mais satisfeito e aumenta o seu envolvimento com processo do com processo de desenvolvimento ah XP é bastante

adaptável à mudanças então permite que as equipes se adaptem rapidamente às mudanças requisitos e as mudanças de prioridades H ele trabalha muito com os princípios ágeis que promove a flexibilidade durante o desenvolvimento então isso permite que ajustes e inclusões de novas funcionalidades sejam realizadas ao longo do projeto ã e garante que o produto final realmente atenda as necessidades do cliente mesmo que elas tenham sofrido muitas mudanças qualidade do produto final há uma forte ênfase na excelência técnica e que o software seja entregue com alta qualidade se trabalha com práticas como o tdd que é o

desenvolvimento dirigido a testes e a programação em pares isso contribui para detecção precoce de erros e aumenta a qualidade do código e também a a questão de haver um parecer constante do cliente ao longo da implementação então permite que ajustes sejam feitos de maneira rápida diminui a ocorrência de erros e os erros são descobertos mais cedo então o produto ele é constantemente melhorado e a qualidade do produto final também eh sofre melhoria e o e o usuário costuma ficar mais satisfeito Ainda há uma colaboração e engajamento da equipe bastante forte a se recomenda que a

equipe se comunique se ajude se aprenda ah troque informações e conhecimento entre si Então isso é permitido através de programação em pares e reuniões diárias e a equipe ela realmente é uma equipe eles agem para sempre melhorar o seu trabalho e para alcançar os seus objetivos então isso fortalece o engajamento da equipe melhora a troca de conhecimentos contribui paraa construção de um ambiente de trabalho mais harmonioso mais produtivo e a equipe se sente bem no no no ambiente e trabalha com mais vontade desvantagens bom a primeira resistência à mudança isso pode ser uma desvantagem Geral

de todos os processos ágeis Ah pode haver situações em que as equipes do cliente elas resistam a adoção do do extreme programming Por estarem acostumados a modelos de desenvolvimento mais prescritivos mais tradicionais para minimizar essa desvantagem deve-se educar a equipe e o cliente sobre as vantagens da abordagem ágil E demonstrar resultados tangíveis desde o início do projeto ah a comunicação precisa ser eficiente isso pode ser uma desvantagem então eh exige-se uma comunicação constante e Clara entre os membros da equipe com as partes interessadas O problema é que as partes interessadas muitas vezes não estão disponíveis

se a comunicação não for bem estabelecida Então pode ocorrer mau entendimentos e isso pode atrasar o projeto e até inserir erros então para superar essa desvantagem é preciso investir em práticas de comunicação eficientes ou seja reuniões diárias de acompanhamento definição Claros requisitos e funcionalidades e pareceres constantes por dos dos clientes e falar com o cliente na linguagem que ele entende foco excessivo no curto prazo pode ser uma desvantagem uma vez que o XP ele é iterativo pode haver uma tendência a se concentrar em demandas imediatas sem pensar numa visão de longo prazo então isso pode

sacrificar a qualidade do código e que o código no final ele fica difícil de manter e modificar então para minimizar essa essa possível desvantagem é preciso haver um bom bom planejamento estratégico desde o início deve-se definir metas de longo prazo estabelecer uma visão Clara do produto final ainda uma desvantagem deve haver uma equipe experiente e autogerenciável e não é toda equipe que consegue se adaptar a essa situação Ahã se a equipe não for experiente não for capaz de se autogerenciar XP pode não funcionar adequadamente então a equipe ela precisa possuir conhecimentos técnicos adequados e precisa

ter bastante autonomia caso contrário o XP pode não funcionar então para mitigar essa possível desvantagem é necessário investir no desenvolvimento da equipe treinamento capacitação e incentivar a troca de conhecimento e a colaboração entre os membros da equipe estranhamente pode haver membros que não gostam de colaborar não gostam de transmitir conhecimento essas pessoas não não são adequadas para uma equipe XP e nós concluímos mais essa aula sobre processo de desenvolvimento ágeis eu espero que vocês tenham gostado dessa aula Se vocês gostaram eu peço que vocês curtam esse conteúdo compartilhem com quem possa se interessar e se

ainda não estão inscritos eu peço que se inscrevam no canal obrigado pela atenção [Música]