métodos Ágeis para desenvolvimento de software

Métodos Ágeis

UCSALUniversidade Católica do Salvador

Engenharia de SoftwareProfessor: Antonio Cláudio P. Neiva

Alunos: Alexandre C. Malaquias

Andrea M. FreireDiego Trindade

Rogério Pacheco

O QUE SÃO MÉTODOS ÁGEIS?

Conjunto de metodologias.

Desenvolvimento de softwares de 1 a 4 semanas.

Iteração (Planejamento, Requisitos, Projeto, Codificação, Teste e Documentação).

Ao término de cada iteração = versão do software para validação.

QUAIS OS OBJETIVOS?

Garantir a satisfação do cliente: entrega rápida e contínua de softwares funcionais.

Estabelecer comunicação cara a cara: representante do cliente sempre disponível.

Se adaptar rapidamente à mudanças no projeto.

Evitar documentação extensa: documentar apenas o essencial ao cliente.

COMO SURGIRAM?

Reação contra os problemas enfrentados pelas metodologias tradicionais.

Softwares cada vez mais complexos e requisitos que nunca se repetiam.

Dificuldades na alteração do projeto.

Aumento de custo e de tempo.

COMO SURGIRAM?

Popularização do termo “Métodos Ágeis” através do encontro de 17 especialistas em desenvolvimento de

software.

Eles compartilharam suas experiências na área (fracassos e sucessos)

Concordaram em estabelecer novo paradigma em Desenvolvimento de software.

Criação do Manifesto Ágil

O QUE É O MANIFESTO ÁGIL?

“O Manifesto Ágil é uma declaração sobre os princípios que servem como base para o

desenvolvimento ágil de software.”

www.agilemanifesto.org

Alguns dos idealizadores:

• Kent Beck • Ken Schwaber

• Martin Fowler • Jim Highsmith

QUAIS OS PRINCÍPIOS DO MANIFESTO ÁGIL?

Documento que propõe o desenvolvimento de software baseado nos seguintes fundamentos:

Indivíduos e iterações são mais importantes do que processos e ferramentas.

Software funcionando é mais importante do que negociação de contratos.

Adaptação a mudanças é mais importante do que seguir o plano inicial.

Garantir a satisfação do cliente através da entrega rápida e contínua de softwares funcionais.

Simplicidade.

QUAIS OS PRINCÍPIOS DO MANIFESTO ÁGIL?

Aceitar mudanças nos requisitos, mesmo no fim do desenvolvimento, permitindo ao cliente conquistar vantagens competitivas.

Entregar softwares funcionais com frequência, de preferência em semanas e não meses.

Deve haver cooperação constante entre as pessoas que conhecem o negócio e os desenvolvedores durante todo o projeto.

Software funcional é a medida primária de progresso.

Construção de projetos por indivíduos motivados, que tenham uma relação de confiança.

Transmitir informações com conversas presenciais, cara a cara, é mais eficiente do que as documentações.

Uma contínua atenção a excelência técnica e ao bom designer do software, aumenta a agilidade.

COMPARAÇÃO ENTRE METODOLOGIAS ÁGEIS E TRADICIONAIS

AMBIENTE DE DESENVOLVIMENTO ÁGIL

Indicado para projetos onde seus requisitos sofram constante mudanças.

Equipe formada por poucos profissionais com especialistas diferentes, focados no mesmo objetivo.

Equipe capaz de se auto-organizar, estabelecer cronogramas e se adequar ao processo.

Equipe e representante do cliente devem trabalhar juntos, alocados em um mesmo ambiente.

O ambiente deve colaborar para uma comunicação rápida, cara a cara, entre a equipe.

EXEMPLO DE METODOLOGIAS ÁGEIS

Scrum

XP (Extreme Programming)

Open Up (Open Unified Process)

AUP (Agile Unified Process)

FDD (Feature Driven Development)

TDD (Test Driven Development)

DSSM (Dynamic Systems Development Method)

Destaque para Scrum e XP

SCRUM

Metodologia cujas práticas são aplicadas em um processo iterativo e incremental.

Indicado para projetos complexos e imprevisíveis.

Modelado para se adaptar à mudanças em qualquer fase do projeto.

A evolução do projeto é acompanhada de perto por um representante do cliente.

SCRUM

As necessidades do negócio vão determinar a prioridade do desenvolvimento.

Ocorrem reuniões diárias para:

Planejar as iterações.

Determinar as tarefas.

Gerenciar os riscos.

Definir prioridades.

OS PAPÉIS DENTRO DO SCRUM

Srum Master

É o gerente do projeto.

Dá suporte à equipe e mantém a sua produtividade.

Implanta as práticas e os valores do Scrum entre os membros da equipe.


Product Owner

Pode ser o cliente ou seu representante.

Determina as funcionalidades do produto.

Modifica os requisitos quando necessário.

Aprova ou não cada versão obtida do software.


Scrum Team

É a equipe técnica focada no desempenho do software.

Composta por cerca de 7 pessoas.

Formada por profissionais multifuncionais.

Não há divisão de papéis na equipe.

SPRINT

Ciclo ou iteração com duração média de 30 dias.

Ocorre o desenvolvimento e a implantação dos requisitos.

Ao seu término ocorre a entrega de um incremento funcional ao cliente.

OS ARTEFATOS USADOS NO SCRUM

Product Backlog

Lista que contém todas as funcionalidades do produto.

Cada funcionalidade é chamada de “estória”.

É definida pelo Product Owner.

Pode sofrer alterações no decorrer de cada Sprint.


Product Backlog


Sprint Backlog

Lista que contém as atividades que serão realizadas pela Scrum Team dentro da Sprint corrente.

Cada membro da Scrum Team decide que tarefa irá realizar.


Sprint Backlog


Burndown Chart

Representação gárfica das atividades do projeto.

Permite visualizar rapidamente o andamento de todo o projeto (tarefas concluídas e pendentes).

É atualizada diariamente.


Burndown Chart


Sprint Planning

Reunião que ocorre no início de cada Sprint.

Determina o objetivo da Sprint.

Define as atividades que serão listadas na Sprint Backlog.

Define as prioridades das funcionalidades que serão listadas no Product Backlog.


Sprint Planning


DashBoard

Quadro com dados da Sprint atual.

Permite acompanhar atividades realizadas e as que ainda estão por fazer.

Os dados são apresentados no quadro na forma de post-its.


DashBoard


Daily Scrum

Reuniões diárias de no máximo 15 minutos.

Realizada entre o Scrum Master e a sua equipe.

Seu objetivo é:

– Expor atividades concluídas.

– Analisar as próximas atividades.

– Identificar possíveis problemas.


Sprint Review

Reunião que ocorre entre o Scrum Master, sua equipe e o Product Owner.

Apresenta ao Product Owner os resultados obtidos ao final da Sprint.


Sprint Retrospective

Reunião que ocorre após o Sprint Review.

Seu objetivo é:

– Expor a opinião dos membros para discutir pontos positivos e negativos da equipe.

– Gerar melhorias para o próximo Sprint.

SCRUM

Ciclo do Scrum


Metodologia de desenvolvimento ágil voltada para pequenas e médias equipes.

Indicada para softwares que se modificam constantemente.

Sua abordagem incremental é focada em feedbacks diários entre os membros da equipe.

OS VALORES DO XP

Comunicação – direta, esclarecendo dúvidas de imediato, uma vez que o cliente deve ficar a disposição da equipe.

Simplicidade – é desenvolvido apenas o essencial para atender o cliente.

Feedback – para permitir que o cliente determine prioridades e identifique erros de imediato.

Coragem – necessária para implementar os 3 valores anteriores por serem contrários à metodologia tradicional.

PAPÉIS DENTRO DO XP

Cliente

Apresenta as funcionalidades necessárias e as prioridades no sistema.

Acompanha a equipe durante todo o projeto.

Gerente de Equipe

Lidera a equipe garantindo a execução das suas atividades.

Esclarece o andamento do projeto ao cliente.


Desenvolvedor

Codifica e testa as funcionalidades apresentadas pelo cliente.

Se comunica com o cliente durante cada incremento para esclarecer dúvidas, evitar erros e propor melhorias.


Coach

Desenvolvedor com maior conhecimento na equipe.

É ele quem verifica se todos estão seguindo as práticas do XP.

Identifica habilidades entre os membros da equipe visando uma melhor distribuição das atividades.


Redator Técnico

Produz documentação do projeto somente quando necessário.

Isto é feito apenas quando for agregar algum valor ao cliente.


Tracker

Responsável por adicionar lembretes informativos no ambiente de trabalho.

Os lembretes indicam:

– Pendências nos processos.

– Falhas encontradas.

AS PRÁTICAS APLICADAS NO XP

Jogo de Planejamento

Momento de negociação com o cliente.

O cliente expõe suas necessidades e prioridades.

Na ausência do cliente são realizados:

– O planejamento do incremento.

– A divisão das atividades.

– O tempo estimado de conclusão.

Ao final do incremento o release do produto é apresentado ao cliente.


Jogo de Planejamento

É realizado o feedback onde o cliente aprova ou sugere melhorias.

Se aprovado, o release é adicionado ao produto final.

Senão, o release terá o seu ciclo refeito.

Ciclo do XP



Programação em Pares

2 desenvolvedores trabalham juntos no mesmo computador.

Ocorre a troca de conhecimentos entre eles no decorrer do projeto.

Isso otimiza a qualidade da codificação.

Juntos eles discutem soluções, reduzem linhas de código e possíveis erros.


Programação em Pares


Stand Up Meeting

Reuniões de no máximo 15 minutos.

É realizada com os participantes em pé, garantindo maior atenção dos mesmos.

Tem o objetivo de:

– Discutir obstáculos encontrados.

– Transmitir informações sobre o andamento do projeto.


Stand Up Meeting


Teste

Desenvolvidos e realizados pela equipe.

Garante melhor qualidade ao software.

São feitos Testes de Unidade para verificar o correto funcionamento dos métodos codificados.

São feitos Testes de Aceitação para verificar:

– Se as partes testadas estão integradas.

– Se as partes testadas se comportam como necessário.

Refactoring

Modificações realizadas na codificação para:

– Reduzir linhas de código.

– Tornar o código mais rápido e claro.

Pode ser realizada por qualquer membro da equipe que julgue isso necessário.


Design Simples

Funcionalidades que serão raramente usadas pelo cliente são evitadas.

Somente o que agregue valor ao cliente será codificado.

Tem como objetivo diminuir custo e reduzir a complexidade do projeto.


Metáfora

Comunicação da maneira mais simples e no nível mais próximo do cliente.

Facilita a compreensão do cliente durante o andamento do projeto.

Evita possíveis falhas de comunicação que possam atrapalhar o desenvolvimento.


Releases Curtos

Pequenas partes funcionais do produto final.

São gerados à cada ciclo de desenvolvimento.

Entregues regularmente ao cliente para validação.

É uma maneira de manter o cliente satisfeito, já que ele participa de toda a evolução do projeto.


Benefícios

Críticas

CONCLUSÃO SOBRE O USO DE MÉTODOS ÁGEIS


http://at2011.agiletour.org/fr/node/1249


www.agilebrazil.com

•Schwaber, K. (2004) “Agile Project Management with Scrum”, Microsoft Press.

•Soares, Michel dos Santos. 2004. “Comparação entre metodologias ágeis e tradicionais para o desenvolvimento de software”.

•KUHN, Giovane Roslindo & PAMPLONA, Vitor Fernando. 2009. “Apresentando XP, Encante seus clientes com Extreme Programming – Java Fee.org”.

•“Manifesto for Agile Software Development”. 2001. Disponível em http://www.agilemanifesto.org. Último acesso em 16 de Outubro de 2011.

•“Métodos Ágeis”. 2005. Disponível em http://www.ccw.com.br/post/ler/50/metodologias_ageis. Último acesso em 15 de Outubro de 2011.

•SILVA, Tiago de Farias. 2008. “Compondo Métodos Ágeis de Desenvolvimento de Software”.

•SCHWABER, Ken & BEEDLE, Mike. 2008. “Scrum e XP direto das trincheiras”. Disponível em: http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches. Último acesso em 22 de Outubro de 2011.

•SOARES, Michel dos Santos. 2004. “Metodologias Ágeis Extreme Programming e Scrum para o Desenvolvimento de Software” Disponível em: http://revistas.facecla.com.br/index.php/reinfo/article/view/146. Último acesso em 22 de Outubro de 2011.

•SATO, Danilo Toshiaki. 2007. “Uso eficaz de métricas em métodos ágeis de desenvolvimento de software” Disponível em: http://grenoble.ime.usp.br/~gold/orientados. Último acesso em 23 de Outubro de 2011.

REFERÊNCIAS

métodos Ágeis para desenvolvimento de software

Technology