Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Métodos Ágeis para Desenvolvimento de Software

1,633 views

Published on

Published in: Technology
  • Be the first to comment

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

×