Métodos ágeis

1.964 visualizações

Publicada em

Apresentação sobre Métodos Ágeis.

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

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

Nenhuma nota no slide

Métodos ágeis

  1. 1. Métodos Ágeis Arthur Piccolo@arthur_piccolo
  2. 2. Plano do Curso O que é Agilidade De onde Viemos - Waterfall Manifesto ÁgilO que é um Projeto de Sucesso? Vantagens da Agilidade Overview de Métodos Ágeis:GTD, Scrum, Pomodoro, XP, TDD & FDD
  3. 3. Plano do CursoAgilidade Com Lean O método Toyota Scrum Kanban Time
  4. 4. De onde ViemosSeguimos processos e fluxos lineares dopensamento industrial.O mundo mudou, ambientes complexos,imprevistos, demandas diárias, e incapacidadede pensar e responder tudo.
  5. 5. De onde Viemos
  6. 6. WaterfallProcesso tradicional com cronogramas, prazos, custos e projetos rígidos.Taxa de Insucesso alta e compreensão falha direcionados aos casos de uso. Centrados na Arquitetura UML.
  7. 7. Cultura Organizacional Construção Hipotética Ideia ou Rótulo Modelo de TrabalhoSoma dos hábitos das pessoas relacionados ao modo de como elas realizam os trabalhos.
  8. 8. PráticaCultura
  9. 9. O que é AgilidadeCultura e valores que permitem interaçõescom foco em resultados rápidos e orientados nas necessidades reais das pessoas.
  10. 10. Agilidade com LeanLean não é um processo, Lean não é um conjunto de técnicas, Lean não é apenas redução de custos. E por último, Lean não é tangível.Soluções elegantes através da simplicidade.
  11. 11. Pensar LeanProcesso de eliminaçãosistemática de desperdíciosatravés de melhoriacontínua, sempre na visãode clientes.Estado de espírito.
  12. 12. Método Toyota (TPS)
  13. 13. Muda Eliminar Desperdícios DefeitosMáxima Economia de Recursos Just in TimeFuncionalidades Desnecessárias
  14. 14. Push vs. Pull SystemsTecnologia deve ser puxada (pull) e não empurrada (push)
  15. 15. Jidoka Automação com Toque Humano Alarmes Visuais e Sonoros (Andon)PokaYoke - Detectar Erros de execução Correção Imediata PDCA
  16. 16. Genchi Genbutsu Ver com os Próprios Olhos Entender a SituaçãoLíderes e Equipes que Seguem a Filosofia e Ensinam aos Outros
  17. 17. Hansei Auto-Reflexão Identificar FalhasThe 5 Whys Causa e Efeito Retrospectivas
  18. 18. Kaizen Melhoria Contínua Padronizações Mudança de AtitudeQualidade e Sem Defeitos
  19. 19. Kanban Sinalização Informações Indicações Sobre a TarefaFluxos, Entregas e Comunicações Ritmo
  20. 20. Manifesto Ágil
  21. 21. Criado em 2001 Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros afazerem o mesmo. Através deste trabalho, passamos a valorizar: Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangenteColaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. (Project)
  22. 22. Software Project
  23. 23. O que é um Projeto de Sucesso? Paradoxo de Cobb Nós sabemos porque os projetos falham, sabemos como prevenir... Porque eles continuam falhando? Martin Cobb Treasury Board of Canada Secretariat
  24. 24. Complexidade “A complexidade se apresenta com os traçosinquietantes do emaranhado, do inextricável, da desordem, da ambiguidade, da incerteza...” fonte: – Introdução ao Pensamento Complexo / Edgar Morin
  25. 25. Compreensão“As relações humanas estão cada vez mais ameaçadas pela incompreensão,uma vez que o fato das pessoas se comunicarem não garante que estejam se entendendo.” fonte: – Os Sete Saberes Necessários à Educação do Futuro / Edgar Morin
  26. 26. Diálogo“Num diálogo, ninguém está tentando ganhar. Cadaum vence se qualquer um vencer. É algo mais que uma participação comum, na qual não estamos jogando um contra o outro, mas com o outro.” NUM DIÁLOGO, TODOS VENCEM. fonte: O Diálogo / David Bohm
  27. 27. Vantagens da AgilidadeSimplicidade ProcessosIndivíduos e Interações ao invés FerramentasProduto que Funciona Documentação AbrangenteColaboração do Cliente Negociação de ContratoResposta à Mudanças Seguir um Plano
  28. 28. Overview sobre Métodos Ágeis
  29. 29. EuOpen LoopsMente como ÁguaColetar, Processar e RevisarMenos de Dois Minutos ?Próximas AçõesSistema de Lembretes
  30. 30. NósPessoasInteraçõesIterativo e IncrementalTimeboxResponder MudançasGerenciamento da ComplexidadeAdaptação e FlexibilidadeSoftware FuncionadoTimes Pequenos 5-9Auto Organização
  31. 31. PomodoroAgoraCiclos Curtos25 Minutos Concentrado5 Minutos de DescansoDespertadoresPlanejamento (Morning)Tracking (The promodoro`s)Recording, processing and visualizing (end of day)
  32. 32. XP (Extreme Programming) Nós Integração Contínua e Frequente Jogo do Planejamento Ritmo Sustentável Versões Pequenas Cliente com os Desenvolvedores Metáfora Padrão de Código Projeto Simples TDD (Desenvolvimento Orientado por Testes) Testes dos Clientes Refatoração Programação em ParPropriedade Coletiva do Código
  33. 33. FDD (Feature Driven Development) Nós Concepção Planejamento Desenvolver um Modelo Abrangente Construir uma Lista de Funcionalidades Planejar por Funcionalidade Detalhar por Funcionalidade Construir por Funcionalidade
  34. 34. TDD (Test Driven Development)AgoraInício LentoDesingTestImplementTestRefactoringPrimeiro o teste, depois a funcionalidadepara passar no testeTestes automatizados: Unitários, Interface eAceitação
  35. 35. O Método Scrum
  36. 36. A Metodologia Scrum Agilidade na Gestão de Projetos Scrum é um framework para gerenciamento de projetos de softwares Pode ser utilizado por outras áreas Pequenos times Auto Organizados Flexibilidade – “Framewrok” Visbilidade e Adaptação Metáfora do Icebarg Enxerga o desenvolvimento como uma caixa preta controladaUm processo iterativo e incremental para desenvolvimento ou manutenção Planejando de Releases Baseado em Necessidades
  37. 37. História do Scrum O nome Scrum vem de uma jogada ou formação do Rugby, onde 8jogadores de cada time devem se encaixar para formar uma muralha. É muito importante que seja realizado um trabalho de equipe, pois se um dos jogadores na formação falhar, toda a jogada é comprometida. - Inspiração: Takeuchi and Nonaka / The New Product Development Game - Inicio em 1990 - Primeira Implementação 1993 - Apresentado em 1995 como The Scrum Development Process por Ken Schwaber
  38. 38. Fases do ScrumPre-game Postgame– Planejamento – Fechamento (Agrupamento da– Desenho e alto nível da Documentação, Treinamento,Arquitetura Lições Aprendidas)– Modelo AbrangentezGame– Sprints (Modelagem incremental,desenvolvimento, revisões eajustes)
  39. 39. Ciclo de Vida do Scrum
  40. 40. O núcleo do Scrum Artefatos: Papéis: Cerimônias: Estórias Product Owner (PO) Planejamento da Sprint Planning Poker ScrumMaster (SM) Reunião Diária Product Backlog Equipe Scrum Revisão da Sprint Sprint Backlog Retrospectiva da SprintBurndown (gráfico)
  41. 41. Product OwnerQuem é o nosso cliente?Funcionalidades do ProdutoEstórias do ProdutoDecide as Datas e ConteúdoRentabilidade (ROI)PrioridadesAceita o rejeita resultados
  42. 42. Scrum MasterRemove ObstáculosComprometimentoAuxilia o Time no Auto GerenciamentoResponsávelProdutividade da EquipeRealiza ReuniõesConduz EventosEscudo da equipe
  43. 43. Equipe Scrum5 a 9 pessoasMulti-funcionalAuto-organizávelMelhoria ContínuaEnsina o OutroConfiança e UniãoSugere funcionalidades do produto
  44. 44. A Equipe e o Comprometimento
  45. 45. Time-BoxesEventos com Duração FixaReuniões de Planejamento Reunião Diária Reunião de Revisão Reunião de Retrospectiva Sprints
  46. 46. Estória de Usuários Pequenas Descrições Fornecidas pelo Cliente ou P.ODescreve funcionalidades que devem gerar valor para o cliente Necessidades do Cliente (Requisitos – Casos de Uso) Entender o que o Software deve Fazer P.O indica valor agregado Épicos – histórias ainda brutas (alto nível) / poucos detalhes Componentes: Ator, Objetivo e Justificativa Cartão para Histórias: Quem ? O que? Por que? Pontuação? Prioridade? Geram uma visão Compartilhada de Negócio e Técnica Realizável em uma Sprint
  47. 47. Modelo de Estória do Usuário - Frente
  48. 48. Modelo de Estória do Usuário – Verso – Teste de Aceitação
  49. 49. Definindo Papéis para Estórias Site de HotelVisitante: Pessoa que apenas navega pelo site para ver promoções. Cliente: Pessoa que possui um cadastro e faz reservas.
  50. 50. Definindo Papéis para Estórias
  51. 51. Estórias Eficazes INVEST:Bill Wake Livro – Extreme Programming Explored – Criou conjunto de seis atributos:
  52. 52. Estórias Eficazes Os Três “C”s: Cartão Conversa Confirmação
  53. 53. Sprints Deve ter um objetivo Iterações para implementação das histórias / tarefas Normalmente leva 15 ou 30 dias (em alguns casos horas) Maior risco - Sprint Menor Membros da Equipe vão pegando tarefas e executando Scrum Master facilita o trabalho da equipe Pode ser necessário tirar dúvidas com o P.O ou outros especialistas Evitar MUDANÇAS! Tarefas devem ocupar 1 ou 2 dis de trabalho de um membro Produto é desenvolvido no SprintRespeitar Estórias, Pontos, Prioridades, Tamanho e Tempo de Execução
  54. 54. Planning Poker Técnica para estimar histórias Equipe trabalha na estimação junto com o Scrum MasterUsamos cartas com pontuação baseada na série de Fibonacci (0, 1, 2, 3, 5, 8, 13) Dialogar sobre a história Equipe joga cartas com valores que acredita representar o esforço para o desenvolvimento da história A estimativa deve ser encontrada por unanimidade Ajuda a indicar o quanto o time consegue fazer numa Sprint Medida em pontos Pode ser usado para o planejamento de entregas (Releases)
  55. 55. Planning Poker
  56. 56. Product Backlog Lista de funcionalidades desejadas no projetoOs itens que compõe a lista são chamados de histórias ou itens de backlog Todos podem incluir histórias Somente o Product Owner pode priorizá-las Product Owner pode priorizar novamente no início de cada Sprint Conjuntos de estórias que darão origem ao produto
  57. 57. Product Backlog
  58. 58. Sprint Planning O que vamos Fazer? Proposição de uma META para Sprint pelo P.O Meta: Descrição do que se deseja ao final da Sprint em termo de valor ( funcionalidades do produto)Explicação das histórias prioritárias do Backlog, para a Equipe, pelo P.O Planning Poker De forma colaborativa (por todos) Equipe compromete-se a concluir as tarefas Exemplo: Sprint de 30 dias = 4 Horas de planejamento A equipe decide o quanto acha que conseguirá fazer na Sprint Definição da META da Sprint Participa dessa Reunião P.O Equipe, SM e Outros Convidados
  59. 59. Sprint Backlog Como vamos fazer? Equipe planeja o trabalhoHistórias selecionadas no Product Backlog são transformados em tarefas As tarefas identificadas constituem o Sprint Backlog Tarefas podem receber estimativa de horas ou pontos P.O e outros Convidados podem participar para tirar dúvidas da Equipe Ao final, tarefas bem definidas e entendidas
  60. 60. Sprint Backlog
  61. 61. Daily Scrum CompartilharNão é pausa pro Lanche, nem brincadeira, deve ser o mais objetiva possível Serve para que todos saibam o que está acontecendo e se coordenam Encontro da equipe / Todos devem Participar 15 Minutos Stand-up Meeting ( Em pé) O que Fiz? O que pretende fazer? Impedimentos? Não é reunião para discussões técnicas Atualizar Quadro de Tarefas ou Kanban Atualizar Burndown Chart
  62. 62. Scrum BoardVisibilidade do ProjetoSinaliza estado do ScrumDeve ficar visível a todosDeve ser atualizado em tempo realEvita colocar meta em Risco
  63. 63. Definição de Pronto Objetivo do Produto Podemos Usar?Garantir Entrega Real das Necessidades do Produto Qualidade Manutenção Futura Testar Unitariamente Testar Integrações Refactoring Verificar Build do Produto Atualizar Documentação Aceitação
  64. 64. Sprint Burndown Chart (Grático)Exibir Esforço para o Objetivo da IteraçãoExibir o Quanto Próximo ou Distante da EquipeAtingir a METAColuna Vertical = Quantidade de EsforçoColuna Horizontal = Tempo da IteraçãoLinha Vermelha = Fluxo Ideal de TrabalhoLinha Azul = Estado Atual do Fluxo (SuperandoExpectativas ou Abaixo do Previsto)
  65. 65. Sprint ReviewEquipe apresenta resultado da Sprint para o P.O , para sua aprovação Demonstração Funcional O P.O aprova as histórias que entender que foram satisfeitas Muito importante a definição de PRONTO Problemas Enfrentados Resoluções Revisão do Product Backlog Aceitação História pelo P.O Avaliação se a META foi atingida Transparências – O que está pronto ? Sprint = 30 Dias = 4 Horas Gera base para o próximo planejamento
  66. 66. Sprint Retrospective Última reunião da Sprint Melhoria Contínua Debriefing Conduzida da Equipe para Equipe (P.O pode ser convidado) Discutir o que aconteceu na SprintFatores Positivos e Negativos devem ser Levantados e RegistradosRevisão do Conceito de Trabalho, Pronto, Ferramentas, Testes e Etc Propor Soluções Adaptação Empírica A equipe discute o que gostaria de: Iniciar a fazer Parar de fazer Continuar fazendo
  67. 67. Release Planning Equipes Testes Documentação Duração das Sprints Número de Releases Priorização dos Product Backlog Estimativa de VelocidadeData de Liberação de Releases
  68. 68. Um pouco mais de Kanban...Kanban - Siginificado = Sinalizador / PlacarCard WallBacklogKanban torna as coisas visíveis e tangíveisIdentificar PadrõesFacilidade de Priorizar e AnalisarDefini o WIPGanha Tempo *LivrePermite visualizar o trabalhoEvita Multitasking
  69. 69. Fluxo e Etapas
  70. 70. Card Wall
  71. 71. GargaloImpede o fluxo do trabalho
  72. 72. ÉpicosEvite Criar Itens Gigantescos e Pouco Concretos
  73. 73. Finalização Kanban Tarefas menores são mais fáceis de compreender e estimarEvite procrastinar tarefas importantes até que se tornem urgentes Torne as prioridades e complexidade visíveis Adote Métricas Mudança de Planos Acabe com o Desperdício Impedimentos O que Farei Hoje Retrospectiva
  74. 74. O TimeMais produtivo, divertido e feliz
  75. 75. Obrigado! :) Arthur Piccolo @arthur_piccolo Essa apresentação foi produzida com pesquisa ereferência de vários sites e conteúdos da Internet.

×