Scrum e o Ambiente de Desenvolvimento Ágil

340 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
340
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Criado em 2001, descreve a essência de um conjunto de abordagens para desenvolvimento de software criadas ao longo da última década. 
    Principios
    Garantir a satisfação do consumidor entregando rapidamente e continuamente softwares funcionais
    Softwares funcionais são entregues frequentemente (semanas, ao invés de meses);
    Softwares funcionais são a principal medida de progresso do projeto;
    Até mesmo mudanças tardias de escopo no projeto são bem-vindas.
    Cooperação constante entre pessoas que entendem do 'negócio' e desenvolvedores;
     Projetos surgem através de indivíduos motivados, e que deve existir uma relação de confiança.
    Design do software deve prezar pela excelência técnica;
    Simplicidade;
    Rápida adaptação às mudanças;
    Indivíduos e interações mais do que processos e ferramentas;
    Software funcional mais do que documentação extensa;
    Colaboração com clientes mais do que negociação de contratos;
     Responder a mudanças mais do que seguir um plano.
  • Quem assinou?
    Kent Beck
    Martin Fowler
    Robert Martin (uncle bob)
    Dave Thomas
    Mike Beedle
    Arie van Bennekum
    Alistair Cockburn
    Ward Cunningham
    James Grenning
    Jim Highsmith
    Andrew Hunt
    Ron Jeffries
    Jon Kern
    Brian Marick
    Steve Mellor
    Ken Schwaber
    Jeff Sutherland
  • O nome vem do rugby. Reinício da partida.
    O SCRUM
    Acontece na disputa pela bola em casos de penalidades ou faltas. É normalmente formado por 3 linhas de jogadores, sendo 3 na primeira, 4 na segunda e 1 na terceira, totalizando 8 jogadores. A bola é jogada no meio do "túnel" do scrum pelo Half Scrum do time lesado pela penalidade pela esquerda do seu time. Neste momento um time tenta empurrar o outro até a bola sair entre as pernas dos jogadores e continuar o jogo. A bola não pode sair pelo túnel e a formação não pode cair nem girar mais de 90º sob pena de ter de repetir o scrum ou inclusive inverter a posse da bola a critério do juiz.
  • Equipes que se auto-organizam
    O produto evolui em uma série de “Sprints” mensais
    Os requerimentos são listados em um “Product Backlog”
    Não há prática de engenharia prescrita (o Scrum adequa-se a todas)
    Usa regras generativas na criação de um ambiente ágil para a entrega de projetos
  • Product Owner (CLIENTE - Dono do produto)
    Responsável por:
    – Lista de requisitos (product backlog)
    – Planejamento de Releases (priorizar)
    Team (EQUIPE)
    – Desenvolvimento de funcionalidades
    – Auto-gerido e auto-organizado
    – Multi-funcional
    ScrumMaster
    Ensinar Scrum aos outros envolvidos
    Manter o método nos trilhos
    Garantir que os outros envolvidos
    sigam as regras e práticas do SCRUM
  • Os requerimentos
    Lista todo trabalho desejado no projeto
  • Projetos Scrum progridem em uma série de “sprints”
    Obtém-se do backlog o que é de mais valor
    Planeja-se a iteração
    Faz-se acompanhamento diário
    Entrega acréscimo de funcionalidades ao fim da iteração.
    Ocorre em um período de duas a quatro semanas
    Um período constante leva a um melhor “ritmo”
    O produto é projetado, codificado e testado durante o sprint
    Nenhuma mudança durante o Sprint
  • Mostra quanto de trabalho resta na iteração final
    Quanto mais horizontal, melhor
  • Quadro do Scrum.
    *Product Backlog também pode ser montado em quadro na parede, utilizando post-it para cada tarefa
  • Planejamento do Sprint
    4 horas definindo itens mais importantes e empacotáveis do backlog de produto
    A equipe seleciona itens do Product Backlog com os quais compromete-se a concluir
    O Sprint Backlog é criado
    Tarefas identificadas e estimadas (1 a 16 horas)
    De forma colaborativa, não apenas feito pelo ScrumMaster
    Scrum Diário
    15 minutos
    Todos em pé!
    Não é para solução de problemas
    3 questões p/ todos
    O que fez ontem?
    O que vai fazer hoje?
    Há algum obstáculo?
    Revisão do Sprint
    Equipe apresenta os resultados obtidos durante o Sprint
    Tipicamente, demonstração de novas funcionalidades ou sua arquitetura
    Informal
    2 horas de preparação
    Sem slides
    Todo o time participa
    Todo mundo é convidado
    Retrospectiva do Sprint
    Periodicamente, observe o que funciona e o que não funciona
    Tipicamente de 15 a 30 minutos
    Feita após cada Sprint
    Toda a equipe participa
    A equipe discute o que gostaria de:
    Iniciar a fazer
    Parar de fazer
    Continuar fazendo
  • Extremo porque leva os princípios e práticas de senso comum ao extremo
    – “Se revisar código é bom, nós revisaremos código o tempo todo (programação em pares)”
    – “Se testar é bom, vamos testar o tempo todo (testes de unidade), inclusive os clientes(testes funcionais e de aceitação)”
    – São 12 práticas na primeira versão. Já foi estendido.
    Conservador: a maioria das práticas existem há décadas
  • "O XP está fazendo uma aposta. Ele está apostando que é melhor fazer uma coisa simples hoje e pagar amanhã um pouco mais para alterá-lo se preciso for, do que fazer uma coisa mais complicada hoje que nunca poderá ser usada de qualquer maneira. "
  • Feedback
    – Do estado do sistema. Testes.
    – Do cliente. Testes funcionais.
    – Da equipe para o cliente quando se planeja as liberações
  • Coragem
    – Desenvolver sem pensar no que pode acontecer amanhã não é um ato de coragem?
    – Jogar código fora também é, certo?
  • Programação em pares (in pair)
    Planning poker
    TDD
    Integração contínua
    Pequenas liberações
    Refactoring
    Padrões de Código e código de vários donos
    XP vai além da gerência!!!
  • Planning poker
  • “Framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação.”
    Mercado Atual exige conhecimento de Frameworks (Principalmente no ambiente ágil)
    O interessante do Grails é q ele surge como a solução mais bem aceita pra plataforma java do modelo ágil de dev. Ele é MVC, trabalha c/ principios Dry e CoC (convenção sobre configuração) e por ser baseado em rails e ter groovy (q é a linguagem dinâmica mais comentada da JVM) como linguagem ele se torna poderoso e bem aceito no mercado.
    Hibernate
    J2EE
    Struts
    Zend Framework
    Kumbia PHP Framework
  • We are discovering better ways of building communities by connecting people
    Trust - which must be respected and never put at risk;
    Dialog - is the way to establish a truly trustful relationship;
    Personal Contact - the richest experience, not matched by any media or technology;
    Transparency - the mean to maintain a sustainable community;
    Diversity - people have many interests, but if you need a label, label yourself as a human;
    Self-organization - leaders emerge, but there should be no owners;
    Example - that's how you must teach, live and learn;
    Consistency - things take time, intensity is not always the answer;
    Give, give, give! - you'll be impressed by how fast things will come back;
    Do it! - as simple as you can, just what is essential to pass it forward.
  • Scrum e o Ambiente de Desenvolvimento Ágil

    1. 1.  Indivíduos e Interações mais que processos e ferramentas.  Software funcionando mais que documentação abrangente.  Colaboração com cliente mais que negociação de contratos  Resposta a mudança mais que seguir um plano. www.agilemanifesto.org
    2. 2. • Effective Smalltalk • Extreme Programming • Junit Pocket guide • Tdd By example • Implementation Patterns •  Refactoring • Domain-Specific Languages • Patterns of Enterprise Application Architecture • UML • Beyond Software Architecture • Clean Code • Programming in Ruby
    3. 3.  São métodos utilizados no intuito de facilitar a adoção de práticas ágeis em processos tradicionais já definidos – não precisa substituir o processo Algumas são:  Extreme Programming – XP  Scrum  Kanban
    4. 4. PROJETOS DE PONTES PROJETOS DE SOFTWARE  – Prazo – OK ( menos no Brasil )  – Orçamento – OK  – Quase nenhuma cai  – Ciência Antiga – 4 a 6 mil anos  – Prazo – estoura  – Orçamento – estoura  – Têm problemas com freqüência  – Ciência nova – 50 anos Aspectos críticos – Projetos de ponte são engessados e ninguém dá “pitaco” – Projetos de software normalmente precisam suportar mudanças nas regras de negócio – Pontes que caem têm relatórios de erros. Softwares são mascarados e ignorados. Não há aprendizado Fonte: Joaquim Lopes Júnior joaquim@f6sistemas.com.br
    5. 5. Fonte: Joaquim Lopes Júnior joaquim@f6sistemas.com.br 1º Encontro PHPMG/2009
    6. 6.  Desenvolvimento ágil não garante necessariamente que o projeto terá mais ou menos sucesso  Mas ajuda a descobrir antes que algo não está indo bem – ITERAÇÕES CURTAS E ENVOLVIMENTO DO CLIENTE PARA VALIDAÇÃO Fonte: Joaquim Lopes Júnior joaquim@f6sistemas.com.br 1º Encontro PHPMG/2009
    7. 7. Vamos a elas: Scrum e XP
    8. 8.  Baseado na teoria de controle de processo industrial – Auto-organização e emergência  Utilizado há 15 anos com sucesso em milhares de projetos, centenas de organizações  É gerencial. Não serve apenas para projetos de software  Scrum é um processo ágil que permite manter o foco na entrega do maior valor de negócio, no menor tempo possível.
    9. 9.  Equipes que se auto-organizam  Prescreve os papéis de Product Owner (cliente) e Scrum Master, além da equipe (team)  O produto evolui em uma série de “Sprints” mensais  Os requerimentos são listados em um “Product Backlog”  Não há prática de engenharia prescrita (o Scrum adequa-se a todas)  Usa regras generativas na criação de um ambiente ágil para a entrega de projetos
    10. 10.  Product backlog
    11. 11.  Burndown Chart
    12. 12.  Planejamento do Sprint  Scrum Diário  Revisão do Sprint  Retrospectiva do Sprint
    13. 13.  Microsoft  Yahoo  Google  Electronic Arts  The New York Times  Philips  Siemens  Nokia  Globo.com  BBC  Intuit  Nielsen Media  First American Real Estate  BMC Software  Ipswitch  John Deere  Lexis Nexis  Sabre  Salesforce.com  Time Warner  Turner Broadcasting  Oce
    14. 14. Extreme Programming
    15. 15. “Jeito leve, eficiente, de baixo risco, flexível, previsível, científico e divertido de desenvolver software” - KentBeck
    16. 16.  Programadores trabalham em coisas que realmente importam  Cliente tem maior valor agregado possível a cada semana de desenvolvimento  Comunicação:  Interna e com o cliente  Simplicidade  Não olhar para frente. Para que pensar no trabalho de amanhã, se amanhã talvez ele não faça mais sentido?
    17. 17.  “XP is making a bet. It is betting that it is better to do a simple thing today and pay a little more tomorrow to change it if it needs it, than to do a more complicated thing today that may never be used anyway.” - Kent Beck
    18. 18. PROGRAMAÇÃO EM PAR
    19. 19. PLANNING POKER
    20. 20.  TDD  Integração contínua  Pequenas liberações  Refactoring  Padrões de Código e código de vários donos
    21. 21. “Contrate bons profissionais, dê a eles ferramentas e treinamentos para que façam o trabalho, depois saia da frente deles” Dave Thomas – OBT
    22. 22. Linguagens e Frameworks
    23. 23.  Linguagens de alto nível  Não são compiladas (em sua maioria)  Tipagem dinâmica  Duck Type  Vantagens e Desvantagens  Protocolo de Meta-Objeto (Meta-Object Protocol), ou MOP.  Forte presença no Ambiente ágil de Desenvolvimento.  Algumas Aceitam tipagem estática.
    24. 24.  Três principais linguagens Dinâmicas da Atualidade  Ruby e Python  Tipagem apenas dinâmica e não compiladas.  Mais populares linguagens do Meio ágil  Orientadas a objeto  Código legível  Groovy  Tipagem Dinâmica e Estática. Pode ser Compilada .  Solução ágil para plataforma JVM.  Grande integração com código Java.
    25. 25. Desenvolvendo Ágil
    26. 26. Testes Automatizados, TDD e BDD, Refatoração, CI Improve it
    27. 27. “Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object orientated or well- encapsulated it is. With tests, we can change the behavior of our code quickly and verifiable. Without them, we really don’t know if our code is getting better or worse.” Working Effectively With Legacy Code - Michael C. Feathers
    28. 28. “To me, legacy code is simply code without tests.” Working Effectively With Legacy Code - Michael C. Feathers
    29. 29.  De autoria do desenvolvedor  Escritos durante o desenvolvimento  Casos de teste  Sucesso  Falha  Especificação  Assert  Frameworks:  Junit  EasyMock  Selenium  Rspec  Cucumber
    30. 30.  Pedaços de código  Métodos  classes  Exemplo: Class matematica def soma(a,b) a+b end end
    31. 31. class TestMatematica def test_soma math = Matematica.new result = math.soma(2, 2) assert_equal(result, 4) end end
    32. 32. def test_parse arquivo = File.new(“tests/arquivo.txt”) parser = Parser.new parsed_content = parser.parse(arquivo) assert_equal(parsed_content, “teste”) end
    33. 33. def cliente_nao_deve_ser_salvo_sem_nome cliente = Cliente.new(:nome =>’’) salvo = cliente.save assert !salvo end
    34. 34.  Funcionalidades  Interação  Fluxo  Robôs
    35. 35.  Exemplos: def test_deve_criar_cliente assert_difference(‘Cliente.count’)do post :create, :cliente =>{:nome => ‘josé’} end assert_redirected_to cliente_path(assigns(:cliente)) end
    36. 36.  Exemplos: def test_deve_criar_cliente assert_difference(‘Cliente.count’)do post :create, :cliente =>{:nome => ‘josé’} end assert_redirected_to cliente_path(assigns(:cliente)) end
    37. 37.  Módulos  Banco de Dados  WebServices  RMI Fixtures  Dados utilizados nos testes  Simulam dados reais  Independente de esquema
    38. 38. TDD não é descrever testes, é descrever um comportamento.
    39. 39.  Testar Antes  Codificar depois  Codificar somente o necessário para o teste passar  Falha do teste indica próximo passo de codificação
    40. 40. Se você escrever testes antes, irá codificar melhor depois.
    41. 41.  Teste Falha  Teste passa  Refatorar Ciclo do TDD
    42. 42. Usando TDD, quando acabamos, realmente acabamos.
    43. 43.  DSL - Domain Specific Language  Especificar um comportamento  Especificar o sistema
    44. 44.  Exemplo com Rspec describe User end Usuário não existe!
    45. 45. class usuario end OK!
    46. 46. describe usuario it “deve estar no papel atribuido a ele” do usuario= Usuario.new usuario.should be_no_papel(“papel atribuido”) end end Método “no_papel?” não existe!
    47. 47. Class Usuario def no_papel?(papel) end end Método “no_papel?” retornou nulo mas deveria ter retornado verdadeiro!
    48. 48. Class Usuario def no_papel?(papel) true end end OK!
    49. 49. describe usuario it “deve estar no papel atribuido a ele” do usuario= Usuario.new usuario.should be_no_papel(“papel atribuido”) end end
    50. 50. describe usuario it “deve estar no papel atribuido a ele” do usuario= Usuario.new usuario.atribuir_papel(“papel atribuido”) usuario.should be_no_papel(“papel atribuido”) end end Método “atribuir_papel” não existe!
    51. 51. Class Usuario def no_papel?(papel) true end def atribuir_papel(papel) end end OK!
    52. 52. describe usuario it “deve estar no papel atribuido a ele” do usuario= Usuario.new usuario.atribuir_papel(“papel atribuido”) usuario.should be_no_papel(“papel atribuido”) end it “não deve estar no papel não atribuido a ele” do usuario= Usuario.new usuario.should_not be_no_papel(“papel não atribuido”) end end Método “in_role” retornou true
    53. 53. Class Usuario def no_papel?(papel) papel == “papel atribuido” end def atribuir_papel(papel) end end OK!
    54. 54. Hora de refatorar!
    55. 55. Class Usuario @papel def no_papel?(papel) @papel ==papel end def atribuir_papel(papel) @papel = papel end end
    56. 56. Usuario -deve estar no papel atribuido a ele -Não deve estar no papel não atribuido a ele Finished in 0.018 seconds 2 examples, 0 failures
    57. 57. Assuntos Pendentes
    58. 58.  CI – Integração Contínua  Repositório de codigo  Build automático  Execução de testes  Controle de releases  Deploy
    59. 59.  CI – Integração Contínua  Diminui o tempo de integração  Ambiente de build controlado  Detecção de bugs  Reduz riscos
    60. 60.  Refatoração  Pequenas mudanças  Preservam o comportamento externo  Mudanças estruturais  Organizam o código  Melhoram o entendimento  Facilitam adição de novas funcionalidades
    61. 61.  Considerações Finais  Testes especificam o software  Testes aumentam a qualidade  Testes melhoram o design  Testes provêem segurança  Testes dão liberdade
    62. 62.  Está provado que Desenvolvimento Ágil funciona e que é o que o mercado procura  Tendências do Mercado de TI apontam:  Programação em nuvem  Tecnologias que cortem custos e de retorno rápido do investimento aplicado  Tecnologias OpenSource e Sustentáveis  Comunidades coperativas  Ninguém faz nada sozinho  Mobilidade
    63. 63.  Criar grupos  Trocar conhecimentos  Aprender coisas novas  Estar sempre atualizados  Participar de eventos  Assistir palestras E depois, porque não: Um Happy Hour!!
    64. 64.  agilemanifesto.org  neactar.com  ruby-lang.org  rubyonrails.pro.br  python.org  groovy.codehaus.org  djangoproject.com  scrumalliance.org  improveit.com.br/scrum  improveit.com.br/xp  testdriven.com  improveit.com.br/xp/praticas/tdd  behaviour-driven.org/  martinfowler.com/articles/continuousIntegration  refactoring.com  infoq.com/br  grails.org
    65. 65. @abacrazytech @thiagocifani aba532@gmail.com cifani.thiago@gmail.com

    ×