Métodos ágeis
6 gostaram2,022 visualizações
Quero poder pesquisar hotéis disponíveis em uma cidade e datas específicas para planejar minhas férias. Isso me ajudará a organizar minha viagem de forma mais eficiente. Visitante: Como visitante, eu quero poder pesquisar hotéis disponíveis em uma cidade e datas específicas para planejar minhas férias. Isso me ajudará a organizar minha viagem de forma mais eficiente.
Métodos ágeis
- 1. Métodos Ágeis Arthur Piccolo @arthur_piccolo
- 2. Plano do Curso O que é Agilidade De onde Viemos - Waterfall Manifesto Ágil O que é um Projeto de Sucesso? Vantagens da Agilidade Overview de Métodos Ágeis: GTD, Scrum, Pomodoro, XP, TDD & FDD
- 3. Plano do Curso Agilidade Com Lean O método Toyota Scrum Kanban Time
- 4. De onde Viemos Seguimos processos e fluxos lineares do pensamento industrial. O mundo mudou, ambientes complexos, imprevistos, demandas diárias, e incapacidade de pensar e responder tudo.
- 6. Waterfall Processo 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. Cultura Organizacional Construção Hipotética Ideia ou Rótulo Modelo de Trabalho Soma dos hábitos das pessoas relacionados ao modo de como elas realizam os trabalhos.
- 9. O que é Agilidade Cultura e valores que permitem interações com foco em resultados rápidos e orientados nas necessidades reais das pessoas.
- 10. Agilidade com Lean Lean 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. Pensar Lean Processo de eliminação sistemática de desperdícios através de melhoria contínua, sempre na visão de clientes. Estado de espírito.
- 13. Muda Eliminar Desperdícios Defeitos Máxima Economia de Recursos Just in Time Funcionalidades Desnecessárias
- 14. Push vs. Pull Systems Tecnologia deve ser puxada (pull) e não empurrada (push)
- 15. Jidoka Automação com Toque Humano Alarmes Visuais e Sonoros (Andon) PokaYoke - Detectar Erros de execução Correção Imediata PDCA
- 16. Genchi Genbutsu Ver com os Próprios Olhos Entender a Situação Líderes e Equipes que Seguem a Filosofia e Ensinam aos Outros
- 17. Hansei Auto-Reflexão Identificar Falhas The 5 Whys Causa e Efeito Retrospectivas
- 18. Kaizen Melhoria Contínua Padronizações Mudança de Atitude Qualidade e Sem Defeitos
- 19. Kanban Sinalização Informações Indicações Sobre a Tarefa Fluxos, Entregas e Comunicações Ritmo
- 20. Manifesto Ágil
- 21. Criado em 2001 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: Indivíduos e interações 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 Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. (Project)
- 22. Software Project
- 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. Complexidade “A complexidade se apresenta com os traços inquietantes do emaranhado, do inextricável, da desordem, da ambiguidade, da incerteza...” fonte: – Introdução ao Pensamento Complexo / Edgar Morin
- 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. Diálogo “Num diálogo, ninguém está tentando ganhar. Cada um 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. Vantagens da Agilidade Simplicidade Processos Indivíduos e Interações ao invés Ferramentas Produto que Funciona Documentação Abrangente Colaboração do Cliente Negociação de Contrato Resposta à Mudanças Seguir um Plano
- 28. Overview sobre Métodos Ágeis
- 29. Eu Open Loops Mente como Água Coletar, Processar e Revisar Menos de Dois Minutos ? Próximas Ações Sistema de Lembretes
- 30. Nós Pessoas Interações Iterativo e Incremental Timebox Responder Mudanças Gerenciamento da Complexidade Adaptação e Flexibilidade Software Funcionado Times Pequenos 5-9 Auto Organização
- 31. Pomodoro Agora Ciclos Curtos 25 Minutos Concentrado 5 Minutos de Descanso Despertadores Planejamento (Morning) Tracking (The promodoro`s) Recording, processing and visualizing (end of day)
- 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 Par Propriedade Coletiva do Código
- 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. TDD (Test Driven Development) Agora Início Lento Desing Test Implement Test Refactoring Primeiro o teste, depois a funcionalidade para passar no teste Testes automatizados: Unitários, Interface e Aceitação
- 35. O Método Scrum
- 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 controlada Um processo iterativo e incremental para desenvolvimento ou manutenção Planejando de Releases Baseado em Necessidades
- 37. História do Scrum O nome Scrum vem de uma jogada ou formação do Rugby, onde 8 jogadores 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. Fases do Scrum Pre-game Postgame – Planejamento – Fechamento (Agrupamento da – Desenho e alto nível da Documentação, Treinamento, Arquitetura Lições Aprendidas) – Modelo Abrangentez Game – Sprints (Modelagem incremental, desenvolvimento, revisões e ajustes)
- 39. Ciclo de Vida do Scrum
- 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 Sprint Burndown (gráfico)
- 41. Product Owner Quem é o nosso cliente? Funcionalidades do Produto Estórias do Produto Decide as Datas e Conteúdo Rentabilidade (ROI) Prioridades Aceita o rejeita resultados
- 42. Scrum Master Remove Obstáculos Comprometimento Auxilia o Time no Auto Gerenciamento Responsável Produtividade da Equipe Realiza Reuniões Conduz Eventos Escudo da equipe
- 43. Equipe Scrum 5 a 9 pessoas Multi-funcional Auto-organizável Melhoria Contínua Ensina o Outro Confiança e União Sugere funcionalidades do produto
- 44. A Equipe e o Comprometimento
- 45. Time-Boxes Eventos com Duração Fixa Reuniões de Planejamento Reunião Diária Reunião de Revisão Reunião de Retrospectiva Sprints
- 46. Estória de Usuários Pequenas Descrições Fornecidas pelo Cliente ou P.O Descreve 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. Modelo de Estória do Usuário - Frente
- 48. Modelo de Estória do Usuário – Verso – Teste de Aceitação
- 49. Definindo Papéis para Estórias Site de Hotel Visitante: Pessoa que apenas navega pelo site para ver promoções. Cliente: Pessoa que possui um cadastro e faz reservas.
- 50. Definindo Papéis para Estórias
- 51. Estórias Eficazes INVEST: Bill Wake Livro – Extreme Programming Explored – Criou conjunto de seis atributos:
- 52. Estórias Eficazes Os Três “C”s: Cartão Conversa Confirmação
- 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 Sprint Respeitar Estórias, Pontos, Prioridades, Tamanho e Tempo de Execução
- 54. Planning Poker Técnica para estimar histórias Equipe trabalha na estimação junto com o Scrum Master Usamos 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. Planning Poker
- 56. Product Backlog Lista de funcionalidades desejadas no projeto Os 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. Product Backlog
- 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. Sprint Backlog Como vamos fazer? Equipe planeja o trabalho Histó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. Sprint Backlog
- 61. Daily Scrum Compartilhar Nã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. Scrum Board Visibilidade do Projeto Sinaliza estado do Scrum Deve ficar visível a todos Deve ser atualizado em tempo real Evita colocar meta em Risco
- 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. Sprint Burndown Chart (Grático) Exibir Esforço para o Objetivo da Iteração Exibir o Quanto Próximo ou Distante da Equipe Atingir a META Coluna Vertical = Quantidade de Esforço Coluna Horizontal = Tempo da Iteração Linha Vermelha = Fluxo Ideal de Trabalho Linha Azul = Estado Atual do Fluxo (Superando Expectativas ou Abaixo do Previsto)
- 65. Sprint Review Equipe 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. 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 Sprint Fatores Positivos e Negativos devem ser Levantados e Registrados Revisã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. Release Planning Equipes Testes Documentação Duração das Sprints Número de Releases Priorização dos Product Backlog Estimativa de Velocidade Data de Liberação de Releases
- 68. Um pouco mais de Kanban... Kanban - Siginificado = Sinalizador / Placar Card Wall Backlog Kanban torna as coisas visíveis e tangíveis Identificar Padrões Facilidade de Priorizar e Analisar Defini o WIP Ganha Tempo *Livre Permite visualizar o trabalho Evita Multitasking
- 69. Fluxo e Etapas
- 70. Card Wall
- 71. Gargalo Impede o fluxo do trabalho
- 72. Épicos Evite Criar Itens Gigantescos e Pouco Concretos
- 73. Finalização Kanban Tarefas menores são mais fáceis de compreender e estimar Evite 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. O Time Mais produtivo, divertido e feliz
- 75. Obrigado! :) Arthur Piccolo @arthur_piccolo Essa apresentação foi produzida com pesquisa e referência de vários sites e conteúdos da Internet.