Posts com Tags Frameworks ágeis

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

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

O Ciclo de Vida do Framework Scrum

A figura acima representa o ciclo de vida do desenvolvimento de software utilizando o framework Scrum. Nela podemos 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.

Posteriormente quebram-no em pequenas “histórias” menores, originando vários Backlogs de Sprint. O Product Owner escolhe então quais histórias serão priorizadas para o Sprint.
Após definir o Backlog do Sprint a equipe realiza uma reunião na qual planeja e estabelece as metas para o Sprint; trata-se da Sprint Plane Meeting (Reunião de Planejamento do Sprint). Na próxima etapa 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 pequena reunião de 15 minutos (Reunião Scrum Diária), realizada pela equipe sempre no mesmo horário e local. Nela cada membro conta o que fez desde a última Daily Scrum, o que pretende fazer e se está tendo algum problema.

Tags: , , , , , , , , , , ,