As boas práticas do Extreme Programming

A estrutura do xp também é constituida de práticas que são sustentadas pelos valores já citados na postagem anterior. Antes de qualquer coisa, é necessário ter confiança nestas boas práticas e consciência de que elas devem ser aplicadas em conjunto. Quando aplicadas isoladamente, elas não trazem os mesmos resultados por que os pontos fracos de cada prática são protegidos pelos pontos fortes das outras práticas. As práticas são:

• O jogo do planejamento: entre o cliente e os técnicos são estimuladas reuniões usando quadros brancos, com o objetivo de captar e definir as "user stories" e também para poder estimar o tempo ideal das interações, o projeto como um todo, elaborar estratégias e tentar prever as contingências para projeto.
• Releases pequenas: cada release deve ser tão pequena quanto possível, contendo apenas os requisitos mais importanter para o negócio.
• Metáfora: a intenção é oferecer uma visão geral do sistema em um formato simples, que possa ser compartilhada por clientes e programadores, a ideia da metáfora é que seja feita uma analogia entre o sistema que está sendo desenvolvido e um sistema que todos entendam, com o objetivo de obter um "vocabulário comum".
  
• Projeto Simples: o código está, a qualquer momento, na forma mais simples e mais clara, conforme os padrões definidos pela equipe de desenvolvimento, facilitando a compreensão e possível continuidade por qualquer um de seus membros.
• Testes constantes: os testes no xp são feitos antes da programação. Existem os testes funcionais e os de unidade, os testes de unidade são feitos para verificar tudo que possa dar errado e os funcionais são usados para verificação junto ao cliente do sistema como um todo.
• Refatoramento: são constantes melhorias no projeto do software para aumentar sua capacidade de se adaptar a mudanças.
• Programação em pares: todo o código produzido em xp é escrito por um par de programadores sentados lado-a-lado e olhando para o computador. Um parceiro será responsável pela codificação e o outro observa o código e pensará mais estratégicamente em como melhorá-lo e torná-lo mais simples.
• Propriedade coletiva do código: uma vez aplicados a programação em pares, a equipe como um todo é responsável por cada arquivo de código. Não é preciso pedir autorização para alterar qualquer arquivo, mantendo claro, um padrão prático de comunicação da equipe.
• Integração contínua: os diversos módulos do software são integrados diversas vezes por dia e todos os testes unitários são executados. O código não passa até obter sucesso em 100% dos testes unitários, facilitando, dessa forma, o trabalho de implementação da solução
• Semana de quarenta horas: trabalhar por longos períodos é contraproducente. Portanto, sempre que possível, deve-se evitar a sobrecarga de trabalho de todos da equipe, criando condições favoráveis ao uso da carga normal de trabalho. É necessário deixar a equipe livre para relaxar, brincar, ou fazer o quem bem entender para equilibrar o trabalho mental e físico. Existe até uma frase que diz: trabalhe a 100% durante as 40 horas e descanse a 100% no resto. Se algum deles não for feito com 100%, um afetará o outro.
• Cliente no local: Constante disponibilidade do cliente para colaborar em dúvidas, alterações, e prioridades em um escopo, ou seja, dando um dinamismo ativo ao projeto
• Padrões de codificação: todo código é desenvolvido seguindo um padrão, qualquer que seja, mas toda equipe deve seguir o mesmo padrão. Dessa forma, todos da equipe terão a mesma visão do código.
  
  
  Fonte: http://www.devmedia.com.br/extreme-programming-conceitos-e-praticas/1498
  http://www.cin.ufpe.br/~gamr/FAFICA/Desenvolvimento%20de%20sistemas/XP.pdf

XP: Vantagens da Programação em par

“Quando há olhos suficientes, todos os erros são óbvios” - Eric S. Raymond

As vezes um erro de codificação pode estar diante de nossos olhos e nem repararmos, mas basta alguém ler o código e percebe-lo.

Trabalho em par

O princípio da programação em par é justamente esse. Duas pessoas, juntas, trabalham melhor do que duas pessoas isoladas.

Como funciona  

Durante a implementação, um programador digita o código e outro revisa o que está sendo digitado, apontando problemas e pensando na solução como um todo).

Vantagens

Compartilhamento do conhecimento  

Como todo o código produzido é visto por, pelo menos, duas pessoas é menor o risco de existir a figura do “responsável pelo código do produto X”. O conhecimento pode ser ainda mais compartilhado, principalmente se os pares forem revezados com frequência.

Isso é, obviamente, bom para o projeto. Mas também é muito bom para os desenvolvedores. Afinal de contas, é comum desenvolvedores que não podem tirar férias pois caso contrário o projeto onde eles trabalham não pode ser mantido.

Ser o responsável único por determinado projeto, ou parte dele, quase sempre é um fardo pesado demais que faz com que o desenvolvedor seja levado ao esgotamento. 



Correção de falhas

Com duas pessoas olhando o código, as falhas e erros de lógica são detectados (e corrigidos) mais cedo. Isso faz com que o trabalho seja mais fluído, uma vez que é mais difícil aquela situação onde o programador perde horas realizando o debug do código para encontrar uma falha de lógica, por exemplo.

Manutenibilidade

Um código escrito à quatro mãos é, naturalmente, mais simples de sofrer manutenção. Afinal de contas, durante a escrita do código sua clareza já estava sendo testada pelo co-piloto, que questionará sempre que não entender determinado trecho.

Confiança

Como o código é desenvolvido em pares, os desenvolvedores tem mais confiança no resultado final, uma vez que ele foi validado por, pelo menos, mais uma pessoa.  Os possíveis erros e problemas também são divididos, o que faz com que o time como um todo passe a enxergar o código como propriedade coletiva. Nesse formato, todos estão sempre dispostos a ajudar, pois o sucesso ou fracasso pertencem a todos os membros da equipe.

Amadurecimento

Durante o ciclo de desenvolvimento há uma constante relação aluno-professor entre o par, sendo que esse papel é constantemente revezado de acordo com o nível de conhecimento de cada um no caso específico.

Pressão do Par

Quando há uma outra pessoa junto fazendo o trabalho, a tendência é que o desperdício de tempo diminua consideravelmente. Qualquer pessoa fica constrangida ao acessar e-mails, mensagens instantâneas ou mesmo atender celular na presença de terceiros. Além disso, como o trabalho é compartilhado, há um maior sentimento de compromisso e ninguém gosta de ser responsável pelo fracasso de outro.

Velocidade

Um código com menos bugs, onde as soluções são discutidas e há a pressão do par para que o resultado saia, faz com que as soluções fiquem prontas mais rapidamente e com mais qualidade.


Dificuldades

Existem, é claro, algumas dificuldades para a adoção da programação em par. A primeira delas diz respeito a personalidade os desenvolvedores envolvidos.

Eles devem entender que o código produzido é coletivo, e não sua propriedade. Devem também aceitar sugestões e críticas ao seu trabalho, entendendo que isso decorre do fato de a propriedade do código ser coletiva.

Outra grande dificuldade é convencer “quem paga a conta” que vale a pena. No entanto, isso pode ser feito utilizando-se a prática. Realizando alguns experimentos com programação em par, comparando o resultado com programação solo, normalmente chega-se a conclusão de que a programação em par é extremamente vantajosa.


















Fonte: fonte

Valores e princípios do Extreme Programming

O Extreme Programming é um processo de desenvolvimento de software que adota os valores de comunicação, simplicade, feedback e coragem, que a partir desses valores são geradas as práticas, esses valores são as diretrizes da metodologia, eles definem as atitudes das equipes e as prioridades a serem seguidas. Os valores são detalhados a seguir:

• Comunicação: é obrigatória para que não haja lacunas em processos e problemas entre equipe, cliente e fornecedor já que o XP foca em construir um entendimento pessoa-a-pessoa de problema, com o uso mínimo de documentação formal e com o uso máximo de interação "cara-a-cara". 
• Simplicidade: é necessária desde a forma como se levanta requisitos até a codificação e os testes da solução desenvolvida já que o XP sugere que cada membro da equipe adote a solução mais fácil que possa funcionar. O objetivo é fazer aquilo que é mais simples hoje e criar um ambiente em que o custo de mudanças futuras seja baixo.
• Coragem: por ser um processo de desenvolvimento novo e baseado em diversas premissas que contrariam o modelo tradicional, o XP exige que os desenvolvedores tenham coragem para: desenvolver software de forma incremental, manter o sistema simples, permitir que o cliente defina prioridades, fazer desenvolvedores trabalharem em pares, investir tempo em refactoring, investir tempo em testes automatizados estimar estórias na presença do cliente, expor código a todos os membros da equipe, integrar o sistema diversas vezes ao dia, adotar ritmo sustentável de desenvolvimento, abrir mão de documentos que servem como defesa, propor contratos de escopo variável, propor a adoção de um processo novo, assumir em relação ao cliente possíveis atrasos e problemas de implementação, colocar desenvolvedores e clientes frente a frente, implantar uma nova versão do sistema no cliente semanalmente, apostar em seus colaboradores aumentando suas responsabilidades, modelar e documentar apenas quando for de extrema necessidade. 
• Feedback: é a pratica fundamentada em retornar informações entre os membros da equipe e também na relação com o cliente, desde responder e-mails, telefonemas bips e demais meios. Devido a isso, é um mecanismo para melhorar a prática de comunicação explanada acima.

Fonte: http://www.devmedia.com.br/praticas-em-xp-extreme-programming/29330
http://www.devmedia.com.br/extreme-programming-conceitos-e-praticas/1498
http://javafree.uol.com.br/artigo/871447/Apresentando-XP-Encante-seus-clientes-com-Extreme-Programming.html#valores
http://www.cin.ufpe.br/~gamr/FAFIC/Desenvolvimento%20de%20sistemas/XP.pdf

Conhecendo os Papéis do Scrum

a) ScrumMaster: É aquele que faz com que a equipe siga as práticas, valores e regras do Scrum.

b) Product Owner: O Product Owner determinar os itens que compõe o Product Backlog, também priorizando os itens da mesma, qualquer repriorização deve passar pelo Product Owner e para que isso funcione corretamente, suas decisões devem ser respeitadas por todos os envolvidos no projeto.

c) O Time ou Equipe: São as pessoas que realizam todos os itens do Product Backlog, finalizando e entregando uma parte dele em cada Sprint.

d) Time Boxes: São os eventos com duração fixa, como as Reuniões de planejamento de Sprints e Release, Daily Scrum(Reuniões diárias), Revisão da Sprint, Retrospectiva da Sprint, e a própria Sprint.

e) Reunião de Planejamento da Release: Nas reuniões de planejamento da release são estabelecidos os planos e metas com a equipe Scrum e o restante da organização, buscando encontrar as melhores maneiras de atingir ou até superar as expectativas do cliente, bem como o melhor retorno sobre o investimento.

f) Sprint: Trata-se das iterações definidas previamente, as quais têm duração fixa, e trata-se do momento que são executadas as tarefas estabelecidas para essa iteração.

g) Reunião de Planejamento da Sprint: Como o próprio nome define é o momento para planejar a Sprint, tendo seu tempo fixado de acordo com o tamanho da iteração, onde, uma iteração de duas semanas leva em torno de 4 horas para realizar uma Reunião de Planejamento da Sprint.

Exemplo de Planejamento dos itens do Product Backlog.

h)  Revisão da Sprint: A revisão da Sprint trata-se de uma reunião que ocorre ao final da sprint, para que todos da equipe possam conversar sobre o que foi ou não foi feito nessa iteração.

i)  Retrospectiva da Sprint: A retrospectiva ocorre após a revisão de sprint, com uma duração de 3 horas para sprints de um mês, sendo proporcionalmente diminuída para sprints menores.

j)  Daily Scrum: Ocorrem  todos  os dias, deve ter uma duração de 10 a 15 minutos, não mais que isso, onde cada membro da equipe vai explanar para  os outros membros:

1- O que realizou desde a última reunião.

2- O que vai fazer antes da próxima reunião.

3-  E se existe algum obstáculo.

O ScrumMaster deve garantir que a reunião ocorra todos os dias, e que os membros da equipe sejam breves em suas explicações.

Fonte: http://www.uniedu.sed.sc.gov.br/wp-content/uploads/2013/10/Wilian-Vargas-de-Lima.pdf

Os Papéis e Modelos do Scrum

O Scrum é basicamente divido por Equipes Scrum com seus membros tendo papéis definidos, pelos Times Boxes que são as reuniões de planejamento, releases, sprints e por fim os Artefatos e Regras.

De acordo com Schwaber e Sutherland (2010, p.4) as Equipes de Scrum tem em sua formação três papéis:

O Product Owner: define os itens que devem ser realizados pela Equipe Scrum.

O ScrumMaster: assegura que a equipe vai seguir as práticas e processos do Scrum.

A Equipe Scrum: são as pessoas que realmente colocam a “mão na massa”, que executam o trabalho e tornam os requisitos em um produto.

A partir dos Times Boxes é que se tem uma regularidade no projeto, os

quais são os elementos fixos como: Reunião de Planejamento da Release, reunião

de Planejamento da Sprint, a Sprint em si, as Reuniões Diárias(Daily Scrum), a

Revisão da Sprint e a Retrospectiva da Sprint.

 

Dentre todas as Times Boxes a Sprint pode-se considerar a mais importante, pois é a iteração previamente definida, em que durante esse período é feito o esforço para o desenvolvimento do que foi planejado para essa iteração e sendo uma parcela do produto final busca-se que sejam partes funcionais. 

As sprints funcionam uma após a outra, e mesmo que um produto não tenha sido concluído em sua iteração estipulada, pode continuar sendo trabalhada na próxima. Como definem Schwaber e Sutherland (2010) os artefatos são formados por: 

Product Backlog – Trata-se de uma lista contendo as funcionalidades desejadas.

Sprint Backlog – É uma lista de tarefas feita a partir do Product Backlog para ser desenvolvida dentro da Sprint.

Burndown de Release – mensura o Product Backlog ao longo do tempo.

Burndown de Sprint – mensura os itens da Sprint Backlog restante ao longo das sprints.

Já as Regras, funcionam como o próprio nome determina, são regras para manter todos os pontos funcionando bem e ligados. Como exemplo, uma regra do Scrum diz que “somente membros do Time - as pessoas comprometidas em transformar o Product Backlog em um incremento - podem falar durante uma Daily Scrum”. (Schwaber e Sutherland, 2010, p. 5).

Fonte: http://www.uniedu.sed.sc.gov.br/wp-content/uploads/2013/10/Wilian-Vargas-de-Lima.pdf

Conceitos em torno do Scrum

As informações a cerca do modelo Scrum, foram principalmente baseadas no Scrum Guide, que como o nome define serve de guia para todos que tem o interesse de utilizar o framework, o qual foi desenvolvido e é mantido por Ken Schwaber e Jeff Sutherland, gestores de grande conhecimento e respeito em todo o mundo, sendo grandes contribuidores do Scrum e do manifesto ágil.

O Scrum é utilizado desde a década de 90, formado por práticas e técnicas comprovadas por anos. Foi realmente apresentado e publicado na OOPSLA de 1995, a qual é uma conferência dedicada à programação orientada a objetos, e desde então vem sendo aprimorado.

Trata-se de uma metodologia ágil, a qual funciona como um guia para o “caminho das pedras” no gerenciamento e desenvolvimento de projetos de softwares, não é um processo que pode ser seguido e vai dizer exatamente como fazer, ou como deve ser trabalhado na empresa, e sim um framework.

Empregando uma abordagem incremental e iterativa para otimização e controle dos riscos, o Scrum tem como base a teoria de controle de processos empíricos, os quais têm três pontos de base que são a Transparência, a Inspeção e a Adaptação. (Schwaber e Sutherland, 2010).

Transparência: Os processos devem ser claros e visíveis para quem esta gerenciando os resultados.

Inspeção: Como o nome determina, é necessário realizar inspeções nos processos, para que possa ser detectado o quanto antes qualquer problema nos mesmos. A reunião diária trata-se de um tipo de inspeção.

Adaptação: Determina através da inspeção, se os processos apresentam problemas que podem levar a um produto fora das especificações, deve tentar adaptar e ajusta o processo para que isso não venha a ocorrer.

Fonte: http://www.uniedu.sed.sc.gov.br/wp-content/uploads/2013/10/Wilian-Vargas-de-Lima.pdf