Scrum - A Metodologia Ágil Explicada de Forma Definitiva

10/02/2016 Scrum: A Metodologia Ágil Explicada de Forma Definitiva
Home Blog Login Cursos ▾ Sobre Nos
Scrum: A Metodologia Ágil
Explicada de forma Definitiva
Popular
Denisson Vieira junho 26 2014
Scrum: A
Metodologia
Ágil
Explicada…
74 Comments
Como
implantar
Scrum: O
passoa
passo…
21 Comments
Scrum Master:
Quem é ele e
qual sua…
17 Comments
O Guia Simples
47 20 Like 259
e Prático Para
Fazer…
O que é Scrum Afinal? 12 Comments
Product
Por mais que atualmente existam muitos materiais gratuitos na internet, e muitos Owner: Pra
livros escritos sobre assunto, eu ainda recebo muitas dúvidas básicas. que?
11 Comments
Por este motivo resolvi escrever este post para explicar de uma maneira definitiva
e clara como esta metodologia ágil funciona.
Fizemos também um ebook que é um verdadeiro Mapa para implantar Scrum…
Baixe o nosso e
book
Seu EMail
Clique para Baixar!
Ou, se preferir, também pode assistir a este vídeo onde explico o Scrum em apenas
http://www.mindmaster.com.br/scrum/ 1/13
9 minutos:
Scrum - Aprenda Scrum em 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
Papéis Fundamentais

Os esforços de
desenvolvimento utilizando
Scrum consiste em uma ou
mais equipes Scrum, cada
uma composta basicamente
de três papéis:
Product Owner,
ScrumMaster e
Time de Desenvolvimento.
Podem haver outros
Figura extraída do excelente livro: Essencial Scrum 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 autoorganiza
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.
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 comunicandoo
na forma de uma lista de prioridades conhecida como o Product Backlog
O Product Owner, em
FIQUE ATUALIZADO!
conjunto com as demais
Receba nossas atualizações
partes interessadas no
gratuitamente.
produto, definem os
itens do Product Digite seu EMail
Backlog.
Cadastrar
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.
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.
Esta reunião também é muitas vezes
chamada de StandUp 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.
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 destinase 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 timeboxed 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 endtoend
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 EBook
Se gostou deste artigo deixe um comentário abaixo
Mais informações sobre Scrum:
Agile Manifesto
Wikipedia /Scrum
Scrum.Org
Scrum Alliance
Mountain Goat
    
259 20 74
« Scrum Master: Quem é ele e qual
sua importância?
Product Owner: Pra que?
»
48 Comments MindMaster Treinamento 
1 Login
 Recommend 7 ⤤ Share Sort by Best
Join the discussion…
Bruno Willians • a year ago
Perfeita explicação e abordagem do tema!!! Parabéns, realmente está bem claro como você
pretendia!! Muito obrigado por compartilhar o conhecimento!
1 △ ▽ • Reply • Share ›
Denisson Vieira > Bruno Willians • a year ago
Eu que agradeço suas palavras Bruno!
△ ▽ • Reply • Share ›
carla sousa • 3 months ago
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.
Antonio Carlos Zava • 4 months ago
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.
Marcio Amorim • 5 months ago
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?
Kleuber Vasconcelos • a year ago
Post muito bom, parabéns e muitíssimo obrigado. Abraço.
Denisson Vieira > Kleuber Vasconcelos • 10 months ago
Eu que agradeço Kleuber!!! Fico feliz que tenha gostado.
Elaine Navalho • a year ago
Muito bom post. Parabéns!
Denisson Vieira > Elaine Navalho • 10 months ago
Obrigado Elaine!
Julio Graffin • a year ago
Ótimo post, cara.
Vlw!
Denisson Vieira > Julio Graffin • 10 months ago
Muito Obrigado Julio!
oseias • a year ago
Excelente! Muito BOM! Agora uma pergunta, quais ferramentas existem para que eu utilize
essa ferramenta? Tens algum modelo de planilhas, etc?
Denisson Vieira > oseias • a year ago
Obrigado Oseias!
Temos um post que trata justamente de ferramentas: http://www.mindmaster.com.br/f...
Mavie de Sousa Ozório • a year ago
até agora o mais útil que li na internet! Obrigada
Denisson Vieira > Mavie de Sousa Ozório • a year ago
Eu que agradeço Mavie!!
Xandre Silveira > Mavie de Sousa Ozório • 9 months ago
Mavie, me fale sobre o que já estudou sobre esse assunto e se fez algum curso sobre.
Obrigado!
Mavie de Sousa Ozório > Xandre Silveira • 9 months ago
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!
Esdras Silva • a year ago
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 > Esdras Silva • a year ago
Que bom Esdras, fiquei feliz de saber que o artigo contribuiu para te ajudar. Obrigado!
D. Pedoneze • a year ago
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? Aplicase a mesma ideia de funcionalidade x sprints?
Denisson Vieira > D. Pedoneze • a year ago
Olá D. Pedroneze.
Esta é uma dúvida muito comum... Existem diversas formas de contratação ágil.
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.
Podese ter um preço e tempo fixos, mas nunca um escopo fixo... senão não é Scrum.
Isto posto, podese cobrar um valor fixo por Sprint, podese cobrar por alocação
recursos, podese cobrar por horas de trabalho, etc.
Vou escrever um post sobre isso :)
Hellen Fernandes • a year ago
Muito bom!!!
Denisson Vieira > Hellen Fernandes • a year ago
Muito Obrigado Hellen!
Claudio Aiello Sprovieri • a year ago
Sensacional. Não sou mais leigo no assunto.
Denisson Vieira > Claudio Aiello Sprovieri • a year ago
Obrigado Claudio!
É exatamente isso que nos pretendíamos ao escrever este artigo :)
Elis • a year ago
Pra mim que não sabia nada, foi muito esclarecedor, obrigado.
Denisson Vieira > Elis • a year ago
Eu que agradeço Elis!
Seu comentário me dá ainda mais forças para continuar seguindo esse caminho. :)
Um abraço
Rubens Lacerda Almeida • a year ago
Muito bom!!!
mindmasterbrasil Mod > Rubens Lacerda Almeida • a year ago

Muito Obrigado Rubens!
Jaqueline Pino • a year ago
Muito bom!!! obrigada pela contribuição
Denisson Vieira > Jaqueline Pino • a year ago
Eu que agradeço seu comentário Jaqueline :)
Denisson Vieira • a year ago
Muito obrigado Edi!
Edi Edi • a year ago
Muito bom o artigo, vale apena investir 10 ou 20 minutos de leitura.
Denisson Vieira • 2 years ago
Muito Obrigado Vitor!
Vitor Mannu • 2 years ago
Vitor Mannu • 2 years ago
Cara muito bom seu artigo, já o acompanho há algum tempo porem somente agora pude lêlo.
vlw =D
Obrigado Helton!
Helton Rodrigues • 2 years ago
Excelente.. Simples, direto e bem esclarecedor..Parabens
Obrigado tiago!
Tiago Tôrres • 2 years ago
Gostei, é sempre bom ter esses conteúdos tão bem explicados.
Jaqueline Tavares Meneses • 2 years ago
Nossa Denisson o q artigo bacana, parabéns
Valeu Jaque!
Muito Obrigado Flavio!
Obrigado Contancio, essa é a nossa idéia... tentar facilitar o entendimento sem deixar nenhum
conteúdo de fora.
Obrigado Robert!
Constancio Alvaro • 2 years ago
Sucinto e de fácil entendimento!
Robert Santos • 2 years ago
Muito objetivo. Estão de parabéns!
Flavio Spedaletti • 2 years ago
Conciso e objetivo. Muito bom!
Xandre Silveira • 9 months ago
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: 22999793005
ALSO ON MINDMASTER TREINAMENTO WHAT'S THIS?
Ferramentas Scrum: Um Dossiê Completo Cronograma no Scrum – Como usar?
3 comments • a year ago 6 comments • 5 months ago
Gabriel Costa — Para quando a ferramenta Fabio Leite — Excelente material, muito bom,
não incorporar o time tracking, recomendo parabéns !
utilizar o primaERP: …
12 Sinais de Riscos em Projeto Scrum As verdades que nunca te contaram sobre
8 comments • a year ago o Time Scrum
Cleide Silva — Parabéns, excelente artigo 6 comments • a year ago
Samuel Messias — Olá, estou muito
interessado em saber mais como é feita a
gestão de pessoas em empresas que …
✉ Subscribe d Add Disqus to your site Add Disqus Add ὑ Privacy
Copyright © 2015 · MindMaster · Todos os Direitos Reservados

Scrum - A Metodologia Ágil Explicada de Forma Definitiva

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Scrum - A Metodologia Ágil Explicada de Forma Definitiva

Enviado por

Direitos autorais:

Formatos disponíveis

10/02/2016 Scrum: A Metodologia Ágil Explicada de Forma Definitiva

Home Blog Login Cursos ▾ Sobre Nos

Scrum - Aprenda Scrum em 9 minutos

 Recommend 7 ⤤ Share Sort by Best

mindmasterbrasil Mod > Rubens Lacerda Almeida • a year ago

✉ Subscribe d Add Disqus to your site Add Disqus Add ὑ Privacy

Você também pode gostar