Metodologias Ageis

19.748 visualizações

Publicada em

Publicada em: Educação, Tecnologia
1 comentário
2 gostaram
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
19.748
No SlideShare
0
A partir de incorporações
0
Número de incorporações
112
Ações
Compartilhamentos
0
Downloads
496
Comentários
1
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Metodologias Ageis

  1. 1. Universidade Federal de Sergipe Departamento de Computação Metodologias de Desenvolvimento de Software Desenvolvimento de aplicações WEB utilizando XP, Scrum e Ruby on Rails Alunos: Rafael Mendonça França Marcos José Ribeiro Barrêto Vilnei Leite Bottari Leonardo Araujo Zoehler Brum Gabriel Viana Passos
  2. 2. Agenda Introdução Características Ágeis x RAD Exemplos de metodologias ágeis Scrum XP Ruby on Rails Trabalhos futuros
  3. 3. Introdução Aliança de Desenvolvimento Ágil de Software Fundada em 11-13/02/2001 17 pessoas envolvidas Metodologia Ágil Há Modelagem Há Documentação Há Planejamento Valoriza-se Individualidade e interações > processos e ferramentas Software funcional > documentação Colaboração do cliente > negociação de contrato Responder às mudanças > seguir um plano
  4. 4. Características Maior prioridade: satisfazer o cliente com entrega contínua e mais cedo possível de um software usável Mudanças de requerimentos são sempre bem vindas, mesmo quando for tarde Entregar freqüentemente um software que funcione Algumas semanas/meses Cliente e desenvolvedor trabalham juntos diariamente no projeto
  5. 5. Características Construir projetos com individualismo e motivação Proporcionar ambiente e suporte que os desenvolvedores precisam e confiar que eles farão o trabalho Conversa cara-a-cara Método mais efetivo e eficiente de se obter informação em uma equipe Um software funcionando é a medida de progresso Processos ágeis promovem desenvolvimento sustentável
  6. 6. Características Atenção contínua na excelência técnica e num bom design aumentam a agilidade Simplicidade Fácil de mudar A melhor arquitetura, requerimento e design surgem das equipes com auto-organização Em intervalos regulares, a equipe discute sobre um meio de aumentar a eficiência e então ajusta-se de acordo
  7. 7. Papéis? O Manifesto Ágil não define qualquer papel a ser exercido dentro de uma equipe Apenas princípios e valores com os quais se caracteriza uma metodologia como ágil
  8. 8. Ágeis x RAD Não admite protótipos Projetos são quebrados em funcionalidades No RAD o foco está em entregar todas as funcionalidades de uma vez Baixa qualidade antes para depois haver um melhoramento depois Equipes democráticas Membros das equipes são auto-gestores
  9. 9. Ágeis x RAD As práticas ágeis focam nos problemas e os resolvem o mais rápido possível Equipes se comunicam Equipes demonstram apenas trabalhos completos Equipes incluem também testadores e especialistas com experiência de usuário
  10. 10. Exemplos de Metodologias Ágeis Crystal Family FDD (Feature Driven Development) DSDM (Dynamic Systems Development Method) ASD (Adaptative Software Development) Scrum XP (eXtreme Programming)
  11. 11. Crystal Family Características: Os projetos sempre usam um ciclo de desenvolvimento com um tempo máximo de quatro meses, mas, preferivelmente, entre um e três meses; A ênfase é focada na comunicação e cooperação das pessoas; Não há limitação de qualquer prática de desenvolvimento, ferramentas ou produtos de trabalho; Provêem diretrizes padrão de política, produtos de trabalho, assuntos locais, ferramentas, padrões e papéis a serem seguidos no processo de desenvolvimento.
  12. 12. Feature Driven Development FDD Características Resultados úteis a cada duas semanas ou menos Blocos bem pequenos de funcionalidade valorizada pelo cliente, chamados quot;Featuresquot; Planejamento detalhado e guia para medição Rastreabilidade e relatórios precisos Monitoramento detalhado dentro do projeto, com resumos de alto nível para clientes e gerentes Fornece uma forma de saber, no início, se o plano e a estimativa são sólidos
  13. 13. ESTRUTURA FDD Fonte: http://www.heptagon.com.br/fdd-estrutura
  14. 14. Dynamic Systems Development Method DSDM Características do DSDM: Envolvimento ativo do Usuário Poder de decisão da equipe DSDM Entrega freqüente O critério mais importante para aceitação é adequação à tarefa requisitada Teste integrado ao ciclo de vida
  15. 15. Dynamic Systems Development Method DSDM Ciclo de vida DSDM: Estudo de Viabilidade - determina se o projeto é factível ou não, e se o DSDM é o método adequado. Estudo do Negócio - Nesta etapa são determinados os requisitos primários. Iteração para o Modelo Funcional e Iteração para Desenvolvimento - ocorre o desenvolvimento em si, sendo que na primeira é aprimorado o levantamento de requisitos, e na segunda, assegurada a qualidade dos protótipos gerados. Implementação - Esta fase engloba a entrega do produto e as atividades relacionadas.
  16. 16. Adaptative Software Development ASD Atuação principalmente em sistemas complexos Estimula o desenvolvimento com repetições e uma constante prototipação Ciclo de vida composto por três fases: Especulação: utilizada no lugar de planejamento Colaboração: realça a importância de trabalho de equipe Aprendizado: devido à necessidade para reconhecer e reagir a decisões erradas e o fato que os requisitos podem mudar durante o desenvolvimento.
  17. 17. Scrum O que é Scrum Papéis em Scrum Fases do Scrum
  18. 18. O que é Scrum Scrum é uma metodologia ágil para gestão e planejamento de software. Parte da premissa de que o processo de desenvolvimento é complexo e imprevisível Adota uma abordagem empírica em relação ao processo, em contraposição às metodologias tradicionais
  19. 19. Papéis em Scrum Project Owner : prioriza os requisitos do sistema, enumerados no chamado backlog ; Scrum Master : age como facilitador para a equipe de desenvolvimento Equipe Scrum : grupo responsável pelo cumprimento das tarefas definidas
  20. 20. Fases do Scrum Pré-game Planejamento Define um novo release através do backlog Estimativa de prazos e custos Arquitetura Revisão do backlog Estebelece como os itens do backlog serão implementados
  21. 21. Fases do Scrum Game Sprints Desenvolvimento : implementa os itens do backlog e realiza as mudanças necessárias Corte : cria uma versão executável daquilo que foi implementado Revisão : avalia o progresso do desenvolvimento, adicionando novos itens ao backlog Ajuste : consolida as informações adquiridas na revisão
  22. 22. Fases do Scrum Postgame Fechamento Prepara o produto desenvolvido para o release Testa o sistema Prepara a documentação para o usuário Promove treinamento
  23. 23. Fases do Scrum
  24. 24. XP (eXtreme Programming) Introdução Ciclo de Vida Papéis e responsabilidades Práticas
  25. 25. XP - Introdução É uma metodologia ágil de desenvolvimento de software criada por Kent Beck Prima pela qualidade do software desenvolvido XP recomenda que mudanças sejam prontamente “abraçadas”, aceitas sem relutância Simplicidade e um rápido feedback por parte dos clientes
  26. 26. XP - Introdução
  27. 27. XP - Ciclo de vida Exploração Planejamento Iterações para liberação Produção Manutenção Morte
  28. 28. XP - Ciclo de vida
  29. 29. XP - Ciclo de vida Exploração O cliente escreve histórias Cada história descreve uma função adicionada ao programa Equipe se familiariza com as técnicas, ferramentas, tecnologias e práticas que serão usadas no projeto As possíveis arquiteturas são exploradas, construindo- se um protótipo do sistema Esta fase dura o sufuciente para os programadores se familiarizarem com o projeto
  30. 30. XP - Ciclo de vida Planejamento É determinada a prioridade das histórias É feito um acordo das funções que irão constar na primeira liberação Não deve exceder duas semanas
  31. 31. XP - Ciclo de vida Iteração para liberação Inclui várias iterações do sistema antes da sua primeira liberação A programação que foi feita durante a fase de planejamento é quebrada em iterações sendo que cada iteração leva de um a quatro semanas para ser completada A primeira iteração cria um sistema base com as principais histórias O cliente decide as histórias que vão ser implementadas a cada iteração
  32. 32. XP - Ciclo de vida Produção Faz teste extra e checa o desempenho do sistema antes que este seja entregue ao cliente Podem existir mudanças Reduz as iterações para uma semana As idéias e sugestões são documentadas para implementação futura durante a fase de manutenção
  33. 33. XP - Ciclo de vida Manutenção Depois da primeira liberação, o XP deve manter o sistema rodando e introduzir novas iterações A velocidade pode desacelerar para evitar erros no sistema em produção Pode haver mudanças na equipe e na sua estrutura
  34. 34. XP - Ciclo de vida Morte Cliente não tem mais histórias a serem implementadas Sistema satisfaz as necessidades do cliente É feita a documentação do sistema, mas nenhuma linha de código é alterada Pode ocorrer quando o sistema não esteja exibindo as saídas corretas ou se tornou muito caro para desenvolvimento adicional
  35. 35. XP - Papéis e responsabilidades Cliente Verificador Fiscal (Tracker) Técnico Programador Consultor Gerente (Big Boss)
  36. 36. XP - Papéis e responsabilidades Cliente O cliente escreve as histórias e testes funcionais e decide quando cada requisito deve ser satisfeito Também determina a prioridade de implementação dos requisitos
  37. 37. XP - Papéis e responsabilidades Verificador O verificador ajuda o cliente a escrever os testes funcionais Os verificadores rodam testes funcionais regularmente, transmitem o resultado dos testes e mantém as ferramentas de testes
  38. 38. XP - Papéis e responsabilidades Fiscal (Tracker) Fornece feedback ao processo XP Traça as estimativas feitas pela equipe (por exemplo, estimativas de custo) e dá o feedback de quão exatas essas estimativas estão para melhorar as futuras Determina o progresso de cada iteração e avalia se o objetivo é alcançado com os recursos e o tempo fornecidos ou se qualquer mudança é necessária durante o processo
  39. 39. XP - Papéis e responsabilidades Técnico É a pessoa responsável pelo processo como um todo Quem exerce esse papel deve possuir um conhecimento amplo de toda a metodologia XP, conhecimento esse que deve habilitar o técnico a guiar os outros membros do time durante todo o processo
  40. 40. XP - Papéis e responsabilidades Programador Escreve os testes e programa mantendo o código do programa o mais simples e definido possível A primeira coisa que faz o processo XP obter sucesso é a comunicação e coordenação com os outros programadores e membros da equipe
  41. 41. XP - Papéis e responsabilidades Consultor É um membro externo que detém conhecimento técnico específico necessário Guia a equipe para resolver os problemas específicos
  42. 42. XP - Papéis e responsabilidades Gerente (BIG BOSS) Toma as decisões comunicando-se com a equipe de projeto para determinar a situação atual e para distinguir qualquer dificuldade ou deficiência no processo.
  43. 43. Práticas do XP Jogo de planejamento Posse coletiva Liberações em curto tempo Integração Continuada Metáfora 40 horas por semana Design simples Cliente no local Teste Padrões de código Reconstrução Área de trabalho aberta Programação em par Regras justas
  44. 44. XP - Práticas Jogo de planejamento Programadores estimam o esforço para implementar as histórias Clientes decidem o escopo e tempo dos releases Releases em curto tempo Produz-se rapidamente um sistema simples Atualizações freqüentes em ciclos curtos Metáforas Descrevem o funcionamento do sistema Facilitam a comunicação programador/cliente
  45. 45. XP - Práticas Design simples Satisfazer estritamente as necessidades Ênfase na agregação de valor Testes Dirigem o desenvolvimento do sistema Testes unitários Testes de aceitação Reconstrução O sistema é reestruturado visando sua melhoria contínua
  46. 46. XP - Práticas Programação em par Dois programadores juntos em uma mesma máquina Provê melhoria de qualidade, segundo experimentos Posse coletiva Qualquer parte do código pode ser alterada por qualquer programador Aumento na velocidade de desenvolvimento
  47. 47. XP - Práticas Integração continuada Novos blocos de código são integrados com freqüência ao sistema Mantém os progrmadores em sintonia Requer testes adequados 40 horas por semana Visa evitar erros por trabalho excessivo Cliente no local Comunicação constante com o cliente Diminuição do número de documentos
  48. 48. XP - Práticas Padrões de código Garante a clareza do código, auxiliando a posse coletiva Área de trabalho aberta Espaço amplo para se trabalhar Regras justas As equipes têm regras próprias a serem seguidas As regras são mutáveis, mas é preciso entrar num acordo
  49. 49. Ruby on Rails É um framework que torna fácil o desenvolvimento, a distribuição e a manutenção de aplicações Web Ele é uma das principais escolhas no desenvolvimento das ap Web 2.0 Todas as aplicações Rails são feitas usando o padrão arquitetural MVC (Model-View-Controler)
  50. 50. Ruby on Rails Todas as aplicações Rails vêm com suporte a testes integrados.O framework facilita o teste de aplicações e, como resultado, as aplicações Rails tendem a ser testadas As aplicações Rails são feitas na linguagem Ruby, uma linguagem moderna, de script orientada a objetos É fácil ler uma aplicação em Ruby, por ser uma linguagem concisa e que facilita a expressão de idéias no código
  51. 51. Ruby on Rails class Project < ActiveRecord::Base belongs_to :portfolio has_one :project_manager has_many :milestones validates_presence_of :name, :description validates_acceptance_of :non_disclosure_agreement validates_uniqueness_of :short_name end
  52. 52. Ruby on Rails Os projetos em Rails seguem uma dupla de conceitos chaves: DRY (Don't Repeat Yourself) Convenção sobre configuração Rails traz o que há de mais novo em padrões para desenvolvimento Web (Ajax, REST) O Rails facilita a distribuição e configuração das aplicações. As mudanças são geridas facilmente e podem ser feitas e desfeitas sem prejuízo algum para o desenvolvimento.
  53. 53. Ruby on Rails Algumas ferramentas do Rails: Migrations Fixtures Generator Templates Plugins
  54. 54. Caminhos Ágeis com o Rails
  55. 55. Caminhos Ágeis com Rails
  56. 56. Trabalhos Futuros SCRUM, XP e certificações existentes (MPS.BR, CMMI, PMBOK, etc) Testar, validar e aperfeiçoar a metodologia proposta na Empresa Júnior de Informática da UFS (Softeam Jr.) utilizando o Ruby on Rails como uma das ferramentas de desenvolvimento de software
  57. 57. quot;Try and fail, but not fail on tryquot; Bons Caminhos

×