APS - RAD x Ágeis

2.065 visualizações

Publicada em

Apresentação sobre Metodologias ágeis x Metodologias Rápidas (RAD).

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
2.065
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
65
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Metodologias de Desenvolvimento de Software? São estruturas conceituais para reger projetos de engenharia de software . Metodologia: São etapas a cumprir em um determinado processo. No caso, processo de desenvolvimento de software. Metodologias tradicionais? Metodologias baseadas nos processos clássicos ou até nos evolucionários, são as metodologias não ágeis. Essas metodologias tradicionais se baseavam na documentação do software e no seguir rigidamente o processo.
  • Metodologias de Desenvolvimento de Software? São estruturas conceituais para reger projetos de engenharia de software . Metodologia: São etapas a cumprir em um determinado processo. No caso, processo de desenvolvimento de software. Metodologias tradicionais? Metodologias baseadas nos processos clássicos ou até nos evolucionários, são as metodologias não ágeis. Essas metodologias tradicionais se baseavam na documentação do software e no seguir rigidamente o processo.
  • Metodologias de Desenvolvimento de Software? São estruturas conceituais para reger projetos de engenharia de software . Metodologia: São etapas a cumprir em um determinado processo. No caso, processo de desenvolvimento de software. Metodologias tradicionais? Metodologias baseadas nos processos clássicos ou até nos evolucionários, são as metodologias não ágeis. Essas metodologias tradicionais se baseavam na documentação do software e no seguir rigidamente o processo.
  • Nós chamamos de CAOS uma situação perturbadora e desanimadora. Uma situação onde uma empresa utilizando um processo definido ou não trabalha de forma a obter muitos riscos em seus projetos e muitas vezes obtendo um custo muito alto, e ainda sim não conseguindo manter um projeto de boa qualidade interna e externa.
  • APS - RAD x Ágeis

    1. 1. Grupo: Felipe de Mesquita Philippe Norbert Silvio Carréra
    2. 2. <ul><ul><li>RAD </li></ul></ul><ul><ul><li>Prototipação </li></ul></ul><ul><ul><li>Metodologias Ágeis </li></ul></ul><ul><ul><li>XP </li></ul></ul><ul><ul><li>SCRUM </li></ul></ul><ul><ul><li>Pros e Cons de RAD e Ágeis </li></ul></ul><ul><ul><li>Agradecimentos e Perguntas. </li></ul></ul>
    3. 3. <ul><ul><li>Ele surgiu para “combater” as metodologias procedurais dos anos 70. </li></ul></ul><ul><ul><li>Criado por James Martin, nos anos 80. </li></ul></ul>James Martin
    4. 4. <ul><ul><li>Pequenos Ciclos ou TimeBoxes. </li></ul></ul><ul><ul><li>Uso de ferramentas CASE (Computer Aided Software Engineering). </li></ul></ul><ul><ul><li>Construção de protótipos rapidamente. </li></ul></ul><ul><ul><li>Iterações </li></ul></ul>
    5. 5. Protótipos são modelos construídos para simular a aparência e funcionalidade de um produto em desenvolvimento.
    6. 6. 1. Identificar Requerimentos Básicos 2.Desenvolver Protótipo Inicial        3. Review 4. Melhora do Protótipo
    7. 7. Horizontal Foco na interação com usuário Vertical Foco em funções específicas
    8. 8. 6.1 Protótipo Descartado <ul><ul><li>Feito nas primeiras fases de desenvolvimento. </li></ul></ul><ul><ul><li>Feito sem formalidade e rápido. </li></ul></ul><ul><ul><li>Clientes tem feedback rápido dos requerimentos. </li></ul></ul><ul><ul><li>Normalmente usado para desenvolvimento de interface </li></ul></ul>
    9. 9. Define requerimentos iniciais Design do protótipo descartado Cliente usa protótipo e levanta requerimentos Repete fase 2 se necessário Define requerimentos finais Faz o produto real
    10. 10. 6.2 Protótipo Evolutivo <ul><ul><li>Desenvolve-se um protótipo robusto. </li></ul></ul><ul><ul><li>São sistemas funcionais, embora incompletos servem como base ao projeto final. </li></ul></ul><ul><ul><li>Desenvolvedores podem focar em partes que conhecem do sistema. </li></ul></ul><ul><ul><li>Feito com certa formalidade. </li></ul></ul>Protótipo com fluxo de telas Adicionado Tratamento de Colisão Adicionado Sistema de Fade-in/out
    11. 11. 6.3 Protótipo Incremental <ul><ul><li>O projeto final é o conjunto de vários protótipos. </li></ul></ul>Jogo Final Protótipo de Gerenciador de Telas Protótipo de Gerenciador de Som Protótipo de Tratamento de Colisões Protótipo de tratamento de controle
    12. 12. <ul><ul><li>Projetos de Construção Civil </li></ul></ul><ul><ul><li>São geralmente construídos como planejados </li></ul></ul><ul><ul><li>Clientes acompanham a evolução </li></ul></ul><ul><ul><li>Se algo dá errado, faz-se um relatório </li></ul></ul><ul><ul><li>Projetos de Software </li></ul></ul><ul><ul><li>Precisam suportar mudanças nas regras de negócio </li></ul></ul><ul><ul><li>Clientes só vêem algo funcionando perto do fim ou em prazos longos </li></ul></ul><ul><ul><li>Se algo dá errado, se esquece ou mascara o erro </li></ul></ul>3/26/2011 RAD x Ágeis
    13. 13. <ul><li>Algumas empresas adotam metodologias de desenvolvimento e práticas extremamente formais e controladoras, porém ainda não conseguem obter qualidade. </li></ul><ul><ul><li>Por quê? </li></ul></ul><ul><ul><ul><li>Pouca preocupação com as pessoas e a interação entre elas </li></ul></ul></ul><ul><ul><ul><li>Pouca comunicação com o cliente </li></ul></ul></ul><ul><ul><ul><li>Custos muito altos </li></ul></ul></ul><ul><ul><ul><li>Excesso de formalismo </li></ul></ul></ul><ul><ul><li>Qual a consequência disso? </li></ul></ul><ul><ul><ul><li>Alta rotatividade </li></ul></ul></ul><ul><ul><ul><li>No fim o software não serve mais </li></ul></ul></ul><ul><ul><ul><li>Projeto cancelado </li></ul></ul></ul><ul><ul><ul><li>Prazos estourados </li></ul></ul></ul>3/26/2011 RAD x Ágeis
    14. 14. Algumas empresas adotam metodologias de desenvolvimento e práticas extremamente Além disso muitas empresas vivem em uma situação de total descontrole e falta de qualidade, e não são nada ágeis, vivem o ... 3/26/2011 RAD x Ágeis
    15. 15. <ul><ul><li>Situação perturbadora, desmotivante; </li></ul></ul><ul><ul><li>Utilizando processo definido ou não; </li></ul></ul><ul><ul><li>Altos riscos nos projetos; </li></ul></ul><ul><ul><li>Custos muito altos; </li></ul></ul><ul><ul><li>Projetos sem boa qualidade interna e externa. </li></ul></ul><ul><li>Mas esse problema não é novo, em 2001, 17 caras lançaram o ... </li></ul>3/26/2011 RAD x Ágeis
    16. 16. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick <ul><li>O que é isso? </li></ul><ul><ul><li>Um manifesto que criticava algumas mitos/práticas da engenharia de software e da gerência de projetos adotadas por abordagens tradicionalistas </li></ul></ul><ul><ul><li>Foi assinado por 17 pessoas envolvidas com desenvolvimento de software, dentre eles consultores e programadores experientes </li></ul></ul>3/26/2011 RAD x Ágeis
    17. 17. <ul><ul><li>Indivíduos e interação entre eles mais que processos e ferramentas </li></ul></ul><ul><ul><li>Software em funcionamento mais que documentação abrangente </li></ul></ul><ul><ul><li>Colaboração com o cliente mais que negociação de contratos </li></ul></ul><ul><ul><li>Responder a mudanças mais que seguir um plano </li></ul></ul>3/26/2011 RAD x Ágeis
    18. 18. <ul><li>12 princípios por traz do Manifesto Ágil </li></ul><ul><ul><li>Satisfazer o cliente </li></ul></ul><ul><ul><li>As mudanças são bem vindas </li></ul></ul><ul><ul><li>Entrega periódica de funcionalidade </li></ul></ul><ul><ul><li>Todos juntos </li></ul></ul><ul><ul><li>Indivíduos Motivados </li></ul></ul><ul><ul><li>Conversas face a face </li></ul></ul><ul><ul><li>Medida primária é o software trabalhado </li></ul></ul><ul><ul><li>Manter um ritmo constante sempre </li></ul></ul><ul><ul><li>Atenção contínua, excelência técnica e bom projeto </li></ul></ul><ul><ul><li>Simplicidade </li></ul></ul><ul><ul><li>Equipes auto-organizáveis ou auto-gerenciáveis </li></ul></ul><ul><ul><li>Reflexão de melhoria regularmente </li></ul></ul>3/26/2011 RAD x Ágeis
    19. 19. <ul><li>XP – eXtreme Programming </li></ul><ul><li>SCRUM </li></ul><ul><li>LEAN </li></ul><ul><li>CRYSTAL </li></ul><ul><li>FDD </li></ul><ul><li>... </li></ul>3/26/2011 RAD x Ágeis
    20. 20. Começou a engatinhar 1987 e a se estruturar em 1996 com o projeto C3 da Chrysler Criado pro Kent Beck, que utilizou pela primeira vez em conjunto as práticas que formam a estrutura do Extreme Programming nesse projeto da Chrysler “ Jeito leve, eficiente, de baixo risco, flexível, previsível, científico e divertido de desenvolver software” – Kent Beck 3/26/2011 RAD x Ágeis
    21. 21. <ul><ul><li>Valores: </li></ul></ul><ul><ul><ul><li>Comunicação </li></ul></ul></ul><ul><ul><ul><li>Simplicidade </li></ul></ul></ul><ul><ul><ul><li>Feedback </li></ul></ul></ul><ul><ul><ul><li>Coragem </li></ul></ul></ul><ul><ul><li>Abordagem Incremental </li></ul></ul>3/26/2011 RAD x Ágeis
    22. 22. <ul><ul><li>Refatorar </li></ul></ul><ul><ul><li>Propriedade Coletiva </li></ul></ul><ul><ul><li>Integração Contínua </li></ul></ul><ul><ul><li>40 horas semanais de trabalho </li></ul></ul><ul><ul><li>Cliente presente </li></ul></ul><ul><ul><li>Padronização do Código </li></ul></ul><ul><ul><li>Planejamento </li></ul></ul><ul><ul><li>Entregas Frequêntes </li></ul></ul><ul><ul><li>Metáfora </li></ul></ul><ul><ul><li>Projeto Simples </li></ul></ul><ul><ul><li>Testes </li></ul></ul><ul><ul><li>Programação em pares </li></ul></ul>3/26/2011 RAD x Ágeis
    23. 23. <ul><li>Por quê? </li></ul><ul><ul><li>Gasta-se tempo fazendo coisas inúteis que servem para aumentar o escopo, o tempo e o custo do projeto </li></ul></ul><ul><li>Como? </li></ul><ul><ul><li>Triando o que é essencial, importante e desejável </li></ul></ul><ul><ul><li>Assumindo a regra “80-20” </li></ul></ul><ul><ul><ul><li>Entregando 80% dos benefícios </li></ul></ul></ul>3/26/2011 RAD x Ágeis
    24. 24. <ul><li>Como? </li></ul><ul><ul><li>Definição de histórias </li></ul></ul><ul><ul><li>Valor de negócio das histórias </li></ul></ul><ul><ul><li>Definição de releases </li></ul></ul><ul><ul><li>Estimativa com base nas experiências anteriores </li></ul></ul><ul><ul><li>Observação de riscos </li></ul></ul><ul><ul><li>Medições de progresso </li></ul></ul>3/26/2011 RAD x Ágeis
    25. 25. <ul><li>Consiste em colocar o sistema em produção com freqüência, em prazos curtos, normalmente de dois ou três meses. </li></ul><ul><li>Objetivos: </li></ul><ul><ul><li>Feedbacks rápidos do cliente e para o cliente </li></ul></ul><ul><ul><li>Aceitação de mudanças rápidas e sem burocracia </li></ul></ul>3/26/2011 RAD x Ágeis
    26. 26. <ul><li>Utilizam as metáforas para inserir a estrutura conceitual do negócio. </li></ul><ul><li>Objetivos: </li></ul><ul><ul><li>Facilidade de entendimento e compreensão </li></ul></ul><ul><ul><li>Envolvidos compreendem o que se quer, mesmo não dominando a linguagem do negócio. </li></ul></ul>3/26/2011 RAD x Ágeis
    27. 27. <ul><li>Projete um software do jeito que o usuário espera: </li></ul><ul><ul><li>Primeiro que funcione </li></ul></ul><ul><ul><li>E funcione corretamente </li></ul></ul><ul><ul><li>Que seja fácil de utilizar (modelo mental coerente) </li></ul></ul><ul><ul><li>E que possa evoluir com o tempo </li></ul></ul>3/26/2011 RAD x Ágeis
    28. 28. <ul><ul><li>Partindo do pressuposto que achar as causas do bug é mais difícil e demorado que corrigir </li></ul></ul><ul><ul><li>Então vamos evitar o problema </li></ul></ul><ul><ul><li>Evitar problema é mais inteligente que resolver </li></ul></ul><ul><ul><li>TDD (Test Driven Development) consiste em escrever um mecanismo de teste automatizado antes de codificar cada história e cada método do sistema (BECK, 2000) </li></ul></ul>3/26/2011 RAD x Ágeis
    29. 29. “ O XP se concentra sobretudo em dois tipos de testes: o teste de unidade e o teste de aceitação. O primeiro tenta assegurar que cada componente do sistema funcione corretamente. O segundo procura testar a interação entre os componentes, as quais dão origem às funcionalidades.” [BECK, 2000 apud TELLES, 2005] método do sistema (BECK, 2000) 3/26/2011 RAD x Ágeis
    30. 30. <ul><ul><li>Dois programadores continuamente colaborando no mesmo projeto, algoritmo, código e teste. </li></ul></ul><ul><ul><li>Diminui erros de código, permite a refatoração instantânea, aprendizado contínuo, etc. </li></ul></ul>3/26/2011 RAD x Ágeis
    31. 31. <ul><li>A “refatoração é o processo de fazer mudanças em um código existente e funcional sem alterar seu comportamento externo. [...]” [ASTELS, 2003 apud TELLES,2005 </li></ul><ul><li>Objetivos: </li></ul><ul><ul><li>Enxugar o código (Tornar simples e claro) </li></ul></ul><ul><ul><li>Melhor a eficiência do código </li></ul></ul><ul><ul><li>Minimizar chances de introduzir bugs </li></ul></ul><ul><li>Garantias </li></ul><ul><ul><li>Melhoria interna contínua </li></ul></ul>3/26/2011 RAD x Ágeis
    32. 32. O desenvolvedor tem acesso a todo o código O código é de todos os desenvolvedores e qualquer um pode melhorar até aquilo que não fez As alterações podem causar erros. Por segurança, é indicado adotar essa prática apenas quando se tem testes de regressão automatizados 3/26/2011 RAD x Ágeis
    33. 33. <ul><li>Os pares trabalham de forma isolada, mas integram o que produzem diversas vezes ao dia. </li></ul><ul><li>Objetivos: </li></ul><ul><ul><li>Identificar conflitos cedo, para evitar futuras falhas de integração </li></ul></ul><ul><li>Consequência: </li></ul><ul><ul><li>Identificação quase que instantânea de conflito, já que se produz pouco código em poucas horas </li></ul></ul>3/26/2011 RAD x Ágeis
    34. 34. 3/26/2011 <ul><ul><li>Hora extra é exceção </li></ul></ul><ul><ul><li>Em atividade de 40 horas semanais já ocorre a diminuição do fator foco </li></ul></ul><ul><ul><li>Pressões não aumentam o fator foco, pelo contrário diminuem </li></ul></ul>RAD x Ágeis
    35. 35. <ul><li>“ O melhor e mais participativo cliente não será capaz de obter o software desejado se a equipe de desenvolvimento não implementar corretamente o que é pedido e a melhor equipe não será capaz de produzir o software certo se o cliente não for capaz de especificá-lo adequadamente e prover feedback ao longo do projeto.” [TELLES, 2005] </li></ul><ul><li>Junte-os e terá: </li></ul><ul><ul><li>Feedbacks mais rápidos </li></ul></ul><ul><ul><li>Mudanças rápidas sem burocracia </li></ul></ul>3/26/2011 RAD x Ágeis
    36. 36. <ul><li>“ O melhor e mais participativo cliente não será capaz de obter o software desejado se a equipe de desenvolvimento não implementar corretamente o que é pedido e a melhor equipe não será capaz de produzir o software certo se o cliente não for capaz de especificá-lo adequadamente e prover feedback ao longo do projeto.” [TELLES, 2005] </li></ul><ul><li>Junte-os e terá: </li></ul><ul><ul><li>Feedbacks mais rápidos </li></ul></ul><ul><ul><li>Mudanças rápidas sem burocracia </li></ul></ul>3/26/2011 RAD x Ágeis
    37. 37. <ul><ul><li>O nome é originado da organização de uma equipe de Rugby para o reinicio da partida. </li></ul></ul><ul><ul><li>Formalizado e implantado no desenvolvimento de software em 1995 por Ken Shwaber </li></ul></ul><ul><ul><li>A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software </li></ul></ul>3/26/2011 RAD x Ágeis
    38. 38. <ul><ul><li>O que é de fato? </li></ul></ul><ul><ul><ul><li>É um framework de desenvolvimento de produto, sobre um ciclo de vida interativo e incremental </li></ul></ul></ul><ul><ul><li>Objetivos: </li></ul></ul><ul><ul><ul><li>Acompanhamento contínuo </li></ul></ul></ul><ul><ul><ul><li>Iterações curtas </li></ul></ul></ul><ul><ul><ul><li>Retorno mais rápido </li></ul></ul></ul>3/26/2011 RAD x Ágeis
    39. 39. <ul><ul><li>Quais são os papeis envolvidos? </li></ul></ul><ul><ul><ul><li>Product Owner (PO) </li></ul></ul></ul><ul><ul><ul><li>Scrum Team </li></ul></ul></ul><ul><ul><ul><li>Scrum Master </li></ul></ul></ul>3/26/2011 RAD x Ágeis
    40. 40. <ul><ul><li>Conhece o produto e as necessidades do cliente </li></ul></ul><ul><ul><li>Representa o cliente </li></ul></ul><ul><ul><li>Define os requisitos do produto, bem como sua importância e urgência </li></ul></ul><ul><ul><li>É responsável pelo retorno do investimento </li></ul></ul>3/26/2011 RAD x Ágeis
    41. 41. <ul><ul><li>É o líder servidor </li></ul></ul><ul><ul><li>Responsável por remover os impedimentos do time </li></ul></ul><ul><ul><li>Por remover interferências externas </li></ul></ul><ul><ul><li>E por garantir o uso correto do Scrum </li></ul></ul><ul><ul><li>Ensina Scrum aos envolvidos </li></ul></ul>3/26/2011 RAD x Ágeis
    42. 42. <ul><ul><li>Fazem parte do Scrum team todos os desenvolvedores, arquitetos, analistas, ... que participam do projeto </li></ul></ul><ul><ul><li>O time é auto-gerenciável e multifuncional ou multidisciplinar (pessoas com diferentes aptidões) </li></ul></ul><ul><ul><li>Decidem junto com o PO o que entra no Sprint </li></ul></ul><ul><ul><li>E são responsáveis pelas estimativas de esforço </li></ul></ul>3/26/2011 RAD x Ágeis
    43. 43. <ul><ul><li>São elas: </li></ul></ul><ul><ul><ul><li>Planejamentos de Sprint </li></ul></ul></ul><ul><ul><ul><li>Revisões de Sprint </li></ul></ul></ul><ul><ul><ul><li>Retrospectivas de Sprint </li></ul></ul></ul><ul><ul><ul><li>Reuniões diárias </li></ul></ul></ul>3/26/2011 RAD x Ágeis
    44. 44. <ul><ul><li>Product Backlog </li></ul></ul><ul><ul><ul><li>Lista priorizada de requisitos (Lista mutável) </li></ul></ul></ul><ul><ul><li>Sprint Backlog </li></ul></ul><ul><ul><ul><li>Itens que serão feitos na Sprint (Lista não mutável) </li></ul></ul></ul><ul><ul><li>Burndown Charts </li></ul></ul><ul><ul><ul><li>O trabalho acumulado ou realizado (atualizados diariamente durante um Sprint) </li></ul></ul></ul>3/26/2011 RAD x Ágeis
    45. 45. 3/26/2011 RAD x Ágeis
    46. 46. RAD x Ágeis 3/26/2011
    47. 47. <ul><ul><li>Scrum não define técnicas de Engenharia de Software </li></ul></ul><ul><ul><li>Foi construído inicialmente para o desenvolvimento de software </li></ul></ul><ul><ul><li>Porém, é um framework para gerenciamento do desenvolvimento de um produto </li></ul></ul><ul><ul><li>Por isso uma parceria de sucesso no desenvolvimento de software é: </li></ul></ul><ul><ul><ul><li>SCRUM + XP (Algumas práticas ) </li></ul></ul></ul>3/26/2011 RAD x Ágeis
    48. 48. <ul><ul><li>SCRUM é uma excelente alternativa para empresas que estão no CAOS </li></ul></ul><ul><ul><li>É interessante para equipes pequenas, onde a comunicação possa funcionar de forma tranquila </li></ul></ul><ul><ul><li>XP define boas práticas que contribuem para uma boa comunicação e para a prevenção de problemas </li></ul></ul><ul><ul><li>Ambas se preocupam e melhoria contínua da qualidade, através de avaliação contínua do trabalho e do processo </li></ul></ul>3/26/2011 RAD x Ágeis
    49. 49. “ Que se move ou age com muita facilidade .”
    50. 50. “ Que se move depressa, com muita velocidade”
    51. 51. Metodologias Ágeis Metodologias RAD Alto Controle por parte dos Gestores Reutilização de Componentes Reduz o tempo de entrega da 1ª versão Tempo de Desenvolvimento Reduzido Planejamento Alta Interação com o Usuário Respostas Rápidas a Mudanças
    52. 52. Metodologias Ágeis Metodologias RAD Menor Controle dos Custos Reutilização não garante eficiência Baixo Custo Pode Comprometer Qualidade Sem Planejamento
    53. 53. <ul><ul><li>Aplicação puder ser modularizada </li></ul></ul><ul><ul><li>Funções devem ser desenvolvidas em até 3 meses </li></ul></ul>
    54. 54. <ul><ul><li>Tenta diminuir o retrabalho. </li></ul></ul><ul><ul><li>Simplicidade. (Códigos Simples, porém EFICIENTES.) </li></ul></ul>

    ×