Scrum - Um Método Ágil de Desenvolvimento de Sistemas

555 visualizações

Publicada em

Palestra de Gislaine Silva no evento Women Techmakers Sorocaba especial Dia Internacional da Mulher, em 28/03/15 no auditório da Biblioteca Municipal de Sorocaba.

"Scrum - Um Método Ágil de Desenvolvimento de Sistemas".

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

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

Nenhuma nota no slide
  • <number>
  • Scrum - Um Método Ágil de Desenvolvimento de Sistemas

    1. 1. SCRUM #WTM Sorocaba Março/2015
    2. 2. O desenvolvimento ágil é incremental, ou seja, não se faz um plano completo com tudo que devemos fazer para depois iniciar o desenvolvimento. Manifesto Ágil
    3. 3. O contato com o cliente é de extrema importância!! O produto é feito aos poucos e entregue constantemente. Toda mudança é bem vinda. Manifesto Ágil
    4. 4. Os indivíduos e interações Software funcionando Colaboração com o cliente Respostas a mudanças Manifesto Ágil Scrum + Que processos e as ferramentas documentação completa negociações de contratos seguir um plano PMBOK, RUP, UML, TDD, CMMI, MPS-BR, ISO....
    5. 5. “Scrum é um... framework Ágil utilizado para a gestão do desenvolvimento.” “Scrum é um... processo iterativo e incremental para desenvolvimento de qualquer produto ou gerenciamento de qualquer trabalho.” O que é o Scrum? Scrum não é...  Complexo  Extenso  Frágil  Garantia de Sucesso  XP
    6. 6. Rugby: Conjunto de 8 jogadores abraçados, realizam uma força onde o objetivo é empurrar o outro time e roubar a bola. Por que Scrum?
    7. 7. Pilares SCRUM
    8. 8. Transparência “Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. Esta transparência requer aspectos definidos por um padrão comum para que os observadores compartilharem um mesmo entendimento do que está sendo visto.” Todo o time deve ter uma visão comum e clara do processo inteiro.
    9. 9. “Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas.” Inspeção
    10. 10. “Se o inspetor determinar, a partir da inspeção, que um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, ele deverá ajustar o processo ou o material sendo processado. ” Adaptação
    11. 11. Conteúdo
    12. 12. Papéis
    13. 13. Papéis
    14. 14. Product Owner (PO) • Representante do Cliente • Gerencia o Product Backlog • Um por projeto • Facilitador entre Time -> Cliente • Não define como fazer, mas sim o que fazer primeiro
    15. 15. Product Backlog  Visão do produto  Elabora e prioriza o Product Backlog Exemplo de Product Backlog: Sistema de Reservas Online: Product Owner (PO) Nível de Prioridade Categoria Descrição do Item Backlog 1 Reserva Os clientes poderão fazer reserva de apartamento 1 Reserva Os clientes poderão cancelar a reserva 1 Reserva Os clientes poderão fazer alterações de data da reserva 1 Reserva Os clientes poderão fazer consultas de reservas 2 Reserva Criação do Book de reserva 1 Pagamento O meio de pagaamento da reserva serão por cartão de crédito 3 Apartamento Os apartamentos deverão ser cadastrados 3 Apartamento Os apartamentos são classificados por categoria 1 Cliente Precisamos registrar os dados dos clientes
    16. 16. User Stories  Pequena descrição do Product Backlog Product Owner (PO) Nível de Prioridade Categoria Descrição do Item Backlog 1 Cliente Precisamos registrar os dados dos clientes Título: Precisamos registrar os dados dos clientes Prioridade: 1 - Alta Todos os dados do cliente deverá ser registrado. Será possível alterar os dados se necessário. O Cliente deverá ter um "status" para que se possam definir quais são os clientes ativos e inativos
    17. 17. Facilitador Mantém contato constante com as partes interessadas e cuida para que haja um entendimento comum dos requisitos. Gerencia as mudanças e aceita ou rejeita os entregáveis da equipe. Product Owner (PO)
    18. 18. Scrum Master • Garante que o time adote o scrum • Garante produtividade e qualidade • Remove impedimentos • Pode ser um desenvolvedor • Não é o gerente
    19. 19. Scrum Master BurnDown • Atualiza o BurnDown diariamente
    20. 20. Time • Estima as histórias e tarefas • São interdisciplinares • Compartilham conhecimento • São Auto gerenciáveis
    21. 21. Time • Transforma o Sprint Backlog em produto Time
    22. 22. Artefatos
    23. 23. Product Backlog Exemplo de Product Backlog: Sistema de Reservas Online: Artefatos Nível de Prioridade Categoria Descrição do Item Backlog 1 Reserva Os clientes poderão fazer reserva de apartamento 1 Reserva Os clientes poderão cancelar a reserva 1 Reserva Os clientes poderão fazer alterações de data da reserva 1 Reserva Os clientes poderão fazer consultas de reservas 2 Reserva Criação do Book de reserva 1 Pagamento O meio de pagaamento da reserva serão por cartão de crédito 3 Apartamento Os apartamentos deverão ser cadastrados 3 Apartamento Os apartamentos são classificados por categoria 1 Cliente Precisamos registrar os dados dos clientes
    24. 24. Artefatos Sprint Backlog
    25. 25. Artefatos BurnDown
    26. 26. Cerimônias Sprint Planning Daily Meeting Sprint Review Sprint Retrospective
    27. 27. Uma reunião de curta duração que dura entre 3 a 4 horas e que tem como objetivo fazer todo o planejamento da Sprint. Sprints são eventos com duração fixa. (2 a 4 semanas) Sprint Planning Sprint Planning Participantes: Time, SM, PO Alguns objetivos: • Definir meta da Sprint • Estimar novos itens se necessário • Dividir as estórias em tarefas • Definir o conceito do “Done”.
    28. 28. Sprint Planning Sprint Planning Estimativas - Planning Poker O Planning Poker é a prática que ajuda na estimativa de uma estória ou de uma tarefa. 1 2 3 5 8 13 21 100 ?
    29. 29. Duração: 15 minutos, no máximo !!!  Objetivo: alinhar o desenvolvimento com a meta  Realizada de pé.  Sempre no mesmo local (reservado) e horário  Participantes: Scrum Master e Team Product Owner  Cada membro explica: O que fez desde a última reunião diária O que vai fazer até a próxima reunião diária Impedimentos, problemas, ...  Não são discutidas questões técnicas ou como serão feitas Daily Meeting Daily Meeting
    30. 30.  Tempo Estimado: 4 horas  Participantes: PO, Time e SM  Objetivo: Avaliar o que deu certo e que deu errado durante a Sprint e fazer ajustes possíveis para a próxima Sprint, ou seja, o ciclo de melhoria continua. Sprint Review Sprint Review
    31. 31. • Duração: 4 horas • Objetivo: refletir, rever e definir meios de entrega sem maiores transtornos e incômodos • Participantes: PO, SM e Time • Não há culpados, mas uma equipe que trabalha com objetivos Sprint Retrospective Sprint Retrospective
    32. 32. Revisão
    33. 33. Benefícios  VELOCIDADE, de entrega  QUALIDADE, sem bugs  MOTIVACÃO, no time  Trabalho em EQUIPE  Compartilhamento de CONHECIMENTO  INTERAÇÃO com o Cliente  Aceitar MUDANÇAS Sim, é possível! 
    34. 34. Scrum na prática... Dificuldades: • Resistência de quem está “perdendo poder” • Desmotivação de quem está fora do time • Visão tradicional dos superiores Mitos: • Scrum é para projetos pequenos • Somente para experientes e times nivelados • Não há documentação • Não tem como estimar, logo é impossível vender
    35. 35. Obrigada! 

    ×