Scrum: A Metodologia Ágil Explicada de forma Definitiva

Processo Scrum

O que é Scrum Afinal?

Por mais que atualmente existam muitos materiais gratuitos na internet, e muitos livros escritos sobre assunto, eu ainda recebo muitas dúvidas básicas.

Por este motivo resolvi escrever este post para explicar de uma maneira definitiva e clara como esta metodologia ágil funciona.

Fizemos também um e-book que é um verdadeiro Mapa para implantar Scrum…


Capa E-Book 2

Clique no Botão Para Baixar

FAZER O DOWNLOAD

Ou, se preferir, também pode assistir a este vídeo onde explico o Scrum em apenas 9 minutos:

Visão Geral da Metodologia Ágil Scrum

O Scrum não é um processo padronizado onde metodicamente você segue uma série de etapas sequenciais e que vão garantir que você produza, no prazo e no orçamento, um produto de alta qualidade e que encanta os seus clientes.

Em vez disso, o Scrum é um framework para organizar e gerenciar trabalhos complexos, tal como projetos de desenvolvimento de software.

Importante

O framework Scrum é um conjunto de valores, princípios e  práticas que fornecem a base para que a sua organização adicione suas práticas particulares de engenharia e gestão e que sejam relevantes para a realidade da sua empresa. O resultado será uma versão de Scrum que é exclusivamente sua.

Para melhor entender este conceito, imagine que o framework seja como a fundação e as paredes de um edifício. Os valores do Scrum, princípios e práticas  seriam os principais componentes estruturais. Você não pode ignorar ou mudar fundamentalmente um valor, princípio ou prática sem o risco de colapso.

O que você pode fazer, porém, é personalizar o interior da estrutura do Scrum, acrescentando artefatos e recursos até que você tenha e um processo que funciona para sua empresa.

A Base Fundamental

A base fundamento é composta pelas seguintes práticas

Práticas do Scrum

 

Papéis Fundamentais

 

Papeis Scrum

Figura extraída do excelente livro: Essencial Scrum

Os esforços de desenvolvimento utilizando Scrum consiste em uma ou mais equipes Scrum, cada uma composta basicamente de  três papéis:

Podem haver outros papéis ao usar Scrum, mas o framework básico requer apenas os três listados aqui.

 

 

 

  • Product Owner

    Product Owner é o ponto central com poderes de liderança sobre o produto. Ele é o único responsável por decidir quais recursos e funcionalidades serão construídos e qual a ordem que devem ser feitos.

    É responsabilidade dele manter e comunicar a todos os outros participantes uma visão clara do que a equipe Scrum está buscando alcançar no projeto. Como tal, ele é responsável pelo sucesso global da solução.

    Para garantir que a equipe construa rapidamente o que o Product Owner precisa, ele deve colaborar ativamente com o ScrumMaster e equipe de desenvolvimento e deve estar disponível para responder às perguntas tão logo estas são feitas.

  • Scrum Master

    O ScrumMaster é responsável por ajudar a todos os envolvidos a entender e abraçar os valores, princípios e práticas do Scrum.

    Ela age como um Coach, executando a liderança do processo e ajudando a equipe Scrum (e o resto da organização) a desenvolver sua própria abordagem do Scrum, que tenha a melhor performance, respeitando as particularidades da organização.

    O ScrumMaster também tem um papel de facilitador.  Ele deve ajudar a equipe a resolver problemas e fazer melhorias no uso do Scrum. Ele também é responsável por proteger a equipe contra interferências externas e assume um papel de liderança na remoção de impedimentos que podem atrapalhar a produtividade.

    Normalmente o ScrumMaster não tem autoridade para exercer o controle sobre a equipe, de modo que este papel não é o
    mesmo que o papel tradicional do Gerente de Projeto ou Gerente de Desenvolvimento. O ScrumMaster age como um líder, não como um gerente.

  • Time Scrum

    No desenvolvimento tradicional de software são abordados vários tipos de trabalho, tais como: arquiteto, programador, testador, administrador de banco de dados, Designer, e assim por diante.

    No Scrum é definido o papel do Time de Desenvolvimento, que é simplesmente a junção de todas essas pessoas em uma equipe multidisciplinar, e que são responsáveis pela concepção, construção e testes do produto.

    A idéia principal é que a equipe de desenvolvimento se auto-organiza para determinar a melhor maneira de realizar o trabalho para atingir a meta estabelecida pelo Product Owner.

    Um time de desenvolvimento tem tipicamente entre 5 e 9 pessoas; e seus membros devem ter coletivamente todas as habilidades necessárias para produzir, com qualidade, software funcionando.

    Claro, scrum pode também ser usado em projetos que exigem equipes muito maiores. No entanto, ao invés de ter uma equipe Scrum com, digamos, 30 pessoas, seria melhor ter entre 3 ou mais times scrum, cada um com um time de 9 ou menos pessoas.

Você encontra mais detalhes sobe o time no nosso curso grátis.

Atividades e Artefatos Principais

Abaixo eu apresento um outro tipo de imagem que é também muito utilizada para representar as interações entre as atividades no processo.

Processo Scrum

Deixa eu explicar um pouco como interpretar esta imagem.

O Product Owner tem uma visão do que ele quer criar (o grande cubo). Como o o cubo pode ser grande, por meio de uma atividade chamada Grooming, ele é dividido em um conjunto de funcionalidades que são compilados em uma única lista priorizada chamado de Product Backlog.

Então é feito a primeira reunião de Planejamento de Sprint, para definir o Sprint Backlog, que contém todo o trabalho que será executado durante o Sprint.

O Sprint tem duração média de 2 a 4 semanas e são feitas reuniões diárias de acompanhamento (Daily Scrum) do trabalho.

Product Backlog

No Scrum, sempre fazemos o trabalho mais importante primeiro.

O Product Owner, com ajuda do resto da equipe Scrum e as partes interessadas, é o responsável por determinar e gerir a seqüência deste trabalho e comunicando-o na forma de uma lista de prioridades conhecida como o Product Backlog

Product Backlog O Product Owner,  em conjunto com as demais partes interessadas no produto, definem os itens do Product Backlog.

Em seguida, ele garante que os itens do Backlog são colocadas na seqüência correta (usando fatores como valor, custo, conhecimento e risco), de modo que os itens de alto valor, aparecerá no topo do backlog do produto e os itens de menor valor aparecer em direção ao fundo.

O Product backlog é um documento que está constantemente evoluindo. Os itens podem ser adicionados, excluídos e revisto pelo Product Owner por conta de mudanças nas condições de negócios, ou conforme a compreensão da equipe Scrum sobre o produto aumenta.

Em geral a atividade de criar e de refinar os itens do product backlog, estimando o tamanho e esforço de cada item, é chamada de Grooming.

Antes de finalizar a priorização,  ou refinamento do produto backlog, é preciso saber o tamanho de cada item. É importante que o Product Owner saiba o custo de cada item para que possa determinar a sua prioridade de forma adequada. O Scrum não especifica como você deve medir o tamanho dos itens do backlog.

Na prática, muitas equipes usam uma medida de tamanho relativo, como Story Point ou dias ideais.

Essa questão sobre estimativas é um capítulo a parte e cabe um post depois para explicar somente isso.

Sprints

No Scrum, o trabalho é realizado em iterações ou ciclos de até um mês de calendário chamado de Sprints.

O trabalho realizado em cada sprint deve criar algo de valor tangível para o cliente ou usuário. Sprints são timeboxed (duração fixa) para que tenham sempre um início e fim data fixa, e, geralmente, todos eles devem estar com a mesma duração.

Sprints

Um novo Sprint segue imediatamente a conclusão do Sprint anterior e, via de regra, não devemos permitir nenhuma alteração de escopo ou pessoal durante um Sprint (mas por experiência própria posso afirmar que esta regra é quase sempre quebrada devido à algumas necessidades de negócio)

Sprint Planning

O product backlog pode representar muitas semanas ou até meses de trabalho, o que é muito mais do que pode ser concluído em um único e curto sprint.

Para determinar quais os subconjuntos de itens do Product Backlog mais importantes para construir no próximo sprint, o product owner, junto com o time de desenvolvimento e ScrumMaster, devem realizar o Sprint Planning (planejamento de sprint ).

Durante o planejamento do sprint, a equipe de desenvolvimento e o product owner devem chegar a um acordo sobre qual o Objetivo do Sprint.

Com este objetivo em mãos, eles determinam quais os itens do backlog devem ser priorizados para serem executados neste Sprint.

A maioria das equipes Scrum que estão realizando Sprints de duas semanas a um mês de duração tentam completar o planejamento do sprint em cerca de 4 a 8 horas.

Um sprint de uma semana não deve tomar mais do que 2 horas para planejar.

Daily Scrum

Todos os dias, idealmente no mesmo horário, os membros da equipe de desenvolvimento devem realizar uma reunião com tempo definido (15 minutos ou menos), chamado Daily Scrum.

Daily Scrum

Esta reunião também é muitas vezes chamada de Stand-Up Meeting, por causa de uma prática recomendada para que a reunião seja feita em pé (com a intenção de fazer com que a reunião seja rápida).

Uma abordagem comum nesta reunião é o Scrum Master perguntar para cada membro da equipe três perguntas:

3 Perguntas básicas da Reunião Diária

  1. O que fiz ontem que ajudou o time a atingir a meta do sprint?
  2. O que vou fazer hoje para ajudar o time a atingir a meta do sprint?
  3. Existe algum impedimento que não permita a mim ou ao time atingir a meta do sprint?
Ao responder a estas questões, todos conseguem visualizar de uma maneira geral como está progredindo o trabalho do Sprint em direção à meta.

Definition of Done (Definição de Pronto)

No Scrum nós consideramos como resultado do Sprint produto ou funcionalidade concluída.

Definition of Done

Para saber quando, e como, uma parte do produto ou funcionalidade deve ser considerada concluída nós utilizamos um documento chamado Definition of Done.

Para aprender mais sobre DoD, clique aqui e leia o nosso artigo completo sobre o assunto.

Embora, isso varie significativamente de um extremo ao outro para cada time Scrum, os integrantes devem ter um entendimento compartilhado do que significa o trabalho estar completo, assegurando a transparência. Esta é a “Definição de Pronto” para o Time Scrum e é usado para assegurar quando o trabalho esta completado no incremento do produto.

Sprint Review (Revisão do Sprint)

No final do Sprint, existem duas atividades adicionais que são fundamentais. Uma delas é chamada Sprint Review.

O objetivo desta atividade é verificar e adaptar o produto que está sendo construído.

Esta é uma reunião informal, e a apresentação do incremento destina-se a motivar e obter comentários e promover a colaboração

Sprint Retrospective (Retrospectiva do Sprint)

Enquanto o objetivo do Sprint Review é verificar necessidades de adaptações no produto, o Sprint Retrospective tem como objetivo verificar necessidades de adaptações no processo de trabalho.

A Retrospectiva do Sprint ocorre depois da Revisão da Sprint e antes da reunião de planejamento da próxima Sprint. Esta é uma reunião time-boxed de três horas para uma Sprint de um mês.

Conclusão

Este post descreveu as principais práticas do núcleo do Scrum, com foco em uma descrição end-to-end
dos papéis do framework Scrum, atividades e artefatos.

Existem outras práticas, principalmente em relação à comunicação em um projeto Scrum, tais como Kanban Board, Burn Down Chart, que muitas equipes Scrum usam e que trataremos em outros posts.

 

Quer aprender a fundo os Fundamentos do Scrum?

Aprenda tudo o que precisa sobre o Scrum e ainda baixe Modelos Prontos para utilização, Vídeos, Simulado Certificação e muito mais...

Eu Quero o E-Book

Se gostou deste artigo deixe um comentário abaixo 🙂

 

Mais informações sobre Scrum:

Agile Manifesto

Wikipedia /Scrum

Scrum.Org

Scrum Alliance

Mountain Goat

Scrum Master: Quem é ele e qual sua importância?
Product Owner: Pra que?
  • Pingback: Mini Curso Scrum Grátis | Edimar S. Ramos()

  • Pingback: Scrum Master: Quem é e o que ele e qual sua importância?()

  • Pingback: Product Owner: Pra que?()

  • Pingback: As verdades que nunca te contaram sobre o Time Scrum()

  • Pingback: Ferramentas Scrum: Um Dossiê Completo - MindMaster Treinamentos()

  • Pingback: Mapa do Scrum()

  • Pingback: Como Vender Scrum para seu Cliente()

  • Pingback: Como Implantar Scrum em sua Empresa()

  • Pingback: Definition of Done()

  • Jaqueline Pino

    Muito bom!!! obrigada pela contribuição

    • Denisson Vieira

      Eu que agradeço seu comentário Jaqueline 🙂

  • Pingback: O guia simples e prático para Daily Scrums que funcionam | Webinsider()

  • Pingback: Scrum em Manutenção de Sistemas()

  • Rubens Lacerda Almeida

    Muito bom!!!

    • mindmasterbrasil

      Muito Obrigado Rubens!

  • Pingback: Scrum | Sistemas de Informação e Empreendedorismo()

  • Elis

    Pra mim que não sabia nada, foi muito esclarecedor, obrigado.

    • Muito obrigado pelo comentário Elis!

    • Denisson Vieira

      Eu que agradeço Elis!

      Seu comentário me dá ainda mais forças para continuar seguindo esse caminho. 🙂

      Um abraço

  • Pingback: Scrum | Infinity TI()

  • Pingback: Você sabe o que é metodologia ágil? | Unicorp UniNews()

  • Bruno Willians

    Perfeita explicação e abordagem do tema!!! Parabéns, realmente está bem claro como você pretendia!! Muito obrigado por compartilhar o conhecimento!

    • Denisson Vieira

      Eu que agradeço suas palavras Bruno!

  • Claudio Aiello Sprovieri

    Sensacional. Não sou mais leigo no assunto.

    • Denisson Vieira

      Obrigado Claudio!
      É exatamente isso que nos pretendíamos ao escrever este artigo 🙂

  • Pingback: Scrum | Acordo Coletivo (Petroleiros, Bancários, Prof de Saúde)()

  • Hellen Fernandes

    Muito bom!!!

    • Denisson Vieira

      Muito Obrigado Hellen!

  • Pingback: Scrum | areadeconhecimento.com.br/site()

  • D. Pedoneze

    Muito bom! Apenas me perco na área de proposta/orçamento.

    Como fazer uma proposta ao cliente usando o Scrum como base? Visto que entregamos “novas” funcionalidades (dependendo do time) a cada Sprint.

    No caso poderíamos ter que em X Sprints conseguiríamos entregar N funcionalidades e consequentemente com esses dados conseguiríamos ter uma estimativa para os valores a serem cobrados.

    Mas e se a ideia for mais abrangente no sentido de não ter um valor fixo final e sim um valor mensal? Aplica-se a mesma ideia de funcionalidade x sprints?

    • Denisson Vieira

      Olá D. Pedroneze.

      Esta é uma dúvida muito comum… Existem diversas formas de contratação ágil.
      Mas a principal questão na contratação ágil (e principal diferença entre Ágil e Tradicional) é que o escopo é variável, e não fixo.

      Pode-se ter um preço e tempo fixos, mas nunca um escopo fixo… senão não é Scrum.

      Isto posto, pode-se cobrar um valor fixo por Sprint, pode-se cobrar por alocação recursos, pode-se cobrar por horas de trabalho, etc.

      Vou escrever um post sobre isso 🙂

  • Esdras Silva

    Excelente matéria! Precisa de uma conceitualização para um concurso de Analista de TI e ela, sanou todas as minhas duvidas conceituais relativas ao framework. Parabéns!!!

    • Denisson Vieira

      Que bom Esdras, fiquei feliz de saber que o artigo contribuiu para te ajudar. Obrigado!

  • Mavie de Sousa Ozório

    até agora o mais útil que li na internet! Obrigada

    • Denisson Vieira

      Eu que agradeço Mavie!!

    • Xandre Silveira

      Mavie, me fale sobre o que já estudou sobre esse assunto e se fez algum curso sobre. Obrigado!

      • Mavie de Sousa Ozório

        Olá! Estou me formando agora no meio de 2015 em bacharel de sistemas de informação, e eu faço estágio na área e lá usamos essa metodologia!

  • Excelente! Muito BOM! Agora uma pergunta, quais ferramentas existem para que eu utilize essa ferramenta? Tens algum modelo de planilhas, etc?

  • Pingback: Scrum: 11 Passos Essenciais para Implantação()

  • Julio Graffin

    Ótimo post, cara.
    Vlw!

    • Denisson Vieira

      Muito Obrigado Julio!

  • Elaine Navalho

    Muito bom post. Parabéns!

    • Denisson Vieira

      Obrigado Elaine!

  • Kleuber Vasconcelos

    Post muito bom, parabéns e muitíssimo obrigado. Abraço.

    • Denisson Vieira

      Eu que agradeço Kleuber!!! Fico feliz que tenha gostado.

  • Pingback: ALM()

  • Xandre Silveira

    Denisson, podemos trocar umas idéias sobre o assunto – meus projetos são destinados a serviços de integridade de plataformas, então tenho um projeto com 400 a 500 escopos diferentes e com disciplinas diferentes. Desafio, vamos! Meu email: planejamento.petrobras@gmail.com – Whatsapp: 22-99979-3005

  • Pingback: Scrum | Calm & Dev()

  • Pingback: Cronograma no Scrum - Como usar?()

  • Pingback: Aprenda Scrum em 9 minutos | Ernando de Castro()

  • Marcio Amorim

    Obrigado Denisson. Não tinha entendimento algum sobre Scrum, embora vivencie algumas de suas práticas em meu trabalho, Então percebi algo, que vejo no dia a dia, não contemplado, a princípio, neste framework. Como tratar o não cumprimento dos prazos por conta da necessidade de deslocamento de foco para erros nos sistemas já em produção? Scrum considera isto?

  • Antonio Carlos Zava

    Excelente material introdutório. Simples, direto e ágil, como deveriam ser todos os materiais sobre scrum. Vou referenciar nas páginas da empresa como material de consulta sobre o tema.

    Obrigado pelo post e parabéns pela qualidade da apresentação.

  • Pingback: Scrum | Sistemas de Informação em Estruturas Organizacionais()

  • Pingback: SCRUM | GPDBlogSIEO()

  • Pingback: SCRUM | Insane Information Systems()

  • carla sousa

    Hoje na faculdade no curso de analise e desenvolvimento de sistema a materia de engenharia de software a professora solicitou para que realizarmos uma pesquisa sobre Scrum estou satisfeita e feliz com esse tutorial Parabéns.

  • Pingback: Scrum: Gerencie projetos de forma ágil e eficaz | LP Produtividade()

  • Pingback: Scrum – gestão e planejamento de projetos de software – Infocacto()

  • Larissa Pavarini da Luz

    Muito bom o post, mas pedi para baixar o e-book, e nao veio no meu e-mail fico no aguardo

  • Pingback: Afinal o que é SCRUM – Lía Siqueira UX/UI Designer()

  • Pingback: BibSonomy :: url :: Scrum: A Metodologia Ágil Explicada de Forma Definitiva()

  • Pingback: Front-end e back-end devem ser friends()

  • Pingback: Framework Scrum | Blog Codeline()

  • Pingback: SCRUM – SmarTI()

  • Edson Silva Alves

    Ficou tudo muito claro, realmente consegui entender de uma forma simples o framework Scrum. parabéns!

  • Diego Mendes

    Realmente agregou conhecimento, ficou bem conceituado de uma forma clara. Parabéns pelo conteúdo.

  • Mauricio Silva

    “Um novo Sprint segue imediatamente a conclusão do Sprint anterior e, via de regra, não devemos permitir nenhuma alteração de escopo ou pessoal durante um Sprint (mas por experiência própria posso afirmar que esta regra é quase sempre quebrada devido à algumas necessidades de negócio)”

    Em relação a alteração de escopo e mesmo de pessoas, podemos minimizar este problema diminuindo a duração dos sprints, em geral em um sprint de 2 semanas temos menos chances de ter alguma alteração de escopo ou de pessoas do que um sprint de 4 semanas, mas isto vai de acordo com a empresa e com as necessidades de negócio.

    Escrevi um pouco sobre sprints de curtas direção no meu blog http://agiledevelop.blogspot.com.br

    abraços.