Arquivo por categoria eXtreme Programming

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: , , , , ,

Os frameworks Ágeis de Desenvolvimento de Software

A maioria dos conceitos adotados pelos frameworks ágeis nada possuem de novo. A principal diferença entre essas frameworks e  as metodologias tradicionais são o enfoque e os valores. As frameworks ágeis enfocam as pessoas e não os processos ou algoritmos como as metodologias tradicionais. Além disso, existe a preocupação de gastar menos tempo com documentação e mais com a implementação. Propiciando assim maior interação entre desenvolvedores e clientes (ALVES, 2009).

O Manifesto Ágil

Percebendo que a industria de software apresentava um grande numero de casos de fracasso, alguns lideres experientes adotaram modos de trabalho opostos às metodologias tradicionais. Nesse sentido em 2001, durante uma reunião realizada por 17 desses lideres, concluiu-se que desenvolver software é algo complexo demais para ser definido por um único processo. O desenvolvimento de software depende de muitas variáveis e principalmente é realizado por pessoas em praticamente todas as etapas do processo (BASSI FILHO, 2008). Nesse encontro chegaram a um concenso quanto a alguns princípios que levavam a bons resultados. Entretanto concluiram que uma metodologia unificada seria incapaz de atender todas as particularidades (SOUZA NETO, 2004). Desse trabalho surgiu o Manifesto Ágil cujo foco era o cliente e a agilidade no desenvolvimento de softwares.

O Manifesto Ágil valoriza quatro principios centrais, que resumem bem o foco do novo processo (BEEDLE, 2001).

  1. Indivíduos e interação entre eles mais que processos e ferramentas
  2. Software em funcionamento mais que documentação abrangente
  3. Colaboração com o cliente mais que negociação de contratos
  4. Responder a mudanças mais que seguir um plano

Após a divulgação do Manifesto Ágil surgiram e/ou ganharam destaque uma ampla gama de novos frameworks Ágeis. Dentre as quais as mais conhecidas são eXtreme Programming (XP), a Scrum e a TDD. Essas frameworks mantem, entre si, muitas características em comum e geralmente diferenças sutis. De acordo com Pressman (2006) essas frameworks ressaltam quatro tópicos-chave: são equipes de desenvolvimento pequenas, entre 2 e 10 membros, que se auto organizam; priorizam mais o desenvolvimento em detrimento da documentação; reconhecem aceitam a mudança além de valorizarem e estimularem a comunicação tanto entre os membros da equipe quanto entre a equipe e o cliente.

Outras características não citadas por Pressmam mas que merecem destaque são o fato de serem mais utilizadas em projetos pequenos, embora possam ser aplicadas em grandes projetos. Além disso, assim como no PU os agilistas adotam o desenvolvimento iterativo a fim de maximizar o feedback e minimizar riscos.

Referências:

ALVES, Sérgio de Rezende; ALVES, André Luiz. Engenharia de Requisitos em Metodologias Ágeis.  Goiânia: Universidade Católica de Goiás (PUC – Goiás), 2009. Disponível em: < http://www.cpgls.ucg.br/ArquivosUpload/1/File/V%20MOSTRA%20DE%20PRODUO%20CIENTIFICA/EXATAS/10-.PDF > acesso em: 04 abr. de 2011.

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.

SOUZA NETO, Oscar Nogueira de. Análise Comparativa das Metodologias de Desenvolvimento de Softwares Tradicionais e Ágeis. Belém: Unama – Universidade da Amazônia, 2004.

PRESSMAN, Roger S. Engenharia de Software : 6 ed. São Paulo: McGraw Hill/Nacional, 2006.

BEEDLE, Mike et al. Manifesto para o desenvolvimento ágil de software. Disponível em: <http://manifestoagil.com.br/>. Acesso em: 28 fev. 2011.

Tags: , , , , ,