Introdução às Metodologias Ágeis de Desenvolvimento

600 visualizações

Publicada em

Apresentação base para o Workshop "Introdução às Metodologias Ágeis de Desenvolvimento" ministrado na FET@AGE - FUMEC

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
600
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
6
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Introdução às Metodologias Ágeis de Desenvolvimento

  1. 1. Introdução às Metodologias Ágeis De Desenvolvimento Métodos ÁgeisJerry Medeiros
  2. 2. Minha avó me convidou paravisitá-la e almoçaro salpicão que eu adoro nesse sábado às 13h
  3. 3. O que ela deve fazer?•Ela irá acordar às 8h;•Banho até as 8h30min;•Café da manhã até as 9h;•Consulta médica às 10h;•Supermercado às 11h;•Voltará para a casa às 12h;• Almoço pronto às 13h.
  4. 4. E se...•O ônibus atrasar?•O médico atrasar?•Não tiver os ingredientes nosupermercado ?
  5. 5. E se...Meu netinho, você seimporta de eu fazeruma sopinha delegumes em vez dosalpicão ?
  6. 6. E se...Meu netinho, você seimporta de eu fazeruma sopinha delegumes em vez dosalpicão ?
  7. 7. Objetivos Principais Reencontrar minha vovó Matar a fome
  8. 8. Escopo Variável •Sempre há um escopo •Teoricamente não será alterado durante o projeto, porque existe um contrato •Existe uma ilusão de previsibilidade
  9. 9. O cliente acredita que: •O escopo é previsível; •O prazo é previsível; •O custo é previsível;
  10. 10. A equipe acredita que sabe: •O que tem que fazer; •Em quanto tempo fará; •Quanto vai ganhar; •Quais recursos vai precisar.
  11. 11. Então não há problema !! Tranquilo ?
  12. 12. Só que..... “ O Cliente sabe o que quer desde o início do projeto.
  13. 13. Só que..... “ A equipe consegue estimar o tempo exato necessário para a produção.
  14. 14. O escopo não é fixo •Variáveis do Projeto •Prazo •Escopo •Custo •Qualidade
  15. 15. Priorização do Escopo Princípio de Pareto se aplica: 20% das funcionalidades geram 80% do valor
  16. 16. Funcionalidades nunca ou raramenteutilizadas 64%
  17. 17. 64% de desperdício de tempo e dinheiro
  18. 18. Resultado• Projetos que falha;• A maioria das funcionalidades nunca seráusada pelo usuário;• Nos projetos com sucesso, apenas 42% dasfuncionalidades previstas no início estavam noproduto final;
  19. 19. Como é feito
  20. 20. Como é feito
  21. 21. Como é feito
  22. 22. O Cliente precisa de Resultado Sempre entregar valor
  23. 23. Entender as Necessidades
  24. 24. Mudança de Paradigma
  25. 25. Como Mudar essa situação ?
  26. 26. Manifesto ÁgilEm 2001, dezessete especialistas em processos dedesenvolvimento de software estabeleceram princípioscomuns compartilhados por diferentes métodos ecriaram o Manifesto Ágil.
  27. 27. Como Mudar essa situação ?
  28. 28. Manifesto Ágil“ Estamos descobrindo maneiras melhores de desenvolver software fazendo‐o nós mesmos e ajudando outros a fazê‐lo. Através desse trabalho, passamos a valorizar:
  29. 29. Valores Indivíduos e InteraçõesFerramentas eProcessos
  30. 30. Valores Software FuncionandoDocumentaçãoAbrangente
  31. 31. Valores Colaboração com ClienteNegociação decontratos
  32. 32. Valores Responder a mudançasSeguir umplano
  33. 33. Princípios“ Nossa maior prioridade é satisfazer o cliente através da entrega adiantada e contínua de software de valor
  34. 34. Princípios“ Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adéquam a mudanças para que o cliente possa tirar vantagens competitivas
  35. 35. Princípios“ Entregar software funcionando com frequência, na escala de semanas ou meses, com preferência aos períodos mais curtos
  36. 36. Princípios“ Pessoas relacionadas a negócio e desenvolvimento devem trabalhar em conjunto e diariamente, durante todo o curso do projeto
  37. 37. Princípios“ Construir projetos ao redor de indivíduos motivados dando a eles o ambiente necessário, e confiar que farão seu trabalho
  38. 38. Princípios“ O método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara
  39. 39. Princípios“ Contínua atenção à excelência técnica e bom design aumenta a agilidade
  40. 40. Princípios“ Simplicidade: A arte de maximizar a quantidade de trabalho que não precisou ser feito - KISS
  41. 41. Princípios“ Software funcional é a medida primária de progresso
  42. 42. Princípios“ Em intervalos regulares, o time reflete como ficar mais efetivo, então, ajustam e otimizam seu comportamento
  43. 43. Princípios“ As melhores arquiteturas, requisitos e designs emergem de times auto- organizáveis
  44. 44. Envolvimento e Comprometimento
  45. 45. Características de Um Time Ágil Auto-gerência Responsabilidade Transparência Interdisciplinaridade Auto-organização Motivação Adaptabilidade Confiança Feedback Comunicação Coragem Sem hierarquia formal Respeito Comprometimento
  46. 46. Scrum“ É um processo para construir software incrementalmente em ambientes complexos, onde os requisitos não são claros ou mudam com muita frequência.
  47. 47. ScrumEm Rugby, Scrum é um time de oito integrantesque trabalham em conjunto para levar a bolaadiante no campo. Ou seja: times trabalhandocomo uma unidade altamente integrada comcada membro desempenhando um papel bemdefinido e o time inteiro focando num únicoobjetivo.
  48. 48. Backlog• Lista de todas as funcionalidades desejadas• É gerada incrementalmente – Começa pelo básico, o extra aparece com o tempo• Pode conter – Tarefas diretas, casos de uso e histórias• A lista é priorizada pelo dono do projeto – Cliente, depto de marketing, ...
  49. 49. O Backlog Inicial• Deve conter características que agreguem algum valor de negócio ao produto• Novos requisitos aparecem quando o cliente vê o produto• A arquitetura do sistema surge enquanto o projeto surge e é refatorado
  50. 50. Equipes• Sem nível hierárquico nem papéis – Mas com várias especialidades• Estão todos no mesmo barco• Geralmente equipes pequenas (até 10) – Existem casos com equipes maiores (800 !) – Usa-se também Scrum hierárquico• Comunicação é essencial – Encontro Scrum diário
  51. 51. Sprint• Unidades básicas de tempo (até 30 dias)• Começa com um encontro Sprint – Tarefas do Backlog são priorizadas – A equipe seleciona tarefas que podem ser completadas durante o próximo Sprint – As mesmas podem ser quebradas para o Backlog do Sprint – Cada tarefa recebe um responsável na equipe – Não há mudança nas tarefas durante o Sprint
  52. 52. Daily Scrum• Pequenos encontros diários da equipe – geralmente pela manhã – galinhas e porcos (só os porcos falam) – todos os porcos devem participar• Questões que aparecem devem ser resolvidas durante o dia e não na reunião• Os encontros iniciais são geralmente mais longos
  53. 53. Daily Scrum• Questões que devem ser respondidas por cada porco: – 1) O quê você fez ontem? – 2) O quê você vai fazer hoje? – 3) Quais os problemas encontrados?• Ajuda a manter as promessas• Evita: Como um projeto atrasa um ano? – Um dia por vez ... – Qualquer deslize pode ser corrigido de imediato
  54. 54. Local do Encontro• Sempre o mesmo local e • Todos devem participar hora • Galinhas ficam na• Pode ser o local de periferia desenvolvimento • Pode ser em pé• Pessoas sentadas ao redor de uma mesa • Sala bem equipada,• A sala já deve estar quadro branco, etc. arrumada antes• Punições (atrasos/faltas)
  55. 55. Revisão do Sprint• No final de cada Sprint é feita uma reunião com todos os interessados• Geralmente – Na forma de demonstração – Informal (preparação rápida, sem projetor,..) – Deve ser o resultado natural de um Sprint• O projeto é comparado com os objetivos iniciais do Sprint
  56. 56. Scrum Master• Faz com que a equipe viva os valores e práticas de Scrum• Protege a equipe de: – Riscos e interferências externos – Excesso de otimismo• Resolve os problemas que aparecerem – logísticos – de conhecimento/habilidade
  57. 57. Scrum Master• Mantém o Backlog do Sprint – Tarefas completadas – Identifica eventuais problemas• Mantém um gráfico de “quanto falta” 100 90 80 70 60 50 horas 40 30 20 10 0
  58. 58. Exemplo real
  59. 59. Scrum de Forma Gráfica
  60. 60. Dúvidas?

×