Métodos Ágeis

795 visualizações

Publicada em

Palestra sobre métodos ágeis para desenvolvimento de software.

Publicada em: Software
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
795
No SlideShare
0
A partir de incorporações
0
Número de incorporações
345
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Objetivo da apresentação: Apresentar e discutir soluçoes para o desenvolvimento de aplicacoes modernadas, baseado em estratégias empresarias modernas, com foco economia, agilidade e escala

    Falar:
    Desenvolvimento Aplicações hoje
    Infraestrutura para manter um ciclo de desenvolvimento
    Gestão moderna
    Soluçao de gestao: Visual Studio ALM
    Solucao de infraestrutura: Nuvem (Windows Azure)
    Vantagens e o porque cloud?
  • Era uma vez um consumidor. Um consumidor moderno. Como você! CLIQUE

    Este ser humano deseja trabalhar, se divertir e consumir informação e usa muitos dispositivos. Cada vez mais. Um americano adulto hoje usa em média 4 dispositivos conectados. Estamos vivendo uma explosão de dispositivos CLIQUE

    Estes dispositivos consomem aplicações modernas. Twitter, Facebook, Instagram. De simples a complexas. Cada usuário de iPhone investe em torno de 84 minutos por dia nas aplicações e têm no seu iPhone de 80 a 100 aplicações instaladas

    Estas aplicações geram e consomem uma quantidade crescente de dados. Este ano calendário o IDC estima que existam 2.7ZB (1ZB = 1 billion terabytes) um crescimento de 48% em um ano podendo chegar a 8ZB em 2015

    Estes dispositivos, aplicações e dados consomem uma quantidade crescente de serviços que obvimente rodam em servidores, nas configurações tradicinais (on premise, client server e mainframe) e as mais modernas public & private clouds.

    Só que existe a volta neste caminho. Milhões de usuários que usam dispositivos modernos podem ser encontrados com precisão por técnicas modernas de advertising que usam as apps como veículo. Isto é uma parte importante das estratégias de online advertising que podem acelerar o market share do advertising online versus as midias tradicionais como jornais, revistas, Tv e Rádio.
  • Aumento de sucesso a partir de 2001
  • Outro ponto que precisamos ficar atentos além da todo suporte a infraestrutra é o modelo de gestão de todo ciclo de desenvolvimento, aplicando um modelo de gestão moderna.
  • Outro ponto que precisamos ficar atentos além da todo suporte a infraestrutra é o modelo de gestão de todo ciclo de desenvolvimento, aplicando um modelo de gestão moderna.
  • A origem do termo scrum vem do esporte rúgbi, onde scrum define a aglomeração dos jogadores, muitas vezes vista como "formação ordenada". No scrum, 8 jogadores de cada time estão frente a frente e têm que fazer um esforço para recuperar a bola que se encontra no meio do "aglomerado".
  • Outro ponto que precisamos ficar atentos além da todo suporte a infraestrutra é o modelo de gestão de todo ciclo de desenvolvimento, aplicando um modelo de gestão moderna.
  • ACT = AGIR
  • 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 equips


    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 equips

    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
  • FATOR FOCO é onde uma estimativa de como a equipe é focada para achar o fator foco, então o calculo para encontrar esse “fator foco”


    HOMEM DIA
    Camilo: 20 dias
    João: 20 dias
    Maria: 10 dias
    50 homens-dia disponiveis
  • Métodos Ágeis

    1. 1. www.konia.com.br Métodos Ágeis Como trabalhar com engenharia de software sem perder a agilidade? Adriano Bertucci Consultor ALM – Konia Tecnologia Microsoft Visual Studio ALM MVP adriano.bertucci@konia.com.br @adrianobertucci
    2. 2. www.konia.com.br O Que veremos?  Métodos Ágeis  Métodos Tradicionais  Dinâmica conceitual  Scrum  Dinâmica conceitual
    3. 3. Como ganhar dinheiro resolvendo problemas que voce não conhece, com pessoas desconhecidas, em um tempo curto e com poucos recursos (e se www.konia.com.br Motivação divertindo)? Tradicional Nuvem privada Nuvem pública
    4. 4. www.konia.com.br Relatório do Chaos (Chaos Report)
    5. 5. www.konia.com.br Relatório do Chaos (Chaos Report)  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! DESPERDÍCIO!! !!
    6. 6. www.konia.com.br MOTIVAÇÃO
    7. 7. Como tratamos desenvolvimento de software? www.konia.com.br
    8. 8. www.konia.com.br Da para fazer diferente?
    9. 9. Problemas do mundo de desenvolvimento  Métodos tradicionais/clássicos de desenvolvimento www.konia.com.br  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  Softwares  Grande quantidade de erros  Falta de flexibilidade
    10. 10. www.konia.com.br Como resolver isso?  Melhores Tecnologias  Padrões de Projeto (reutilização de idéias)  Componentes (reutilização de código)  Middleware/frameworks (aumenta abstração)  Novas Metodologias Métodos Ágeis
    11. 11. O que é desenvolvimento de software? www.konia.com.br Modelagem (Jacobson) Engenharia (Meyer) Disciplina (Humphreys) Poesia (Cockburn) Artesanato (Knuth) Arte (Gabriel) Erro comum: olhar para software como apenas um desses itens e ignorar os demais
    12. 12. www.konia.com.br O que são métodos agéis? “Agile não é um conjunto de práticas, mas um conjunto de crenças e princípios” Jim Highsmith
    13. 13. www.konia.com.br PRINCIPIOS Retorno de investimento Inovação Melhoria de processo Pessoas Cultura Comunicação Adaptação x Antecipação
    14. 14. www.konia.com.br Manifesto ágil - histórico  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
    15. 15. www.konia.com.br Manifesto ágil
    16. 16. www.konia.com.br Um projeto ágil ideal…  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
    17. 17. www.konia.com.br Um projeto ágil ideal…  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
    18. 18. www.konia.com.br EVITE MULTI-tarefa
    19. 19. www.konia.com.br O segredo da comunicação…
    20. 20. www.konia.com.br O desafio de uma equipe auto organizada
    21. 21. www.konia.com.br Premissas básicas do modelo tradicional  É 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
    22. 22. www.konia.com.br Como funciona?
    23. 23. www.konia.com.br Mudança de postura! Tradicional Ágil Equipe Equipe Equipe Equipe GP Equipe Equipe Equipe Equipe GP Cross-funcional Auto-organização
    24. 24. www.konia.com.br Iterativo e incremental Desenvolvimento monolítico Interface Cliente Servidor BD C Desenvolvimento incremental Iterativo = não espere ter tudo correto na primeira vez Incremental = construa em ”pedaços” verticais (features) ao invés de horizontais (camadas) Talvez não seja necessário construir o resto C Interface Cliente Servidor BD Ref: Henrik Kniberg
    25. 25. www.konia.com.br Iterativo e incremental
    26. 26. IMPORTANTE!!! 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 www.konia.com.br das pessoas
    27. 27. Importante!!! Metodologias ágeis é uma febre? www.konia.com.br Uma onda passageira? É o início de uma mudança na forma de trabalho...
    28. 28. www.konia.com.br O Paradoxo da multitarefa
    29. 29. www.konia.com.br O Que muda?  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
    30. 30. www.konia.com.br 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 Ágil Tradicional
    31. 31. www.konia.com.br Relatório do Chaos (Chaos Report)
    32. 32. www.konia.com.br Principais métodos ágeis  Adaptative Software Development (ASD)  Crystal Clear (Crystal)  Extreme Programming (XP)  Scrum  Lean Software Development  Feature Driven Development (FDD)  Test Drive Development (TDD)  Kanban
    33. 33. www.konia.com.br Mudança de perspectiva
    34. 34. 5 motivos para NÃO usar métodos ágeis?
    35. 35. Qual projeto de software possui todos os requisitos definidos (corretamente) www.konia.com.br Motivo 1 Não preciso de ciclos iterativos no início? Eu sei e defino todos os requisitos no início do projeto
    36. 36. www.konia.com.br Motivo 2 O cliente descobre o que quer ao longo do caminho Os objetivos do meu projeto estão muito claros desde o início
    37. 37. www.konia.com.br Motivo 3 Qual projeto de software envolve baixa incerteza? Meu projeto envolve baixa incerteza
    38. 38. Em qual projeto de software consigo ter estimativas precisas? www.konia.com.br Motivo 4 Minha estimativa está toda definida e com índice de erro muito baixo
    39. 39. www.konia.com.br Praticando… PRODUÇÃO X PRODUTIVIDADE Analista Projetista Programador Testador Cliente Æ OE Ref: Luiz Cláudio Parzianello
    40. 40. www.konia.com.br Praticando… PRODUÇÃO X PRODUTIVIDADE Pequenos Lotes Æ … Æ Æ OE Æ … Æ OE Æ OE ™ Æ OE … ÆÆ OEOE ™™ … Ref: Luiz Cláudio Parzianello Æ Æ OE Æ OE ™ … … … … Grandes Lotes
    41. 41. www.konia.com.br Praticando… PRODUÇÃO X PRODUTIVIDADE  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?
    42. 42. SCRUM
    43. 43. www.konia.com.br SCRUM - Origem
    44. 44. Scrum foi criado no início da década de 1990 por Jeff Sutherland e Ken Schwaber, nos EUA www.konia.com.br Os pais da criança Ken Schwaber Jeff Sutherland
    45. 45. www.konia.com.br O que é SCRUM?  Um processo iterativo e incremental para o gerenciamento de projetos de desenvolvimento de produtos (especialmente software).  Mais um framework que uma metodologia.  Mais Atitude que uma processo. Cultura Auto-Gerenciamento, time multi-disciplinar, envolvimento do cliente, comprometimento, papéis, entregas frequentes, liderança, colaboração, Respeito, etc.
    46. 46. Beleza, mas como o SCRUM roda?
    47. 47. www.konia.com.br De forma iterativa
    48. 48. www.konia.com.br e Incremental…
    49. 49. www.konia.com.br Ênfase: processo empírico  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 PLAN DO ACT CHECK
    50. 50. www.konia.com.br O uso do SCRUM Ref.: 3rd Annual ”State of Agile Development” Survey June-July 2008 3061 respondentes, 80 países
    51. 51. www.konia.com.br O SCRUM possui 3 papéis.
    52. 52. www.konia.com.br Equipe de desenvolvimento  Auto gerenciáveis  “Sem títulos” definidos  TODOS são desenvolvedores
    53. 53. www.konia.com.br Product Owner  Responsável por Maximizar o ROI  Gerencia as demandas  Prioriza as tarefas  Garante o entendimento das tarefas  Apenas UMA pessoa
    54. 54. www.konia.com.br Scrum Master  Líder Servidor  Remover impedimentos  Proteger a equipe
    55. 55. www.konia.com.br SCRUM Master NÃO É Gerente de Projetos
    56. 56. www.konia.com.br Não delega tarefas; Não define responsabilidades;
    57. 57. www.konia.com.br Macro fases  Pregame  Planejamento  Desenho e alto nível da  Arquitetura  Modelo Abrangente  Game  Sprints (Modelagem incremental, desenvolvimento, revisões e ajustes)  Postgame  Fechamento (Agrupamento da Documentação, Treinamento, Lições Aprendidas)
    58. 58. www.konia.com.br
    59. 59. www.konia.com.br Fluxo do scrum
    60. 60. www.konia.com.br pregame
    61. 61. www.konia.com.br Product backlog
    62. 62. www.konia.com.br Business value - ROI  Business Value será uma moeda de troca durante o projeto e o cliente empresta um determinado valor dessa moeda para a equipe e esta por sua vez, terá que devolver o valor correspondente em forma de software, ou seja, é uma dívida que a equipe assume com o cliente e que deverá ser amortizada a cada ciclo(Sprint), até que a mesma seja totalmente liquidada (zerada).
    63. 63. www.konia.com.br User stories  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?  Deve ter  Deveria ter  Poderia ter
    64. 64. www.konia.com.br Priorização e classificação do backlog
    65. 65. www.konia.com.br Tarefas Administrate users User admin Register new user User admin Find user User admin 2 Edit existing user User admin Delete user Write failing test Do GUI design 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 Ref: Henrik Kniberg
    66. 66. www.konia.com.br Os objetivos SMART de uma Sprint
    67. 67. www.konia.com.br ESTIMATIVAS  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.
    68. 68. www.konia.com.br Sprint Planning Meeting
    69. 69. Velocidade da sprint – o que teremos? www.konia.com.br  Técnicas de estimativas  Instinto, sentimentos e percepções  O cálculo de velocidade pode ser baseado:  HOMEM DIA DISPONIVEL * FATOR FOCO = VELOCIDADE
    70. 70. www.konia.com.br O dia a dia do scrum 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
    71. 71. www.konia.com.br Sprint backlog
    72. 72. www.konia.com.br KANBAN - VISIBILIDADE
    73. 73. www.konia.com.br Burndown
    74. 74. www.konia.com.br Dashboard – visibilidade
    75. 75. www.konia.com.br Daily meetings Daily Meetings (Daily Scrum) Reunião diária de 15 minutos Mantém equipe informada e 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
    76. 76. www.konia.com.br Sprint review  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?
    77. 77. www.konia.com.br Próxima sprint  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 Lições aprendidas
    78. 78. www.konia.com.br Praticando Scrum  Fábrica de Aviões
    79. 79. Science to Business Copyright – Direitos autorais Copyright © 2011-2014 Konia Tecnologia. Este documento é inédito e a advertência precedente é fixada para proteger Konia Tecnologia. no caso de publicação não autorizada. Todos os direitos reservados. Nenhuma parte deste documento pode ser reproduzida em qualquer forma, inclusive fotocópia ou transmissão eletrônica para qualquer computador, sem autorização prévia por escrito de Konia Tecnologia. As informações contidas neste documento são confidenciais e propriedade da Konia Tecnologia. e não podem ser usadas ou reveladas exceto quando expressamente autorizado por escrito por Konia Tecnologia. Adriano Bertucci Consultor ALM – Konia Tecnologia Microsoft Visual Studio ALM MVP adriano.bertucci@konia.com.br @adrianobertucci

    ×