O Extreme Programming é um dos métodos ágeis. É diferente pois é Leve, Reduz o risco,  Eficiente, Flexível, Antecipado,  Fácil,  E o mais importante, é uma maneira emocionante e divertida de desenvolver software.

O que é o Extreme Programming?

Conforme Wikipedia – Extreme Programming (XP) é uma metodologia de desenvolvimento de software que visa melhorar a qualidade e a capacidade de resposta do software às mudanças nos requisitos do cliente.

Como um tipo de desenvolvimento ágil de software, defende frequentes “libera” em curtos ciclos de desenvolvimento, que visam melhorar a produtividade e introduzir pontos de verificação nos quais novos requisitos de clientes podem ser adotados.

Por que é chamado de “ Extreme? ”

Porque aumenta a eficiência e também garante a aplicação de princípios e valores de maneira extremamente eficaz. É feito por

• Em primeiro lugar, revisar o código a cada passo de cada iteração para torná-lo mais eficaz
• Em segundo lugar, fazendo testes de regressão em todas as etapas do desenvolvimento para tornar os testes mais eficazes.
• Além do acima exposto, a reutilização diária de códigos torna o design mais eficaz.
• Além disso, iterações curtas tornam a entrega mais eficaz.

A figura abaixo mostra como as fases e valores típicos de desenvolvimento de software foram levados ao seu nível extremo neste método de desenvolvimento.

Kent Beck originalmente definiu Extreme Programming (XP) em 1996; no entanto, sua segunda versão tinha uma explicação dos princípios, lançados em 1999. O foco principal da Extreme Programming é satisfação do cliente, e suas equipes de desenvolvimento alcançam isso organizando-se.

Eles desenvolvem recursos quando o cliente precisa deles. Além disso, a Extreme Programming leva as melhores práticas do processo de desenvolvimento a um nível extremo. No mercado em rápida mudança de hoje, ele usa o método de iteração para se adaptar rapidamente aos novos requisitos. É uma maneira altamente disciplinada de fornecer continuamente software de alta qualidade mais rapidamente.

Além disso, o cliente está envolvido ativamente com a equipe para executar planejamento, testes e feedback rápidos contínuos para fornecer software de trabalho com frequência.

XP é um dos métodos mais populares. É leve porque

• Em primeiro lugar, concentra-se em obter mais feedback, em vez de perguntar aos clientes antecipadamente sobre o que ele quer.
• Em segundo lugar, ele agrega valor ao cliente em pequenas iterações ( 1 ou 2 semanas ).
• Incentiva a mudança. Em outras palavras, ele tenta acomodar todas as alterações sugeridas pelo feedback do cliente, depois a redesenha, a recodifica e a reteste.
• Além disso, tenta eliminar defeitos nos estágios iniciais, reduzindo assim o retrabalho e o custo.
• Mantém o cliente envolvido durante todo o projeto.

Quando usar a Extreme Programming:

• O aplicativo de Extreme Programming acontece nos projetos em que os requisitos continuam mudando.
• Em alguns projetos críticos, mesmo antes de iniciar o projeto, os cronogramas são decididos. É referido como risco do projeto, pois é um desafio cumprir esses prazos. Portanto, a Extreme Programming também aborda o risco do projeto por ciclos de desenvolvimento frequentes e mais curtos e, consequentemente, permitindo feedback antecipado.
• O XP é aplicado onde temos um pequeno grupo de programadores, não mais que 12.

Valores, Princípios e Práticas:

Valores

Existem cinco valores de Extreme Programming

1. Comunicação	A comunicação é a parte mais crucial de qualquer projeto. É necessária uma comunicação adequada para preencher as lacunas entre o que o desenvolvedor está fazendo e os requisitos do cliente. Ajudará a reduzir o retrabalho se soubermos a condição exata. Além disso, comunicação adequada dentro da equipe (os desenvolvedores) também é necessário para garantir que todos estejam na mesma página. Por exemplo, digamos em um restaurante se um cliente diz especificamente ao garçom que ele quer que seu prato seja Menos oleoso levemente picante Menos salgado devido a razões médicas. Mas o garçom diz ao chef para tornar o prato menos picante. Depois disso, quando a refeição chega, ela é rejeitada pelo cliente, o motivo é; também tinha óleo e a quantidade usual de sal. E o chef teve que cozinhar novamente. Tudo porque não havia comunicação adequada entre o garçom e o chef.
2. Simplicidade	Precisamos começar a desenvolver os recursos mais diretos primeiro e, posteriormente, devemos passar para as funcionalidades problemáticas e extras. Deve ser simples, e devemos trabalhar na necessidade no momento. Além do acima exposto, não devemos nos preocupar com requisitos futuros e não devemos complicar, assumindo que esse recurso possa ser necessário posteriormente. Os desenvolvedores e testadores entenderão facilmente código e design simples. Por exemplo, quando o chef tem vários pedidos, ele sempre começa com o que acha confortável e está confiante de que pode cozinhar bem. Como, durante os exames, sempre fomos sugeridos por nossos idosos para começar com o que for mais simples.
3. Feedback	O feedback contínuo ajuda a entender o desempenho de você. Funciona como um catalisador para o projeto. Em Extreme Programming, o feedback pode vir de diferentes fontes, como Cliente: Após cada iteração, uma função será entregue ao cliente que executará o teste de aceitação. Com base nos resultados dos testes de aceitação, os desenvolvedores recebem o feedback e trabalham com ele posteriormente. Sistema: O principal motivo para realizar o teste da unidade é obter feedback. Ao escrever o teste da unidade ou realizar um teste de iteração, eles sabem do estado do sistema se há alguma falha na codificação. Dentro da equipe: O objetivo de formar uma equipe é ajudar um ao outro e trabalhar como um. Sempre que o cliente vem com um novo requisito, ele pode fornecer feedback sobre a estimativa do tempo necessário e a criação de uma expectativa com base em suas experiências anteriores. Por exemplo, desenvolvedores são como chefs em um restaurante. Eles devem estar prontos para aceitar feedback de todas as fontes da mesma maneira que um chef pode obter feedback do cliente, de seu chef sênior, do garçom ou da gerência..
4. Coragem	No desenvolvimento de software, coragem significa: Em primeiro lugar, fornecer confiança aos desenvolvedores para tomar decisões corajosas, entendendo todos os aspectos envolvidos. Em segundo lugar, confere confiança ao programador e permite que ele refacte ( reutilize ) o código usado, quando e quando necessário. Em outras palavras, o desenvolvedor analisa o código atual e o altera ou modifica para se adequar a fins futuros. Além do acima, ele suporta os desenvolvedores líderes na decisão de fazer o restante dos desenvolvedores funcionar com mais eficiência. Por exemplo, quando um programador fica preso em um problema difícil por um dia inteiro, ele pode preferir fazer uma pausa e resolvê-lo rapidamente no dia seguinte. No entanto, só será possível se ele for persistente. Por exemplo, em um restaurante, o chef é responsável por decidir os ingredientes, o tempo de cozinhar e o tempero. É o tipo de fé que a equipe mostra no chef e lhe dá coragem para tomar suas próprias decisões.
5. Respeito	No Extreme Programming, todos se respeitam. O respeito é a base dos quatro valores. Podemos ganhar respeito adotando acima os valores no sistema. Além disso, esse valor é mais sobre o trabalho em equipe. Em resumo, esse valor depende dos quatro valores acima. Por exemplo, em um restaurante, todos têm seus papéis específicos e outros valores. Um chef respeitará e valorizará o que o garçom disser; o chef nunca voltará e verificará com o cliente se o garçom está certo ou não? Da mesma forma, o garçom, enquanto serve, nunca perguntará ao chef sobre o prato. O garçom respeitará a experiência e a habilidade do chef.

Princípios

Os princípios abaixo são aplicados durante todo o procedimento de Extreme Programming:

1. Feedback rápido:

Feedback rápido significa que o tempo entre o recebimento do feedback e a implementação no sistema deve ser mínimo.

• Os desenvolvedores projetam, implementam e testam as funções. Consequentemente, o feedback é compartilhado imediatamente e é aplicado sem demora.
• Além disso, o código também é revisado com o sistema e o feedback é compartilhado instantaneamente.

2. Suponha simplicidade:

Esse princípio sugere que os desenvolvedores devem tentar lidar com todos os problemas com simplicidade, como,

• Um código desenvolvido deve refactar facilmente o ( reutilize após algumas modificações ) para realizar testes adicionais realizando testes de unidade.
• Tente manter o código simples e siga a regra de “você não vai precisar”. Em outras palavras, significa que, se não precisamos agora, não devemos mantê-lo.
• “Não se repita“, os desenvolvedores seguem esse princípio. Ou seja; você não deve manter várias cópias do mesmo documento, código, tarefa ou qualquer coisa.

3. Mudança incremental:

Alterações incrementais significam “mudanças em pequenos passos”. A Extreme Programming suporta alterações incrementais. Significa em um momento apenas muito:

• Pequenas mudanças no plano
• Alterações mínimas em uma equipe
• Pequenas mudanças no design

4. Abraçando a alteração:

É a abordagem que fala sobre adotar e considerar a maioria das mudanças, enquanto o problema real está sendo resolvido simultaneamente. Portanto, abraçando as conversas sobre mudanças

• A capacidade de aceitar as alterações no seu trabalho atual.
• Adaptar essas mudanças sem prejudicar seu trabalho.
• Fornecer o mesmo desempenho na implementação dessas mudanças também.

5. Trabalho de qualidade:

Fornecer o produto da melhor qualidade é o principal motivo. Para esclarecer, a equipe precisa

• Trabalhe em equipe
• Aproveite seus papéis
• Deve ser de suporte
• Deve se sentir bem e focado em fornecer um produto de qualidade

Práticas

A Extreme Programming possui as seguintes áreas de práticas –

• Feedback em escala fina
• Processo contínuo
• Compreensão compartilhada
• Bem-estar do programador

As Práticas do Extreme Programming

As 12 práticas de Extreme Programming atingem o objetivo de Extreme Programming. A fraqueza de qualquer um dos métodos é composta pela força de outras práticas.

Havia 24 práticas de XP, que mais tarde foram perfuradas por Kent Beck para 12 práticas primárias:

1. O jogo de planejamento ( histórias de usuários )
2. Pequenos lançamentos
3. Metáfora
4. Design simples
5. Teste
6. Refatoração
7. Programação de pares
8. Propriedade coletiva
9. Integração Contínua
10. Semana de trabalho de 40 horas
11. Cliente no local
12. Codificação

A figura acima mostra a aplicação das práticas no Extreme Programming.

• Como o uso de terminologias normais e a estrutura do sistema subjacente ( metáfora ), o cliente no local cria as histórias.
• Como essas histórias são passadas para os desenvolvedores e, além disso, o desenvolvedor cria um jogo de planejamento baseado nas histórias do usuário e, finalmente, inicia o desenvolvimento de todas as funcionalidades em pequenas iterações.
• Os recursos começam a ser lançados em pequenas iterações.
• A cor verde escura representa todos os processos pelos quais cada iteração passa. Ou seja, cada funcionalidade, em cada iteração, passa pelo teste de aceitação.
• A integração contínua usa os dados dos testes de aceitação. Junto com isso, a metáfora também usa esses resultados para esclarecer requisitos.
• Os padrões contínuos de integração e codificação enfatizam a propriedade coletiva. Em outras palavras, se alguém estiver ausente ou não estiver disponível, o trabalho não deve parar.
• Devido a requisitos precisos e linguagem fácil na metáfora, o design é simples.
• O mesmo design também pode ser refatorado para qualquer outra função.
• O teste da unidade é realizado após a conclusão do projeto.
• Os resultados dos testes de unidade são usados para integração contínua. Além disso, se houver algum bug, a programação em pares poderá ser feita para resolvê-lo.
• A solução da programação de pares pode ser documentada para referência futura, a fim de simplificar o design.
• Além disso, os resultados também são usados na definição do padrão de codificação, para que o mesmo problema, na mesma situação, não ocorra novamente.
• O padrão e a metáfora da codificação nos falam coletivamente sobre os padrões e a estrutura da organização com base nas práticas e resultados anteriores. E de acordo com isso na indústria de software, não se deve trabalhar mais de 40 horas por semana para trabalhar com eficiência.
• Propriedade coletiva

As quatro áreas em que as práticas de Extreme Programming se enquadram são:

1. Feedback em escala fina

• Teste:
  • O que é – Isso inclui todos os tipos de testes
    • Teste de unidade
    • Primeiro teste de projeto
    • Vários tipos de testes automatizados
    • Vantagens:
  • Em primeiro lugar, o teste de unidade é o teste final antes do teste do usuário. Indica que não é necessário mais design ou codificação.
    • Em segundo lugar, a refatoração do código acontece usando os resultados dos testes da unidade. Reduzirá o trabalho à medida que o código for reutilizado novamente.
    • Em terceiro lugar, o teste da unidade indica que o design é claro e não são necessárias mais modificações. Portanto, o desenvolvedor conhece seus objetivos de acordo com o design e sabe o que ele tem que desenvolver.
    • Além disso, a automação fornece uma série de testes de regressão que confirmam que o recurso / função testado está funcionando bem e não há efeito adverso disso.

• Cliente no local
  • O que é isso?
  • Alguém que tem profundo conhecimento do projeto.
  • Desempenha papéis significativos durante o “Fase de direção ( a fase em que todas as alterações são feitas, discutida em detalhes posteriormente neste artigo ) ” do projeto.
  • Ele fornece feedback rápido, pontual e contínuo à equipe de desenvolvimento.
  • Vantagens:
    • Em primeiro lugar, todas as perguntas são respondidas naquele momento; sem necessidade de e-mail ou aprovações.
    • Em segundo lugar, os clientes podem garantir que o produto esteja se moldando de acordo com seus requisitos.
    • Além disso, eles podem priorizar novamente os requisitos.

• Programação de pares
  • O que é isso?
    • Dois desenvolvedores compartilham uma estação de trabalho.
    • Eles usam seus cérebros para descobrir como fazer a codificação e como os outros codificarão.
    • Consequentemente, eles podem mudar de função, quando e quando necessário.
  • Vantagens:
    • Em primeiro lugar, dois cérebros sempre pensam melhor que um.
    • Em segundo lugar, eles trabalham com melhor concentração.
    • Além disso, duas pessoas podem debater e responder abaixo das perguntas de uma maneira melhor
      • Existe uma maneira de executar a tarefa de maneira mais simples?
      • Essa codificação como um todo vai funcionar?
      • Quais são os casos de teste que podem não funcionar e por quê?

2. Processo Contínuo

• Integração Contínua
  • O que é isso?
    • Adicionando novos recursos ou alterações ao sistema sem demora.
    • Além disso, acontece a aplicação de pequenas integrações ( características adicionais ) às funcionalidades.
    • Para esclarecer, um desenvolvedor estará tirando uma cópia do código base atual e trabalhará para criar um código para alguns recursos diferentes. Da mesma forma, outro desenvolvedor estará trabalhando com a mesma base de código para codificar para outra função. É assim que o código é improvisado ( integrado ) se for usado por mais de um dia.
  • Vantagens:
    • Em primeiro lugar, torna o processo menos demorado.
    • Além disso, permite pequenos lançamentos de projetos.

• Refatoração
  • O que é isso?
    • Processo de alteração do sistema de software para melhorar sua estrutura interna sem alterar o comportamento externo do código.
    • Reutilize o código antigo ( após o teste da unidade ) para codificar algumas outras funcionalidades.
  • Vantagens:
    • Em primeiro lugar, ajuda o desenvolvedor a melhorar o produto.
    • Em segundo lugar, permite brainstorming para encontrar diferentes maneiras e, portanto, promove a formação de equipes.
    • Além disso, aumenta o conhecimento do programador sobre o sistema.

• Lançamentos curtos
  • O que é isso?
    • Funcionalidades entregues em pequenas porções.
    • Menor os recursos, mais rápido o lançamento.
    • Suporte “Jogo de planejamento”.
  • Vantagens:
    • Em primeiro lugar, promove uma liberação mais rápida e frequente.
    • Em segundo lugar, é fácil acompanhar o progresso.
    • Em terceiro lugar, reduz as chances de grandes erros.
    • Além do acima, reduz o retrabalho.

3. Entendimento compartilhado −

• O jogo de planejamento
  • O que é isso?
    • Aprenda histórias de usuários para planejar.
    • Planeje o que será entregue na próxima iteração.
    • Uma pessoa técnica e experiente estimará o custo e o tempo.
    • O jogo Planejamento mostra a ligação entre o desenvolvedor e o customer.
  • Vantagens:
    • Em primeiro lugar, evita o desperdício de tempo no desenvolvimento de recursos desnecessários.
    • Em segundo lugar, é uma abordagem planejada, portanto, nenhuma adivinhação.
    • Além disso, todos estão cientes do progresso.

• Design simples
  • O que é isso?
    • Mantendo o design o mais simples possível.
    • Além do acima, fazendo o mínimo suficiente para agregar valor ao sistema.
  • Vantagens:
    • Em primeiro lugar, economiza tempo, porque nenhum recurso adicional é trabalhado.
    • Em segundo lugar, é fácil de entender.
    • Finalmente, trata-se de propriedade coletiva e, portanto, a refatoração será fácil.

• Metáfora
  • O que é isso?
    • A arquitetura verbal de todo o sistema. Em outras palavras, a metáfora define todo o sistema em seus termos técnicos e é compreensível apenas para aqueles que fazem parte do sistema.
    • Ele usa um conjunto padrão de condições.
    • As metáforas estão comandando ferramentas de ensino. Isso é para dizer; eles se acostumam em um grande número de áreas. Além disso, uma metáfora visa criar uma ponte de entendimento entre duas ou mais partes.
  • Vantagens:
    • Em primeiro lugar, inspira terminologias comuns.
    • Em segundo lugar, reduz o uso de jargões técnicos.
    • Além disso, é uma correção rápida e direta para entender o sistema.

• Propriedade coletiva
  • O que é isso?
    • Fala sobre responsabilizar os desenvolvedores pelo que estão fazendo.
    • Em outras palavras, todos os desenvolvedores da equipe possuem todo o código.
    • Refatorar acontece.
  • Vantagens:
    • Em primeiro lugar, não há medo de alguém deixar a equipe, pois todos na equipe conhecem o código completamente.
    • Além disso, torna cada desenvolvedor responsável por cada código no sistema.
    • Além disso, torna o desenvolvedor responsável pelo sistema como um todo e, portanto, não sendo apenas uma parte do sistema.

• Padrões de codificação
  • O que é isso?
    • Todo código deve seguir os mesmos padrões de codificação, que é uma decisão mútua do desenvolvedor líder e do cliente no momento do planejamento.
    • Além disso, apenas o líder deve saber quem projetou qual código para que a equipe trabalhe em equipe e não como indivíduos.
  • Vantagens:
    • Em primeiro lugar, mantém todos na mesma página, pois todos seguirão os mesmos padrões de codificação predefinidos.
    • Em segundo lugar, será fácil encontrar brechas ( se houver ), pois qualquer coisa que não atenda às regras de codificação padrão não será adequada.
  • Além disso, diminui o tempo que o desenvolvedor leva para codificar, pois ele conhece o conjunto de regras a seguir.
  • Finalmente, a codificação será clara e inconfundível.

4. Bem-estar do desenvolvedor / programador −

• Semana 40 horas
  • O que é isso?
    • Limitação do horário de trabalho a 40 horas em uma semana.
    • Nenhuma hora extra promovida porque é um sintoma de um problema.
    • Além disso, trabalhar mais de 40 horas por semana não será adequado a longo prazo.
  • Vantagens:
    • Em primeiro lugar, menos horas de trabalho mantêm o desenvolvedor ativo.
    • Ao mesmo tempo, eles trabalham com mais eficiência.
    • Além disso, mantém o desenvolvedor livre de estresse e saudável .

Artefatos XP

Dois artefatos principais no XP são

• Cartões de história
• Cartões de tarefas

Outros artefatos importantes da Extreme Programming são os seguintes

• Testes de aceitação
• Estimativas
  • Plano de liberação
  • Plano de iteração
• Design
• Casos de teste de unidade
• Registros de comunicação

Cartões de história

Uma história de usuário não passa de um documento que descreve os requisitos do usuário. As estruturas dos cartões de história do usuário têm os seguintes recursos:

• O cliente projeta ou grava um cartão de usuário.
• Descreve o sistema do ponto de vista do cliente.
• Um cartão de usuário é uma linguagem simples e pouco técnica. Em outras palavras, o cliente usa seus termos para explicar o requisito.
• Um cartão de usuário deve ser detalhado o suficiente para que o desenvolvedor possa estimar quanto tempo levará para que uma história específica seja projetada, testada e implementada.
• Uma descrição do recurso requer um cartão de usuário no sistema. Em outras palavras, um cartão de usuário para cada requisito.
• As estimativas para a entrega do recurso são feitas usando os cartões de histórias do usuário.

Cartões de tarefas

A Cartão de Tarefas é criado pela equipe de desenvolvimento para implementar a tarefa de maneira organizada. Ele terá os seguintes detalhes da tarefa em relação a uma história específica do usuário.

• A lista de tarefas necessárias para a implementação de uma História de Usuário é chamada de Cartão de Tarefas.
• Além disso, apenas um cartão de tarefa é projetado e emitido contra uma história de usuário.
• eualém disso, o Cartões de tarefa trabalhar como base para tarefas e fornecer uma estimativa para concluir uma tarefa.

Testes de aceitação:

O desempenho dos testes de aceitação ocorre para garantir que todas as histórias do usuário sejam adequadamente compreendidas e implementadas. A equipe de testadores faz esses testes.

Estimativas:

Existem duas fases, onde a avaliação da tarefa, a estimativa de tempo e a estimativa de esforço acontecem.

Abaixo estão as duas fases de estimativa e seu planejamento.

• Planejamento de Liberação– Nesta fase, a decisão de cada recurso ( iteração ) do “Plano de liberação” ocorre juntamente com a estimativa da duração da entrega e do número de pessoas / esforços necessários. A seguir, estão as razões para esta estimativa:
  • Primeiro, para descobrir a data completa de lançamento do objetivo do projeto, executada na fase de exploração.
  • Segundo, para descobrir se algum tempo ou ajuste da força de trabalho é planejado na fase de direção.
• Plano de Liberação – Plano de liberação é o plano documentado que terá os detalhes de −
  • As histórias de usuários que foram selecionadas pela equipe de desenvolvimento para lançamento.
  • Estimativas do tempo necessário e dos esforços necessários.
  • A data que foi confirmada como a data de lançamento.
• Estimativas – Planejamento de Iteração – Na mesma linha do planejamento de liberações, aqui nesta fase, acontece a avaliação das estimativas das tarefas relacionadas ao esforço e duração. Além disso, essa avaliação é usada para atribuir as tarefas no planejamento da iteração e equilibrar uma carga de trabalho por recurso na fase de compromisso.
• Plano de Iteração – O projeto é dividido em pequenas iterações e cada iteração terá os planos de iteração. O plano de iteração tem os seguintes detalhes:
  • As histórias do usuário selecionadas para essa iteração específica.
  • Tarefas atribuídas e os detalhes da pessoa a quem é atribuída.
  • Uma estimativa, quando a tarefa for concluída.

Design

O desenvolvedor desenvolve o design referindo-se à história do usuário. O desenvolvedor requer esse design para a implementação da história do usuário.

Casos de teste de unidade

Após o design, o desenvolvedor faz a codificação, seguida pelo teste da unidade.

Para testes de unidade –o caso de teste da unidade é preparado pelo desenvolvedor para garantir que o recurso específico ( unit ) esteja funcionando conforme o esperado. O teste da unidade é um teste escrito pelo desenvolvedor para qualquer funcionalidade específica. Além disso, o caso de teste da unidade leva à codificação e teste da unidade para qualquer tarefa. Em resumo, é o primeiro passo no nível de testes e feito antes Teste de integração.

Registros de comunicação do cliente e do desenvolvedor:

Todas as atividades são baseadas nas histórias.

• A história do usuário é a comunicação do usuário para um desenvolvedor.
• O cartão de tarefa é a comunicação dentro da equipe.

Portanto, ambas as histórias são documentadas com base na comunicação entre clientes e desenvolvedores ou dentro da equipe.

Como o XP não suporta documentação desnecessária,

• Se não for necessário – a comunicação pode ser verbal.
• Se necessário – a documentação pode acontecer posteriormente.

Quais são as diferentes atividades da Extreme Programming?

Existem quatro atividades principais da Extreme Programming. Eles são:

• Codificação
• Teste
• Ouvindo
• *Projetando

Codificação

Antes de codificar, trata-se de coletar os requisitos e projetar conforme os requisitos. No entanto, uma vez que o design e o teste acontecem, a codificação é iniciada.

Uma equipe de desenvolvedores ou programadores fará a codificação.

Teste:

O teste é de dois tipos, a saber, Manual e Automatizado. Aqui neste método, o teste manual é realizado.

A equipe de testadores realiza testes manuais e, posteriormente, os resultados dos testes serão publicados.

• Se os resultados do teste forem positivos, podemos prosseguir com o processo de liberação.
• No entanto, se não, o testador precisa aumentar o defeito, classificá-lo e testá-lo novamente.

Ouvindo:

Como o desenvolvedor saberia o que deve ser codificado por ele e testado pelo testador? Ouvir permite que você entenda seu trabalho.

Testadores e desenvolvedores são uma parte crítica do sistema. Portanto, ambos precisam ser um ouvinte ativo para entender o progresso atual e as próximas etapas.

Projetando:

Manter todas as três atividades no design de uma página acontece. Em outras palavras, coloca todas as três atividades sob um guarda-chuva.

Fases de programação

O desempenho de todas as atividades acima ocorre em diferentes fases do desenvolvimento. Essas diferentes fases da programação são −

• Planejamento de Liberação
• Planejamento de Iteração
• Implementação

Planejamento de lançamento

Nesta fase, planejamos o próximo lançamento. As histórias do usuário e a data de lançamento subsequente projetam isso. O planejamento da versão será feito pelo cliente e desenvolvedores mutuamente em três fases.

• Fase de Exploração
• Fase de Compromisso
• Fase de Direção

Planejamento de liberação – Fase de exploração:

Em primeiro lugar, a fase de Exploração é a fase de coleta de requisitos e descoberta do impacto desse requisito no projeto e, portanto, enquadrá-los em uma história de usuário. A seguir, estão as etapas para isso:

• Crie uma história:

Os clientes enfrentam alguns problemas e abordam o desenvolvedor com um problema e explicam sua pergunta ao desenvolvedor*.

• Posteriormente, o cliente e o desenvolvedor discutem o problema e compreendem os aspectos técnicos dele.
• Além disso, o desenvolvedor deve ajudar os clientes a entender os termos técnicos e não deve influenciar os requisitos do cliente.
• Por fim, os clientes documentam o problema e fornecem um cartão de história formalmente documentado para suas perguntas.
• O cartão de história do usuário deve ser documentado apenas pelo cliente e, posteriormente, o desenvolvedor o obtém.
• Em resumo, no cartão de história do usuário, os clientes chamarão seus requisitos e termos exatos.
• Estime uma história: Os desenvolvedores farão esta parte. Eles estimarão quanto tempo levará para implementar o trabalho mencionado no cartão de história do usuário. Além disso, eles podem analisar e preparar um layout para resolver o problema, para que todos tenham uma idéia clara sobre o problema e sua solução. Esta solução não deve influenciar os requisitos comerciais ou “Cartão de história do usuário“.
• Divida uma história: Antes de passar para a próxima fase, que é “Planejamento de Iteração”, precisamos projetar complexidades críticas primeiro. Se o desenvolvedor não conseguir estimar a história do usuário, ele deverá dividi-la ainda mais e escrever / explicar novamente.

Funções usadas nesta fase: Cliente e Desenvolvedor

Artefatos utilizados: Cartão de história do usuário

Importante: A escuta ativa é crucial nesta fase para:

• Atenda adequadamente aos requisitos do cliente
• Entenda o cartão de história do usuário
• Explique um cartão de história para a equipe de desenvolvimento
• Ganhe clareza
• Evite incerteza
• Expresse-se claramente no caso de interrupções de entendimento.

Fase de compromisso do planejamento de lançamento:

A segunda fase é conhecida como fase de compromisso, porque envolve a resolução de:

• Funcionalidades desejadas
• Custo estimado
• Impacto nos negócios
• Lucro e
• Data de lançamento

O cliente e o desenvolvedor resolverão isso com base em quatro componentes:

• Classificar por valor: O cliente classificará as histórias do usuário de acordo com os valores comerciais pelo cliente.
• Por velocidade: Os desenvolvedores tentam descobrir a que velocidade eles podem executar e entregar o projeto.
• Classificar por risco: O desenvolvedor classificará as histórias com base no risco.
• Escolhendo o escopo: Finalmente, as histórias do usuário com uma data de lançamento serão coletadas primeiro para garantir que sejam entregues a tempo. Em outras palavras, as histórias de usuários que terminarem primeiro no próximo lançamento serão retomadas mais cedo.

Funções usadas nesta fase: Cliente e Desenvolvedor

Artefatos utilizados: Cartão de história do usuário

Importante: A escuta ativa também é essencial aqui, devido aos seguintes motivos −

• Primeiro, o desenvolvedor precisa ter um entendimento claro da funcionalidade exigida na versão atual.
• Além disso, é essencial estimar os esforços e a duração necessários para a entrega dessa funcionalidade.
• Além disso, o cliente e o desenvolvedor poderão entender e decidir se é possível cumprir a data de lançamento comprometida ou não..

Fase de direção do planejamento de liberação:

Finalmente, chega a fase de direção, que também é conhecida como fase de mudança. Os requisitos de novas mudanças acontecem nesta fase.  Em outras palavras, tudo acontece nesta fase, como adicionar um novo recurso, remover ou alterar um recurso existente etc.

Na fase de direção, o cliente pode solicitar ao desenvolvedor que “boi” o processo

• Como, traga mudanças nas histórias do usuário.
• Priorizar as histórias de diferentes usuários ( alterando a prioridade ).
• Ajuste o plano de liberação em caso de estimativas incorretamente estabelecidas.
• Para acomodar as alterações sugeridas pelo usuário.

Funções usadas nesta fase: Cliente e Desenvolvedor

Artefatos utilizados: Cartão de história do usuário

Importante: Como todas as fases, a escuta ativa também é essencial nesta fase. É importante:

• Entenda a adição dos novos requisitos.
• Compreender as alterações necessárias para as necessidades atuais.
• Analise o que precisa ser removido e o impacto subsequente da remoção no sistema existente.
• Conhecer o trabalho realizado até agora.

Planejamento de Iteração:

Nesta fase, não há envolvimento do cliente. Isso é para dizer; os desenvolvedores planejarão as atividades e tarefas para iteração.

O planejamento de iteração tem três fases

• Fase de exploração.
• Fase de compromisso.
• Fase de direção.

Planejamento de iteração – Fase de exploração:

Na fase de exploração,

• Várias tarefas obtêm a interpretação dos requisitos.
• O cartão de tarefa registra todas as tarefas.
• Além do acima, o desenvolvedor fará uma estimativa do tempo de implementação da tarefa.
• Finalmente, trabalhos muito pequenos ou muito grandes são combinados / divididos para obter uma estimativa.

Funções: Desenvolvedores

Artefatos: Cartão de tarefa

Planejamento de iteração – fase de compromisso:

Na fase de compromisso,

• O desenvolvedor recebe as tarefas.
• O desenvolvedor reconhece a responsabilidade da tarefa atribuída.
• Além disso, o desenvolvedor fornece uma estimativa do tempo necessário para a conclusão da tarefa.
• Finalmente, o tempo estimado e a comparação de trabalho ocorrem quando toda a carga ( de trabalho ) ocorre entre os programadores.

Funções:  Desenvolvedores

Artefatos: Cartão de tarefa

Planejamento de iteração – Fase de direção:

Na fase de direção,

• O desenvolvedor entende o cartão de tarefa da tarefa executada.
• A equipe do desenvolvedor executa a tarefa usando as técnicas de programação do Pair.

Funções:  Desenvolvedores

Artefato: Cartão de tarefa

Implementação:

A implementação acontece durante a fase de direção da iteração. As atividades que se enquadram nisso são-

• Projete a tarefa: O desenvolvedor começa a trabalhar no trabalho escrito no cartão de tarefa e, posteriormente, começa a projetar conforme o cartão.
• Escreva um teste de unidade: O programador primeiro grava um teste automatizado conhecido como teste de unidade, antes da codificação real.
• Escreva o código: O programador começa a codificar.
• Executar teste:  Os testes de unidade são executados para verificação de código.
• Refatoração: Isso significa reutilizar o código com algumas pequenas alterações.
• Execute testes funcionais: Testes integrados e testes de aceitação do usuário estão sob este.

Papel: Desenvolvedores

Funções e responsabilidades extremas:

Na Extreme Programming, três funções são muito críticas e vitais. Da mesma forma, existem outros papéis também, mas eles trabalham sob eles. Esses papéis principais são-

Cliente:

O cliente é quem decide e transmite todo o requisito. Na Extreme Programming, o cliente deve estar em contato contínuo com os desenvolvedores. Além disso, o cliente pode ser

• Uma comunidade específica
• Um grupo de partes interessadas
  • Uma equipe com o membro que inclui
  • Gerentes de produtos
  • Membros de vendas e marketing
  • Usuários e gerentes finais
  • Analista de Negócios
  • Operações

O cliente será responsável pelo seguinte

• Escrevendo histórias de usuários
• Testando as funções finais entregues pelos desenvolvedores e escrevendo um teste funcional
• Definindo prioridades
• Explicando histórias para o desenvolvedor
• Decidir se ele se encaixa no requisito do usuário final
• Decidindo perguntas sobre as histórias

Programador:

Desenvolvedor ou programador deve ser um comunicador eficaz, porque ele é o único canal de comunicação entre a equipe de desenvolvimento, a equipe de testes e o cliente. Um desenvolvedor terá o direito de fazer o seguinte

• Realizar conhecimento de requisitos
• Produzir trabalho de qualidade
• Gerenciamento de abordagem para obter ajuda, que inclui seus supervisores hieráticos e o cliente
• Desenvolver e alterar as estimativas fornecidas
• Seja responsável

As principais responsabilidades de um programador são

• Primeiro, para entender e estimar histórias de usuários.
• Segundo, definir e estimar tarefas com base na história do usuário.
• Terceiro, para escrever um teste de unidade.
• Além disso, para gravar código para passar no teste da unidade.
• Posteriormente, para realizar o teste da unidade.
• Refatorar
• Finalmente, para integrar e tentar melhorar continuamente.

Treinador:

O papel de um treinador é significativo na Extreme Programming. Um treinador garante que todos estejam trabalhando para fazer a programação para uma Extreme Programming. O treinador deveria ter

• Comportamento sutil para ser treinador, mesmo que todos os outros estejam em pânico
• Excelente conhecimento da Extreme Programming
• Natureza útil, porque ele tem que observar todos e, consequentemente, ajudar.

As responsabilidades de um treinador incluem

• Observando todas as atividades e certificando-se de que todo o projeto permaneça no caminho certo.
• Ele estará ajudando a equipe com qualquer coisa relacionada ao projeto.
• Responsável por descobrir as práticas extremas de programação que ajudam a resolver quaisquer problemas no projeto.
• Além do acima, ele garante que a equipe seja auto-suficiente.
• Ele estará observando todas as equipes silenciosamente.
• Se surgir algum problema, ele pode envolver ou formar qualquer equipe destinada a ajudar.

Alguns outros papéis são:

Testador:

O testador será quem fará o teste após a codificação. As responsabilidades de um testador incluem –

• Implementando todos os testes funcionais (, exceto o teste de unidade )
• Gráficos de todos os resultados
• Informar o cliente e o desenvolvedor quando os resultados do teste não forem possíveis

Rastreador:

O rastreador será a pessoa que garantirá que todos estejam fazendo seu trabalho corretamente, incluindo o desenvolvedor. As responsabilidades de um rastreador incluem:

• Organizar reuniões do desenvolvedor com os clientes quando e quando necessário.
• Monitorando o progresso do desenvolvedor.
• Além disso, marcar uma reunião de equipe e agir se as coisas não estiverem indo tão comprometidas.
• Entre em contato com o treinador ou o programador para obter ajuda ( se necessário ).

Doomsayer:

Como o nome sugere, o portador será quem ficará de olho em qualquer desastre. Esses desastres podem ser como não cumprindo cronogramas, um bug devido a um pequeno erro, questões de infra-estrutura, ou algo que possa impactar o projeto de qualquer maneira. Em outras palavras, o portador tentará que nada dê errado. As responsabilidades do porteiro incluem:

• Prever o risco, se houver
• Garantir que todos os envolvidos nos projetos conheçam o risco envolvido
• Manter a transparência de qualquer notícia má
• Certifique-se de que todos estejam cientes do impacto, urgência e fatores / atividades que serão afetados.

Gerente:

O gerente é quem passará os relatórios e rastreadores para o progresso do processo. Ele será responsável perante o Proprietário de ouro em caso de problemas (O proprietário do ouro é alguém que financiará o projeto pelo lado do cliente). As responsabilidades de um gerente são as seguintes:

• Em primeiro lugar, para garantir que a equipe de Desenvolvimento, assim como o cliente, conheça adequadamente a explicação do Jogo de Planejamento.
• Em segundo lugar, observar o Jogo de Planejamento e modificar regras, quando e quando necessário.
• Terceiro, para garantir a identificação e rastreamento dos defeitos.
• Além disso, para verificar o rastreamento do tempo de resolução e do tempo gasto por cada equipe no defeito.
• Além disso, obtenha todas as informações sem perturbar o trabalho atual da equipe.
• Por fim, participar das reuniões dos clientes e acompanhar todas as informações úteis discutidas na reunião.

Fases do Extreme Programming

Esta figura nos fala sobre o fluxo da Extreme Programming, em Extreme Programming primeiro.

• Inicialmente, os requisitos do usuário são coletados em o cartão da história do usuário.
• Posteriormente, o cartão de história do usuário faz o planejamento de iteração. Tempo e esforço estimativas acontecer em Planejamento de iteração.
• O desenvolvimento sábio da iteração processo começa após o planejamento.
• Além disso, a incorporação de novos requisitos acontecem durante o desenvolvimento.
• Além disso, quaisquer alterações necessárias durante teste de iteração estão incluídos apenas nesta fase. Além disso, a adição de Novos requisitos do usuário também acontece nesta fase apenas.
• Após testes bem-sucedidos de iteração, ele será desenvolvido UAT ( Teste de aceitação do usuário ).
• Depois disso, se os defeitos aumentará, em caso de bugs; voltará na fase de desenvolvimento.
• Finalmente, se não houver bugs – Lançamento final, Acabamentos de treinamento do usuário e suporte ao produto fornecido.

Foi um fluxo de programação extremo. Isso nos leva à questão de quantas fases existem no fluxo de trabalho de programação extremo? Existem 6 fases no fluxo de processo da Extreme Programming.

Essas 6 fases são as seguintes:

Planejamento:

• Identificação de investidores
• Reconhecendo as necessidades de infraestrutura
• Estabelecendo necessidades de segurança
• Contrato de nível de serviço de assinatura ( i. e um documento formal que fala sobre a prestação de vários serviços ) com todas as restrições.

Análise

• Obtendo histórias de usuários do cliente
• Analisando histórias de usuários
• Priorizando histórias
• Matrizes para estimativas
• Definindo iteração, por exemplo, qual iteração fornece todas as funcionalidades.
• Planejamento para equipes de teste e desenvolvimento

Design

• Projeto para a primeira iteração
• Preparando um caso de teste para cada tarefa
• Estrutura de automação de regressão

Execução

• O desenvolvedor fará a codificação.
• Após a codificação dos acabamentos, o controle de qualidade realiza o teste de unidade.
• Depois disso, o teste manual acontece.
• Relatório de defeitos gera ( se os defeitos aumentarem ).
• A conversão dos casos de teste de regressão Manual para Automação acontece.
• Revisão de média iteração
• Revisão do final da iteração

Embrulho

• Liberação de iteração acontece
• O teste de regressão ocorre
• O cliente recebe as demos e as revisa
• Posteriormente, se necessário, o cliente desenvolve uma nova história após o teste.
• Finalmente, após a revisão da iteração, os planos de melhoria serão preparados com base no feedback.

Encerramento

• Treinamento para o usuário final fornecido
• Lançamento da produção acontece
• Além disso, o desempenho de várias verificações acontece se o desenvolvedor tiver cumprido o SLA.
• Finalmente, o suporte à produção é fornecido para o produto desenvolvido.

Agora que entendemos a Extreme Programming, vamos analisar as principais diferenças entre a Extreme Programming e o Scrum.

Diferenças entre Extreme Programming e Scrum

Extreme Programming	Scrum
Um sprint é concluído em 2-10 dias	Um sprint leva duas semanas a 6 semanas para ser concluído
A Extreme Programming permite alterações no sprint em qualquer estágio do desenvolvimento	Por outro lado, em Scrum, quando a reunião de planejamento do sprint terminar e a entrega acontecer, nenhuma alteração poderá ocorrer no sprint.
Os desenvolvedores começam a trabalhar de acordo com a prioridade dada pelos usuários.	Os desenvolvedores decidem a prioridade e, posteriormente, começam a se desenvolver.
O XP possui práticas como TDD, Programação de pares, refatoração etc., que são obrigatórias a seguir	Não recomenda nenhuma prática de engenharia

Por que Extreme pode falhar

• Na Extreme Programming, o código ganha importância sobre o design. No entanto, é o design que vende o aplicativo e não o código. Quando os programadores se concentram no código e no design difere um pouco, o produto final pode deixar o cliente insatisfeito. Portanto, para evitar isso, os desenvolvedores precisam se concentrar no design e no código.
• A Extreme Programming aceita mudanças em qualquer estágio. Por outro lado, essas alterações não são documentadas adequadamente. Por exemplo, se houver alguma falha na implementação, encontrar seu motivo será extremamente difícil devido à falta de documentação. Portanto, é imperativo ter documentação adequada para cada alteração, a fim de evitar erros.
• Além disso, a Extreme Programming limita a gama de projetos porque requer interação cara a cara com projetos XP. Isso é ainda mais desafiador de implementar se o cliente se afastar do local de desenvolvimento.

Conclusão

Para concluir, a Extreme Programming é uma estrutura ágil de desenvolvimento de software. Melhora a qualidade e a capacidade de resposta do software aos requisitos em constante mudança do cliente. Além disso, favorece frequentes “libera” para melhorar a produtividade.