Extreme Programming: práticas.

Extreme Programming possui um conjunto de cinco valores: comunicação, simplicidade, feedback, coragem e respeito, partindo desses valores, apresentados anteriormente. Eles servem como base para criação das doze práticas. Essas práticas já são utilizadas na indústria de software a décadas em seus projetos, e com eficiência. Essas práticas foram desenvolvidas para que sua utilização e avaliação fosse coletiva, afim de reduzir possíveis inconsistências, caso fossem aplicadas de forma individual.

• Jogo do Planejamento: Seu objetivo é determinar rapidamente o escopo da próxima Release, combinando prioridades do negócio e estimativas técnicas. Portanto no XP planejamos o tempo todo, diferente do que alguns pensam. Com um cliente presente ele define o escopo para a próxima Release. Dessa forma, define-se as features, prioridades e o escopo da release.
  Os desenvolvedores irão definir estimativas, consequências técnicas de adotar determinadas plataformas ou componentes (por exemplo, os programadores podem dizer que determinado componente dá muito problema e seria mais adequado utilizar um componente pago que economizará muito tempo), e por fim os desenvolvedores também ajudam no detalhamento de prazos para as atividades. Por fim, mantemos o plano atualizado sempre que houver um novo “toque de realidade” no projeto como algum imprevisto ou algo desejável que não contava-se que iria acontecer, ou qualquer outra coisa que possa afetar o plano atual.
• Teste: é uma pratica bastante técnica, e envolve a presença do cliente no desenvolvimento e na validação de testes. Cada componente do sistema deve possuir testes de unidades, afim de se ter confiança no comportamento do sistema, fazendo com que seja parte do próprio sistema. Existem também casos em que os testes de unidades são desenvolvidos antes mesmo do próprio código do trabalho real, também chamado de Test-Driven.
  Teste automatizado é a prática que sustenta e viabiliza muitas outras práticas como Integração contínua, Projeto Simples, Versão Pequena, Refatoração, e Propriedade Coletiva.
• Programação em pares: há literalmente uma programação em dupla, dois desenvolvedores utilizando-se de uma mesma máquina, ela tende a melhorar a qualidade do código produzido, mas sem afetar em sua velocidade de desenvolvimento. Outro fator, é que está prática tende a melhorar também a comunicação entre todos os membros da equipe, principalmente quando estes pares se alteram com frequência, ou todos os dias. Um dos critérios para definir os pares, não é só a sua disponibilidade, mas também deve ser levado em consideração a experiência de cada pessoa. Por exemplo, quando se necessita desenvolver algo que necessite da utilização de duas tecnologias, como interface Web e banco de dados, haverá dois integrantes, cada um experiente em uma área necessária.
• Projeto Simples: Projetos flexíveis são considerados uma defesa contra mudanças imprevistas no software, porém, projetos flexíveis também têm custos, tempo para desenvolvimento e manutenção, além de um código mais complexo e que muitas vezes nunca será utilizado.
  O XP preconiza que a mudança é barata, pois ele utiliza ciclos curtos, projetos simples, refatorações, por isso mantém-se o projeto o mais simples possível, modificando-o quando for necessário suportar mais funcionalidade. Portanto, o XP diz que o melhor e mais simples projeto é aquele que passa em todos os testes, não contém duplicação de funcionalidade, salienta as decisões de projeto importantes e tem o menor número possível de classes e métodos.
• Refatoração: significa melhorar o código sem alterar sua funcionalidade. Antes de uma mudança sempre refatoramos o código para facilitar a realização de mudanças. Ou seja, se após a refatoração o código continua funcionando como anteriormente, incluímos as novas mudanças. A refatoração contínua possibilita manter um bom projeto, apesar das mudanças frequentes. O Projeto é uma atividade diária, de responsabilidade de todos. A refatoração provê um aumento contínuo de qualidade do código.
• Propriedade Coletiva: Todos podem modificar o código a qualquer momento. Códigos não pertencem a apenas uma pessoa. A melhor forma de evitarmos problemas como trocas de pessoas da equipe e com isso a perda de conhecimento é a propriedade coletiva, onde todos mexem em todas as partes do programa e conhecem de tudo um pouco.
• Integração Contínua: Todo código deve ser integrado diariamente e todos testes devem passar antes e depois da integração. Se algum problema é encontra do ele deve ser corrigido imediatamente.
• Cliente presente: Clientes devem estar presentes para escrevem testes de aceitação, definirem prioridades e histórias para as futuras iterações. Estando sempre disponível afim de responder possíveis perguntas. Não importando o que venha a ocorrer com o projeto, nunca haverá para o cliente uma grande surpresa, se o mesmo estiver presente no desenvolvimento diariamente.
• Semana de 40 horas, é uma prática muito importante, pois deve-se respeitar o ritmo de trabalho que se pode sustentar, sem prejudicar os integrantes, no caso, 40 horas semanais. Uma equipe desgastada fisicamente e intelectualmente, possui grandes chances de produzir um software de baixa qualidade. Caso seja necessário fazer horas extras, essa condição é aceitável, contanto que não se torne uma rotina. Este pode ser um sinal de que pode haver algo errado com o projeto.
• Padrões de Codificação: Todos mexem em todos os códigos, todos refatoram e todos trabalham em pares. Assim é interessante mantermos um padrão para termos algo solidificado. Por isso a melhor forma é a equipe definir um padrão de codificação sempre no início dos projetos. Tendo em vista esta questão, todos os integrantes possuirão a mesma visão diante do código. Isto permite que grupos de vários desenvolvedores, possam produzir um código consistente, e também facilita a sua devida comunicação.
• Metáfora: a sua função é melhorar a comunicação, tanto dentro da equipe, como para com o cliente. Uma linguagem comum que todos devem possuir. Por exemplo, ao invés de descrevermos como uma certa arquitetura funciona apenas comunicamos o seu nome e todos entendem o que um programador quis dizer.
• Reunião diária: é uma prática vinda do SCRUM em que todos fazem uma rápida reunião de pé para discutir o que foi feito no dia anterior, o que será feito no dia atual e se existe algum impedimento.

Tais práticas tendem a funcionar bem quando utilizadas em conjunto. Quando utilizadas uma de cada vez é perceptível os seus benefícios. Mas quando elas começam a ser usadas em conjunto, as melhorias são drásticas. Ainda mais quando existe uma interação entre as práticas.

Fontes: http://www.desenvolvimentoagil.com.br/xp/praticas/

http://blog.locaweb.com.br/artigos/metodologias-ageis/programacao-extrema-extreme-programming-ou-simplesmente-xp/

https://www.devmedia.com.br/introducao-ao-extreme-programming-xp/29249

https://www.devmedia.com.br/praticas-em-xp-extreme-programming/29330

http://www.redspark.io/metodologias-parte-2-xp-extreme-programming/

Como a técnica Pomodoro pode ajudar as metodologias ágeis

Figura 1 - Relógio de cozinheiro

     Muitas vezes estamos prestes a iniciar um projeto que aparentemente mostra-se complexo e trabalhoso, isto acaba nos desmotivando de uma tal forma a ponto de procrastinarmos quanto ao início daquele projeto. Projetos de software são exemplos de projetos que tendem a ter várias tarefas a serem concluídas, mas devido a quantidade de tarefas obrigatórias, interrupções e complexidade de algumas tarefas, os prazos nunca são cumpridos, e como consequência, os seus desenvolvedores ficam desmotivados, infelizes e a produtividade cai. 

   

     Técnica Pomodoro busca solucionar estes problemas. Criada por Francesco Cirillo em 1992, esta técnica busca aumentar a concentração e o foco em tarefas importantes, tarefas que,  quando concluídas, trarão uma recompensa de valor. Seu principal simbolo é o relógio de cozinha em forma de tomate (como este da Figura 1), tomate em italiano chama-se Pomodoro, daí o nome da técnica. Esta técnica é bem simples de ser implementada, basta ter em mãos uma caneta, uma folha de papel e um relógio de cozinheiro. 

Figura 2 -  Fluxo de trabalho do Pomodoro - Ilustração retirada do livro Pomodoro Technique Illustrated (2009). 

      A técnica funciona da seguinte forma: escreve-se no papel todas as tarefas que precisam ser concluídas durante o dia, depois escolhe-se uma das tarefas para ser feita primeiro (aquela que for julgada a mais importante), depois inicia-se o relógio com um tempo de 25 minutos. Durante este tempo não se fará outra coisa a não ser aquela tarefa que foi escolhida. Se ocorrer alguma interrupção durante a execução daquela tarefa, como uma tarefa secundária ou outras requisições, escreva na lista de tarefas como uma nova tarefa a ser feita, e então volte a sua tarefa principal. Ao tocar o alarme, imediatamente devemos para o que estiver sendo feito naquela tarefa e então fazemos uma pausa de 5 min, independente se esta tarefa tenha sido concluída ou não. Durante a pausa, precisamos relaxar a mente e tentar não pensar nas tarefas. Depois da pausa, nós podemos voltar a tarefa, caso esta não tenha sido concluída, ou podemos escolher outra para ser executada. E então refazemos todo o processo.

      O objetivo da Técnica Pomodoro não é o de completar tarefas, mas sim, manter o foco nas tarefas importantes a ponto de evitar perca de energia com atividades sem retorno, tudo isto de uma forma que diminua o stress e melhore a produtividade pessoal. 

      Como utilizar a Técnica Pomodoro junto com as metodologias ágeis?

      Depois de conhecer o Pomodoro, vocês devem ter notado uma singela semelhança entre a Técnica Pomodoro e as Metodologias Ágeis. E sim! O Pomodoro é uma  metodologia Ágil. Henrik Kniberg, um dos escritores do livro Pomodoro Technique Illustrated (2009), diz que a ela é similar a uma metodologia Ágil, como a Scrum e XP, mas a diferença entre elas é que a o Pomodoro é executado em um nível mais baixo ou "micro". As metodologias Ágeis focam em organizar a execução de blocos de incrementos de sistemas ou softwares que trarão maior valor ao produto ao final da iteração. Mas dentro de cada bloco é necessário que exista um gerenciamento de tarefas, onde são escolhidas as mais importantes para a entrega daquele bloco. 

Figura 3 - Pomello

       Existem vários aplicativos que utilizam a Técnica Pomodoro para melhorar a execução de projetos com metedologias Ágeis. O Pomello é um exemplo deles, este software é um contador que vincula-se a uma conta do Trello. Ele usa as tarefas do Trello como suas tarefas do Pomodoro. A cada intervalo de 25 min (ou outros intervalos), são anexadas na tarefas a quantidade de turnos que já foram executadas naquela tarefa. Isto pode ser útil para medir a complexidade de uma tarefa, bem como, saber a produtividade de uma pessoa ou equipe e ver o real tempo trabalhado no projeto.    

 
             E para concluir, este artigo apenas mostra um olhar geral sobre a Técnica Pomodoro, claro que a princípio pareça uma técnica muito engessada, mas uma qualidade que o autor Francesco Cirillo deixa bem claro é que, ao final de cada dia, você terá que analisar como foi o seu desempenho, e então, buscar adaptar a técnica ao seu modo de fazer as tarefas, isto quer dizer que você pode aumentar ou diminuir o tempo, pular pausas... o principal objetivo é que aumentar o seu foco nas tarefas e melhorar a sua produtividade de uma forma feliz e sem stress.



Fonte: Staffan Noteberg, Pomodoro Technique Illustrated, 2009.

Project Model Canvas: Uma ferramenta para Planejamento de Projetos (Parte 1)

Visando simplificar o trabalho do gerente de projetos, José Finocchio Jr. desenvolveu uma ferramenta robusta para gerenciamento de projetos, o Project Model Canvas (PMC). Apesar da robustez, a ideia é simplista e favorece a integração da equipe de trabalho. Segundo Finocchio, “É mais fácil pensar e planejar visualmente”. É justamente essa a proposta do PMC: ser uma ferramenta visual, construída pela equipe, a qual elimine a complexidade e a burocracia do planejamento de qualquer projeto.

Ele é ideal para ambientes que querem aprimorar sua capacidade de planejamento, mas que se caracterizam por inovação, alta dinâmica dos negócios e simultaneidade de projetos (tocados em paralelo), aos quais soluções rígidas e engessadas não se aplicam.

Project Model Canvas

O Project Model Canvas é uma metodologia robusta, porém simplista, de planejamento de projetos, a qual utiliza conceitos visuais da neurociência aliados a uma estrutura lógica de componentes que formam um plano de projeto. Tais componentes estão organizados em blocos de perguntas fundamentais (Por quê, O quê, Quem, Como, Quando e Quanto) integrados em consonância com a teoria que rege o gerenciamento de projetos.

Project Model Canvas e suas perguntas fundamentais.

Esses blocos de perguntas são formados pelos elementos fundamentais do plano, os quais compõem o modelo mental que permite visualizar todos os componentes e suas dependências em uma única página. É recomendável que o canvas seja construído sobre uma única folha de formato A1 e notas autoadesivas, os famosos post-its, com no máximo 140 caracteres por nota. Tal metodologia permite que o modelo seja modificado quantas vezes for necessário. Lembre-se, o plano é um artefato em constante evolução! No início do projeto, as incertezas são grandes e a imprevisibilidade é dominante. Durante o decorrer do projeto, mais informações são disponibilizadas e de forma mais precisa, assim o plano deve evoluir paralelamente.

Project Model Canvas e seus elementos fundamentais.

Dependências entre elementos fundamentais do PMC.

Essa publicação tem como intuito mostrar de uma forma geral o que é o PMC, na próxima publicação destrincharemos cada uma das áreas do PMC e como preenchê-las.

Fontes:

FINOCCHIO Jr., José. Project Model Canvas – Gerenciamento de Projetos sem Burocracia. Editora Campus, 2013.

http://pmcanvas.com.br/

http://www.projectbuilder.com.br/guia-definitivo-do-pm-canvas/

https://danielettinger.com/2015/07/13/project-model-canvas-a-alma-do-projeto/

Kanban: O que é e como funciona o método?

Figure 1 - Kanban.

O que é?

O sistema Kanban está baseado em referências visuais que estão atrelados aos produtos, lugares comuns, murais de produção ou até mesmo em computadores que utilizam uma espécie de método kanban eletrónico para funcionar. São utlizados cartões (post-its), com cores e tamanhos diferentes para definir e descrever as tarefas que precisam ser feitas, que estão sendo feitas e as já conluídas. É um sistema que visa aumentar a eficiência da produção e otimizar seus sistemas de movimentação, produção, realização de tarefas e conclusão de demandas.

Apesar de parecer simpels, o Kanban nasceu com uma ideia complexa de orientar a produção pelo cumprimento de tarefas complexas, e não pela movimentação do estoque. Foi desenvolvido pelos japoneses da Toyota dentro do modo de produção Just In Time (JIT), ou seja, o Kanban não é o JIT, mas sim, parte dele. É importante destacar isso, pois tanto o Kanban como outras técnicas  toyotistas do sistema JIT vieram para modificar uma produção que era puatada ainda pelo modesto fordista de produção, utilizado basicamente desde o começo do século XX em boa parte das plantas industriais de todo o planeta. 

Como funciona? 

O cartão kanban é responsável pela comunicação e pelo funcionamento de todo o sistema, nele devem estar contidos as informações mínimas para o bom funcionamento da linha de produção. Sendo necessário, ele poderá conter um número maior de informações, desde que sejam importantes para a área específica, onde se pretende implementar o sistema kanban.

Um quadro Kanban é uma ferramenta que ajuda a visualizar o fluxo de trabalho de qualquer projeto. Ele fornece alto nível de transparência, permitindo que todos entendam o status de um projeto com um simples olhar.

Esses quadros e cartões visuais integram o sistema Kanban, que ajudam os trabalhadores a planejarem a produção na indústria e a controlar o estoque. Assim, conforme a quantidade de cartões disponíveis nos quadros são tomadas decisões, priorizando o que é mais importante, realizando setup de máquinas e até mesmo as paradas para manutenção.

Existem dois tipos de Kanban - o de produção e o de movimentação. Kanban de Produção informa a um processo fluxo acima qual tipo e em que quantidade o produto deve ser produzido para atender a um processo fluxo abaixo. Geralmente colocam se murais contendo cartões (post-its) em um espaço que possa ser visualizado por todos os funcionários resposáveis por desempenhar ações naquela linha de produção. Os murais costumam ser dividos em três seções: To do (por fazer), Doing (fazendo/em execução) e Done (feito/concluído). Mais divisões podem ser inseridas no mural para adequar com necessidade de cada projeto.

Figure 2 - Kaban de Produção.

O Kanban de Movimentação, também denominado ainda de Kanban de Transporte, notifica os diversos setores de produção de uma linha para quando realizar determinada ação ou quando esperar pela próxima ordem. Os cartões são afixados nos produtos, geralmente, o cartão de movimentação é afixado em substituição ao cartão de produção, e levados a outro processo ou local, onde são retirados e voltam à etapa inicial.

Figure 3 - Kanban de Movimentação.

Vídeo de explicação abaixo:

Fonte:

https://www.industriahoje.com.br/o-que-e-kanban
https://pt.wikipedia.org/wiki/Kanban
http://www.leanti.com.br/conceitos/9/O-que-e-Kanban.aspx
https://www.citisystems.com.br/kanban-conceito-sistema-o-que-e-on-line/

Planning Poker: uma forma divertida mas séria de se estimar projetos ágeis.

Planning Poker: uma forma divertida mas séria de se estimar projetos ágeis

Figura 1 - Planning Poker.

Com a popularização das metodologias ágeis (SCRUM, XP, FDD, CRISTAL), veio também a necessidade de estimar a complexidade e o tempo das tarefas. Mas como seria possível estimá-los em um grupo que utiliza metodologias ágeis, onde geralmente existem uma quantidade menor de artefatos documentais que burocratizam o processo de desenvolvimento?

Foi pensado nestas questões que James Grenning criou o Planning Poker, em 2002, e que mais tarde foi popularizado por Mike Cohn no livro Agile Estimating and Planning no qual registrou o termo.

O Planning Poker consiste em obter uma estimativa média do custo de tempo e complexidade das tarefas por meio de um jogo de cartas. Todos os integrantes da equipe de desenvolvimento (programadores, testadores, analistas, designs) devem participar. Cada integrante dará a sua percepção de tempo e complexidade para a conclusão de uma tarefa, as opiniões são então comparadas e analisadas até que se chegue a um consenso.

O jogo de cartas

Para se estimar quanto uma tarefa pode custar em termos de tempo e esforço para serem concluídas, cada participante deve dar a sua opinião através de cartas que possuem números ou símbolos escritos nelas. Veja a figura 2 que mostra um exemplo de baralho do Planning Poker.

Figura 2 - Exemplo de baralho de Planning Poker.

Quanto maior o número, mais complexa é a tarefa para quem lançou aquela carta. Geralmente os valores numéricos são definidos seguindo a sequência Fibonacci (0, 1, 2, 3, 5, 8, 13, 20, 40, 100), mas isso fica a critério da equipe. Da mesma forma os símbolos podem ser escolhidos pela equipe, onde devem representar algum significado para auxiliar na predição do esforço. Vamos descrever os significados mais complexos das cartas do jogo:

- Interrogação: é usado quando o seu proprietário não sabe opinar sobre o custo necessário para aquela tarefa.

- Zero: significa que esta tarefa é absolutamente desnecessária e deve ser descartada.

- 1/2 (meio): significa que esta tarefa é extremamente fácil de ser implementada. 

- Infinito: é utilizado quando a tarefa demonstra ter um nível de complexidade muito alto ou até seja impossível de ser concluída.

- Chicara de café: usado quando o o proprietário não entende o objetivo da tarefa e necessita de melhor compreensão da mesma, quando esta carta é jogada uma pausa deve ser feita. Esta pausa é muito importante e deve ser respeitada, os integrantes da equipe não podem fazer o uso excessivo desta carta. 

Lembrando que cada componente deve possuir um baralho próprio e que todos precisam ter os mesmos valores e símbolos.

A sequência Fibonacci

Figura 3 - Gráfico da função Fibonacci.

 Agora que sabemos como são organizadas as cartas do Planning Poker você pode está se perguntando o porque do uso da sequência Fibonacci. Esta sequência é obtida ao somar os dois números antecessores, o resultado irá compor a próxima soma  e assim segue infinitamente, a sequência inicia com os dois valores 0 e 1. A medida que os valores são obtidos, o gráfico cresce indefinidamente o que ajuda na comparação dos valores. Por exemplo, se em uma rodada são jogadas as seguintes cartas: 5, 8 e 13 , desta forma demonstrará o nível de incerteza do grupo com mais força, onde de 5 para 8 existe a diferença de 3, de 8 para 13 existe uma diferença de 5, já de 5 para 13 existe uma diferença de 8. Isto força a discussão entre os envolvidos para chegarem em um consenso. 

Como o Planning Poker é jogado

Definidos os principais conceitos, é hora do Planning Poker ser executado. Toda a equipe participa, inclusive o cliente, mas somente os que vão criar o produto é que podem jogar as cartas. Deve existir um facilitador (uma pessoa neutra) e um cliente (que explica os detalhes das tarefas ou stories). Uma boa técnica para estimar é utilizar pontuações de tarefas passadas, escolhe - se a menor pontuação para ser usada como uma base para tarefas menores. As tarefas são avaliadas segundo as que são consideradas mais fáceis até as chegar as mais difíceis. 

Ao começar a primeira rodada, o cliente conta uma "história" de como deve ser o produto que ele deseja, logo em seguida, o facilitador irá  pedir que joguem as cartas. Depois são analisadas as pontuações. São analisadas as maiores discrepâncias entre os valores, o dono da carta que tiver o maior valor é então questionado, e mais uma vez, as cartas são jogadas até que todas as cartas sejam iguais, ou seja, até que todos entrem em um consenso.

Conclusão

  Como foi discutido neste texto o Planning Poker mostra-se uma ótima técnica "democrática" para estimação de tarefas. Os seus ganhos vão desde melhor entrosamento da equipe e melhor compreensão das suas atividades até o melhor controle por meio dos seus gestores. Os pontos dos cartões ainda podem ser mapeados à custos em dias, esforço ou horas/homem, estas métricas podem ser facilmente definidas pela equipe.

Fonte:

www.culturaagil.com.br/planning-poker-tecnica-baseada-consenso/

www.devmedia.com.br/scrum-e-planning-poker-analise-de-estimativa-de-software/31019

www.slideshare.net/JamesGrenning/beyond-planning-poker-agile-2011

www.metodoagil.com/planning-poker/#fibonacci

Extreme Programming: conceitos e valores.

A Programação Extrema, ou simplesmente o XP, é uma metodologia ágil cujo foco está no desenvolvimento de software com requisitos vagos e em constante mudança. É adota a estratégia de constante acompanhamento e realização de vários ajustes durante o desenvolvimento de software. O XP foi criado em 1997 por Kent Beck e tornou-se notório após a OOPLSA 2000 (Conferência de Programação Orientada a Objetos, Sistemas, Liguagens e Aplicações).

O objetivo do XP é otimizar o uso das boas práticas na engenharia de software. Entre elas podemos citar o teste, visto que procurar defeitos é perda de tempo, nós temos que constantemente testar. Entre outras práticas, o XP diz que:

• Já que testar é bom, que todos testem o tempo todo;
• Já que revisão é bom, que se revise o tempo todo;
• Se projetar é bom, então refatorar o tempo todo;
• Se teste de integração é bom, então que se integre o tempo todo;
• Se simplicidade é bom, desenvolva uma solução não apenas que funcione, mas que seja a mais simples possível;
• Se iterações curtas é bom, então mantenha-as realmente curtas;

O XP já foi utilizado por grandes empresas como a Chrysler no seu sistema de folha de pagamento global que envolvia seus 90 mil empregados ao redor de todo o mundo. Esse projeto tem 2.000 classes e 30.000 métodos, e foi para produção sem nenhum atraso.

As práticas da Programação Extrema são fundamentadas nos seguintes valores:

1.      Comunicação: segundo Beck “Os problemas nos projetos invariavelmente recaem sobre alguém não falando com alguém sobre algo importante”. Assim, a comunicação enfatiza que devemos sempre estar se comunicando seja entre desenvolvedores ou com os clientes. O XP é organizado em práticas que não podem ocorrer se não houver comunicação. Para um projeto de sucesso é necessária muita interação entre os membros da equipe, programadores, cliente, treinador. O time precisa ter muita qualidade nos canais de comunicação, sendo conversas cara-a-cara uma das melhores formas, mas também são utilizados telefonemas ou e-mails.

2.      Feedback: quanto antes, melhor. Para sabermos se estamos fazendo a coisa correta, precisa ser concreto perguntando diretamente ao código e precisa ser constante através de iterações curtas, incrementos e releases. Aqui garantimos constantemente junto ao cliente se estamos fazendo certo e se o prazo está de acordo com o planejamento. As respostas às decisões tomadas devem ser rápidas e visíveis. Os envolvidos precisam estar cintes do que está acontecendo. E os clientes devem se manter próximos dos desenvolvedores, para sempre que necessário passar informações sobre qualquer dúvidas ao longo do projeto.

3.      Coragem: muitas vezes não fazemos as coisas porque não temos coragem de fazer as mudanças. XP diz que devemos ter coragem de sempre colocar o cliente a par do que está acontecendo. Porém, em equipes XP consideram que errar é algo natural, e que quebrar eventualmente o que já estava funcionando pode ocorrer, por isso, é necessário ter a devida coragem para lidar com esse tipo de risco, as práticas do XP são voltadas para proteger o software das mais variadas formas, e as equipes confiam nessas práticas, o que os tornam adeptos as mudanças quando necessário, em vez de impedir as ideias do cliente e evitar mudanças.

4.      Simplicidade: para atender rapidamente às necessidades do cliente, quase sempre um dos valores mais importantes é simplicidade. Normalmente o que o cliente quer é muito mais simples do que aquilo que os programadores constroem. O XP se empenha em assegurar que a equipe se concentre em desenvolver primeiramente o que é realmente necessário, em vez de rechear o projeto com várias funcionalidades que o cliente um dia possa a vir utilizar.

5.      Respeito: é o valor mais básico de todos, é o que dá sustentação aos demais. Todos têm sua importância dentro da equipe e devem ser respeitados e valorizados. Isso ajuda a garantir que o projeto seja bem-sucedido. A falta do respeito dentro de um projeto, pode ser o suficiente para que o mesmo enfrente muitos problemas, causando até a impossibilidade de sua continuação.

A ao contrário do que se acredita, o XP pode ser aplicada em projetos de vários portes, pois seu dinamismo é tão latente, que permite seu uso por equipes criativas em qualquer projeto.

A metodologia Extreme Programming é dinâmica e flexível, porém é necessária muita disciplina para usá-la em um projeto. Para demonstrar isso, será apresentado uma postagem com o conjunto sugerido de "boas práticas". 

Fonte: https://www.devmedia.com.br/praticas-em-xp-extreme-programming/29330

http://blog.locaweb.com.br/artigos/metodologias-ageis/programacao-extrema-extreme-programming-ou-simplesmente-xp/

http://www.redspark.io/metodologias-parte-2-xp-extreme-programming/

Os doze princípios do Manifesto Ágil

A cada dia que passa, vem se tornando cada vez mais comum as metodologias ágeis, entretanto a grande maioria delas não cumprem com todos os requisitos para serem consideradas metologias ágeis. 

Pouco se sabe da existência de um Manifesto que aborda os princípios de toda essa ideia de gerenciamento ágil de projetos. Para aqueles que ainda não conhecem, existe os 12 Princípios do Manifesto Ágil, são eles:

• 1- Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.

• 2- Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

• 3- Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.

• 4- Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.

• 5- Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.

• 6- O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.

• 7- Software funcional é a medida primária de progresso.

• 8- Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.

• 9- Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

• 10- Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

• 11- As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.

• 12- Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

Fonte: http://www.manifestoagil.com.br