Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Desenvolvimento ágil com Scrum

Desenvolvimento ágil com Scrum

Principais metodologias utilizadas no Scrum e como aplicar de maneira prática e fácil.
--
Main methodologies used in Scrum and how to apply practical and easily.

Rodrigo Chimello

September 23, 2014
Tweet

More Decks by Rodrigo Chimello

Other Decks in Technology

Transcript

  1. FUNDAMENTOS DO SCRUM • Ampla visão do framework Scrum e

    suas peculiaridades • Entendimento sobre os processos essenciais do Scrum • Compreensão sobre os termos utilizados no Scrum 2
  2. O QUE É SCRUM 3 De onde saiu isso? O

    nome Scrum vem de uma jogada ou formação do Rugby, onde oito jogadores de cada time devem se encaixar para formar uma muralha. É muito importante que seja realizado um trabalho de equipe, pois se um dos jogadores na formação falhar, toda a jogada é comprometida.
  3. O QUE SIGNIFICA DESENVOLVIMENTO ÁGIL? Desenvolvimento ágil é um conjunto

    de estratégias para gerenciamento de projetos incremental e com ciclos de desenvolvimentos rápido. As vantagens disto são: • Melhoria continua de um projeto • Frequente resolução de problemas • Aumento da produtividade. O conceito surgiu em em oposição ao método cascata, no qual o desenvolvimento é linear. 5
  4. O QUE TORNA SCRUM DIFERENTE? Métodos tradicionais 6 Scrum •

    Seguir o planejamento à risca • Processos e ferramentas onerosos • Negociações contratuais complexas • Documentação detalhada • Indivíduos e interações • Colaboração com o cliente • Software funcional • Adaptação as mudanças
  5. O QUE TORNA SCRUM DIFERENTE? 7 Scrum é baseado em

    método de trabalho cuja eficácia foi comprovada em campo. Métodos tradicionais prescrevem processos ideais que são bons em teoria, mas não se comprovam na prática.
  6. VANTAGENS DO SCRUM Foco no valor agregado 8 • Todo

    o trabalho é priorizado em função do valor de negócio percebido pelo cliente • O time sempre está executando as tarefas que mais interessam aos stakeholders • Os stakeholders passam a enxergar os resultados mais rapidamente • Redução do desperdício de dinheiro e tempo na execução de itens de menor prioridade
  7. VANTAGENS DO SCRUM Visibilidade do progresso 9 • O trabalho

    é organizado de forma simples, portanto é fácil determinar o progresso do projeto • Todos os envolvidos sabem o que foi feito, o que está em execução e o que ainda deve ser realizado
  8. SEQUENCIAL VS PARALELO Sequencial 10 Um após o outro REQUISITOS

    CÓDIGO TESTES Paralelo ou Ágil Um pouco aqui, um pouco ali… AO INVÉS DE COMPLETAR UMA COISA POR VEZ… EQUIPES SCRUM FAZEM UM POUCO DE CADA COISA, TODO O TEMPO
  9. O TIME SCRUM 11 • O Time Scrum é um

    conjunto multi-disciplinar de profissionais. • Estes times devem ser autogeridos, ou seja, não existe hierarquia ou a figura de um líder. • O time deve decidir, em conjunto a melhor forma de completar o seu trabalho ao invés de receber ordens externas de alguem que não faz parte da equipe e por isto não tem o conhecimento empirico para determinar prazos, por exemplo. • A opinião de todos deve ser igualmente ouvida e respeitada. Mas existem alguns papéis fixos para auxiliar o bom andamento do trabalho.
  10. O TIME SCRUM Product Owner 12 • A responsabilidade do

    Product Owner, ou Dono do Produto, é garantir a qualidade do trabalho. • Atua como representante dos stakeholders perante o time. • Direciona o time estabelecendo metas e objetivos priorizados que atendam as necessidades e desejos dos stakeholders • É o responsável pela manutenção do Product Backlog
  11. O TIME SCRUM Scrum Master 13 • O Scrum Master,

    ao contrário do que o título pode sugerir, não manda na equipe. • Atua como moderador, facilitador do processo Scrum • Auxilia removendo obstáculos que impeçam o progresso do time • Gerencia o relacionamento do time com o Product Owner • Orienta a equipe para capacidade de auto-organização
  12. O TIME SCRUM Equipe de desenvolvimento 14 • Deve ser

    composto por até 9 pessoas • Equipe multifuncional responsável pela análise, projeto, implementação, e teste do sistema • A equipe coletivamente deve possuir todos os skills necessários para realizar o trabalho • O time é auto-organizado e trabalha pra atender as prioridades definidas pelo Product Owner
  13. EVENTOS 15 Quem nunca perdeu tempo em uma reunião longa

    e sem propósito? Pensando nisso todos os eventos Scrum são time-boxed, ou seja, tem uma duração fixa de tempo. Desta forma a comunicação é sempre mais clara, objetiva e ágil.
  14. EVENTOS Sprint 16 • Interação com duração de 2 a

    4 semanas • Cada Sprint deve possuir metas bem definidas, mensuráveis e exeqüíveis • São iniciados com reuniões de planejamento • São encerrados com reuniões de retrospectiva • O time se compromete a realizar o trabalho definido na reunião de planejamento
  15. EVENTOS Reunião de Planejamento 17 Nesta reunião serão definidos todos

    os objetivos da Sprint. Se o seu Sprint é de 2 semana, por exemplo, esta reunião terá a duração máxima de 4 horas. A primeira metade é a priorização do que deve ser feito entre o Product Owner e o Time A segunda metade é uma discussão da equipe para planejar o Sprint e gerar o Sprint Backlog Duas perguntas devem ser respondidas: - O que será entregue como resultado? - Como o trabalho necessário para entregar o produto será realizado?
  16. EVENTOS Reunião Diária 18 A idéia da reunião diária, ou

    stand-up meeting, é juntar a equipe para um bate-papo de 15 minutos no máximo para revisar o andamento do projeto. Cada membro da equipe deve responder as seguintes perguntas: - O que eu consegui completar ontem? - O que farei hoje? - Quais obstáculos estão impedindo o meu progresso? A função do Scrum Master é moderar a dinâmica e tentar ao máximo solucionar os obstáculos apresentados para que a Sprint seja bem sucedida.
  17. EVENTOS Revisão da Sprint 19 A idéia aqui, obviamente, é

    revisar todos os itens desenvolvidos e demonstrar o produto final. A duração desta reunião considerando um sprint de duas semana é 2 horas.
  18. EVENTOS Retrospectiva da Sprint 20 A sprint acabou! Agora é

    hora de olhar para trás e repensar: - O que deu certo - O que pode ser melhorado no futuro. - O que deu errado Cliente participativo Divulgação do Scrum Feedback Lanche no Final CONTINUAR MELHORAR PARAR Reunião diária Planejar Sprint Backlog Delegar tarefa Participar em vários projetos Equipe dispersa
  19. ARTEFATOS 21 Vamos ser sinceros… Artefato é só um nome

    mais estiloso para documento ou ferramenta. Mas eles ajudam a facilitar a sua vida…
  20. ARTEFATOS Product Backlog 22 O product backlog é uma compilação

    de tudo o que o seu cliente gostaria de realizar no projeto. Pense com uma grande wishlist com todos os recursos e funcionalidades. Esta lista deve ser organizada pelo Product Owner de acordo com valor, risco, prioridade e necessidade. Por natureza o backlog é algo dinâmico e muda constantemente para incluir as novas solicitações dos clientes. Desta forma os produtos são sempre aperfeiçoados em cada Sprint.
  21. ARTEFATOS Sprint Backlog 23 Agora que já sabemos tudo o

    que precisa ser realizado, a equipe define as tarefas a serem desenvolvidas na próxima Sprint. Esta lista é conhecida como Sprint Backlog. O Sprint Backlog é um afunilamento mais detalhado do Product Backlog.
  22. ARTEFATOS Incremento 24 É o produto que deve estar “pronto”

    após a Sprint. Pronto aqui é uma palavra relativa já que o incremento pode (e deve) ser aperfeiçoado em próximos Sprints. Cada equipe vai definir anteriormente o que pronto significa de acordo com o contexto. É importante, no entanto, que o incremento seja algo concreto e utilizável.
  23. ARTEFATOS Burndown Chart 25 É um gráfico que tem a

    função de monitorar o desenvolvimento da equipe. Funciona da seguinte maneira: todos os dias você anota quantas tarefas do seu Sprint Backlog foram efetivamente cumpridas. Desta maneira você pode saber com antecedência a velocidade que sua equipe trabalha. Este gráfico facilita a previsão de prazos futuros e até mesmo deduzir se a deadline vai estourar. O Burndown Chart é criado tendo como base dois eixos: um vertical representando a quantidade de trabalho que existe a ser feito (horas) e um horizontal para o tempo (dias). A linha diagonal mostrará a velocidade da equipe ao completar as tarefas. A Burndown Chart é uma ótima maneira de medir o nível de produtividade do seu projeto.
  24. ARTEFATOS Kanban Boards 26 É uma boa ferramenta de planejamento

    e funciona bem em conjunto com o framework. Basicamente é um quadro, ou um app, folha de papel, parede em branco, etc – com quatro lista de tarefas: - Não iniciado - Iniciado - Pronto Esta é uma ótima maneira de visualizar rapidamente o status de um projeto, independentemente do uso do Scrum.
  25. UM EXEMPLO CONCRETO 27 Artefatos, mestres, papéis… A primeira vista

    tudo isto pode parecer mais um jogo de RPG do que um framework de gerenciamento de projetos… Mas na verdade tudo é mais simples do que parece.
  26. UM EXEMPLO CONCRETO 28 A sua empresa tem um cliente

    X que quer lançar um novo sistema. Um gerente de projetos (Product Owner) faz um briefing e levanta todas as necessidades do sistema.
  27. UM EXEMPLO CONCRETO 29 Ele se reúne com os profissionais

    de design, front-end e back-end (Equipe de Desenvolvimento). Definindo todas as tarefas necessárias para produzir o projeto (Reunião de planejamento)
  28. UM EXEMPLO CONCRETO 30 O PO formaliza isto em uma

    lista de tarefas (Product Backlog). Você (Scrum Master) fica encarregado de organizar as reuniões e garantir que todos entendam as tarefas.
  29. UM EXEMPLO CONCRETO 31 A equipe decide democraticamente que vai

    entregar o Log inicial pronto (Objetivo/Meta) Até o final de 2 semanas (Sprint).
  30. UM EXEMPLO CONCRETO 32 A equipe então divide o objetivo

    em tarefas menores (Sprint Backlog) como criar o layout, desenvolver o código, implantar um sistema de administração de conteúdo e testar tudo em diversos Sistemas Operacionais. Cada um escolhe que tarefas gostaria de realizar, define um prazo de duração em horas para cada tarefa e diariamente vocês se reúnem por 15 minutos para acompanhar o andamento do projeto (Reunião Diária).
  31. UM EXEMPLO CONCRETO 33 Ao final da semana vocês apresentam

    o resultado (Revisão da Sprint) Refletem sobre dificuldades e quais melhorias podem ser feitas na próxima semana (Retrospectiva da Sprint). Cliente participativo Divulgação do Scrum Feedback Lanche no Final CONTINUAR MELHORAR PARAR Reunião diária Planejar Sprint Backlog Delegar tarefa Participar em vários projetos Equipe dispersa
  32. UM EXEMPLO CONCRETO 34 Mas mais importante de tudo vocês

    entregaram um produto parcial, porém funcional (Incremento) para o cliente.
  33. UM EXEMPLO CONCRETO 35 A partir do feedback de todos

    vocês decidem qual vai ser a tarefa a ser realizada na próxima semana. E assim o ciclo recomeça!
  34. HORA DE PRATICAR… 36 Vamos realizar um planejamento e iniciar

    a implementação do Scrum para a equipe. Definir papéis: - Product Owner - Scrum Master - Equipe de desenvolvimento Definir artefatos: - Product Backlog - Sprint Backlog - Burndown (Gráfico) - Kanban Boards Eventos/cerimônias: - Reunião de Planejamento da Sprint - Reunião diária - Revisão da Sprint - Retrospectiva da Sprint