Posts com Tags Desenvolvimento Ágil

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

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

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