SCRUM - Aula1

946 views

Published on

Slides da primeira aula do curso de Gestão Ágil de Projetos com SCRUM

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

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

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • SCRUM - Aula1

    1. 1. Gestão Ágil de Projetos com SCRUM Aula 1
    2. 2. Muito prazer!• Saulo Arruda (@sauloarruda) • Entusiasta/Praticante/Evangelista de métodos ágeis há 6 anos • Instrutor do SENAC há 5 anos e desenvolvedor há 12 anos • Co-fundador da Jera • Casado, pai de 2 filhas / Músico e cozinheiro amador
    3. 3. Fale sobre você!• Diga-nos seu nome?• Sua experiência com desenvolvimento de software?• Onde trabalha/estuda?• Quer falar mais alguma coisa?
    4. 4. O que teremos?• Aula 1 • Introdução ao Desenvolvimento Ágil de Software • Metodologias Ágeis • Práticas Ágeis
    5. 5. O que teremos?• Aula 2 • Introdução à engenharia de requisitos • Introdução à histórias do usuário • Métrica por pontos e estimativas
    6. 6. O que teremos?• Aula 3 • Papéis do SCRUM • Artefatos do SCRUM • Cerimônias do SCRUM
    7. 7. O que teremos?• Aula 4 • Executar projeto SCRUM
    8. 8. Mas antes...O que é Ágil?
    9. 9. O que NÃO É Ágil
    10. 10. Metodologia de Desenvolvimento• 1968 - Engenharia de Software• 1987 - CMM (Capability and Maturity Model)• 2001 - Agile Manifesto
    11. 11. Manifesto Ágil?• De 11 a 13 de Fevereiro de 2001, em uma estação de Esqui em Utah, 17 pessoas se encontraram para conversar, esquiar, relaxar, e tentar encontrar um senso comum - e claro, COMER!• Do resultado desse encontro surgiu...
    12. 12. Manifesto para odesenvolvimento ágil de software Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê- lo. Através deste trabalho, passamos a valorizar:Indivíduos e interação entre eles mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
    13. 13. Os Autores• Kent Beck • Arie van Bennekum• Ward Cunningham • James Grenning• Andrew Hunt • Jon Kern• Robert C. Martin • Ken Schwaber• Dave Thomas • Alistair Cockburn• Mike Beedle • Jim Highsmith• Margin Fowler • Brian Marick• Ron Jeffries • Jeff Sutherland• Steve Mellor
    14. 14. Os Autores• Kent Beck • Arie van Bennekum• Ward Cunningham • James Grenning• Andrew Hunt • Jon Kern• Robert C. Martin • Ken Schwaber• Dave Thomas • Alistair Cockburn• Mike Beedle • Jim Highsmith• Margin Fowler • Brian Marick• Ron Jeffries • Jeff Sutherland• Steve Mellor
    15. 15. PrincípiosPor trás do Manifesto Ágil, foi criada uma lista de 12 princípios que são seguidos...
    16. 16. 1º Princípio Nossa maior prioridade ésatisfazer o cliente,através da entrega adiantada e contínua de software de valor.
    17. 17. 2º Princípio Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam amudanças, para queo cliente possa tirar vantagens competitivas.
    18. 18. 3º Princípio Entregar software funcionando comfreqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos.
    19. 19. 4º Princípio Pessoas relacionadas à negócios e desenvolvedoresdevem trabalhar em conjunto e diariamente, durante todo o curso do projeto.
    20. 20. 5º PrincípioConstruir projetos ao redor de indivíduosmotivados. Dando a eles o ambiente esuporte necessário,e confiar que farão seu trabalho.
    21. 21. 6º Princípio O Método maiseficiente e eficaz de transmitirinformações para, e por dentro de um time dedesenvolvimento, é através de uma conversa cara a cara.
    22. 22. 7º PrincípioSoftware funcional é a medida primária de progresso.
    23. 23. 8º Princípio Processos ágeis promovem um ambiente sustentável. Os patrocinadores,desenvolvedores eusuários, devem sercapazes de manter indefinidamente,passos constantes.
    24. 24. 9º PrincípioContínua atenção àexcelência técnica e bom design,aumenta a agilidade.
    25. 25. 10º PrincípioSimplicidade: a arte de maximizar a quantidade de trabalho que nãoprecisou ser feito.
    26. 26. 11º Princípio As melhores arquiteturas,requisitos e designsemergem de times auto-organizáveis.
    27. 27. 12º Princípio Em intervalos regulares, o time reflete em como ficar mais efetivo,então, se ajustam e otimizam seucomportamento de acordo.
    28. 28. Métodos Ágeis• Ciclo de Vida Iterativo• Planejamento Adaptivo• Iterações Curtas com Duração Fixa• Alguns exemplos: eXtreme Programming, SCRUM, ICONIX, Agile UP, Open UP
    29. 29. Unified Process
    30. 30. Unified Process• Unified Process (UP) ou Processo Unificado não é simplesmente um processo, mas um framework que pode ser customizado para projetos e empresas específicas.• Exemplos de Processos baseados no UP: Agile UP, Basic UP, Enterprise UP, Essential UP, Open UP, Rational UP (RUP), Oracle Unified Method (OUM). [2][3]
    31. 31. Características do Unified Process• Iterativo e Incremental• Dirigido por Casos de Uso• Centrado na Arquitetura• Focado nos Riscos [2][3]
    32. 32. Ciclo de Vida do UP• Um projeto UP é dividido em 4 fases • Iniciação (ou Concepção) • Elaboração • Construção • Transição [2][3]
    33. 33. Processo Unificado
    34. 34. Iniciação• Definir o escopo e fronteiras• Identificação dos Casos de Uso• Identificação da Arquitetura candidata• Estimativa de riscos, custos e prazos [2][3]
    35. 35. Elaboração• Refinar Casos de Uso• Definir e validar da Arquitetura• Elaborar cronograma e custos para a Construção• Identificar e mitigar Riscos [2][3]
    36. 36. Construção• Implementação do código-fonte do software• Lançar builds contendo um conjunto de funcionalidades• Executar testes unitários, funcionais, de aceitação• Atualização do cronograma e lista de riscos [2][3]
    37. 37. Transição• Lançamento da versão final do software• Instalação em ambiente de produção• Testes de carga e stress• Treinamento dos usuários [2][3]
    38. 38. Discilplinas do UP• Uma disciplina mostra todas as atividades que você deve realizar para produzir um determinado conjunto de artefatos
    39. 39. Modelagem de Negócios• Entendimento da estrutura e problemas atuais do cliente;
    40. 40. Requisitos• Entender e descrever o escopo do problema que o software deve resolver;
    41. 41. Análise e Projeto• Transformar requisitos em um projeto (design);
    42. 42. Codificação• Implementar e testar classes em termos de componentes e integrar os resultados;
    43. 43. Teste• Localizar e documentar defeitos;
    44. 44. Implantação• Configurar e distribuir software;
    45. 45. Disciplinas gerenciais• Gestão de Configuração e Mudanças: identificação e restrição de mudanças em itens de configuração;• Gestão de Projeto: planejar, executar e monitorar o projeto;
    46. 46. Práticas do UP• Processo iterativo (iterações curtas com duração fixa), evolutivo e adaptativo;• Enfrentar problemas de alto risco e valor antes;• Envolver continuamente os usuários (avaliação e feedback);• Construir uma aquitetura central nas iterações iniciais;• Verificar continuamente a qualidade;
    47. 47. Ciclo de vida
    48. 48. SCRUM
    49. 49. Scrum?• SCRUM não é um processo;• SCRUM não é uma metodologia;• SCRUM é um framework;• SCRUM confia em um time auto- organizado e multi-disciplinar.
    50. 50. Três Papéis• Product owner: responsável pela área de negócio do projeto• ScrumMaster: garante que o time está funcional e produtivo• Time: time auto-organizável que realiza o trabalho
    51. 51. Quatro cerimônias• Planejamento do Sprint: o time se encontra com o product owner e determina o escopo da entrega• Daily scrum: o time se encontra diariamente para atualizar-se• Sprint reviews: o time demonstra para o product owner o que foi feito• Sprint retrospective: o time busca formas de melhorar o produto e processo
    52. 52. Três artefatos• Product Backlog: lista de funcionalidades ou tarefas• Sprint Backlog: lista de itens que serão entregues na sprint quebrados em tarefas• Burndown chart: gráfico de trabalho restante
    53. 53. eXtreme Programming
    54. 54. eXtreme Programming• Valores • Comunicação: diálogos presenciais • Coragem: mudanças são bem vindas • Feedback: descobrir problemas cedo • Respeito: ouvir e compreender • Simplicidade: fazer o que é necessário
    55. 55. eXtreme Programming• Princípios • Auto-semelhança • Melhoria • Benefício Mútuo • Oportunidade • Diversidade • Passos de Bebê • Economia • Qualidade • Falha • Redundância • Fluidez • Reflexão • Humanismo • Responsabilidade Aceita
    56. 56. eXtreme Programming• Papéis • Analistas de Teste • Programadores • Arquitetos • Recursos Humanos • Designers de • Redatores Técnicos Interação • Usuários • Executivos • Gerentes de Projeto • Gerentes de Produto
    57. 57. eXtreme Programming• Práticas Primárias • Ambiente Informativo • Folga • Build de Dez Minutos • Histórias • Ciclo Semanal • Integração Contínua • Ciclo Trimestral • Programação em Par • Desenvolvimento • Sentar-se Junto Orientado a Testes • Trabalho Energizado • Design Incremental • Equipe Integral
    58. 58. eXtreme Programming• Práticas Corolárias • Análise da Raiz do Problema • Envolvimento do • Base de Código Unificada Cliente Real • Código Coletivo • Equipes que Encolhem • Código e Testes • Implantação Diária • Continuidade da Equipe • Implantação Incremental • Contrato de Escopo • Pagar por Uso Negociável
    59. 59. Práticas Ágeis Organização DeployAutomatizado Time Releases Curtos Programação Retrospectivas em Pares Individual Daily Teste Propriedade Métricas Refatoração Stand-upsAutomatizado Coletiva de Velocidade Iterações Design Simples Padrão de Histórias Equipe do Usuário Ritmo Código Desenvovimento Sustentável co-localizada Dirigido por Testes Histórias Kick-off na Parede da Iteração Integração Cliente Contínua co-localizado
    60. 60. Quais você usa? Organização DeployAutomatizado Time Releases Curtos Programação Retrospectivas em Pares Individual Daily Teste Propriedade Métricas Refatoração Stand-upsAutomatizado Coletiva de Velocidade Iterações Design Simples Padrão de Histórias Equipe do Usuário Ritmo Código Desenvovimento Sustentável co-localizada Dirigido por Testes Histórias Kick-off na Parede da Iteração Integração Cliente Contínua co-localizado
    61. 61. A seguir...• Histórias do Usuário• Métricas por Pontos (velocidade)

    ×