Introdução a Métodos Ágeis de Desenvolvimento de Software
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Introdução a Métodos Ágeis de Desenvolvimento de Software

on

  • 8,213 views

Curso ministrado no evento CBSoft I - Salvador - Bahia por Daniel Cukier e Rafael Prikladnicki

Curso ministrado no evento CBSoft I - Salvador - Bahia por Daniel Cukier e Rafael Prikladnicki

Statistics

Views

Total Views
8,213
Views on SlideShare
7,844
Embed Views
369

Actions

Likes
9
Downloads
272
Comments
0

4 Embeds 369

http://www.agileandart.com 329
http://www.locawebers.com.br 38
http://us-w1.rockmelt.com 1
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • Scrum @ Rafael Prikladnicki
  • TODO
  • Scrum @ Rafael Prikladnicki

Introdução a Métodos Ágeis de Desenvolvimento de Software Presentation Transcript

  • 1. Introdução a Métodos Ágeis de Desenvolvimento de Software Daniel Cukier (AgilCoop) twitter.com/danicuki Prof. Dr. Rafael Prikladnicki (PUCRS) twitter.com/rafaelpri
  • 2. Quem usa Scrum e XP?
  • 3. Quem usa Scrum e XP?
  • 4. EUA BR 2 anos! Quem usa Scrum e XP?
  • 5. Quem usa Scrum e XP?
  • 6. Quem usa Scrum e XP?
  • 7. Quem usa Scrum e XP?
  • 8.  
  • 9. Daniel Cukier
      • 15 anos de experiência com desenvolvimento do Software
      • 3 anos como gerente de Desenvolvimento na Locaweb
      • Membro da Agilcoop desde 2003
      • Autor do blog www.agileandart.com
      • Mestre em Ciência da Computação – IME/USP (2009)
      • Palestra em vários eventos
      • Encontro Ágil, Oxente Rails, Falando em Ágil , SugarLoafPLoP, etc
      • Áreas de atuação acadêmica e profissional:
      • Desenvolvedor e líder técnico em vários projetos de software.
      • Um dos responsáveis pela implantação de Métodos Ágeis na Locaweb
      • Padrões para Introduzir Novas Ideias na Indústria de Software
      • Outras não menos importantes:
      • Teatro, música, poesia, meditação
  • 10. Contexto e experiência na AgilCoop
    • Cursos de graduação em XP desde 2001
    • Apresentações
      • SBES, SUCESU, SEPAI, SEBRAE, etc.
      • Arquivos disponíveis: www.agilcoop.org.br
    • Assessorias em métodos ágeis
    • Artigos científicos
    • Dissertações de Mestrado
  • 11.
      • Professor da FACIN – PUCRS desde 2004 – www.inf.pucrs.br/~rafael
      • Coordenador de Gestão de Projetos da AGT/PUCRS
      • Professor do PPGCC desde 2010/1
      • Coordenador do GUMA e do SPIN-POA (Sucesu-RS)
      • Certified ScrumMaster (CSM) e Project Mgmt Professional (PMP)
      • Mestre em Ciência da Computação – PUCRS (2003)
      • Doutor em Ciência da Computação – PUCRS (2009)
      • Áreas de atuação acadêmica e profissional:
      • Desenvolvimento Distribuído de Software
      • Gerência de Projetos
      • Melhoria de Processo de Software
      • Engenharia de Software Experimental
      • Lean e Métodos Ágeis para Desenvolvimento de Software
    Rafael Prikladnicki
  • 12. Contexto e experiência na PUCRS www.inf.pucrs.br/munddos Criado em 2001 Registrado no CNPq em 2004 Livros publicados em 2007, 2009 e 2010 2 pesquisadores Formou 11 mestres, 1 doutor Possui 6 mestrandos, 2 doutorandos
  • 13. Implantação de práticas de DDS nas empresas Desenvolvimento de ferramentas para apoiar DDS Integração de DDS com métodos ágeis Estudo de maneiras de usar Follow-the-Sun (FTS) Formação de profissionais e alunos em DDS Estudo do papel do Brasil no mercado global de TI www.inf.pucrs.br/munddos Contexto e experiência na PUCRS
  • 14. Contexto e experiência na PUCRS
  • 15.
      • Introdução e motivação
      • O que são Métodos Ágeis?
      • Princípios
      • Problemas com abordagens tradicionais
      • Alguns métodos ágeis
      • Conclusão
    Agenda
  • 16.
    • Por que teu projeto termina com sucesso?
    • Por que teu projeto fracassa?
    • Discussão em grupo
      • 15 minutos
      • Agrupar problemas e fracassos em categorias
    Dinâmica Grupo 2 Grupo n Grupo 1 Grupo 3 Sucesso Fracasso Ref: Henrik Kniberg
  • 17. Motivação
  • 18.
    • Como ganhar dinheiro resolvendo problemas que voce não conhece, com pessoas desconhecidas, em um tempo curto e com poucos recursos (e se divertindo)?
    Motivação
  • 19. Tenho como produzir 100 aviões em 10 minutos? Quantos aviões 10 pessoas produzem em 10 minutos?
    • Tenho, mas:
    • Vou verificar tudo ao final
    • Posso ter baixa qualidade
    • Posso ter retrabalho
    • Posso não ter entendido o escopo
    • Então por que deixar tudo para o final?
  • 20. Tenho como produzir 100 aviões em 10 minutos? E se produzirmos um pouco a cada 2 minutos? E se melhorarmos a cada ciclo? E se o cliente fornecer feedback a cada ciclo? E se a equipe encontrar a melhor forma de trabalhar? Quantos aviões 10 pessoas produzem em 10 minutos?
  • 21. Motivação
  • 22. Motivação
  • 23.
    • Sociedade demanda
      • grande quantidade de sistemas/aplicações
      • software complexo, sistemas distribuídos, heterogêneos
      • requisitos mutantes (todo ano, todo mês, todo dia)
    • Mas, infelizmente,
      • não há gente suficiente para desenvolver tanto software com qualidade
    Novos ventos no desenvolvimento de software
  • 24.
    • Resultado dos projetos em 2004
    Relatório do Chaos ( Chaos Report )
  • 25.
    • Resultado dos projetos em 2004
    Relatório do Chaos ( Chaos Report ) 1994 2004 Projetos não concluídos ------------ 31% Proj etos bem sucedidos ----- 16% Estouro médio de custo -----------------------> 180% Estouro médio de prazo -----------------------> 164% Proje tos não concluídos ------- 18% Projetos bem sucedidos ----------- 29% Estouro méd io de custo ----------------- 56% Estouro médio de prazo ------------------------- 84%
  • 26. Evitar desperdício
    • Estudo do The Standish Group conclui (Chaos Report): Pesquisa sobre a utilização das funcionalidades do software ...
    Mais de 64% de um sistema de software quase nunca não é utilizado!
  • 27.
    • Com métodos tradicionais/clássicos de desenvolvimento
      • Supõem que é possível prever o futuro
      • Pouca interação com os clientes
      • Ênfase em burocracias
        • (documentos, formulários, processos, controles rígidos, etc.)‏
      • Avaliação do progresso baseado na evolução da burocracia e não do código
    • Com software
      • Grande quantidade de erros
      • Falta de flexibilidade
    Problemas
  • 28.
    • Melhores Tecnologias
      • Padrões de Projeto (reutilização de idéias)
      • Componentes (reutilização de código)
      • Middleware/frameworks (aumenta a bstração)
    • Melhores Metodologias
      • Métodos Ágeis (o foco deste mini-curso)
      • outras... (abordados em outros cursos de ES)
    Como resolver o impasse?
  • 29.
    • Erro comum: olhar para software como apenas um desses itens e ignorar os demais
    O que é desenvolvimento de software? Por Alistair Cockburn: (Gabriel) Arte (Knuth) Artesanato (Cockburn) Poesia (Humphreys) Disciplina (Meyer) Engenharia (Jacobson) Modelagem
  • 30.
    • Agile is not a set of practices, but a core set of beliefs and principles
    • Jim Highsmith
    O que são métodos ágeis?
  • 31.
    • Retorno de investimento
    • Inovação
    • Melhoria de processo
    • Pessoas
    • Cultura
    • Comunicação
    • Adaptação x Antecipação
    Princípios
  • 32.
    • Movimento iniciado por programadores experientes e consultores em desenvolvimento de software.
    • Questionam e se opõem a uma série de mitos e práticas adotadas em abordagens tradicionais de Engenharia de Software e Gerência de Projetos.
    • Manifesto Ágil:
      • Assinado por 17 desenvolvedores em Utah em fevereiro/2001.
      • http://agilemanifesto.org
    Histórico
  • 33. Processos e ferramentas Documentação abrangente Negociação de contrato Plano pré-estabelecido mais importante que Agile Manifesto (2001) Indivíduos e interações Software funcionando Colaboração do cliente Resposta às mudanças
      • http://agilemanifesto.org
    Kent Beck James Grenning Robert C. Martin Mike Beedle Jim Highsmith Steve Mellor Arie van Bennekum Andrew Hunt Ken Schwaber Alistair Cockburn Ron Jeffries Jeff Sutherland Ward Cunningham Jon Kern Dave Thomas Martin Fowler Brian Marick
  • 34.
    • O mais importante é o software funcionando
    • Periodicamente a equipe deve refletir sobre como se tornar mais efetivo
    • Profissionais motivados
    • Suporte às necessidades da equipe e a mbiente necessário para desenvolvimento das atividades
    • Confiança no trabalho da equipe
    Alguns princípios
  • 35.
    • O gerente de projeto concorda em prosseguir sem que todos os requisitos estejam bem definidos
    • Os desenvolvedores concordam em prosseguir sem ter todos os requisitos documentados
    • Os membros da equipe sabem que alguém vai ajudar quando ocorrerem problemas
    Em um projeto ágil ideal...
  • 36.
    • Os gerentes percebem que não precisam dizer à equipe o que fazer, ou garantir o que vai ser feito
    • A equipe percebe que ninguém vai dizer o que fazer, isto faz parte do trabalho da equipe
    • Não existem mais a impressão de divisão (testers and programmers), todos são desenvolvedores
    Em um projeto ágil ideal...
  • 37. Mudança de Postura Equipe Equipe Equipe Equipe GP Equipe Equipe Equipe Equipe GP Tradicional Ágil Cross-funcional Auto-organização
  • 38.
    • 0. Levantamento de Requisitos
    • 1. Análise de Requisitos
    • 2. Desenho da Arquitetura
    • 3. Implementação
    • 4. Testes
    • 5. Produção / Manutenção
    Enquanto isso, num projeto tradicional...
  • 39.
    • É necessário fazer uma análise de requisitos profunda e detalhada antes de projetar a arquitetura do sistema
    • É necessário fazer um estudo minucioso e elaborar uma descrição detalhada da arquitetura antes de começar a implementá-la
    • É necessário testar o sistema completamente antes de mandar a versão final para o cliente
    Premissas básicas do modelo tradicional
  • 40. Cascata é como uma bala de canhão
  • 41. Interface Cliente Servidor BD C Iterativo = não espere ter tudo correto na primeira vez Incremental = construa em ”pedaços” verticais ( features ) ao invés de horizontais (camadas) Desenvolvimento monolítico Desenvolvimento incremental Talvez não seja necessário construir o resto C Interface Cliente Servidor BD Iterativo e Incremental Ref: Henrik Kniberg 1 2 3 4 1 2 3
  • 42. Iterativo e Incremental Produto ?
  • 43. O que muda? Custo da mudança Intensidade e stress Tempo Tempo Tempo Entrega de valor Transparência Envolvimento do cliente Tempo Ref: Henrik Kniberg Tradicional Ágil
  • 44. Metodologias ágeis são uma tentativa de refinar as metodologias iterativas, tirando o foco do processo em si e dando mais ênfase para a contribuição das pessoas
  • 45.
    • Metodologias ágeis é uma febre? Uma onda passageira?
    É o início de uma mudança na forma de trabalho...
  • 46. Evitar incerteza x Gerenciar para incerteza Ref: Luiz Cláudio Parzianello
  • 47.
    • Visão tradicional
      • “ Tudo é importante, vamos fazer tudo ao mesmo tempo!”
    • Visão ágil
      • “ Prioriza e foca naquilo que é mais importante!”
    O paradoxo da multitarefa Ref: Henrik Kniberg Jan Feb Mar Abr Mai Jun Jul Jan Feb Mar Abr Mai Jun Jul A B C
  • 48.
    • Métodos tradicionais
      • O planejamento deve propiciar a prevenção de mudanças
    • Métodos ágeis
      • A mudança é incorporada ao escopo
    • Razões
      • Necessidades de negócio
      • Novas oportunidades
      • Mudanças de legislação
      • Requisitos incompletos
    O que muda?
  • 49.
    • A atitude dos desenvolvedores de software seria completamente diferente:
        • Tomaríamos as grandes decisões o mais tarde possível
        • Implementaríamos agora somente o que precisamos agora
        • Não implementaríamos flexibilidade desnecessária (não anteciparíamos necessidades)
    E se fosse essa a realidade?
  • 50.
    • Orientação a Objetos : facilita e cria oportunidades para mudanças
    • Técnicas de Refatoração
    • Testes automatizados : nos dão segurança quando fazemos mudanças
    • Prática / cultura de mudanças : aprendemos técnicas e adquirimos experiência em lidar com código mutante
    E essa é a nova realidade (em muitos casos)
  • 51.
    • Adaptative Software Development (ASD)
      • Jim Highsmith
    • Crystal Clear (Crystal)
      • Alistar Cockburn
    • Extreme Programming (XP)
      • Kent Beck, Eric Gamma
    • Scrum
      • Ken Schwaber, Jeff Sutherland, Mark Beedle
    • Lean Software Development
      • Mary e Tom Poppendieck
    • Feature Driven Development (FDD)
      • Peter Coad, Jeff DeLuca
    • Test Drive Development (TDD)
    • Kanban
    Principais Métodos Ágeis
  • 52.
    • Agile Project Management – Jim Highsmith, 2008
    • Agile Enterprise Framework
    Governança e Portfólio Gerência de Projeto Gerência de Iterações Práticas Técnicas ROI, Progresso, Risco, Investimento Release, aquisição, PMBOK, externo Interno, Scrum XP, FDD, etc Mudança de perspectiva
  • 53.
    • 1. David Rico (2008)
      • Survey de artigos acadêmicos e científicos publicados
    • 2. VersionOne (2008)
      • Survey online com mais de 3.000 pessoas
    • 3. QSMA (Michael Mah 2008)
      • Comparação rigorosa de 26 projetos ágeis com uma base de 7.500 projetos “tradicionais”
      • Equipes ágeis variando entre 26 e 1.000 pessoas
    • 4. Dr. Dobb’s Journal (2008)
      • Survey online com 642 pessoas
    Métodos ágeis funcionam?
  • 54. Fonte: Mah 2008. Agile projects are 16% more productive at a statistically significant level of confidence. Métodos ágeis funcionam?
  • 55.
    • Satisfação no trabalho
      • Após 15 meses de adoção do Scrum, 86% dos colabroadores da Salesforce.com estavam tendo um “good time” ou o “best time”
      • Apenas 40% disseram isto antes de adotar Scrum
      • 92% recomendariam métodos ágeis para outras pessoas
    • Time to Market
      • VersionOne
        • 64% disseram que o time to market melhorou
        • 23% disseram que melhorou significativamente
      • Michael Mah
        • Projetos ágeis tem um time to market 37% mais rápido com um nível de confiança estatisticamente significante
    Métodos ágeis funcionam?
  • 56. Fonte: Mah 2008. Métodos ágeis funcionam?
  • 57.
    • Melhoria na satisfação dos stakeholders
      • Dr. Dobb’s
        • 47% disseram que a satisfação foi “ somewhat higher ”
        • 31% disseram que foi “ much higher ”
      • Version One
    Métodos ágeis funcionam? Improved Significantly Improved Enhanced ability to manage changing priorities 41% 51% Improved project visibility 42% 41% Improved alignment of IT and business goals 39% 27% Reduced project risk 48% 17%
  • 58.
    • 5 motivos para NÃO usar métodos ágeis?
  • 59.
    • Motivo 1
    • Eu sei e defino todos os requisitos no início do projeto
    Cinco Motivos para não usar Métodos Ágeis Não preciso de ciclos iterativos Qual projeto de software possui todos os requisitos definidos (corretamente) no início?
  • 60.
    • Motivo 2
    • Os objetivos do meu projeto estão muito claros desde o início
    Cinco Motivos para não usar Métodos Ágeis O cliente descobre o que quer ao longo do caminho
  • 61.
    • Motivo 3
    • Meu projeto envolve baixa incerteza
    Cinco Motivos para não usar Métodos Ágeis Qual projeto de software envolve baixa incerteza?
  • 62.
    • Motivo 4
    • Minha estimativa está toda definida e com índice de erro muito baixo
    Cinco Motivos para não usar Métodos Ágeis Em qual projeto de software consigo ter estimativas precisas?
  • 63.
    • Motivo 5
    • Meu processo é rígido e controlado (comando-controle)
    Cinco Motivos para não usar Métodos Ágeis As tarefas são delegadas, equipes ficam desmotivadas mais facilmente Qual equipe gosta de trabalhar desmotivada?
  • 64.
    • Requisitos definidos desde o início
    • Objetivos claros desde o início
    • Comando-controle
    • Baixa incerteza
    • Estimativas precisas
    • Qual projeto de desenvolvimento de software possui estas características?
    Cinco Motivos para não usar Métodos Ágeis
  • 65.
    • Requisitos definidos desde o início
    • Objetivos claros desde o início
    • Comando-controle
    • Baixa incerteza
    • Estimativas precisas
    • Qual projeto de desenvolvimento de software possui estas características?
    E os Cinco Motivos? Entao NÃO faz sentido NÃO usar metodologias ágeis na grande maioria dos casos. Mas não APENAS metodologias ágeis!!!
  • 66.
    • SCRUM
  • 67. Scrum - Jogada de Rugby
  • 68. Ref.: 3rd Annual ”State of Agile Development” Survey June-July 2008 3061 respondentes, 80 países Quem usa Scrum?
  • 69. Requisitos Longe de um acordo Perto de um acordo Tecnologia Perto da certeza Longe da certeza Simples Complicado Complexo Anarquia Ref. : Strategic Management and Organizational Dynamics by Ralph Stacey, in Agile Software Development With Scrum by Ken Schwaber and Mike Beedle. Mesmo que o produto seja complexo... ... Tente manter uma iteração simples Como resolver
  • 70. Adaptativo E C D A Planejado Tradicional Ágil B C D A B D A B A B Sem 1 Sem 2 Sem 3 Sem 4 Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 Sem 6 Sem 7 Sem 8 Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 Sem 6 Sem 7 Sem 8
  • 71.
    • Princípio
      • Características desconhecidas
      • Prioridades devem ser consideradas
      • Escopo irá mudar!
    • Essência do SCRUM
      • Inspeção
        • Verificar o que foi feito no período
      • Adaptação
        • Melhorar o processo
    • Planejar
      • Planejar o sprint
    • Desenvolver
      • Realizar o sprint
    • Inspecionar ( check )
      • Sprint review e retrospectiva
    • Adaptar
      • Lições para o próximo planejamento
    Ênfase: processo empírico PLAN DO ACT CHECK
  • 72. O Framework do Scrum
  • 73.
    • Product Owner e Cliente
    • Visão do produto
      • Requisitos funcionais e não funcionais
      • Restrições e User stories (prática do XP)
    • Criação do product backlog
      • Conjunto de funcionalidades do sistema
      • Priorização das funcionalidades
    • Preparação da base necessária para o desenvolvimeto
      • Mecanismos de comunicação e coordenação
      • Formação das equipes
    Planejamento e preparação
  • 74.
    • User stories
      • Identificação de atores envolvidos
      • Como um [papel do usuário] quero [funcionalidade] para [valor de negócio]
      • I.N.V.E.S.T. (independente, negociável, valorizável, estimável, small e testável)
      • Quebrar grandes e juntar pequenas
      • Definição do conceito de DONE (testes)
        • Diferentes perspectivas
      • Prioridades das user stories
        • Valor entre 1 e 150?
          • Must have
          • Should have
          • Could have
    User Stories
  • 75.
    • Product Owner , ScrumMaster e Equipe
    • Análise e organização do Product Backlog
      • Refinamento das funcionalidades
      • Estimativas
      • Escolha das funcionalidades para o sprint
      • Formalização do sprint backlog
      • Identificação das tarefas
      • Organização da taskboard
    Desenvolvimento 2-4 hs 2-4 hs
  • 76.
    • Estimativas
      • Tempo e/ou complexidade?
      • Fibonacci
        • 1, 2, 3, 5, 8, 13, 21…
      • Planning poker
        • As duas estratégias de uso de planning poker
          • Jogar as cartas para cada estória
          • Colocar cada estória embaixo de uma carta
      • Algumas práticas utilizadas:
        • Pontos para funcionalidades e horas para tarefas
        • 1- day tasks (máximo 2 e mínimo 1/2)
        • Considerar tarefas como teste, pesquisas, documentação, etc.
    Desenvolvimento
  • 77.
    • Tempo ou Complexidade
      • 4 pessoas trabalhando 4 semanas
      • Equipe: 640 horas
      • 2 junior, 2 senior
        • Produzem 25 pontos de complexidade
      • 4 pessoas trabalhando 4 semanas
      • Equipe: 640 horas
      • 4 senior
        • Produzem 60 pontos de complexidade
    Desenvolvimento
  • 78. Planning poker 1 Muito pequeno! 2 3 5 8 13 21 40  Férias!  Mais detalhes!  Nem idéia!  Intervalo!
  • 79.
    • Planning Poker na PRÁTICA!
      • Avaliar distância entre
      • Argentina e Mongólia
      • Chile e Itália
      • Japão e Austrália
      • Índia e Alemanha
      • EUA e Rússia
      • Ucrânia e China
    Planning poker
  • 80. VALOR COMPLEXIDADE Alta Baixa Alta Baixa UStory1 UStory2 UStory3 UStory4 Priorização e classificação do backlog
  • 81. 40 30 30 28 30 31 30 30 Estimado Realizado 40 30 40 30 40 30 40 30 50 30 60 30 40 35 35 30 30 25 30 25 20 Calibrando a velocidade Estimado Realizado Estimado Realizado Estimado Realizado
  • 82. Calibrando a velocidade Início da sprint 8 5 3 5 5 5 3 5 5 8 Backlog do produto 8 5 3 5 5 Backlog da sprint Final da sprint 8 5 3 5 5 Feito! Feito! Feito! Quase Nem iniciamos Velocidade real = 18 Backlog da sprint Velocidade estimada = 26
  • 83. Administrate users Register new user Edit existing user Delete user Find user 100 simultaneous users Operations manual As a helpdesk operator I want to see who is logged in View Invoice in HTML, PDF, or Excel format 100 simultaneous users Operations manual As a helpdesk operator I want to see who is logged in View Invoice in HTML, PDF, or Excel format Register new user Edit existing user Delete user Find user 100 simultaneous users Operations manual As a helpdesk operator I want to see who is logged in View Invoice in HTML, PDF, or Excel format Dividindo user stories
  • 84. Dividindo user stories Administrate users Register new user Edit existing user Delete user Find user User admin User admin User admin User admin Do GUI design Write failing test Do integration test Create DB schema Write server-side logic Write form validation Dividir Quebrar em tarefas durante a reunião de sprint planning 13 5 3 8 2 Ref: Henrik Kniberg Como priorizar itens do backlog? Como planejar as tarefas?
  • 85.
    • ScrumMaster e Equipe
    • Dia-a-dia do SCRUM
      • Sprint
        • 2 semanas a 4 semanas
      • Daily meetings (Daily Scrum)
      • Impedimentos
        • Obstáculos ao trabalho da equipe
      • Manter a taskboard
        • Burndown
        • Tarefas e estimativas
        • Tarefas não-planejadas
    Desenvolvimento
  • 86. O Gráfico de Burndown 5 10 15 20 Trabalho que resta na sprint (pontos de user story) Dias da sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Gráfico de Burndown de uma Sprint de duas semanas Vamos terminar antes
  • 87. O Gráfico de Burndown 5 10 15 20 Trabalho que resta na sprint (pontos de user story) Dias da sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Gráfico de Burndown de uma Sprint de duas semanas Não vamos conseguir cumprir a meta desta sprint
  • 88. O Gráfico de Burndown 5 10 15 20 Trabalho que resta na sprint (pontos de user story) Dias da sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Não estamos atualizando o gráfico de burndown Gráfico de Burndown de uma Sprint de duas semanas
  • 89. O Gráfico de Burndown 100 200 300 400 Trabalho que resta no projeto (pontos de user story) Nro de sprints 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 O projeto vai terminar entre os sprints 14 e 16 Gráfico de Burndown da release ou do projeto
  • 90.
    • Daily Meetings (Daily Scrum)
      • Reunião diária de 15 minutos
      • Mantém equipe informada e integrada
        • O que você fez ontem?
        • O que pretende fazer para amanhã?
        • Quais são seus impedimentos?
      • Questões técnicas
        • No final da reunião
      • Não se resolve problema, apenas se identifica
    Desenvolvimento
  • 91.
    • Para ajudar na execução ( taskboard )
    Desenvolvimento
  • 92.
    • Cliente, PO, SM e Team
    • Apresentação do produto
    • Foco no QUE foi feito e não COMO foi feito
    • Aceite formal e feedback do cliente
    • Melhoria na forma de priorização?
    Sprint review
  • 93.
    • Lições aprendidas
      • Alimentam o próximo sprint
        • Velocidade da equipe
        • Erros x acertos
        • Previsto x realizado
        • Fator de foco da equipe
      • Repositório de lições
      • Disseminação na empresa
    • Usar parte do sprint anterior para planejar o próximo sprint
    Próximo sprint Lições aprendidas
  • 94. Sprint 2-4 semanas ??? Objetivo do Sprint Produto a ser entregue (ou seu incremento) ‏ Backlog do produto Cupons Embrulho 24 horas Fluxo do Scrum Cancel Gift wrap Return Backlog da Sprint Cupons Cancelar Sprint Planning 1 Sprint Planning 2 Daily Scrum Sprint Review Retrospectiva
  • 95.
    • XP
  • 96.
    • Lembram disto?
    • Como Métodos Ágeis podem ajudar a resolver ou minimizar os motivos de fracasso identificados?
    Dinâmica Grupo 2 Grupo n Grupo 1 Grupo 3 Sucesso Fracasso Ref: Henrik Kniberg
  • 97.
    • Quando temos problema em cronograma, modelos tradicionais cortam testes, modelos ágeis cortam histórias. Um reduz a qualidade, o outro reduz o escopo.
    • A questão não é documentar, é entender.
    • Não existem melhores práticas. Existem boas práticas para determinadas situações.
    • Entregue hoje. Adapte amanhã.
    • Adaptação é uma resposta à mudança.
    • Equipes auto-gerenciáveis não são equipes sem liderança, são equipes com outro estilo de liderança.
    • Uso de técnicas como Refatoração, Testes, Modelagem Ágil são fundamentais para constante mudança do código
    • Plans are nothing; Planning is everything
    Conclusões
  • 98. twitter.com/danicuki twitter.com/rafaelpri
  • 99. Dinâmica Analista Projetista Programador Testador Cliente Ref: Luiz Cláudio Parzianello  Æ Œ
  • 100. Dinâmica … … … … Ref: Luiz Cláudio Parzianello … … … … Pequenos Lotes Grandes Lotes   Æ    Æ Œ  Æ  Æ  Æ Œ ™  Æ Œ  Æ Œ  Æ Œ ™  Æ Œ ™   Æ  Æ Œ  Æ Œ ™
  • 101.
    • Qual é o arranjo logístico mais rápido ?
    • Qual equipe apresentou o maior esforço por projeto?
    • Quais as vantagens de cada abordagem?
    • Quais as desvantagens de cada abordagem?
    • Qual a justificativa para manter os grandes lotes?
    Dinâmica