Métodos Ágeis - Aula02

442 views

Published on

Published in: Software
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
442
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Métodos Ágeis - Aula02

  1. 1. MÉTODOS ÁGEIS Aula 02 Adriano Bertucci Email: adriano@bertucci.com.br Twitter: @adrianobertucci Site: www.adrianobertucci.com
  2. 2. MOTIVAÇÃO Como ganhar dinheiro resolvendo problemas que voce não conhece, com pessoas desconhecidas, em um tempo curto e com poucos recursos (e se divertindo)?
  3. 3. RELATÓRIO DO CHAOS (CHAOS REPORT)
  4. 4. RELATÓRIO DO CHAOS (CHAOS REPORT)  Estudo doThe 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!!!!
  5. 5. MOTIVAÇÃO
  6. 6. COMOTRATAMOS DESENVOLVIMENTO DE SOFTWARE?
  7. 7. DA PARA FAZER DIFERENTE?
  8. 8. PROBLEMAS DO MUNDO DE DESENVOLVIMENTO 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
  9. 9. COMO RESOLVER ISSO?  MelhoresTecnologias  Padrões de Projeto (reutilização de idéias)  Componentes (reutilização de código)  Middleware/frameworks (aumenta abstração)  Melhores Metodologias Métodos Ágeis
  10. 10. O QUE É DESENVOLVIMENTO DE SOFTWARE? (Gabriel)Arte (Knuth)Artesanato (Cockburn)Poesia (Humphreys)Disciplina (Meyer)Engenharia (Jacobson)Modelagem Erro comum: olhar para software como apenas um desses itens e ignorar os demais
  11. 11. O QUE SÃO MÉTODOSAGÉIS? “Agile não é um conjunto de práticas, mas um conjunto de crenças e princípios” Jim Highsmith
  12. 12. PRINCIPIOS Retorno de investimento Inovação Melhoria de processo Pessoas Cultura Comunicação Adaptação x Antecipação
  13. 13. 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
  14. 14. MANIFESTO ÁGIL
  15. 15. PRINCÍPIOS  Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.  Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.  Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.  Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.
  16. 16. PRINCÍPIOS  Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.  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.  Software funcional é a medida primária de progresso.  Processos ágeis promovem um ambiente sustentável.Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
  17. 17. PRINCÍPIOS  Contínua atenção à excelência técnica e bom design, aumenta a agilidade.  Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.  As melhores arquiteturas, requisitos e designs emergem de times auto- organizáveis.  Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.
  18. 18. 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
  19. 19. 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
  20. 20. EVITE MULTI-TAREFA
  21. 21. O SEGREDO DA COMUNICAÇÃO…
  22. 22. O DESAFIO DE UMA EQUIPE AUTO ORGANIZADA
  23. 23. MUDANÇA DE POSTURA! Equipe Equipe Equipe Equipe GP Equipe Equipe Equipe Equipe GP Tradicional Ágil Cross-funcional Auto-organização
  24. 24. COMO FUNCIONA?
  25. 25. UM PROJETOTRADICIONAL… 0. Levantamento de Requisitos 1.Análise de Requisitos 2. Desenho da Arquitetura 3. Implementação 4.Testes 5. Produção / Manutenção
  26. 26. PREMISSAS BASICAS 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
  27. 27. ITERATIVO E INCREMENTAL 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 1 2 3 4 1 Desenvolvimento incremental 2 3 Talvez não seja necessário construir o resto C Interface Cliente Servidor BD Ref: Henrik Kniberg
  28. 28. ITERATIVO E INCREMENTAL
  29. 29. 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 das pessoas
  30. 30. IMPORTANTE!!! Metodologias ágeis é uma febre? Uma onda passageira? É o início de uma mudança na forma de trabalho...
  31. 31. O PARADOXO DA MULTITAREFA
  32. 32. 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
  33. 33. 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
  34. 34. RELATÓRIO DO CHAOS (CHAOS REPORT)
  35. 35. E SE FOSSE ESSA A REALIDADE?  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)
  36. 36. E ESSA É A NOVA REALIDADE! (EM MUITOSCASOS)  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
  37. 37. PRINCIPAIS MÉTODOS ÁGEIS  Adaptative Software Development (ASD)  CrystalClear (Crystal)  Extreme Programming (XP)  Scrum  Lean Software Development  Feature Driven Development (FDD)  Test Drive Development (TDD)  Kanban
  38. 38. MUDANÇA DE PERSPECTIVA
  39. 39. 5 motivos para NÃO usar métodos ágeis?
  40. 40. Cinco Motivos para não usar Métodos Ágeis Motivo 1 Eu sei e defino todos os requisitos no início do projeto Não preciso de ciclos iterativos Qual projeto de software possui todos os requisitos definidos (corretamente) no início?
  41. 41. Cinco Motivos para não usar Métodos Ágeis Motivo 2 Os objetivos do meu projeto estão muito claros desde o início O cliente descobre o que quer ao longo do caminho
  42. 42. Cinco Motivos para não usar Métodos Ágeis Motivo 3 Meu projeto envolve baixa incerteza Qual projeto de software envolve baixa incerteza?
  43. 43. Cinco Motivos para não usar Métodos Ágeis Motivo 4 Minha estimativa está toda definida e com índice de erro muito baixo Em qual projeto de software consigo ter estimativas precisas?
  44. 44. Cinco Motivos para não usar Métodos Ágeis Motivo 5 Meu processo é rígido e controlado (comando- controle) As tarefas são delegadas, equipes ficam desmotivadas mais facilmente Qual equipe gosta de trabalhar desmotivada?
  45. 45. Cinco Motivos para não usar Métodos Ágeis 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?
  46. 46. E os Cinco Motivos? 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?
  47. 47. SCRUM
  48. 48. SCRUM - ORIGEM
  49. 49. Os pais da criança Jeff SutherlandKen Schwaber Scrum foi criado no início da década de 1990 por Jeff Sutherland e Ken Schwaber, nos EUA
  50. 50. O QUE É O SCRUM  Um processo iterativo e incremental para o gerenciamento de projetos de desenvolvimento de produtos (especialmente software).  Mais um framework que uma metodologia.  MaisAtitude que uma processo. Cultura Auto-Gerenciamento, time multi-disciplinar, envolvimento do cliente, comprometimento, papéis, entregas frequentes, liderança, colaboração, Respeito, etc.
  51. 51. Beleza, mas como o SCRUM roda?
  52. 52. De forma Iterativa
  53. 53. e Incremental...
  54. 54. Ê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
  55. 55. O USO DO SCRUM Ref.: 3rd Annual ”State of Agile Development” Survey June-July 2008 3061 respondentes, 80 países
  56. 56. O SCRUM possui 3 papéis.
  57. 57. Equipe de Desenvolvimento • Auto gerenciáveis; • “Sem títulos” definidos; • TODOS são desenvolvedores;
  58. 58. Product Owner • Responsável por Maximizar o ROI; • Gerencia as demandas; • Prioriza as tarefas; • Garante o entendimento das tarefas; • Apenas UMA pessoa;
  59. 59. SCRUM Master • Líder Servidor; • Remover impedimentos; • Proteger a equipe;
  60. 60. SCRUM Master NÃO É Gerente de Projetos
  61. 61. Não delega tarefas; Não define responsabilidades;
  62. 62. 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)
  63. 63. FLUXO DO SCRUM
  64. 64. PREGAME
  65. 65. PRODUCT BACKLOG
  66. 66. BUSINESSVALUE - 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).
  67. 67. 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
  68. 68. PRIORIZAÇÃO E CLASSIFICAÇÃO DO BACKLOG
  69. 69. TAREFAS 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
  70. 70. OS OBJETIVOS SMART DE UMA SPRINT
  71. 71. SPRINT PLANNING MEETING
  72. 72. 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.
  73. 73. VELOCIDADE DA SPRINT – O QUE TEREMOS?  Técnicas de estimativas  Instinto, sentimentos e percepções  O cálculo de velocidade pode ser baseado:  HOMEM DIA DISPONIVEL * FATOR FOCO = VELOCIDADE
  74. 74. 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
  75. 75. SPRINT BACKLOG
  76. 76. KANBAN -VISIBILIDADE
  77. 77. BURNDOWN
  78. 78. DASHBOARD –VISIBILIDADE
  79. 79. DAILY MEETINGS 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
  80. 80. 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?
  81. 81. 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
  82. 82. PRATICANDO… DINÂMICA DOS AVIÕES
  83. 83. TRABALHO - ARTIGO…  Diserte sobre SCRUM, descrevendo seu funcionamento, seus beneficios e as dificuldades em se adotar a metodologia.  DATA DE ENTREGA 06/06/2014

×