Your SlideShare is downloading. ×
  • Like
  • Save
Metodologias de desenvolvimento - Waterfall vs Agile
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Metodologias de desenvolvimento - Waterfall vs Agile

  • 3,092 views
Published

Comparação entre o modelo waterfall e agile, adicionando uma visão pessoal sobre o que é importante no desenvolvimento de software.

Comparação entre o modelo waterfall e agile, adicionando uma visão pessoal sobre o que é importante no desenvolvimento de software.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,092
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
6

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. Metodologias de Desenvolvimento
  • 2. Um projeto de software é considerado um sucesso.
  • 3. Um projeto de software é considerado um sucesso. Quando...
  • 4. Resolve o problema Um projeto de software é considerado um sucesso. Quando...
  • 5. Resolve o problema É facil de manter e evoluir Um projeto de software é considerado um sucesso. Quando...
  • 6. Resolve o problema É facil de manter e evoluir Menor custo e prazo possível Um projeto de software é considerado um sucesso. Quando...
  • 7. Metodologias de desenvolvimento
  • 8. Waterfall
  • 9. Baseado no paper publicado por Winston Royce em 1970 Waterfall
  • 10. Baseado no paper publicado por Winston Royce em 1970 Waterfall Que foi mal interpretado!!!
  • 11. Waterfall Defeituoso
  • 12. Waterfall X Defeituoso
  • 13. ARRISCADO & CONVITE A FALHAS Waterfall
  • 14. Waterfall
  • 15. Waterfall
  • 16. Waterfall
  • 17. Waterfall
  • 18. Waterfall Até hoje!!!
  • 19. Waterfall Até hoje!!!
  • 20. Waterfall Abordagem clássica e linear Uma fase de cada vez Requisitos bem definidos / Big design up front Cada fase do desenvolvimento é documentada Características
  • 21. Waterfall Gerenciamento e controle Prioridades
  • 22. Waterfall Controle e documentação 5 fases rígidas formam o processo O usuário se envolve apenas no início Princípios
  • 23. Waterfall Progresso Relatórios e gráficos
  • 24. Agile
  • 25. Definido em 1974 por Edmons Agile
  • 26. Definido em 1974 por Edmons Agile Evoluído em 1990
  • 27. Agile Evoluído em 1990 Definido em 1974 por Edmons
  • 28. Agile Evoluído em 1990 Definido em 1974 por Edmons Manifesto ágil em 2001
  • 29. Manifesto ágil Agile Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
  • 30. Manifesto ágil Indivíduos e interações entre eles mais que processos e ferramentas; Agile Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
  • 31. Manifesto ágil Indivíduos e interações entre eles mais que processos e ferramentas; Software em funcionamento mais que documentação abrangente; Agile Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
  • 32. Manifesto ágil Indivíduos e interações entre eles mais que processos e ferramentas; Software em funcionamento mais que documentação abrangente;  Colaboração com o cliente mais que negociação de contratos; Agile Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
  • 33. Manifesto ágil Indivíduos e interações entre eles mais que processos e ferramentas; Software em funcionamento mais que documentação abrangente;  Colaboração com o cliente mais que negociação de contratos;  Responder a mudanças mais que seguir um plano. Agile Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
  • 34. Manifesto ágil Indivíduos e interações entre eles mais que processos e ferramentas; Software em funcionamento mais que documentação abrangente;  Colaboração com o cliente mais que negociação de contratos;  Responder a mudanças mais que seguir um plano. Agile Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda
  • 35. Agile Nasa Microsoft Yahoo Google IBM Siemens Nokia BBC Salesforce.com Utilizado por Globo.com Petrobras Buscapé OI Embraer SERPRO Chemtech DTM Etc.
  • 36. Agile Envolvimento do usuário a cada iteração Permite novas ideias Entregas contínuas Características
  • 37. Agile Princípios
  • 38. Agile Satisfação do usuário com entregas rápidas e contínuas que gerem valor Princípios
  • 39. Agile Satisfação do usuário com entregas rápidas e contínuas que gerem valor Aceitação de mudanças de requisitos, pois aumentam a vantagem competitiva Princípios
  • 40. Agile Satisfação do usuário com entregas rápidas e contínuas que gerem valor Aceitação de mudanças de requisitos, pois aumentam a vantagem competitiva Trabalho em equipe Princípios
  • 41. Agile Satisfação do usuário com entregas rápidas e contínuas que gerem valor Aceitação de mudanças de requisitos, pois aumentam a vantagem competitiva Trabalho em equipe A melhor forma de transmitir informação é cara a cara Princípios
  • 42. Agile Satisfação do usuário com entregas rápidas e contínuas que gerem valor Aceitação de mudanças de requisitos, pois aumentam a vantagem competitiva Trabalho em equipe A melhor forma de transmitir informação é cara a cara As melhores arquiteturas, requisitos e projetos emergem de equipes auto- organizadas Princípios
  • 43. Agile Satisfação do usuário com entregas rápidas e contínuas que gerem valor Aceitação de mudanças de requisitos, pois aumentam a vantagem competitiva Trabalho em equipe A melhor forma de transmitir informação é cara a cara As melhores arquiteturas, requisitos e projetos emergem de equipes auto- organizadas Atenção contínua à excelência técnica, permitindo aumentar a agilidade Princípios
  • 44. Agile Satisfação do usuário com entregas rápidas e contínuas que gerem valor Aceitação de mudanças de requisitos, pois aumentam a vantagem competitiva Trabalho em equipe A melhor forma de transmitir informação é cara a cara As melhores arquiteturas, requisitos e projetos emergem de equipes auto- organizadas Atenção contínua à excelência técnica, permitindo aumentar a agilidade Comunicação Princípios
  • 45. Agile Satisfação do usuário com entregas rápidas e contínuas que gerem valor Aceitação de mudanças de requisitos, pois aumentam a vantagem competitiva Trabalho em equipe A melhor forma de transmitir informação é cara a cara As melhores arquiteturas, requisitos e projetos emergem de equipes auto- organizadas Atenção contínua à excelência técnica, permitindo aumentar a agilidade Comunicação Melhoria contínua Princípios
  • 46. Agile Progresso Software funcionando é a principal forma de medir o progresso
  • 47. http://youtu.be/PHS-ycbRwqI
  • 48. Diferenças
  • 49. Diferenças
  • 50. Diferenças Waterfall Agile Envolvimento do usuário Apenas no início do processo A cada iteração Atitude perante mudanças Não permite A cada iteração Requisitos Bem definidos Definidos ao longo do processo Risco Alto custo de mudança Não causam grande impacto
  • 51. Diferenças Waterfall Agile Envolvimento do usuário Apenas no início do processo A cada iteração Atitude perante mudanças Não permite A cada iteração Requisitos Bem definidos Definidos ao longo do processo Risco Alto custo de mudança Não causam grande impacto
  • 52. Diferenças Waterfall Agile Envolvimento do usuário Apenas no início do processo A cada iteração Atitude perante mudanças Não permite A cada iteração Requisitos Bem definidos Definidos ao longo do processo Risco Alto custo de mudança Não causam grande impacto
  • 53. Conclusão
  • 54. Waterfall define requisitos detalhados. Com alto custo de mudança. É utilizado em projetos de baixa incerteza. Conclusão
  • 55. Waterfall define requisitos detalhados. Com alto custo de mudança. É utilizado em projetos de baixa incerteza. Conclusão Agile define requisitos a cada iteração permitindo mudanças. Valoriza a comunicação. Utilizado em projetos de alta incerteza.
  • 56. Nossa experiência diz
  • 57. Nossa experiência diz Escopo de software não são requisitos detalhados. Escopo são os problemas que o software pretende resolver!
  • 58. Nossa experiência diz Escopo de software não são requisitos detalhados. Escopo são os problemas que o software pretende resolver! Requisitos mundam!
  • 59. Nossa experiência diz Escopo de software não são requisitos detalhados. Escopo são os problemas que o software pretende resolver! Requisitos mundam! Papel e diagramas aceitam qualquer coisa!
  • 60. Nossa experiência diz Escopo de software não são requisitos detalhados. Escopo são os problemas que o software pretende resolver! Requisitos mundam! Papel e diagramas aceitam qualquer coisa! Software funcionando é o melhor artefato para levantar requisitos!
  • 61. Nossa experiência diz
  • 62. Nossa experiência diz Codificação é a atividade que deve ser valorizada no desenvolvimento de software
  • 63. Nossa experiência diz Codificação é a atividade que deve ser valorizada no desenvolvimento de software Afinal, o código é o elemento mais próximo do que queremos de fato
  • 64. Nossa experiência diz Codificação é a atividade que deve ser valorizada no desenvolvimento de software Afinal, o código é o elemento mais próximo do que queremos de fato Solucionar problemas de negócio!
  • 65. O código deve ter forma
  • 66. O código deve ter forma O código documenta o projeto!
  • 67. O código deve ter forma O código documenta o projeto! Orientação a objetos: Alta coesão / Baixo acoplamento
  • 68. O código deve ter forma O código documenta o projeto! Orientação a objetos: Alta coesão / Baixo acoplamento Design Patterns (Padrões)
  • 69. O código deve ter forma O código documenta o projeto! Orientação a objetos: Alta coesão / Baixo acoplamento Design Patterns (Padrões) TDD (test driven development) - Testes, teste e mais testes!
  • 70. O código deve ter forma O código documenta o projeto! Orientação a objetos: Alta coesão / Baixo acoplamento Design Patterns (Padrões) TDD (test driven development) - Testes, teste e mais testes! Fazer mais com menos código (frameworks e abstrações fortes)
  • 71. O código deve ter forma O código documenta o projeto! Orientação a objetos: Alta coesão / Baixo acoplamento Design Patterns (Padrões) TDD (test driven development) - Testes, teste e mais testes! Fazer mais com menos código (frameworks e abstrações fortes) Isso garante a manutenção do projeto