Posts com Tags XP

As Práticas e Valores do XP

O XP recomenda um conjunto de práticas que traduzem os valores do Xp em ações do dia a dia. As principais são:

  • Testes – os testes são muito importantes no XP e devem ser implementados de preferêncialamente antes do desenvolvimento;
  • Refatoração – sempre que possível o código deve ser simplificado e melhorado;
  • Programação Pareada – o XP recomenda que os programadores trabalhem em duplas assim enquanto um programador digita, o outro observa, pensa em melhorias, alternativas;
  • Propriedade Coletiva – o código fonte não pertence a um único programador qualquer um pode modifica-lo e aperfeiçoa-lo.
  • Integração Contínua – depois de testada, cada nova funcionalidade deve ser imediatamente sincronizada entre todos os desenvolvedores;
  • Semana de 40 horas – a programação simplesmente não irá render se o programador não estiver descansado e disposto;
  • Cliente Sempre Presente – o cliente não é alguém de fora, mas sim um membro da equipe;
  • Padronizações – se todo o time seguir padrões pré-acordados de codificação, será mais fácil manter e entender o que já está feito. O uso de padrões é uma das formas de reforçar o valor comunicação.

Além dessas peculiaridades o XP possui uma série de caracteristicas similares a outras frameworks ágeis. Isso se deve ao fato de todas elas terem ganhado destaque após a divulgação do Manifesto Ágil e por seguirem suas recomendações. Além disso muitas vezes o XP é utilizado simultaneamente a outro(s) framework(s) também ágeis que o complementa como o TDD e o AMDD (HENRAJANI, 2007). O XP já foi uma das frameworks mais utilizadas no passado mas hoje ela divide esse espaço com outra framework em ascensão o Scrum.

Referências:

HENRAJANI, Anil. Desenvolvimento ágil em Java com Spring, Hibernate e Eclipse. São Paulo: Pearson Prentice Hall, 2007.

Tags: , , , , ,

A Documentação no XP

No framework XP a documentação é minimalista na maior parte dos casos apenas o código fonte e os testes a compõem. Para a XP um código claro, simples e bem estruturado facilita a compreensão e mudanças no futuro. Com o auxílio de comentários relevantes o código é a melhor documentação que um software pode ter, além de não se desatualizar. Embora não seja muito indicada, extrair a documentação a partir do código é uma opção utilizada pela XP. Além do código pouco material é produzido apenas os radiadores de informação e os cartões de história.

Os cartões de história são feitos de papel e servem para que os clientes e usuários descrevam funcionalidades que desejam no sistema. Os progaramadores utilizam-nos para direcionar a implementação. Os radiadores de informação por sua vez são graficos e cartazes que demonstram a produtividade da equipe. Estes devem ficar expostos onde todos os membros da equipe e os clientes possam vê-los. Dentre os radiadores de informação o mais importante está a adoção do quadro de tarefas inspirado no Kanban.

Tags: , , , , , ,

O Ciclo de Vida do Framework eXtreme Programming (XP)

A Figura 2 representa o ciclo de vida de um projeto utilizando o framework XP. Como se pode ver o primeiro retângulo a esquerda representa a fase de exploração. É nessa fase em que as primeiras histórias de usuário são levantadas e o projeto arquitetônico da aplicação é iniciado. As histórias de usuário são frases curtas  escritas pelo cliente que explica uma funcionalidade que o software deve ter (HENRAJANI, 2007). Ainda na fase de exploração são levantados os requisitos e implementados os cenários de teste. Os cenários de testes serão utilizados na fase de manutenção e antes da fase de produção. Já os requisitos por sua vez serão abordados durante os planos de versão.

O Ciclo de Vida do framework XP

Fonte: HENRAJANI, 2007

Como se pode ver no segundo retângulo, é no plano de versão que são definidas as estimativas e quais histórias de usuário serão implementadas em uma iteração. A iteração é uma pequena etapa de desenvolvimento ao final da qual será entregue uma pequena versão a ser testada. Através dos cenários de testes as pequenas versões são testadas e se não ocorrerem erros e o cliente aprovar ele entra na fase de produção ficando a equipe livre para iniciar uma nova iteração. Já se o cliente desaprovar algo ou ocorrerem bugs terá origem novas histórias de usuário que serão reconsiderados no plano de versão e adicionados à próxima iteração.

Referências:

HENRAJANI, Anil. Desenvolvimento ágil em Java com Spring, Hibernate e Eclipse. São Paulo: Pearson Prentice Hall, 2007.

Tags: , , , , , , ,

O eXtreme Programming (XP)

O Extreme Programming é um framework de desenvolvimento de software, criada por Kent Beck, nos Estados Unidos no final da década de 1990. É uma das frameworks ágeis mais conhecidas e utilizadas no mundo.

As ideias originais do que viria a ser o XP foram definidas por Kent Beck em 1996 através do livro “Smalltalk: best pratice pattners” no qual apresentava pontos positivos e negativos de projetos de software. No mesmo ano Beck foi chamado para conduzir, juntamente com Martin Fowler e Ron Jeffries, um projeto de alto risco na Crysler, o projeto C3. Beck selecionou um conjunto de práticas que haviam se mostrado eficientes em outros projetos e aplicou-as de forma intensiva. A equipe gerenciada por Beck não só conseguiu entregar o software antes do tempo estimado como também criou o  XP (BASSI FILHO, 2008).

Em alinhamento com as idéias do Manifesto Ágil o framework XP se baseia em cinco valores (BASSI FILHO, 2008) que  são:

  • Comunicação – para que um projeto atinja seu objetivo com sucesso a comunicação deve ser intensa entre membros da equipe e os stakeholders;
  • Feedback – as respostas as decisões tomadas e ou mudanças no projeto devem ser rápidas, eficientes e vizíveis;
  • Coragem – é necessário muita coragem para aceitar erros, mudar pontos de vista, se desfazer de antigas idéias;
  • Simplicidade – o sóftware, resultante do projeto, deve ser tão simples quanto possível. Além disso deve-se levar em conta que muitas vezes o que o cliente quer é bem mais simples do que o desenvolvedor imagina;
  • Respeito – todos tem seu valor dentro da equipe e as individualidades não só devem ser respeitadas como também ser valorizadas.

Referências:

BASSI FILHO, Dairton Luiz. Experiências com Desenvolvimento Ágil. São Paulo: USP – Istituto de Matemática e Estatística da Universidade de São Paulo, 2008.

Tags: , , , , , ,

O Quadro Kanban

Uma característica significativa do Scrum é que assim como no XP o enfoque dado à documentação é pequeno. Na maioria das vezes se resume a uma série de histórias de usuário – similares a casos de uso – afixadas em um quadro Kanban. O quadro Kanban é originário de um método, homônimo, de fabricação, orientado à produção em série e serve para facilitar a gerência do fluxo de produção. O desenvolvimento deste método é creditado à Toyota. Ele surgiu dentro do contexto do Just In Time do qual faz parte (PEINADO, 1999). O termo Kanban é uma palavra japonesa que significa literalmente registro ou placa visível que são características básicas do quadro.

O  Quadro Kanban

Fonte: RAHAL JUNIOR, 2011

A Figura acima representa o fluxo de tarefas no quadro Kanban. Uma história de usuário ou item de backlog é quebrada em varias outras menores que são adicionadas a coluna a fazer. Um membro da equipe escolhe um cartão de história, muda-o para a coluna fazendo. Após implementar, executar dos devidos testes de integração e considerar a tarefa como pronta ele então muda o cartão para coluna feito. Feito isto ele pega outro cartão na coluna a fazer reinicia novamente o ciclo. Isso se repetirá até que a equipe mude todas as histórias para a coluna feito.

Muitas vezes pode ocorrer confusão, pois alguns autores chamam o quadro de tarefas de quadro Scrum, e na realidade ele é praticamente igual ao quadro Kanban. De acordo com Kniberg & Skarin (2009) a principal diferença entre eles é que o Scrum deixa a equipe livre para configurar o fluxo de tarefas no quadro como bem entender. Já o Kanban determina que não devem haver mais de duas histórias em andamento simultaneamente.

Referências:

KNIBERG, Henrik. Scrum e XP Direto DasTrincheiras: Como nós fazemos Scrum. InfoQueue, 2007. Disponível em < http://infoq.com/br/minibooks/scrum-xp-fromthe-trenches > Acesso em 14 nov. 2010.

KNIBERG, Henrik; SKARIN, Mattias. Kanban e Scrum : Obtendo o Melhor de Ambos. InfoQueue, 2007. Disponível em <http://www.infoq.com/br/minibooks/kanban-scrum-minibook> Acesso em 14 nov. 2010.

RAHAL JUNIOR, Nelson Abu Samra . Melhorando o Entendimento “Como fazer?”. Disponível em: < http://blogdoabu.blogspot.com/2010/09/melhorando-o-entendimento-como-fazer.html >  acesso em 04 abr. 2011.

PEINADO, Jurandir. O papel do sistema de abastecimento Kanban na redução dos inventários. Revista da FAE, Curitiba, v.2, n.2, p.27-34, maio/ago. 1999.

Tags: , , , , ,

A Equipe e os Papéis do XP

Uma equipe XP deve reunir o máximo possível de habilidades técnicas e de negócio possiveis para desenvolver o software. A hierarquia entre os desenvolvedores deve ser rasa e não é recomendável estabelecer uma divisão de tarefas. Inicialmente as responsabilidades são distribuidas de acordo com as especialidades de cada um mas gradualmente, espera-se que essas especialidades sejam disseminada entre os membros da equipe para evitar a concentração de conhecimento e contribuir para o crescimento profissional de todos os membros da equipe. Apesar disso existem papéis que determinados membros da equipe podem assumir. Nesse sentido os papéis mais importantes do XP são:

• Os programadores que são maioria dos membros da equipe;
• O coach que geralmente é o programador mais experiente da equipe e deve assegurar que seus membros estejam executando as práticas propostas e garantir que a metodologia esteja sendo seguida;
• O tracker é o desenvolvedor responsável por prover informações referentes ao progresso do projeto e por mostrar pontos que devem ser melhorados. É da responsabilidade do tracker elaborar os radiadores de informação.
• Na metodologia XP o cliente é considerado parte da equipe visto que ele conhece as regras do negócio, consegue definir prioridades funcionais do software e além de prover feedback do processo de desenvolvimento. Recomenda-se que o cliente esteja presente o tempo todo. Quando isto não for possivel o coach assume o papel de cliente proxy, responsabilizando-se por repassar informações ao cliente real.

Tags: , , , , , , , , ,