Métodos Ágeis para Desenvolvimento de Software

1,396 views
1,196 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,396
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
78
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Métodos Ágeis para Desenvolvimento de Software

  1. 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. 2. O QUE SÃO MÉTODOS ÁGEIS? <ul><li>Conjunto de metodologias. </li></ul><ul><li>Desenvolvimento de softwares de 1 a 4 semanas. </li></ul><ul><li>Iteração (Planejamento, Requisitos, Projeto, Codificação, Teste e Documentação). </li></ul><ul><li>Ao término de cada iteração = versão do software para validação. </li></ul>
  3. 3. QUAIS OS OBJETIVOS? <ul><li>Garantir a satisfação do cliente: entrega rápida e contínua de softwares funcionais. </li></ul><ul><li>Estabelecer comunicação cara a cara: representante do cliente sempre disponível. </li></ul><ul><li>Se adaptar rapidamente à mudanças no projeto. </li></ul><ul><li>Evitar documentação extensa: documentar apenas o essencial ao cliente. </li></ul>
  4. 4. COMO SURGIRAM? <ul><li>Reação contra os problemas enfrentados pelas metodologias tradicionais. </li></ul><ul><li>Softwares cada vez mais complexos e requisitos que nunca se repetiam. </li></ul>Dificuldades na alteração do projeto. Aumento de custo e de tempo.
  5. 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. 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. 7. QUAIS OS PRINCÍPIOS DO MANIFESTO ÁGIL? Documento que propõe o desenvolvimento de software baseado nos seguintes fundamentos: <ul><li>Indivíduos e iterações são mais importantes do que processos e ferramentas. </li></ul><ul><li>Software funcionando é mais importante do que negociação de contratos. </li></ul><ul><li>Adaptação a mudanças é mais importante do que seguir o plano inicial. </li></ul><ul><li>Garantir a satisfação do cliente através da entrega rápida e contínua de softwares funcionais. </li></ul><ul><li>Simplicidade. </li></ul>
  8. 8. QUAIS OS PRINCÍPIOS DO MANIFESTO ÁGIL? <ul><li>Aceitar mudanças nos requisitos, mesmo no fim do desenvolvimento, permitindo ao cliente conquistar vantagens competitivas. </li></ul><ul><li>Entregar softwares funcionais com frequência, de preferência em semanas e não meses. </li></ul><ul><li>Deve haver cooperação constante entre as pessoas que conhecem o negócio e os desenvolvedores durante todo o projeto. </li></ul><ul><li>Software funcional é a medida primária de progresso. </li></ul><ul><li>Construção de projetos por indivíduos motivados, que tenham uma relação de confiança. </li></ul><ul><li>Transmitir informações com conversas presenciais, cara a cara, é mais eficiente do que as documentações. </li></ul><ul><li>Uma contínua atenção a excelência técnica e ao bom designer do software, aumenta a agilidade. </li></ul>
  9. 9. COMPARAÇÃO ENTRE METODOLOGIAS ÁGEIS E TRADICIONAIS
  10. 10. AMBIENTE DE DESENVOLVIMENTO ÁGIL <ul><li>Indicado para projetos onde seus requisitos sofram constante mudanças. </li></ul><ul><li>Equipe formada por poucos profissionais com especialistas diferentes, focados no mesmo objetivo. </li></ul><ul><li>Equipe capaz de se auto-organizar, estabelecer cronogramas e se adequar ao processo. </li></ul><ul><li>Equipe e representante do cliente devem trabalhar juntos, alocados em um mesmo ambiente. </li></ul><ul><li>O ambiente deve colaborar para uma comunicação rápida, cara a cara, entre a equipe. </li></ul>
  11. 11. EXEMPLO DE METODOLOGIAS ÁGEIS <ul><li>Scrum </li></ul><ul><li>XP (Extreme Programming) </li></ul><ul><li>Open Up ( Open Unified Process ) </li></ul><ul><li>AUP ( Agile Unified Process ) </li></ul><ul><li>FDD ( Feature Driven Development ) </li></ul><ul><li>TDD ( Test Driven Development ) </li></ul><ul><li>DSSM ( Dynamic Systems Development Method ) </li></ul>Destaque para Scrum e XP
  12. 12. SCRUM <ul><li>Metodologia cujas práticas são aplicadas em um processo iterativo e incremental. </li></ul><ul><li>Indicado para projetos complexos e imprevisíveis. </li></ul><ul><li>Modelado para se adaptar à mudanças em qualquer fase do projeto. </li></ul><ul><li>A evolução do projeto é acompanhada de perto por um representante do cliente. </li></ul>
  13. 13. SCRUM <ul><li>As necessidades do negócio vão determinar a prioridade do desenvolvimento. </li></ul><ul><li>Ocorrem reuniões diárias para: </li></ul><ul><ul><li>Planejar as iterações. </li></ul></ul><ul><ul><li>Determinar as tarefas. </li></ul></ul><ul><ul><li>Gerenciar os riscos. </li></ul></ul><ul><ul><li>Definir prioridades. </li></ul></ul>
  14. 14. OS PAPÉIS DENTRO DO SCRUM <ul><li>Srum Master </li></ul><ul><ul><li>É o gerente do projeto. </li></ul></ul><ul><ul><li>Dá suporte à equipe e mantém a sua produtividade. </li></ul></ul><ul><ul><li>Implanta as práticas e os valores do Scrum entre os membros da equipe. </li></ul></ul>
  15. 15. OS PAPÉIS DENTRO DO SCRUM <ul><li>Product Owner </li></ul><ul><ul><li>Pode ser o cliente ou seu representante. </li></ul></ul><ul><ul><li>Determina as funcionalidades do produto. </li></ul></ul><ul><ul><li>Modifica os requisitos quando necessário. </li></ul></ul><ul><ul><li>Aprova ou não cada versão obtida do software. </li></ul></ul>
  16. 16. OS PAPÉIS DENTRO DO SCRUM <ul><li>Scrum Team </li></ul><ul><ul><li>É a equipe técnica focada no desempenho do software. </li></ul></ul><ul><ul><li>Composta por cerca de 7 pessoas. </li></ul></ul><ul><ul><li>Formada por profissionais multifuncionais. </li></ul></ul><ul><ul><li>Não há divisão de papéis na equipe. </li></ul></ul>
  17. 17. <ul><ul><li>SPRINT </li></ul></ul><ul><li>Ciclo ou iteração com duração média de 30 dias. </li></ul><ul><li>Ocorre o desenvolvimento e a implantação dos requisitos. </li></ul><ul><li>Ao seu término ocorre a entrega de um incremento funcional ao cliente. </li></ul>
  18. 18. <ul><ul><li>OS ARTEFATOS USADOS NO SCRUM </li></ul></ul><ul><li>Product Backlog </li></ul><ul><ul><li>Lista que contém todas as funcionalidades do produto. </li></ul></ul><ul><ul><li>Cada funcionalidade é chamada de “estória”. </li></ul></ul><ul><ul><li>É definida pelo Product Owner. </li></ul></ul><ul><ul><li>Pode sofrer alterações no decorrer de cada Sprint. </li></ul></ul>
  19. 19. <ul><ul><li>OS ARTEFATOS USADOS NO SCRUM </li></ul></ul><ul><li>Product Backlog </li></ul>
  20. 20. <ul><ul><li>OS ARTEFATOS USADOS NO SCRUM </li></ul></ul><ul><li>Sprint Backlog </li></ul><ul><ul><li>Lista que contém as atividades que serão realizadas pela Scrum Team dentro da Sprint corrente. </li></ul></ul><ul><ul><li>Cada membro da Scrum Team decide que tarefa irá realizar. </li></ul></ul>
  21. 21. <ul><ul><li>OS ARTEFATOS USADOS NO SCRUM </li></ul></ul><ul><li>Sprint Backlog </li></ul>
  22. 22. <ul><ul><li>OS ARTEFATOS USADOS NO SCRUM </li></ul></ul><ul><li>Burndown Chart </li></ul><ul><ul><li>Representação gárfica das atividades do projeto. </li></ul></ul><ul><ul><li>Permite visualizar rapidamente o andamento de todo o projeto (tarefas concluídas e pendentes). </li></ul></ul><ul><ul><li>É atualizada diariamente. </li></ul></ul>
  23. 23. <ul><ul><li>OS ARTEFATOS USADOS NO SCRUM </li></ul></ul><ul><li>Burndown Chart </li></ul>
  24. 24. <ul><ul><li>OS ARTEFATOS USADOS NO SCRUM </li></ul></ul><ul><li>Sprint Planning </li></ul><ul><ul><li>Reunião que ocorre no início de cada Sprint. </li></ul></ul><ul><ul><li>Determina o objetivo da Sprint. </li></ul></ul><ul><ul><li>Define as atividades que serão listadas na Sprint Backlog. </li></ul></ul><ul><ul><li>Define as prioridades das funcionalidades que serão listadas no Product Backlog. </li></ul></ul>
  25. 25. <ul><ul><li>OS ARTEFATOS USADOS NO SCRUM </li></ul></ul><ul><li>Sprint Planning </li></ul>
  26. 26. <ul><ul><li>OS ARTEFATOS USADOS NO SCRUM </li></ul></ul><ul><li>DashBoard </li></ul><ul><ul><li>Quadro com dados da Sprint atual. </li></ul></ul><ul><ul><li>Permite acompanhar atividades realizadas e as que ainda estão por fazer. </li></ul></ul><ul><ul><li>Os dados são apresentados no quadro na forma de post-its. </li></ul></ul>
  27. 27. <ul><ul><li>OS ARTEFATOS USADOS NO SCRUM </li></ul></ul><ul><li>DashBoard </li></ul>
  28. 28. <ul><ul><li>OS ARTEFATOS USADOS NO SCRUM </li></ul></ul><ul><li>Daily Scrum </li></ul><ul><ul><li>Reuniões diárias de no máximo 15 minutos. </li></ul></ul><ul><ul><li>Realizada entre o Scrum Master e a sua equipe. </li></ul></ul><ul><ul><li>Seu objetivo é: </li></ul></ul><ul><ul><ul><li>Expor atividades concluídas. </li></ul></ul></ul><ul><ul><ul><li>Analisar as próximas atividades. </li></ul></ul></ul><ul><ul><ul><li>Identificar possíveis problemas. </li></ul></ul></ul>
  29. 29. <ul><ul><li>OS ARTEFATOS USADOS NO SCRUM </li></ul></ul><ul><li>Sprint Review </li></ul><ul><ul><li>Reunião que ocorre entre o Scrum Master, sua equipe e o Product Owner. </li></ul></ul><ul><ul><li>Apresenta ao Product Owner os resultados obtidos ao final da Sprint. </li></ul></ul>
  30. 30. <ul><ul><li>OS ARTEFATOS USADOS NO SCRUM </li></ul></ul><ul><li>Sprint Retrospective </li></ul><ul><ul><li>Reunião que ocorre após o Sprint Review. </li></ul></ul><ul><ul><li>Seu objetivo é: </li></ul></ul><ul><ul><ul><li>Expor a opinião dos membros para discutir pontos positivos e negativos da equipe. </li></ul></ul></ul><ul><ul><ul><li>Gerar melhorias para o próximo Sprint. </li></ul></ul></ul>
  31. 31. <ul><ul><li>SCRUM </li></ul></ul><ul><li>Ciclo do Scrum </li></ul>
  32. 32. XP (Extreme Programming) <ul><li>Metodologia de desenvolvimento ágil voltada para pequenas e médias equipes. </li></ul><ul><li>Indicada para softwares que se modificam constantemente. </li></ul><ul><li>Sua abordagem incremental é focada em feedbacks diários entre os membros da equipe. </li></ul>
  33. 33. OS VALORES DO XP <ul><li>Comunicação – direta, esclarecendo dúvidas de imediato, uma vez que o cliente deve ficar a disposição da equipe. </li></ul><ul><li>Simplicidade – é desenvolvido apenas o essencial para atender o cliente. </li></ul><ul><li>Feedback – para permitir que o cliente determine prioridades e identifique erros de imediato. </li></ul><ul><li>Coragem – necessária para implementar os 3 valores anteriores por serem contrários à metodologia tradicional. </li></ul>
  34. 34. <ul><ul><li>PAPÉIS DENTRO DO XP </li></ul></ul><ul><li>Cliente </li></ul><ul><ul><li>Apresenta as funcionalidades necessárias e as prioridades no sistema. </li></ul></ul><ul><ul><li>Acompanha a equipe durante todo o projeto. </li></ul></ul><ul><li>Gerente de Equipe </li></ul><ul><ul><li>Lidera a equipe garantindo a execução das suas atividades. </li></ul></ul><ul><ul><li>Esclarece o andamento do projeto ao cliente. </li></ul></ul>
  35. 35. <ul><ul><li>PAPÉIS DENTRO DO XP </li></ul></ul><ul><li>Desenvolvedor </li></ul><ul><ul><li>Codifica e testa as funcionalidades apresentadas pelo cliente. </li></ul></ul><ul><ul><li>Se comunica com o cliente durante cada incremento para esclarecer dúvidas, evitar erros e propor melhorias. </li></ul></ul>
  36. 36. <ul><ul><li>PAPÉIS DENTRO DO XP </li></ul></ul><ul><li>Coach </li></ul><ul><ul><li>Desenvolvedor com maior conhecimento na equipe. </li></ul></ul><ul><ul><li>É ele quem verifica se todos estão seguindo as práticas do XP. </li></ul></ul><ul><ul><li>Identifica habilidades entre os membros da equipe visando uma melhor distribuição das atividades. </li></ul></ul>
  37. 37. <ul><ul><li>PAPÉIS DENTRO DO XP </li></ul></ul><ul><li>Redator Técnico </li></ul><ul><ul><li>Produz documentação do projeto somente quando necessário. </li></ul></ul><ul><ul><li>Isto é feito apenas quando for agregar algum valor ao cliente. </li></ul></ul>
  38. 38. <ul><ul><li>PAPÉIS DENTRO DO XP </li></ul></ul><ul><li>Tracker </li></ul><ul><ul><li>Responsável por adicionar lembretes informativos no ambiente de trabalho. </li></ul></ul><ul><ul><li>Os lembretes indicam: </li></ul></ul><ul><ul><ul><li>Pendências nos processos. </li></ul></ul></ul><ul><ul><ul><li>Falhas encontradas. </li></ul></ul></ul>
  39. 39. <ul><ul><li>AS PRÁTICAS APLICADAS NO XP </li></ul></ul><ul><li>Jogo de Planejamento </li></ul><ul><ul><li>Momento de negociação com o cliente. </li></ul></ul><ul><ul><li>O cliente expõe suas necessidades e prioridades. </li></ul></ul><ul><ul><li>Na ausência do cliente são realizados: </li></ul></ul><ul><ul><ul><li>O planejamento do incremento. </li></ul></ul></ul><ul><ul><ul><li>A divisão das atividades. </li></ul></ul></ul><ul><ul><ul><li>O tempo estimado de conclusão. </li></ul></ul></ul><ul><ul><li>Ao final do incremento o release do produto é apresentado ao cliente. </li></ul></ul>
  40. 40. <ul><ul><li>AS PRÁTICAS APLICADAS NO XP </li></ul></ul><ul><li>Jogo de Planejamento </li></ul><ul><ul><li>É realizado o feedback onde o cliente aprova ou sugere melhorias. </li></ul></ul><ul><ul><li>Se aprovado, o release é adicionado ao produto final. </li></ul></ul><ul><ul><li>Senão, o release terá o seu ciclo refeito. </li></ul></ul>
  41. 41. <ul><li>Ciclo do XP </li></ul>XP (Extreme Programming)
  42. 42. <ul><ul><li>AS PRÁTICAS APLICADAS NO XP </li></ul></ul><ul><li>Programação em Pares </li></ul><ul><ul><li>2 desenvolvedores trabalham juntos no mesmo computador. </li></ul></ul><ul><ul><li>Ocorre a troca de conhecimentos entre eles no decorrer do projeto. </li></ul></ul><ul><ul><li>Isso otimiza a qualidade da codificação. </li></ul></ul><ul><ul><li>Juntos eles discutem soluções, reduzem linhas de código e possíveis erros. </li></ul></ul>
  43. 43. <ul><ul><li>AS PRÁTICAS APLICADAS NO XP </li></ul></ul><ul><li>Programação em Pares </li></ul>
  44. 44. <ul><ul><li>AS PRÁTICAS APLICADAS NO XP </li></ul></ul><ul><li>Stand Up Meeting </li></ul><ul><ul><li>Reuniões de no máximo 15 minutos. </li></ul></ul><ul><ul><li>É realizada com os participantes em pé, garantindo maior atenção dos mesmos. </li></ul></ul><ul><ul><li>Tem o objetivo de: </li></ul></ul><ul><ul><ul><li>Discutir obstáculos encontrados. </li></ul></ul></ul><ul><ul><ul><li>Transmitir informações sobre o andamento do projeto. </li></ul></ul></ul>
  45. 45. <ul><ul><li>AS PRÁTICAS APLICADAS NO XP </li></ul></ul><ul><li>Stand Up Meeting </li></ul>
  46. 46. <ul><ul><li>AS PRÁTICAS APLICADAS NO XP </li></ul></ul><ul><li>Teste </li></ul><ul><ul><li>Desenvolvidos e realizados pela equipe. </li></ul></ul><ul><ul><li>Garante melhor qualidade ao software. </li></ul></ul><ul><ul><li>São feitos Testes de Unidade para verificar o correto funcionamento dos métodos codificados. </li></ul></ul><ul><ul><li>São feitos Testes de Aceitação para verificar: </li></ul></ul><ul><ul><ul><li>Se as partes testadas estão integradas. </li></ul></ul></ul><ul><ul><ul><li>Se as partes testadas se comportam como necessário. </li></ul></ul></ul>
  47. 47. <ul><li>Refactoring </li></ul><ul><ul><li>Modificações realizadas na codificação para: </li></ul></ul><ul><ul><ul><li>Reduzir linhas de código. </li></ul></ul></ul><ul><ul><ul><li>Tornar o código mais rápido e claro. </li></ul></ul></ul><ul><ul><li>Pode ser realizada por qualquer membro da equipe que julgue isso necessário. </li></ul></ul><ul><ul><li>AS PRÁTICAS APLICADAS NO XP </li></ul></ul>
  48. 48. <ul><li>Design Simples </li></ul><ul><ul><li>Funcionalidades que serão raramente usadas pelo cliente são evitadas. </li></ul></ul><ul><ul><li>Somente o que agregue valor ao cliente será codificado. </li></ul></ul><ul><ul><li>Tem como objetivo diminuir custo e reduzir a complexidade do projeto. </li></ul></ul><ul><ul><li>AS PRÁTICAS APLICADAS NO XP </li></ul></ul>
  49. 49. <ul><li>Metáfora </li></ul><ul><ul><li>Comunicação da maneira mais simples e no nível mais próximo do cliente. </li></ul></ul><ul><ul><li>Facilita a compreensão do cliente durante o andamento do projeto. </li></ul></ul><ul><ul><li>Evita possíveis falhas de comunicação que possam atrapalhar o desenvolvimento. </li></ul></ul><ul><ul><li>AS PRÁTICAS APLICADAS NO XP </li></ul></ul>
  50. 50. <ul><li>Releases Curtos </li></ul><ul><ul><li>Pequenas partes funcionais do produto final. </li></ul></ul><ul><ul><li>São gerados à cada ciclo de desenvolvimento. </li></ul></ul><ul><ul><li>Entregues regularmente ao cliente para validação. </li></ul></ul><ul><ul><li>É uma maneira de manter o cliente satisfeito, já que ele participa de toda a evolução do projeto. </li></ul></ul><ul><ul><li>AS PRÁTICAS APLICADAS NO XP </li></ul></ul>
  51. 51. <ul><li>Benefícios </li></ul><ul><li>Críticas </li></ul><ul><ul><li>CONCLUSÃO SOBRE O USO DE MÉTODOS ÁGEIS </li></ul></ul>
  52. 52. <ul><ul><li>CONCLUSÃO SOBRE O USO DE MÉTODOS ÁGEIS </li></ul></ul>http://at2011.agiletour.org/fr/node/1249
  53. 53. <ul><ul><li>CONCLUSÃO SOBRE O USO DE MÉTODOS ÁGEIS </li></ul></ul>www.agilebrazil.com
  54. 54. <ul><li>Schwaber, K. (2004) “Agile Project Management with Scrum”, Microsoft Press. </li></ul><ul><li>Soares, Michel dos Santos. 2004. “Comparação entre metodologias ágeis e tradicionais para o desenvolvimento de software”. </li></ul><ul><li>KUHN, Giovane Roslindo & PAMPLONA, Vitor Fernando. 2009. “Apresentando XP, Encante seus clientes com Extreme Programming – Java Fee.org”. </li></ul><ul><li>“ Manifesto for Agile Software Development”. 2001. Disponível em http://www.agilemanifesto.org. Último acesso em 16 de Outubro de 2011. </li></ul><ul><li>“ 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. </li></ul><ul><li>SILVA, Tiago de Farias. 2008. “Compondo Métodos Ágeis de Desenvolvimento de Software”. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul><ul><ul><li>REFERÊNCIAS </li></ul></ul>
  55. 55. Fim

×