Your SlideShare is downloading. ×
Métodos Ágeis para Desenvolvimento de Software
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Métodos Ágeis para Desenvolvimento de Software

842
views

Published on

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
842
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
58
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Métodos Ágeis Engenharia de Software Professor: Antonio Cláudio P. Neiva Alunos: Alexandre C. Malaquias Andrea M. Freire Diego Trindade Rogério Pacheco UCSAL Universidade Católica do Salvador
  • 2. 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.
  • 3. 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.
  • 4. 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.
  • 5. 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
  • 6. 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
  • 7. 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.
  • 8. 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.
  • 9. COMPARAÇÃO ENTRE METODOLOGIAS ÁGEIS E TRADICIONAIS
  • 10. 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.
  • 11. 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
  • 12. 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.
  • 13. 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.
  • 14. 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.
  • 15. OS PAPÉIS DENTRO DO SCRUM
    • 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.
  • 16. OS PAPÉIS DENTRO DO SCRUM
    • 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.
  • 17.
      • 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.
  • 18.
      • 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.
  • 19.
      • OS ARTEFATOS USADOS NO SCRUM
    • Product Backlog
  • 20.
      • OS ARTEFATOS USADOS NO SCRUM
    • 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.
  • 21.
      • OS ARTEFATOS USADOS NO SCRUM
    • Sprint Backlog
  • 22.
      • OS ARTEFATOS USADOS NO SCRUM
    • 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.
  • 23.
      • OS ARTEFATOS USADOS NO SCRUM
    • Burndown Chart
  • 24.
      • OS ARTEFATOS USADOS NO SCRUM
    • 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.
  • 25.
      • OS ARTEFATOS USADOS NO SCRUM
    • Sprint Planning
  • 26.
      • OS ARTEFATOS USADOS NO SCRUM
    • 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.
  • 27.
      • OS ARTEFATOS USADOS NO SCRUM
    • DashBoard
  • 28.
      • OS ARTEFATOS USADOS NO SCRUM
    • 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.
  • 29.
      • OS ARTEFATOS USADOS NO SCRUM
    • 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.
  • 30.
      • OS ARTEFATOS USADOS NO SCRUM
    • 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.
  • 31.
      • SCRUM
    • Ciclo do Scrum
  • 32. XP (Extreme Programming)
    • 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.
  • 33. 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.
  • 34.
      • 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.
  • 35.
      • PAPÉIS DENTRO DO XP
    • 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.
  • 36.
      • PAPÉIS DENTRO DO XP
    • 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.
  • 37.
      • PAPÉIS DENTRO DO XP
    • Redator Técnico
      • Produz documentação do projeto somente quando necessário.
      • Isto é feito apenas quando for agregar algum valor ao cliente.
  • 38.
      • PAPÉIS DENTRO DO XP
    • Tracker
      • Responsável por adicionar lembretes informativos no ambiente de trabalho.
      • Os lembretes indicam:
        • Pendências nos processos.
        • Falhas encontradas.
  • 39.
      • 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.
  • 40.
      • AS PRÁTICAS APLICADAS NO XP
    • 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.
  • 41.
    • Ciclo do XP
    XP (Extreme Programming)
  • 42.
      • AS PRÁTICAS APLICADAS NO 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.
  • 43.
      • AS PRÁTICAS APLICADAS NO XP
    • Programação em Pares
  • 44.
      • AS PRÁTICAS APLICADAS NO XP
    • 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.
  • 45.
      • AS PRÁTICAS APLICADAS NO XP
    • Stand Up Meeting
  • 46.
      • AS PRÁTICAS APLICADAS NO XP
    • 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.
  • 47.
    • 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.
      • AS PRÁTICAS APLICADAS NO XP
  • 48.
    • 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.
      • AS PRÁTICAS APLICADAS NO XP
  • 49.
    • 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.
      • AS PRÁTICAS APLICADAS NO XP
  • 50.
    • 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.
      • AS PRÁTICAS APLICADAS NO XP
  • 51.
    • Benefícios
    • Críticas
      • CONCLUSÃO SOBRE O USO DE MÉTODOS ÁGEIS
  • 52.
      • CONCLUSÃO SOBRE O USO DE MÉTODOS ÁGEIS
    http://at2011.agiletour.org/fr/node/1249
  • 53.
      • CONCLUSÃO SOBRE O USO DE MÉTODOS ÁGEIS
    www.agilebrazil.com
  • 54.
    • 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
  • 55. Fim

×