O Extreme Programming (ou a programação extrema) é um dos métodos ágeis. Ele é diferente pois é Leve, Reduz o risco, Eficiente, Flexível, Antecipado, Fácile, o mais importante, é uma maneira emocionante e divertida de desenvolver software.

Já falamos na nossa série Agile Methods sobre Crystal, DSDMLSD, Kanban, e hoje vamos falar um pouco de Extreme Programming.

O que vamos ver?

  • O que é eXtreme Programming:  Vamos dar uma olhada na definição de eXtreme Programming (XP).
  • Por que é chamado eXtreme: Começaremos explicando a você como a improvisação das funcionalidades e práticas ajuda a aumentar a eficiência e torná-la extrema.
  • Valores, princípios e práticas: Aqui, discutiremos todos os cinco princípios e valores em detalhes, juntamente com uma descrição detalhada de todas as 12 práticas.
  • Artefatos XP: A discussão dos três artefatos mais importantes e outros acontece aqui.
  • Quais são as diferentes atividades do Extreme Programming? Primeiramente vamos ver sobre todas as atividades realizadas no Extreme Programming. Vamos explicá-los em detalhes com a ajuda de um diagrama.
  • Funções e responsabilidades do Extreme Programming: Em segundo lugar teremos uma discussão sobre todas as funções, incluindo as duas funções mais significativas, ou seja, funções de cliente e desenvolvedor, juntamente com seu conjunto de responsabilidades e as habilidades necessárias, acontece aqui em detalhes.
  • Fases da programação do Extreme Programming:  De acordo com esta seção, eu inclui uma descrição do fluxo completo do processo e todas as etapas do desenvolvimento de software usando programação extrema com a ajuda de um diagrama de processo.
  • Diferenças entre Extreme Programming e Scrum: Então aqui, explicaremos as diferenças significativas entre os dois principais métodos Agile.
  • Por que o eXtreme pode falhar: Por fim, esta seção explica quais são as desvantagens da eXtreme Programming e por que ele pode falhar. Ele nos diz que medidas devemos tomar para evitar o fracasso.

O que é o eXtreme Programming?

De acordo com a Wikipedia – Programação extremaXP )1 é 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.

Igualmente à um tipo de desenvolvimento ágil de software, defende “lançamentos ” frequentes em curtos ciclos de desenvolvimento, que visam melhorar a produtividade e introduzir pontos de verificação nos quais novos requisitos do cliente podem ser adotados.

Por que é chamado de “extremo”?

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

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

De acordo com a figura abaixo as fases e os valores típicos de desenvolvimento de software foram levados ao seu nível extremo nesse método de desenvolvimento.

XP - Soft to Extreme

Origens do eXtreme Programming

Kent Beck2 originalmente definiu o eXtreme Programming (XP) em 1996; no entanto, sua segunda versão tinha uma explicação dos princípios, lançados em 1999.

Acima de tudo o foco principal da programação extrema é a satisfação do cliente, e suas equipes de desenvolvimento alcançam esta satisfação organizando-se, ou seja;

Eles desenvolvem recursos quando o cliente precisa deles. 

Além disso, a programação extrema leva as melhores práticas do processo de desenvolvimento a um nível extremo. 

Enquanto o mercado sofre rápidas mudanças nos dias atuais, o XP usa o método de iteração para se adaptar rapidamente aos novos requisitos.

Inclusive é 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 o planejamento contínuo, testes e feedback rápido para fornecer software de trabalho com freqüência.

Uma vez que o XP normalmente é um dos métodos mais populares por sua leveza, e ele é leve porque:

  • Em primeiro lugar, concentra-se em obter mais feedback, em vez de perguntar aos clientes antecipadamente o que ele deseja.
  • Em segundo lugar, 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, o redesenha, o recodifica e volta a testá-lo.
  • Além disso, ele 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 o eXtreme Programming

Primeiramente a aplicação de eXtreme Programming acontece nos projetos em que os requisitos continuam em constante mudança.

Embora em alguns projetos críticos, mesmo antes de iniciar o projeto, os prazos são decididos, o que causa um maior risco do projeto, pois é um desafio cumprir esses prazos. (nem parece que você vive isso todo dia não é?)

Portanto, o eXtreme Programming também aborda os riscos do projeto por ciclos de desenvolvimento freqüentes 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

XP - Valores

1. Comunicação

Acima de tudo 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.

Dessa forma isso vai ajudar a reduzir o retrabalho, além disso, também é necessária uma comunicação adequada dentro da equipe (os desenvolvedores) para garantir que todos estejam na mesma página.

Por exemplo, digamos em um restaurante se um cliente diz ao garçom especificamente 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 deixar o prato menos picante. Depois disso, quando a refeição chega, ela é rejeitada pelo cliente, pelo motivo; também tinha óleo e a quantidade habitual de sal. E o chef teve que cozinhá-lo novamente. Tudo porque não havia comunicação adequada entre o garçom e o chef.

2. Simplicidade

Primeiramente precisamos começar a desenvolver os recursos mais diretos e, depois, devemos passar para as funcionalidades problemáticas e extras, deve ser simples, e devemos trabalhar na necessidade do momento.

Além do acima, não devemos nos preocupar com requisitos futuros e não devemos complicar uma tarefa, assumindo que esse recurso possa ser necessário posteriormente.

Dessa forma 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 achar confortável e confiante de que sabe cozinhar bem.

Como durante os exames escolares, nós sempre fomos orientados pelos mais velhos que devíamos começar pelas perguntas mais simples.  

3. Feedback

O feedback contínuo ajuda a entender o quão bom você está, funciona como um catalisador para o projeto. No eXtreme programming, o feedback pode vir de diferentes fontes, à exemplo:

  • 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 posteriormente.
  • Sistema: O principal motivo para a realização do teste unitário é obter feedback. Dessa forma ao escrever o teste de unidade ou ao executar um teste de iteração, eles ficam sabendo do estado do sistema e se há alguma falha na codificação.
  • Dentro da equipe: O objetivo de formar uma equipe é ajudar um ao outro e trabalhar como um time. Sempre que o cliente atender a um novo requisito, a equipe poderá 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, os desenvolvedores são como chefs em um restaurante. Eles devem estar prontos para aceitar o feedback de todas as fontes na mesma linha em que um chef pode obter feedback do cliente, seu chef sênior, garçom ou gerência.

4. Coragem

No desenvolvimento de software, coragem significa:

  • Em primeiro lugar, fornecer confiança aos desenvolvedores para tomar decisões corajosas, compreendendo todos os aspectos envolvidos.
  • Em segundo lugar, ele dá confiança ao programador e permite refatorar (reutilizar) o código usado, como e quando necessário. Ainda em outras palavras, o desenvolvedor analisa o código atual e o altera ou modifica para se adequar a propósitos futuros.
  • Além do acima, ele suporta desenvolvedores líderes na decisão de fazer com que o restante dos desenvolvedores trabalhe 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, isso só será possível se ele for persistente.

Por exemplo, em um restaurante, o chef é responsável por decidir os ingredientes, o tempo de cozimento 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

Certamente no Extreme Programming, todos se respeitam.

  • Primeiramente respeito é a base de todos os quatro valores.
  • Em segundo lugar podemos ganhar respeito adotando os valores acima no sistema.
  • Além disso, esse valor tem mais a ver com trabalho em equipe.
  • Para resumir, 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 habilidade do chef.

Princípios

Os princípios abaixo são aplicados durante todo o processo do eXtreme Programming

1. Feedback rápido

Em primeiro lugar, Feedback rápido significa que o tempo entre o recebimento e a implementação no sistema deve ser mínimo.

  • Antes de tudo 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. Simplicidade

Esse princípio sugere que os desenvolvedores tentem lidar com todos os problemas com simplicidade, como:

  • Um código desenvolvido deve ser refatorado facilmente (reutilizar após algumas modificações) para fazer testes adicionais executando testes de unidade.
  • Em segundo lugar tentar manter o código simples e seguir a regra de “você não precisará dele“. Em outras palavras, significa que, se não precisarmos agora, não devemos mantê-lo.
  • Finalmente o “Não se repita“, os desenvolvedores seguem esse princípio, o que quer dizer; você não deve manter várias cópias do mesmo documento, código, tarefa ou qualquer coisa.

3. Mudança incremental

Assim sendo as alterações incrementais significam as “alterações em pequenas etapas“. O Extreme Programming suporta mudanças incrementais o que significa de uma só vez; muito:

  • Pequenas mudanças no plano;
  • Mudanças mínimas em uma equipe;
  • Pequenas mudanças no design.

4. Aceitar a mudança

É a abordagem que fala em adotar e considerar a maioria das mudanças, enquanto o problema real está sendo resolvido simultaneamente. Portanto, abraçar 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 alterações também.

5. Trabalho de qualidade

Fornecer o melhor produto de qualidade é o principal motivo; para esclarecer, a equipe precisa:

  • Trabalhar em equipe;
  • Aproveitar seus papéis;
  • Devem ser solidários;
  • Devem se sentir bem e focados em fornecer um produto de qualidade.

Práticas do Extreme Programming

O Extreme Programming possui as seguintes áreas de atuação:

  • Feedback em escala fina;
  • Processo contínuo;
  • Entendimento compartilhado;
  • Bem-estar do programador.

Ademais as 12 práticas de extreme programming alcançam o objetivo de programação extrema. A fraqueza de qualquer um dos métodos é constituída pela força de outras práticas.

Anteriormente haviam 24 práticas de XP, que foram posteriormente analisadas por Kent Beck para as 12 principais práticas:

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

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

 1. Feedback em grande escala

Teste 

O que é isso?

  • Inclui todos os tipos de teste;
  • 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 nenhum design ou codificação adicional.
  • Em segundo lugar, a refatoração do código ocorre usando os resultados do teste de unidade. Reduzirá o trabalho à medida que o código for reutilizado novamente.
  • Em terceiro lugar, o teste de unidade indica que o design é claro e não são necessárias outras modificações. Portanto, o desenvolvedor conhece seus objetivos de acordo com o design e sabe o que ele precisa 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 que não há efeito adverso.

Cliente no local

O que é isso ?

  • Alguém que tem um conhecimento profundo do projeto.
  • Desempenha papéis significativos durante a “ Fase de orientação (a fase em que todas as alterações são feitas, discutidas em detalhes posteriormente neste artigo)” do projeto.
  • Ele fornece feedback rápido, pontual e contínuo para a 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 sendo modelado conforme suas necessidades.
  • Além disso, eles podem priorizar novamente os requisitos.

Programação em pares3

O que é isso?

  • Primeiramente dois desenvolvedores compartilham uma estação de trabalho.
  • Eles usam seus cérebros para descobrir como fazer a codificação e como os outros irão codificar.
  • Conseqüentemente, eles podem mudar de função, conforme 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 às perguntas abaixo 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 ?

  • Adicionar novos recursos ou alterações ao sistema sem demora.
  • Além disso, ocorre a aplicação de pequenas integrações (recursos adicionais) às funcionalidades.
  • Para esclarecer, um desenvolvedor fará uma cópia do código base atual e trabalhará nisso 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 usado por mais de um dia.

Vantagens

  • Em primeiro lugar, torna o processo menos demorado.
  • Além disso, ele permite pequenos lançamentos de projetos.

Reestruturaçã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.
  • Além disso reutilizar o código antigo (após o teste de unidade) para codificar alguma outra funcionalidade.

Vantagens

  • Em primeiro lugar, ajuda o desenvolvedor a melhorar o produto.
  • Em segundo lugar, permite o brainstorming para encontrar maneiras diferentes e, portanto, promove a formação de equipes.
  • Além disso, aumenta o conhecimento do programador sobre o sistema.

Lançamentos breves

O que é isso ?

  • Funcionalidades entregues em pequenas porções.
  • Menos recursos, mais rápido o lançamento.
  • Suporte ao “jogo de planejamento”.

Vantagens

  • Em primeiro lugar, promove a liberação mais rápida e frequente.
  • Em segundo lugar, é fácil acompanhar o progresso.
  • Assim, reduz as chances de grandes erros.
  • Além do exposto, reduz o retrabalho.

3. Entendimento Compartilhado

O jogo do planejamento

O que é isso?

  • Aprenda histórias de usuário 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 de planejamento mostra a ligação entre o desenvolvedor e o cliente.

Vantagens

  • Em primeiro lugar, evita a perda de tempo no desenvolvimento de recursos desnecessários.
  • Em segundo lugar, é uma abordagem planejada, portanto, sem adivinhações.
  • 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 que foi dito acima, fazer o 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 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 as 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 solução rápida e direta para entender o sistema.

Propriedade Coletiva

O que é isso?

  • Fala sobre tornar os desenvolvedores responsáveis ​​pelo que estão fazendo.
  • Em outras palavras, todos os desenvolvedores da equipe possuem todo o código.
  • A refatoração 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 todos os códigos do 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 o 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 levará para fazer a codificação, pois ele conhece o conjunto de regras a seguir.
  • Por fim, a codificação será clara e inconfundível.

4. Bem-Estar do Desenvolvedor / Programador 

Semana de 40 horas

O que é isso?

  • Limitação do horário de trabalho para 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.

XP Práticas

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

Aplicação das práticas Extreme Programming

Primeiramente, usando terminologias normais e a estrutura do sistema subjacente (metáfora), o cliente no local cria as histórias.

Além de mostrar como essas histórias são transmitidas aos desenvolvedores e, ainda assim, o desenvolvedor criar um jogo de Planejamento baseado nas histórias dos usuários e, finalmente, inicia o desenvolvimento de todas as funcionalidades em pequenas iterações.

Portanto os recursos começam a ser lançados em pequenas iterações.

A cor verde escuro representa todos os processos pelos quais cada iteração passa. Ou seja, cada funcionalidade, em todas as iterações, passa pelos testes de aceitação.

Enquanto 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 os requisitos.

Já os padrões de integração e codificação contínuos enfatizam a propriedade coletiva. Em outras palavras, se alguém estiver ausente ou não estiver disponível, o trabalho não deve parar.

Aplicação de design simples

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 de unidade é realizado após a conclusão do projeto, os resultados dos testes de unidade são usados ​​para a integração contínua. Além disso, se houver algum erro, a programação em pares pode ser feita para resolver o problema.

A solução da programação em 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 de codificação e a metáfora nos informam coletivamente sobre os padrões e a estrutura da organização com base nas práticas e resultados anteriores.

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. Além de manter a propriedade coletiva.

Artefatos do Extreme Programming

Dois artefatos principais no XP são:

  • Cartões de História (Story Cards)
  • Cartões de Tarefas (Task Cards)

Outros artefatos importantes de Extreme programming são

  • Testes de aceitação;
  • Estimativas;
    • Plano de liberação;
    • Plano de Iteração.
  • Projeto;
  • Casos de teste de unidade;
  • Registros de comunicação.

Extreme Programming – Cartões de História (Story Cards)

Primordialmente uma história de usuário nada mais é do que o documento que descreve os requisitos do usuário. As estruturas dos cartões de história do usuário têm os seguintes recursos:

  • Primeiramente cliente cria ou grava um cartão de usuário.
  • Ele descreve o sistema do ponto de vista do cliente.
  • Um cartão de usuário é simples e não possui muita linguagem técnica. Em outras palavras, o cliente usa seus termos para explicar o requisito.
  • Já 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 de recurso requer um cartão de usuário no sistema. Em outras palavras, um cartão de usuário para cada requisito.
  • Finalmente as estimativas para a entrega do recurso são feitas usando os cartões de história do usuário.

Extreme Programming – Cartões de tarefas (Task Cards)

Um Cartão de Tarefa é 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 de usuário específica.

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

Extreme Programming – Testes de aceitação

Naturalmente o desempenho dos testes de aceitação acontecem para garantir que todas as histórias de Usuário sejam entendidas e implementadas adequadamente. A equipe de testadores faz esses testes.

Extreme Programming – Estimativas

Paralelamente existem duas fases, nas quais a avaliação da tarefa, a estimativa do tempo e a estimativa do esforço ocorrem. Portanto 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 junto com a estimativa da duração da entrega e do número de pessoas/esforços necessários.

A seguir, apresentamos os motivos dessa estimativa:

  • Primeiro, para descobrir a data de lançamento completa do projeto, executada na fase de exploração.
  • Segundo, para descobrir se algum tempo ou ajustes na força de trabalho são planejados 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ário que foram selecionadas pela equipe de desenvolvimento para liberação.
  • Estimativas do tempo necessário e dos esforços necessários.
  • A data que foi confirmada como a data de lançamento.

Planejamento de iteração

Nesta mesma linha que o planejamento de liberação, aqui nesta fase, ocorre 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 consolidação.

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 possui os seguintes detalhes:

  • As histórias de usuário selecionadas para essa iteração específica.
  • Tarefas atribuídas e os detalhes da pessoa a quem está atribuída.
  • Uma estimativa, quando a tarefa é concluída.

Extreme Programming – Projeto

Primeiramente desenvolvedor desenvolve o design consultando a história do usuário. Assim o desenvolvedor requer esse design para a implementação da história do usuário.

Extreme Programming – Casos de teste de unidade

Após o design, o desenvolvedor faz a codificação, seguida pelo teste de unidade (testes unitários).

Diante disso para realizar este teste de unidade – o caso de teste de unidade é preparado pelo desenvolvedor para garantir que o recurso (unidade) específico esteja funcionando conforme o esperado.

Portanto o teste de unidade é um teste escrito do desenvolvedor para qualquer funcionalidade específica. Além disso, o caso de teste de unidade leva à codificação e ao teste de unidade para qualquer tarefa.

Em resumo, é o primeiro passo no nível de teste e é feito antes do teste de Integração.

Extreme Programming – Registros de comunicação com clientes e desenvolvedores

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

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

Portanto, as duas 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 no Extreme Programming?

Existem quatro atividades principais do XP. Eles são:

Codificação TesteOuvir > Projetar (ou Design/Desenvolver)

XP - Atividades

Codificar

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

De fato uma equipe de desenvolvedores ou programadores fará a codificação.

Testar

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.

Ouvir

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

O testador e os 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.

Projetar

Para manter todas as três atividades no design de uma página, acontece. Em outras palavras, reúne as três atividades sob o mesmo guarda-chuva.

Fases da 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 Liberação

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 liberação será feito pelo cliente e pelos desenvolvedores mutuamente em três fases.

ExploraçãoCompromissoDireção

Planejamento de Liberação – Fase de Exploração

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

Criar uma história

  • Os clientes enfrentam alguns problemas e abordam o desenvolvedor com um problema e explicam suas perguntas ao desenvolvedor.
  • Posteriormente, o cliente e o desenvolvedor discutem o problema e compreendem seus aspectos técnicos.
  • 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 chamam seus requisitos e termos exatos.

Estimar 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 ter influência nos requisitos comerciais ou no “cartão de história do usuário”.

Dividir uma história

Antes de passar para a próxima fase, que é “Planejamento de Iteração”, precisamos primeiro criar complexidades críticas.

Se o desenvolvedor não conseguir estimar a história do usuário, o cliente precisará dividi-la ainda mais e escrever / explicar novamente.

Funções usadas nesta fase: Cliente e Desenvolvedor

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

Importante: A escuta ativa é crucial nesta fase para:

  • Obtenha a exigência do cliente corretamente
  • Compreender o cartão de história do usuário
  • Explicar um cartão de história para a equipe de desenvolvimento
  • Obtenha clareza
  • Evite incertezas
  • Expresse-se claramente no caso de compreender quebras.

Planejamento de liberação – fase de compromisso

A segunda fase é conhecida como fase de compromisso, pois 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 do cliente.
  • Por velocidade : os desenvolvedores tentam descobrir em 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 : Por fim, as histórias de usuários com 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 terminam primeiro no próximo lançamento serão coletadas mais cedo.

Funções usadas nesta fase: Cliente e Desenvolvedor

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

Importante: A escuta ativa também é essencial aqui, pelas seguintes razões:

  • Primeiro, o desenvolvedor precisa ter um entendimento claro da funcionalidade necessária 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 confirmada ou não.

Planejamento de Liberação – Fase de Direção

Finalmente, chega a fase de direção, que também é conhecida como fase de mudança . Os requisitos de quaisquer novas alterações acontecem nesta fase.

Em outras palavras, tudo acontece nessa 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 “conduza” o processo –

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

Funções usadas nesta fase: Cliente e Desenvolvedor

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

Importante: Como em 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 planejam as atividades e tarefas para iteração.

O Planejamento de Iteração possui 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 tarefas registra todas as tarefas.

Além do acima, o desenvolvedor fornecerá uma estimativa do tempo de implementação da tarefa. Finalmente, trabalhos muito pequenos ou grandes são combinados / divididos para obter uma estimativa.

Funções : Desenvolvedores

Artefatos : Cartão de Tarefas

Planejamento de iteração – fase de compromisso

Na fase de compromisso, o desenvolvedor recebe as tarefas, ele 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 do trabalho ocorrem quando toda a distribuição de carga (trabalho) ocorre entre os programadores.

Funções : Desenvolvedores

Artefatos : Cartão de Tarefas

Planejamento de Iteração – Fase de Direção

Tendo em vista a fase de direção, o desenvolvedor entende o cartão de tarefas para a tarefa executada.  A equipe do desenvolvedor executa a tarefa usando as técnicas de programação em pares.

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 nesta são:

  • Projetar a tarefa: o desenvolvedor começa a trabalhar no trabalho escrito no cartão de tarefas e, a partir de então, começa a projetar conforme o cartão.
  • Escrever um teste de unidade: o programador primeiro escreve 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: o teste integrado e o teste de aceitação do usuário são abrangidos por isso.

Função: Desenvolvedores

Funções e responsabilidades do eXtreme Programming:

No 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. No 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 produto;
    • Membros de vendas e marketing;
    • Usuários finais e gerentes;
    • Analista de negócios;
    • Operações.

O Cliente será responsável pelos seguintes itens:

  • Escrever histórias de usuário
  • Testar as funções finais entregues pelos desenvolvedores e escrevendo um teste funcional
  • Definir prioridades
  • Explicar histórias para o desenvolvedor
  • Decidir se ele se encaixa no requisito do usuário final
  • Decidir perguntas sobre as histórias

Programador

O desenvolvedor ou programador deve ser um comunicador eficaz, porque ele é o único canal de comunicação entre a equipe de desenvolvimento, a equipe de teste e o cliente. Pois um desenvolvedor terá direitos para fazer o seguinte:

  • Reunir conhecimentos sobre requisitos
  • Produzir um trabalho de qualidade
  • Abordar o gerenciamento de ajuda, que inclui seus supervisores hierárquicos e o cliente
  • Desenvolver e alterar as estimativas fornecidas
  • Ser 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 escrever código para passar no teste de unidade.
  • Posteriormente, para executar o teste de unidade.
  • Refatorar
  • Finalmente, para integrar e tentar melhorar continuamente.

Treinador / Coach

O papel de um Coach é significativo no extreme programming, um treinador garante que todos estejam trabalhando para tornar a programação extrema. O treinador deve ter:

  • Comportamento sutil para ser treinador, mesmo que todo mundo esteja em pânico.
  • Excelente conhecimento de extreme programming.
  • Natureza útil, porque ele tem que observar todos e, consequentemente, ajudar.

As responsabilidades de um treinador incluem

  • Observar todas as atividades e garantindo que todo o projeto permaneça no caminho certo.
  • Ele ajudará a equipe com qualquer coisa relacionada ao projeto.
  • Será o 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.

Algumas outras funções são

 Testador

Certamente o testador será quem fará o teste após a codificação, as responsabilidades de um testador incluem:

  • Implementar todos os testes funcionais (exceto teste de unidade)
  • Representar graficamente 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.
  • Monitorar o progresso do desenvolvedor.
  • Além disso, organizando uma reunião de equipe e tomando medidas se as coisas não estiverem indo tão bem.
  • Entrar em contato com o treinador ou o programador para obter ajuda (se necessário).

Doomsayer (o observador de desastres)

Doom SayerBem como o nome sugere, doomsayer será quem ficará de olho em qualquer desastre.

Em resumo esses desastres podem ser como não cumprir cronogramasum bug devido a algum pequeno erro, problemas de infraestrutura ou algo que possa impactar o projeto de qualquer maneira.

Em outras palavras, o doomsayer tenta garantir que nada dê errado. As responsabilidades do Doomsayer incluem:

  • Prever o risco, se houver;
  • Garantir que todos os envolvidos nos projetos conheçam os riscos envolvidos;
  • Manter a transparência de qualquer notícia ruim;
  • Inclusive certificar 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 do ouro em caso de problemas (o proprietário do ouro é alguém que financiará o projeto pelo lado do cliente).

Além disso as responsabilidades de um gerente são as seguintes:

  • Primeiramente, para garantir que a equipe de desenvolvimento, assim como o cliente, conheça a explicação do jogo de planejamento adequadamente.
  • Em segundo lugar, observar o jogo de planejamento e modificar as regras, conforme e quando necessário.
  • Em terceiro lugar, garantir a identificação e rastreamento dos defeitos.
  • Além disso, para verificar o rastreamento do tempo de resolução e o tempo gasto por cada equipe no defeito.
  • Ainda obter todas as informações sem atrapalhar o trabalho atual da equipe.
  • Por fim, participar de reuniões com clientes e acompanhar todas as informações úteis discutidas na reunião.

Fases do eXtreme Programming

Fluxo de fases do XP

Esta figura nos fala sobre o fluxo do Extreme Programming.

  • Inicialmente, os requisitos do usuário são coletados no cartão de história do usuário.
  • Posteriormente, o cartão de história do usuário faz o planejamento da Iteração.  As estimativas de tempo e esforço ocorrem no planejamento da iteração .
  • Sobretudo o processo de desenvolvimento sábio da iteração começa após o planejamento.
  • Além disso, a incorporação de novos requisitos ocorre durante o desenvolvimento.
  • Ainda assim, quaisquer alterações necessárias durante o teste de interação são incluídas apenas nesta fase. Portanto, a adição de novos requisitos de usuário também acontece apenas nesta fase.
  • Após o teste de iteração bem-sucedido, ele fará o UAT (Teste de Aceitação do Usuário)4.
  • Depois disso, se os defeitos aumentarem, em caso de erros; voltará para a fase de desenvolvimento.
  • Por fim, se não houver bugs – a versão final, e o treinamento do usuário termina e o suporte ao produto é fornecido.

Dessa forma, o fluxo do extreme programming nos leva à questão de quantas fases existem no fluxo de trabalho do extreme programming? Existem 6 fases no fluxo do processo da Extreme Programming.

Essas 6 fases são as seguintes

Planejamento

  • Primeiramente fazer a identificação de investidores;
  • Em seguida reconhecer as necessidades de infraestrutura;
  • Estabelecendo necessidades de segurança;
  • Finalmente a assinatura de contrato de nível de serviço (ou seja, um documento formal que fala sobre a prestação de vários serviços) com todas as restrições.

Análise

  • Obter histórias de usuário do cliente;
  • Analisar histórias de usuários;
  • Priorização de histórias;
  • Analisar histórias para obter estimativas;
  • Definir a iteração, por exemplo, qual iteração fornece todas as funcionalidades?;
  • Fazer o planejamento para equipes de teste e desenvolvimento.

Projeto

  • Design para a primeira iteração;
  • Preparar um caso de teste para cada tarefa;
  • Estruturar a automação de regressão.

Execução

  • O desenvolvedor fará a codificação;
  • Após a conclusão da codificação, o controle de qualidade executa o teste de unidade;
  • Depois disso, o teste manual acontece;
  • O relatório de defeitos é gerado (se os defeitos aumentarem);
  • A conversão dos casos de teste de regressão Manual para Automação ocorre;
  • Revisão no meio da iteração;
  • Revisão de final de iteração.

Pacote

  • A liberação da iteração acontece;
  • O teste de regressão ocorre;
  • Além disso 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 dado;
  • Lançamento de produção acontece;
  • Além disso, o desempenho de várias verificações acontece se o desenvolvedor atender ao SLA;
  • Por fim, o Suporte à produção é fornecido para o produto desenvolvido.

Sem dúvida agora que entendemos o extreme programming, vamos analisar as principais diferenças entre ele e o Scrum.

Diferenças entre Extreme Programming e Scrum

Extreme ProgrammingScrum
Um sprint é concluído em 2-10 diasUm sprint leva de duas a seis semanas para ser concluído
Programação extrema permite mudanças no sprint em qualquer estágio do desenvolvimentoPor outro lado, no Scrum, quando a reunião de planejamento do sprint termina e a entrega acontece, nenhuma alteração pode ocorrer no sprint.
Os desenvolvedores começam a trabalhar de acordo com a prioridade dada pelos usuários.Os desenvolvedores decidem a prioridade e, a partir de então, começam a desenvolver.
O XP possui práticas como TDD, Programação de Pares, refatoração etc., que são obrigatórias à seguirNão recomenda práticas de engenharia

Por que o Extreme pode falhar?

Primeiramente no 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 o 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.

Além disso o 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 o 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, o Extreme Programming limita a variedade de projetos, pois requer interação cara a cara com os projetos XP. Isso é ainda mais difícil de implementar se o cliente ficar longe do site de desenvolvimento.

Conclusão

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

Referências

  1. Wikipedia – Programação extrema (XP)
  2. Wikipedia – Kent Beck
  3. Programação em Pares obtendo ótimos resultados
  4. What Is User Acceptance Testing (UAT): A Complete Guide
Tags:, , ,

Leave a Reply