Your SlideShare is downloading. ×
Métodos Ágeis - Aula02
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Métodos Ágeis - Aula02

157
views

Published on

Published in: Software

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
157
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. MÉTODOS ÁGEIS Aula 02 Adriano Bertucci Email: adriano@bertucci.com.br Twitter: @adrianobertucci Site: www.adrianobertucci.com
  • 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. RELATÓRIO DO CHAOS (CHAOS REPORT)
  • 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. MOTIVAÇÃO
  • 6. COMOTRATAMOS DESENVOLVIMENTO DE SOFTWARE?
  • 7. DA PARA FAZER DIFERENTE?
  • 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. 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. 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. 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. PRINCIPIOS Retorno de investimento Inovação Melhoria de processo Pessoas Cultura Comunicação Adaptação x Antecipação
  • 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. MANIFESTO ÁGIL
  • 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. 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. 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. 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. 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. EVITE MULTI-TAREFA
  • 21. O SEGREDO DA COMUNICAÇÃO…
  • 22. O DESAFIO DE UMA EQUIPE AUTO ORGANIZADA
  • 23. MUDANÇA DE POSTURA! Equipe Equipe Equipe Equipe GP Equipe Equipe Equipe Equipe GP Tradicional Ágil Cross-funcional Auto-organização
  • 24. COMO FUNCIONA?
  • 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. 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. 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. ITERATIVO E INCREMENTAL
  • 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. IMPORTANTE!!! Metodologias ágeis é uma febre? Uma onda passageira? É o início de uma mudança na forma de trabalho...
  • 31. O PARADOXO DA MULTITAREFA
  • 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. 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. RELATÓRIO DO CHAOS (CHAOS REPORT)
  • 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. 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. 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. MUDANÇA DE PERSPECTIVA
  • 39. 5 motivos para NÃO usar métodos ágeis?
  • 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. 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. Cinco Motivos para não usar Métodos Ágeis Motivo 3 Meu projeto envolve baixa incerteza Qual projeto de software envolve baixa incerteza?
  • 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. 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. 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. 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. SCRUM
  • 48. SCRUM - ORIGEM
  • 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. 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. Beleza, mas como o SCRUM roda?
  • 52. De forma Iterativa
  • 53. e Incremental...
  • 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. O USO DO SCRUM Ref.: 3rd Annual ”State of Agile Development” Survey June-July 2008 3061 respondentes, 80 países
  • 56. O SCRUM possui 3 papéis.
  • 57. Equipe de Desenvolvimento • Auto gerenciáveis; • “Sem títulos” definidos; • TODOS são desenvolvedores;
  • 58. Product Owner • Responsável por Maximizar o ROI; • Gerencia as demandas; • Prioriza as tarefas; • Garante o entendimento das tarefas; • Apenas UMA pessoa;
  • 59. SCRUM Master • Líder Servidor; • Remover impedimentos; • Proteger a equipe;
  • 60. SCRUM Master NÃO É Gerente de Projetos
  • 61. Não delega tarefas; Não define responsabilidades;
  • 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. FLUXO DO SCRUM
  • 64. PREGAME
  • 65. PRODUCT BACKLOG
  • 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. 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. PRIORIZAÇÃO E CLASSIFICAÇÃO DO BACKLOG
  • 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. OS OBJETIVOS SMART DE UMA SPRINT
  • 71. SPRINT PLANNING MEETING
  • 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. 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. 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. SPRINT BACKLOG
  • 76. KANBAN -VISIBILIDADE
  • 77. BURNDOWN
  • 78. DASHBOARD –VISIBILIDADE
  • 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. 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. 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. PRATICANDO… DINÂMICA DOS AVIÕES
  • 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

×