Arquivo para dezembro de 2011

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 Sprint e os Artefatos do Scrum

No Scrum existem vários Time-Boxes que são utilizados para gerar regularidade. Os Time-Boxes mais importantes no Scrum são: a sprint planing meeting(planejamento de versão), o sprint, a reunião diária, a revisão do sprint e a retrospectiva do sprint. O coração do scrum para Schwaber (2010) é o sprint, que é uma iteração de um mês ou menos dentro da qual é feito um esforço de desenvolvimento. Ao final de cada sprint tem se como resultado um pequeno incremento de software que é potencialmente entregável após isto a equipe pode iniciar um novo sprint.

O Scrum utiliza quatro artefatos principais. O backlog de produto que é uma lista priorizada de tudo que pode ser necessário desenvolver em  um software. O backlog de sprint que é uma lista de tarefas  priorizadas no backlog de produto  e que ao final de uma sprint, resultará em um incremento. Um burndown que é um gráfico através do qual é medido a velocidade do time. Um burndown  de release que mede o product backlog restante ao longo do tempo de um plano de release. E um burndown de sprint mede os itens do backlog de sprint restantes ao longo do tempo de um sprint (SHWABER, 2010).

Figura 4 – O Ciclo de Vida da Metodologia Scrum

Adaptado de: 3MONTHS, 2011

A Figura 4 representa o ciclo de vida desenvolvimento de software utilizando a metodologia Scrum. Nela pode-se observar que o product owner e a equipe, baseados na visão inicial do produto, definem as histórias a serem desenvolvidas, ou seja o backlog de produto. Este por sua vez é dividido em pequenas “histórias” menores, pela equipe e pelo product owner. Posteriormente o product owner escolhe então quais dessas histórias serão priorizadas para o sprint originando assim um backlog de sprint.

Após definir-se o backlog do sprint a equipe realiza uma reunião na qual estabelece as suas metas durante o sprint; trata-se da sprint plane meeting (reunião de planejamento do sprint) onde estabelece suas metas durante o sprint. O próximo passo da espiral representa o incremento produzido durante o sprint. É nessa etapa que ocorre o desenvolvimento do produto. Uma vez que o novo incremento foi desenvolvido, devidamente testado e integrado ao sistema a equipe faz uma revisão do sprint nela a equipe apresenta o que foi realizado durante o sprint e demonstra as novas funcionalidades incorporadas. O product ownwer testa, para verificar se o item atende suas expectativas e determina se a meta do sprint foi ou não atingida.

O próximo passo é a retrospectiva do sprint, nela são levantados o que aconteceu de bom, o que foi ruim e o que deve melhorar. O objetivo dessa reunião é trazer melhoria contínua ao trabalho da equipe. Feito isso o backlog de produto é atualizado e o ciclo é reiniciado. Acima do circulo maior, que representa o sprint, tem se outro circulo menor que representa a iteração diária onde são cumpridas as metas diárias que compõem o Sprint. Durante o sprint diário, os membros do time fazem uma pequena reunião de 15 minutos (reunião scrum diária), sempre de pé, no mesmo horário e local. Nela cada membro conta o que fez desde a última reunião o que pretende fazer e se está tendo algum problema.

De acordo com Kniberg (2007) o Scrum fornece bases para a gestão do processo de desenvolvimento, mas não se preocupa com como será feito o desenvolvimento. O XP por sua vez sugere as práticas a serem seguidas para o desenvolvimento de um projeto e não se preocupa com a gestão. Sendo assim muitas equipes ágeis utilizam XP e Scrum juntos, onde um fornece boas práticas de desenvolvimento e o outro, boas práticas de gestão. Devido a essa extensibilidade os autores agilistas tendem a adotar o termo framework e não metodologia quando se referem a elas.

Novas metodologias surgem o tempo todo e as vezes pode parecer dificil escolher uma “correta”. Nesse sentido, Henrajani (2007) afirma que todo projeto deve ter alguma estrutura de processo básico que precisa seguir. Não ter nenhum processo é ruim, mas o excesso deles é igualmente ruim. Sendo assim cabe a equipe encontrar o equilibrio correto, considerando as necessidades do cliente, o tamanho do projeto e as metas da equipe.

Referências:

SCHWABER, Ken. Guia do Scrum. Scrum Alliance, 2010. Disponível em: < http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%20PTBR.pdf >  acesso em 04 abr. 2011.

3MONTHS. Project Lyfecycle. Disponível em: < http://blog.3months.com/wp-content/uploads/2010/01/project_lifecycle_v1cc.png > acesso em: 04 abr. de 2011.

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

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.

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