Your SlideShare is downloading. ×
Synapses Scrum
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

Synapses Scrum

439
views

Published on

Apresentação interna para treinamento sobre framework Scrum.

Apresentação interna para treinamento sobre framework Scrum.

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
439
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
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. + Introdução ao Scrum Tiago Machado tiago@synapses.com.br
  • 2. + 2 Introdução ao Scrum
  • 3. + 3 Origem do termo  O scrum é uma situação freqüente no Rugby, geralmente usada após uma jogada irregular ou em alguma penalização. Os jogadores das duas equipes se agrupam e se colocam uns contra os outros.  O jogador da equipe que não cometeu a infração insere a bola no meio do "túnel" formado pelas duas primeiras linhas de cada equipe com a finalidade de que os jogadores da sua equipe consigam ganhar a bola. “Na abordagem no estilo de rugby, o desenvolvimento surge a partir de constante interação, onde um grupo disciplinado trabalha junto do início ao fim.” Nonaka e Takeuchi – The New New Product Development Game - 1986
  • 4. + 4 O que é o Scrum?  É um framework de processo leve para gestão de projetos, seguindo os valores e princípios ágeis;  É um esqueleto de processo que estabelece um conjunto de práticas e papéis;  Foco na entrega de maior valor de negócio no menor tempo;  Suas ênfases estão em: comunicação, trabalho em equipe e flexibilidade;  Não descreve o que fazer em cada situação. É usado para trabalhos complexos nos quais é impossível predizer tudo o que irá ocorrer.
  • 5. + 5 Teoria da Complexidade A = Sistemas simples B = Sistemas complicados C = Sistemas complexos Desconhecidos D = Sistemas caóticos D No patterns Requisitos C Emergent Practices (Scrum) B Best / Good Practices (PMBOK) Conhecidos A Definida Tecnologia Indefinida
  • 6. + 6 Teoria do Scrum  O Scrum é fundamentado na teoria de controle de processos ricos e emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. Processo Definido x Processo Empírico:  Processo Definido: baseado em leis fundamentais, busca a cada execução conquistar o mesmo resultado, utilizando um processo conhecido que transforma um conjunto de variáveis conhecidas. Basta repetir a fórmula correta, e o sucesso é garantido.  Exemplo de aplicação: Engenharia Civil (PMBOK)  Processo Empírico: nem todas as variáveis são conhecidas, o sistema está começando a ser compreendido, é complexo, as necessidades ainda não foram totalmente identificadas e com o tempo pode ser alterado.  Exemplo de aplicação: Desenvolvimento de Software (Scrum)
  • 7. + 7 Modelo tradicional em cascata Determinismo Um processo de desenvolvimento previamente conhecido por gerar determinados resultados com base nas especificações, gerará resultados semelhantes sempre que suas regras forem rigidamente seguidas. Problema: baseia-se em premissas que não se aplicam ao trabalho de desenvolvimento de software.
  • 8. + 8 Tipos de profissionais  Trabalhador manual  Trabalhador do conhecimento Para atividades que envolvem trabalhadores manuais, erros podem e devem sempre ser evitados, e os processos rígidos e determinísticos ajudam a alcançar este objetivo. Já para atividades que envolvem trabalhadores do conhecimento, erros devem ser encarados como coisas naturais, saudáveis e até inevitáveis. “Tentar sistematizar ou impor metodologias rígidas ao processo de desenvolvimento, visando o determinismo, no máximo torna as pessoas defensivas e pouco criativas." Ken Schwaber
  • 9. + 9 Resultados do desenvolvimento tradicional Bem sucedidos – O projeto é finalizado no prazo, dentro do orçamento e contendo todas as funcionalidades especificadas. Comprometidos – O projeto é finalizado e um software operacional é entregue, porém o orçamento e o prazo ultrapassam os limites estipulados, e, além disso, o software entregue possui menos funcionalidades do que o especificado.Standish Group InternationalChaos Research 2002 Fracassados – O projeto é cancelado em algum momento durante o desenvolvimento.
  • 10. + 10 História • Takeuchi e Nonaka conceberam o Scrum como uma a alternativa de gerenciamento de projetos em empresas de fabricação de automóveis e produtos de consumo. Eles notaram que projetos usando equipes pequenas e multidisciplinares produziram os melhores resultados, e associaram1986 estas equipes altamente eficazes à formação Scrum do Rugby. • Jeff Sutherland, John Scumniotales e Jeff McKenna conceberam, documentaram e implementaram o Scrum, conforme descrito abaixo, na empresa Easel Corporation1993 • Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo no desenvolvimento de softwares em todo o mundo1995 • Manifesto Ágil2001
  • 11. + 11 Manifesto Ágil  “Nós estamos descobrindo novas maneiras de desenvolver software fazendo e ajudando outros a fazê-lo. Através deste trabalho nós valorizamos:  Indivíduos e interações mais que processos e ferramentas;  Software funcionando mais que documentação compreensiva;  Colaboração do cliente mais que negociação de contrato;  Responder à mudança mais que seguir um plano;  Isto é, muito embora valorizemos os itens da direita, valorizamos mais os da esquerda!”  http://www.agilemanifesto.org/
  • 12. + 12 Influenciar pessoas por valores e princípios e não por regras
  • 13. + 13 Tipos de Projeto Projeto Urgente Projeto Crítico Projeto sem orçamento Escopo Escopo EscopoCusto Prazo Custo Prazo Custo Prazo
  • 14. + 14 Projetos Arriscados Urgente e Crítico Crítico e Sem Orçamento Urgente e Sem Orçamento Escopo Escopo EscopoCusto Prazo Custo Prazo Custo Prazo
  • 15. + 15 “Marcha para a morte”  Urgente Escopo  Crítico  Sem Orçamento Custo Prazo
  • 16. + 16 O mais comum em projetos Scrum Escopo Custo Prazo Viagem de férias Prazo: 7 dias Custo: R$ 10.000,00 Escopo flexível
  • 17. + 17 Pilares do Scrum  Transparência: garante que aspectos do processo que afetam o resultado devem ser veis para aqueles que gerenciam os resultados.  Inspeção: Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que es veis no processo possam ser detectadas. A frequência da o deve levar em o que qualquer processo modificado pelo prio ato da o.  Adaptação: a partir da o, se um ou mais aspectos do processo o fora dos limites veis e que o produto resultante vel, devemos ajustar o processo omais pido vel para minimizar desvios posteriores.
  • 18. + 18 Papéis no Scrum  Product Owner = PO  Scrum Master = SM  Scrum Team = ST  Stakeholders  UsuáriosNão há mapeamento direto entre papéis tradicionais para os papéis do Scrum. Não confundir papéis do Scrum com cargo.
  • 19. + 19 Product Owner  É o especialista do negócio e representa o cliente e os stakeholders;  Estabelece e comunica a visão do produto;  Administra fundos e recursos do projeto;  Decide quando serão liberadas as versões do produto;  É responsável por compreender as necessidades do negócio e apoiar o Scrum Team para sanar dúvidas sobre os requisitos do projeto;  É responsável por controlar o escopo e priorizar o que será feito primeiro, com objetivo de assegurar a entrega dos requisitos mais valiosos;  Responsável pelo macro-gerenciamento do projeto.  Pode ser visto como o “Gerente do Produto”.
  • 20. + 20 Scrum Master  É responsável por liderar o time ao sucesso, removendo obstáculos e impedimentos;  É o guardião do processo, assegurando que as práticas do Scrum sejam utilizadas com a disciplina necessária;  Organiza e conduz as cerimônias do Scrum;  Faz um papel do tipo “coach” atuando ao lado dos membros do Scrum Team e do PO;  Ajuda o Time Scrum a entender e usar autogerenciamento e interdisciplinaridade;  É um agente de mudança, mobilizando e conscientizando todos os envolvidos sobre o Scrum.  Pode ser visto como “Gerente do Processo”.
  • 21. + 21 Scrum Team  Equipe multi-funcional que reune todas as especializações necessárias para implementação do projeto;  Estima o esforço necessário para implementar itens do Product Backlog selecionados para o próximo sprint;  Expande os itens do sprint backlog em atividades e gerencia seu próprio trabalho até completar todo o sprint;  Realiza a reunião diária para garantir a comunicação plena do time e sincronismo de tarefas;  Identifica pendências e impedimentos e comunica ao Scrum Master.  Inspeciona e cobra de si mesmo o comprometimento necessário para atingir as metas acordadas.  Responsável pelo micro-gerenciamento do projeto.
  • 22. + 22 Stakeholders  São todos os interessados no software em desenvolvimento, a começar por clientes (internos ou externos), usuários finais, equipe de marketing e vendas, etc.  São representados pelo Product Owner, que deve conhecer o interesse e coletar idéias de todos para constituir o Product Backlog e priorizá-lo constantemente.
  • 23. + 23
  • 24. + 24 E o gerente de projeto?
  • 25. + 25 Comprometimento x Envolvimento • Porcos – Time! • Galinhas – Qualquer outra pessoa (PO, SM, Stakeholders). “Galinhas” o podem dizer aos “porcos” como eles devem fazer seu trabalho.
  • 26. + 26 Conceito: Time-box  O Scrum é baseado em eventos de duração fixa;  Garante que não iremos gastar mais esforço do que o necessário;  Se as cerimônicas e eventos não tivessem hora para terminar, ninguém manteria o foco.  Aumenta produtividade e efetividade.
  • 27. + 27 Conceito: Sprint  É o período dentro do qual um conjunto de atividades deve ser executado para que seja possível entregar ao cliente uma parcela de software útil (funcionando).  Duração de 2 a 4 semanas. Depois de definida para o projeto, não deve mudar;  Sprint padrão na Synapses: 10 dias úteis;  Não deve ter seu escopo modificado após seu início;
  • 28. + 28 Sprint Goal – Meta do sprint  É um objetivo proposto pelo aceito pelo time;  O sprint goal é a meta que irá nortear e motivar o time; Exemplos:  Colocar uma versão beta do produto no ar para permitir avaliação e demonstração do produto;  Automatizar a funcionalidade de o de conta de clientes s de um middleware seguro capaz de recuperar es.
  • 29. + 29 Fases do Desenvolvimento Sprint Sprint 1 2 Pré-game Game Pós-game Sprint Sprint 4 3
  • 30. + 30 Pré-Game  Análise e levantamento de requisitos  Análise de viabilidade do projeto  Criação do Documento de Visão do Projeto (DV)  Público-alvo  Definição do problema  Benefícios  Macro-funcionalidades  Diferenciais competitivos  Restrições de prazo e custo  Riscos  Papéis  Configurações do Scrum  Criação do Product Backlog inicial (priorizado);  Montagem do Scrum Team / Scrum Master;  Realização de Treinamentos Necessários  Plano de Projeto Leve ou Release Plan (duração dos sprints, estimativa inicial, velocidade, número de sprints, entregas).
  • 31. + 31 Game  A fase de game é onde o projeto será desenvolvido propriamente dito.  O desenvolvimento é dividido em sprints, conforme o tamanho e complexidade do projeto.  Cada sprint de 10 dias deve seguir a seguinte estrutura:  Sprint planning 1 (4h)  Sprint planning 2 (4h)  Desenvolvimento + Daily Meeting (8 dias)  Sprint Review (4h)  Sprint Retrospective (2h)
  • 32. + 32 Configurações do Scrum  Tamanho do sprint  Tamanho da equipe  Definição de Ready = forma de garantir para o time que as estórias estão prontas para serem desenvolvidas.  Definição de Done = forma de garantir para o PO que as estórias estarão concluídas e prontas ao término de um sprint.  Scrum but  Scrum and
  • 33. + 33 Scrum típico na Synapes  Tamanho do sprint: 10 dias úteis (começando na segunda)  Equipe típica:  PO  SM  Scrum Team = 2 desenvolvedores  Definição de Ready:  Estória priorizada no product backlog  Escopo da estória definido e compreendido pelo PO  Testes de aceitação elaborados pelo PO  Definição de Done:  Estória implementada conforme padrão de condificação Synapses  Código-fonte revisado e auditado;  Scripts de banco de dados revisados e auditados;  Testes automatizados implementados;  Deploy em ambiente de teste realizado;
  • 34. + 34 Game – Fluxo de trabalho
  • 35. + 35 Sprint Típico S T Q Q S S T Q Q S Planning 1 Desenvolvimento Review Planning 2 Testes Daily Scrum Retrospectiva
  • 36. + 36 Cerimônias do Scrum  Daily Scrum  Sprint Planning 1  Sprint Review  Sprint Planning 2  Sprint Retrospective
  • 37. + 37 Sprint Planning 1 – O que?  Reunião realizada todo início de sprint, com duração de 4 horas (time boxed);  Participação do Product Owner (PO), Scrum Master (SM) e Scrum Team.  Passagem do entendimento sobre o backlog “pré-selecionado”, do PO para o Scrum Team;  O PO propõe a meta do sprint.  O Scrum Team realiza a estimativa inicial de tamanho para ver se é possível cumprir a meta.
  • 38. + 38 Sprint Planning 2 – Como?  Reunião realizada após o Sprint Planning 1, com duração estimada de 4 horas (time boxed).  Planejamento do Scrum Team para seu próprio trabalho: ele refina a análise do itens priorizados pelo PO no Product Backlog, criando a lista de Sprint Backlog;  O Product Owner pode estar presente para esclarecer o Backlog do Produto e para ajudar a efetuar trocas.  Se o Time concluir que ele tem trabalho demais ou de menos, ele pode renegociar o Backlog do Produto escolhido com o Product Owner.  O time finaliza a estimativa iniciada no Sprint Planning 1, reportando ao PO o resultado para confirmação ou pequenos ajustes.  Ao sair dessa reunião, o time deve ter quebrado cada estória em tarefas. Cada tarefa deve ter duração máxima de 8h (ou 1 dia de trabalho).
  • 39. + 39 Daily Scrum  Reunião realizada diariamente, sempre no mesmo lugar e no mesmo horário, de preferência em pé.  Duração estimada de 15 minutos;  Participação do Scrum Team e Scrum Master; Demais Stakeholders podem ser convidados como “galinha”;  Cada participante responde 3 perguntas:  O que você fez hoje?  O que o atrapalhou?  O que você fará amanhã?
  • 40. + 40 Sprint Review  Reunião realizada após cada Sprint, com duração máxima de 4 horas e participação do PO.  O Scrum Team demonstra o trabalho realizado no Sprint.  A demonstração deve ser “de produto funcionando” (nada de powerpoint) e deve comprovar que os itens do Sprint Backlog prioritários foram de fato desenvolvidos.  O PO avalia o time com relação ao Sprint Goal.
  • 41. + 41 Retrospective Meeting  Reunião realizada após o Sprint Review, com duração máxima de 2 horas, com a participação de todos os envolvidos;  Alinhamento em grupo do que ocorreu no Sprint;  Todos respondem 2 perguntas:  “O que foi bem?” (WWW-What Went Well?)  “O que pode ser melhorado?” (WCBI – What Can Be Improved?)  Definição da responsabilidade sobre os itens WCBI para futura avaliação.
  • 42. + 42 Sprint Burndown Chart  É o gráfico que indica o trabalho restante dentro de um Sprint, baseado na pilha de Sprint Backlog (tarefas);  É atualizado diariamente pelo time, após o Daily Scrum, para refletir o progresso do Scrum Team naquele dia.
  • 43. + 43 Scrum Board – Gestão a vista!  Também conhecido como Task Board ou Agile Radiator;  Exibe o progresso de cada atividade do Sprint Backlog;  É atualizado diariamente, pelos membros da equipe;  Deve ficar visível a todos.
  • 44. + 44 Pontos de Atenção  A equipe deve estar sempre comprometida e motivada. Ela é quem deve fazer as estimativas, caso contrário, o time não se compromete;  A equipe deve ser multifuncional (não quer dizer que não podem existir especialistas);  O Product Owner deve ter disponibilidade e presença constante;  As práticas de engenharia devem ser aplicadas (exemplo: XP);  Não fique mudando os membros do time;  Mantenha fixo o tamanho do Sprint ao longo do projeto;  Não mude os requisitos de um Sprint durante sua execução.  Nunca chegue à reunião de Sprint Planning com uma lista inadequada de Product Backlog.
  • 45. + 45 Scrum Smells  Perda de ritmo Sintoma: Sprints não possuem sempre o mesmo tamanho.  “Galinhas falantes” Sintoma: Galinhas fazem perguntas ou observações durante o Daily Scrum.  “Porcos faltantes” Sintoma: Nem todos os porcos participam do Daily Scrum.  Scrum Master atribui trabalho Sintoma: As atividades são atribuídas pelo Scrum Master.  Daily Scrum é para o Scrum Master Sintoma: O Daily Scrum parece um status report para o Scrum Master.  Papéis especializados Sintoma: O Scrum Team tem papéis muito especializados.
  • 46. + 46 FAQ - Perguntas freqüentes  Scrum pode ser utilizado apenas para projetos pequenos? Não. Scrum é escalável por meio de “Scrum of Scrums”.  O que acontece se não for possível finalizar todos os itens previstos para o Sprint? O tamanho do Sprint não pode mudar. Portanto, os itens que não serão finalizados devem ser removidos do Sprint Backlog.  O que acontece se todos os itens previstos para o Sprint forem finalizados antes do fim do Sprint? O tamanho do Sprint não pode mudar. Portanto, novos itens do Product Backlog devem ser solicitados para o Product Owner.  O que aconteceu com o Gerente de Projetos? Não existe esse papel no Scrum. Os gerentes que gostam mais da parte administrativa podem se tornar Product Owners. Aqueles mais técnicos, Scrum Masters.
  • 47. + 47 Perguntas?

×