Gestao Agil de Projetos Com SCRUM - Modulo 4

Núcleo de Educação a Distância
GERENCIANDO PROJETOS COM SCRUM
Módulo IV – Práticas, Métodos e Framework
GESTÃO ÁGIL DE PROJETOS COM SCRUM
Módulo IV – O Framework SCRUM
Rua Tomé de Souza, 1065. Savassi. Belo Horizonte - MG | (31) 3116-1000 (31) 3223-6251.
Caro aluno,
Seja bem-vindo ao Módulo 4 do curso de Gestão Ágil de Projetos com SCRUM!
Por onde vamos começar?
Neste quarto módulo, falaremos sobre o framework SCRUM. Ao término deste módulo,
esperamos que você seja capaz de:
 Conhecer detalhadamente o Framework SCRUM e utilizar esta abordagem nos seus

projetos.
Bons estudos!
MÓDULO 4 – O FRAMEWORK SCRUM
O Framework Scrum
Agora que já aprendeu mais sobre projetos e sobre a abordagem ágil, vamos então
conhecer com mais detalhes, o Scrum. Aqui nós iremos entender melhor este
incrível framework e suas principais características, dando a você conhecimento
para utilizar esta abordagem nos seus projetos.
Para iniciar, vamos primeiro entender o porquê do nome Scrum. Este nome foi
escolhido por causa do jogo de Rugby onde para alcançar o objetivo, necessita
fortemente do trabalho em equipe, uma vez que um time é composto por 8
integrantes que trabalham em conjunto para levar a bola adiante no campo.
No Rugby, Scrum é a forma de recomeçar o jogo depois de uma interrupção.
 Scrum: u
:
 Leve;
 Simples de entender;
 .
O Scrum é bem estruturado no qual até os tempos dos eventos são definidos. É a
abordagem ágil mais utilizada, existem sites específicos do Scrum – dê uma
navegada nos sites scrumalliance.org e scrum.org. Existem também certificações
para os diversos papeis definidos no framework.
Você deve estar se perguntando o porquê do Scrum ser classificado como

framework e não metodologia. Vou te explicar:
Em uma metodologia todos os processos são conhecidos e previamente definidos,

ou seja, prescritivos, diferentemente do Scrum onde o processo de aprendizado
é empírico, isto é, você vai ver que durante o desenvolvimento do projeto, a equipe
estará revendo o processo o tempo todo. Existem os eventos definidos, os papéis e
produtos, mas não existe uma definição de como o trabalho será desenvolvido, a
equipe é que deve achar a melhor forma de realizar o serviço.
O Scrum pode te dar uma base de onde partir para criar sua metodologia de acordo
com as necessidades e peculiaridades da sua empresa. É permitido e até desejável
juntar práticas de outros métodos ágeis com o Scrum, como é muito comum o pair
programming do XP que nós vimos no módulo anterior. Uma outra técnica muito
utilizada nos projetos Scrum é o quadro Kanban, que facilita a visualização do

trabalho que a equipe está executando.
Por essa flexibilidade é que dizemos que o Scrum é um framework e não uma
metodologia. Assim como qualquer framework o Scrum pode ser estendido, tendo
algumas de suas práticas removidas se for o caso. Contudo, deve-se ter cuidado ao
remover alguma prática, pois o seu valor pode se perder durante o processo. Tenha
em mente os benefícios que tais práticas trazem para somente depois se julgar
necessário remover algo.
O framework Scrum é simples e leve, utilizado para a gestão do desenvolvimento de

produtos complexos imersos em ambientes complexos. Scrum utiliza uma
abordagem iterativa e incremental para entregar valor com frequência e, assim,
reduzir os riscos do projeto.
Scrum não é um termo novo e no Brasil, algumas empresas de TI tem adotado este
framework para tornar mais ágil o processo de desenvolvimento de seus produtos. O
Scrum já vem desde a década de 90, quando Ken Schwaber e Jeff Sutherland
decidiram formalizar a maneira como gerenciavam seus projetos de
desenvolvimento de software.
Não é de hoje que muitos profissionais de TI têm procurado novas formas de

desenvolver softwares mais rapidamente e com maior qualidade. O Scrum traz
consigo de uma forma simples, porém consistente, uma gama de boas práticas
ágeis que contribuem para o desenvolvimento do produto.
Os ciclos de desenvolvimento são curtos, de no máximo 30 dias e, por este motivo,

o feedback do cliente se torna mais constante já durante a fase de desenvolvimento
do produto, tornando seu trabalho mais assertivo e alinhado com as necessidades
do negócios do cliente.
Adotar Scrum requer conhecimento das limitações e entendimento que os pilares

básicos da transparência, inspeção e adaptação devem ser respeitados, pois
assim se constrói softwares melhores. Deve-se sempre estar atento aos princípios
do manifesto ágil, pois ele é base de qualquer metodologia ágil. É fundamental

também sempre procurar a melhora no processo e adaptá-lo de forma a ser aceito e
efetivo em sua organização.
Vários são os benefícios de se utilizar Scrum, dentre eles:
 Entregas frequentes de retorno ao investimento dos clientes;

 Redução dos riscos do projeto;
 Maior qualidade no produto gerado;
 Mudanças utilizadas como vantagem competitiva;
 Visibilidade do progresso do projeto;
 Aumento de produtividade.
O maior benefício que pode ser destacado é a redução do desperdício, lembra que
uma das principais características de abordagens ágeis é a redução do desperdício?
E voltando um pouco mais, na história da Toyota e no conceito Lean, veja que todas
estas abordagens estão conectadas com este objetivo de reduzir o desperdício.
O Scrum é formado por pilares, valores, papéis, eventos e artefatos que iremos
conhecer a seguir:
Tópico 4.1 – Pilares
Transparência:
Aspectos significativos do processo devem
para que os observadores compartilhe

sendo visto.
Por exemplo:
 Uma linguagem comum referindo-se ao processo deve ser compartilhada por

todos os participantes;

realizam o trabalho e por aqueles que aceitam o resultado do trabalho.
Inspeção:
Os
Adaptação:
Se uma inspeção determina que um ou mais aspectos de um processo foi desviado
pa
para minimizar mais desvios.
Tópico 4.2 - Valores
Comprometimento:
Quando toda a equipe define e planeja o trabalho que será feito na Sprint,
automaticamente ela se compromete para alcançar os seus objetivos. Ao contrário
de algumas metodologias onde o envolvimento da equipe é pequeno com relação à
prazos e priorização, o Scrum dá muita autonomia à equipe do projeto, o que faz
com que as pessoas tenham maior comprometimento.
Foco:
Como o trabalho é limitado à entrega do período, a equipe do projeto se limitará a
fazer aquele serviço para alcançar o objetivo traçado. Se a equipe não seguir o
planejamento, pode haver atraso nas entregas planejadas e consequentemente
descrédito por parte do cliente.
Sinceridade:
Uma característica de projetos ágeis é exatamente a aceitação maior da mudança,
então novas ideias são bem-vindas. É claro que às vezes o que é pedido pode não
ser a melhor solução, então a equipe Scrum tem toda a liberdade de discutir as
sugestões e desafios para escolher o caminho melhor a seguir e entregar os valores
que o cliente necessita.
Respeito:
Em uma abordagem ágil se ocorre um erro, a equipe toda assume este erro, sem
apontar um culpado. É fundamental que a equipe trabalhe junto, seja um time coeso
e esteja sempre realizando os seus esforços para obter um resultado do grupo.
Coragem:
A equipe Scrum deve assumir as responsabilidades de quando algo não vai bem ou
alguma solução que foi definida não ficou legal. Além disso, se uma pessoa da
equipe estiver com dificuldades de resolver um problema, ela precisa ter coragem
para pedir ajuda.
Esta atitude se torna automática em um time Scrum. Eu vivenciei por diversas vezes
situações em que um desenvolvedor estava com dificuldades para resolver uma
atividade e o time todo se uniu para chegar a uma solução. O espírito de equipe tem
que ser muito forte em times ágeis. Seria que nem em um jogo de futebol, se uma
pessoa erra, é o time que erra. Então é preciso que todos estejam juntos para um
objetivo do grupo.
Tópico 4.3 - O time SCRUM
Product Owner - PO
O Product Owner é o usuário, representante do(s) cliente(s). Quando o cliente não

tem disponibilidade para participar dos eventos Scrum, elege-se o analista de
requisitos (por exemplo) para ser o representante do Product Owner, mas o cliente
continua sendo o PO.
O . Pode representar o desejo de um

comitê
prioridades dos itens de Backlog devem convencer o Product Owner.
Para que o PO tenha sucesso, toda
prioridade e o T
sobre o que outras pessoas disserem.
Dentro do framework Scrum ele é responsável pela manutenção do Produto, através

do Product Backlog.
Esse Backlog é uma lista de requisitos escritos de maneira não detalhada, contendo
somente uma ou duas frases que descrevem as funcionalidades a serem
desenvolvidas.
A razão de não ser detalhada é agilidade: ao invés de serem escritos e revistos em

um documento de n páginas, os requisitos são discutidos entre toda a equipe
durante a Reunião de Planejamento.
Considera-se que o Backlog nunca está completo, ou seja, Histórias são

adicionadas e removidas conforme necessário.
Responsabilidades:
 Gerencia o produto, inserindo, detalhando, removendo e priorizando as
necessidades de negócios do produto no Product Backlog, a partir do
contato frequente com os clientes do projeto e demais partes interessadas;
 Gerencia os clientes e demais partes interessadas em sua relação como
projeto, descobrindo quem são essas partes interessadas que devem
influenciar as decisões sobre o produto, balanceando suas necessidades
com relação ao produto, comunicando-se com elas para descobrir essas
necessidades e influenciando as para maximizar sua colaboração com

relação ao projeto;
 Mantém a Visão do Produto, definindo-a junto aos clientes do projeto e
demais partes interessadas, comunicando-a a todos os envolvidos e
garantindo que o trabalho seja realizado em direção a ela;
 Gerencia as releases do produto para os clientes, definindo a melhor
estratégia para a realização das releases e estabelecendo a meta e a data
de cada release;
 Realiza, com o time de desenvolvimento, o planejamento do Sprint na
reunião de Sprint Planning, para que juntos definam uma Meta para
o Sprint e uma previsão do que será feito durante o Sprint;
 Colabora com o Time de Desenvolvimento, sempre que necessário, para
esclarecer dúvidas ou tomar decisões quanto aos detalhes do produto, e
para refinar e aprimorar o Product Backlog, preparando-o para o
próximo Sprint;
 Aceita ou rejeita as entregas do Time de Desenvolvimento, verificando na
reunião de Sprint Review se a meta estabelecida para o Sprint foi atingida.
O Product Owner é:
 Único para um Time de Scrum, pois é importante haver apenas um foco de
decisões sobre o produto para o Time de Desenvolvimento;
 Disponível para tirar dúvidas e esclarecer itens do Product Backlog para o
Time de Desenvolvimento, para estar presente nas reuniões de Sprint
Planning, Sprint Review e Sprint Retrospective, para interagir com os
clientes e demais partes interessadas e para manter e priorizar o Product
Backlog;
 Representativo com relação ao produto, com conhecimento e poder
suficiente para tomar decisões rápidas e adequadas;
 Fornece os critérios de aceitação que a equipe de entrega usará para
preparar testes de aceitação;
 Determina se cada incremento de produto concluído está funcionando
conforme o esperado e se aceita ou solicita alterações;
 Pode alterar os recursos do produto e sua prioridade a qualquer momento;
 Facilita o engajamento de stakeholders e gerentes externos do projeto em

suas expectativas;
 Fornece as datas de vencimento para o projeto e suas liberações.
Scrum Master
Dentro do framework Scrum, ele é o facilitador da equipe.
Este papel pode ser assumido pelo gerente do projeto, isto é, o GP terá o
chapéu de GP ao realizar o trabalho de planejamento e acompanhamento do
projeto e o chapéu de Scrum Master junto à equipe de desenvolvimento.
É responsável por interagir com o PO e com outras equipes para remover as

pendências que possam impactar o Sprint.
É responsável também pelo agendamento das reuniões, pela atualização diária dos
gráficos de Burndown e Burnup de cada Sprint e de apresentar os resultados na
Reunião de Revisão.
Responsabilidades:
 Atua como líder servidor para a equipe de desenvolvimento, ajudando-os a
melhorar e remover as barreiras ao progresso do trabalho;
 Facilita o trabalho do Time de Desenvolvimento, de forma que seus
membros se auto-organizem para que juntos desenvolvam o produto,
comuniquem-se efetivamente e busquem continuamente melhorar seus

processos de trabalho, realizando-o com qualidade e produtividade, além
de facilitar os eventos do Scrum;
 Gerencia a remoção dos impedimentos que atrapalham o trabalho do time
de desenvolvimento e ajuda a prevenir que os impedimentos aconteçam,
quando possível;
 Promove as mudanças organizacionais necessárias para que o time de
desenvolvimento possa realizar seu trabalho com efetividade;
 Assegura que o Scrum seja compreendido e adequadamente utilizado pelo
time de desenvolvimento;
 Atua como coach e mentor do time de desenvolvimento;
 Ajuda o product owner a gerenciar o backlog do produto;
 Ajuda o product owner a comunicar a visão do projeto, objetivos e itens do
backlog à equipe de desenvolvimento.
, incluindo:
 ;
 , objetivo e itens do Backlog do Produto para o
time de desenvolvimento;
 Ensinar o time de desenvolvimento a criar itens de Backlog do Produto de
forma clara e concisa;
 Compreender a longo-prazo o planejamento do Produto no a
;
 Compreender e praticar a agilidade.
O Scrum Master serve à o , incluindo:

 ;
 ;
 Ajudando
;
 ; e,

Time de Desenvolvimento
A equipe Scrum é auto-organizada, permitindo que todas as decisões sejam

tomadas em grupo e sem a necessidade de uma figura de liderança que gerencie as
informações e atividades. Geralmente, para se chegar o nível de auto-organização,
a equipe precisa ter maior maturidade. Quando a equipe é ainda inexperiente, o
Scrum Master irá dar maior apoio para que ela se torne auto-organizada. Auto-
organizada no sentido de saber a melhor forma de planejar as Sprints e desenvolver
o produto.
É recomendável que a equipe tenha um número entre 4 e 12 pessoas – mais que

isso recomenda-se quebrar a equipe em outras menores.
Cada membro da equipe decide quais atividades irão trabalhar durante o dia, dentro
do escopo definido para cada Sprint.
Responsabilidades:
 Planejar seu trabalho, definindo, com o Product Owner, o que será
realizado no decorrer do Sprint, para então detalhar, de forma autônoma,
como esse trabalho será realizado;
 Realizar as tarefas de desenvolvimento do produto para atingir a meta do
Sprint, garantindo a qualidade do que é produzido, além de acompanhar
seu progresso no Sprint em direção a essa meta;
 Interagir com o Product Owner, sempre que necessário, para ter dúvidas
esclarecidas ou solicitar decisões quanto ao produto e colabora com ele
para refinar e aprimorar o Product Backlog, preparando-o para o próximo
Sprint;
 Identifica e informa ao Scrum Master sobre impedimentos que obstruam
seu trabalho e previne-se deles, quando possível;
 Obtém feedback dos clientes do projeto e demais partes interessadas
sobre o trabalho realizado durante o Sprint, ao apresentar e demonstrar os
resultados desse trabalho ao final do Sprint;
 Entrega valor com frequência para os clientes do projeto.
O Time de Desenvolvimento é:
 Multidisciplinar, possuindo todas as habilidades e conhecimentos
necessários para gerar, em cada Sprint, o Incremento do Produto pronto,
de acordo com a Definição de Pronto;
 Suficientemente pequeno, de forma que seus membros se comuniquem
efetivamente e se auto-organizem, sendo capazes de produzir incrementos
do produto prontos que representem valor visível para os clientes;
 Motivado, uma vez que possua o ambiente, apoio e a confiança
necessários para realizar seu trabalho;
 Orientado a excelência técnica, buscando sempre aprender e realizar seu
trabalho com qualidade e consciência;
 Focado nas metas estabelecidas junto ao Product Owner.
Os eventos Scrum
O que é um Sprint?
Um Sprint é um evento timeboxed em que o time irá planejar, executar e

entregar o trabalho realizado em um tempo determinado que geralmente
pode durar 15 dias ou 1 mês, sendo que o intervalo mais curto é melhor.
No Scrum cada evento possui um tempo máximo pré-determinado para

sua realização. Isto garante que uma quantidade adequada de tempo
seja utilizada em cada evento sem desperdiçar o precioso tempo
disponível para o projeto.
Timeboxing - Períodos curtos e de duração fixa nos quais atividades ou trabalhos são
realizados. Timeboxes ajudam a trazer algum nível de ordem e consistência a um
ambiente de trabalho altamente variável. Eles oferecem uma oportunidade de avaliar
resultados, reunir feedback e controlar custos e riscos associados a um

empreendimento.
A meta de cada Sprint é levar o product backlog para um estado geral de pronto, isto
é, ao final de cada Sprint, você terá um produto completamente testado com todos
os requisitos daquela Sprint 100% completo. O Sprint é uma representação parcial
realista do produto.
Durante um Sprint:
 Não são feitas mudanças que podem afetar o objetivo do Sprint;
 A composição da Equipe de Desenvolvimento permanece constante;
 As metas de qualidade não diminuem;
 Escopo pode ser clarificado e renegociado entre o Product Owner e a Equipe
de Desenvolvimento quanto mais for aprendido;
 Um Sprint pode ser cancelado antes do time-box do Sprint terminar, se o seu
objetivo se tornar obsoleto;
 Somente o Product Owner pode cancelar um sprint;
 Quando o Sprint é cancelado, qualquer item de Backlog do Produto
c ;
 Cancelamento de Sprints consome recursos, já que todos tem que se
reagrupar em outra reunião de planejamento do Sprint para iniciar outro
Sprint.
Planejamento do Sprint:
 Revisão de backlog;
 Discussões e estimativas da equipe;
 Definição de meta de Sprint;
 Definição de "pronto";
 Plano para entregar meta de Sprint;
 Resultado: Sprint backlog e plano.
Sprint.
usualmen
. O Scrum Master ensina o Time de
Desenvolvimento a manter-se dentro dos limites do time-box.
 ?
 ?
O que pode ser pronto nesta Sprint?
O Time de Desenvolvimento trabalha para prever as

desenvolvidas durante o Sprint. O Product Owner debate o objetivo que o Sprint
deve realizar e os itens de Backlog do Produto que, se co
o seu objetivo. Todo o Time de Desenvolvimento colabora com o
entendimento do trabalho do Sprint.
, o mais
recente incremento do produto, a capacidade projetada do Time de
Desenvolvime
Sprint.
entregar no Sprint, ele determina a meta do Sprint.
C ronto?
Tendo definido o objetivo do Sprint e selecionado os itens de Backlog d
-la
jamento do Sprint pelo Time de Desenvolvimento para

prever o que este
O Product Owner pode ajudar a clarificar os itens de Backlog do Prod
convidar ou
.
No final do planejamento do Sprint, o Time de Desenvolvimento deve ser capaz de

explicar ao Product Owner e ao Scrum Master como pretende trabalhar como equipe
auto-organizada para completar o objetivo do Sprint e criar o incremento previsto.
Reunião diária
-boxed
, os membros do Time de Desenvolvimento

esclarecem:
 O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta do

Sprint?
 O que eu farei hoje para ajudar o Time de Desenvolvimento atender a meta do
Sprint?
 Eu vej mim ou o Time de Desenvolvimento no
atendimento do meta da Sprint?
completar o trabalho do Backlog do Sprint.
Todos os dias, o Time de Desenv

-
. O Time de
Desenvolvimento ou membros da equipe frequentemente se e
, ou para adaptar,
ou re-planejar, o restante do trabalho do Sprint.
O Scrum Master
-box de 15 minutos. O Scrum Master
também a regra de que somente os integrantes do Time de
Desenvolvimento .
Desenvolvimento. Esta não é uma reunião para discussão técnica do projeto,

.
Revisão do Sprint:
 Inspecionar produto;
 Ajustar o backlog;
 Demonstrar" trabalho está feito";
 Resultado: incremento.
AR
Sprint, o Time de Desenvolvimento e as partes interessadas colaboram sobre o que
-se a motivar e obter c

.
-
. O Scrum Master garante que o
evento ocorra e que os participantes entendam o seu objetivo e ensina à
-box.
A :
 Os participantes incluem o Time de Desenvolvimento e os Stakeholders

chaves convidados pelo Product Owner;
 O Product
;
 O Time de Desenvolvimento discute o que foi bem durante o Sprint, quais
problemas ocorreram dentro do Sprint, e como estes problemas foram
resolvidos;
 O Time
;

(se
);
 O grupo todo colabora sobre o que fazer a seguir
;

novas oportunidades.
Restropectiva do Sprint:
 Refletir sobre o processo;

 Identificar a melhoria potencial;
 Foco em pessoas, relacionamentos, processos e ferramentas.
-
. O
Scrum Ma
- -
responsabilidade pelo processo Scrum.
;
 Identificar e ordenar os principais itens que foram bem e as potenciais melhorias;
e,
 Criar um plano para implementar melhorias no modo que o Time Scrum faz seu
trabalho.
-lo mais efetivo e a .
Tópico 4.4 – Os artefatos SCRUM
entendimento dos artefatos.
 Product Backlog:
o no
produto e
.
Vale lembrar que um Backlog do Produto
.
,
O Backlog do Produto , requisitos, melhorias e
, ordem, estimativa e
valor.
imes de desenvolvimento frequentemente trabalham juntos no mesmo

produto.
produto .
, estimativas e
ordem aos itens no Backlog do P
Product Owner e o Time de Desenvolvimento colaboram nos detalhes dos itens.
Os itens do Backlog do Produto de maior prioridade (topo da lista) devem ser mais
claros e mais detalhados que os itens de menor pr
refinados, de modo que todos possa -boxed do Sprint.
atividades de refinamento descritas acima.
izar o trabalho fazem a estimativa

final.
Monitorando o Progresso a Caminho do Objetivo
somado. O Product Owner
o trabalho p
transparente para todas as partes interessadas.
êm sido utilizadas
para prever o progresso. Estas
 Sprint Backlog:
Podemos definir o Sprint Backlog e suas funções como:

 Um conjunto de itens do Backlog do Produto selecionados para o Sprint, juntamente com
o plano para entregar o incremento do produto e atingir o objetivo do Sprint.
 P
 Responsável pela visibilidade de todo o trabalho que o Time de Desenv

.
 U
durante a r d .
Monitorando o Progresso do Sprint
Em qualquer ponto do tempo no Sprint, o total do trabalho remanescente dos itens do

Backlog do Sprint pode ser somado. O Time de Desenvolvimento monitora o total do
trabalho restante pelo menos a cada , acompanha estes resumos elaborados
diariamente . Com o rastreamento
do trabalho restante em todo o Sprint, o Time de Desenvolvimento pode gerenciar o seu
progresso.
Incremento
Backlog do Produto completados durante o

Sprint e o valor dos incrementos de todos os Sprints anteriores. Ao final do Sprint,
- .
Definição de Pronto
Q
todos devem .
Embora, isso varie significativamente de um extremo ao outro para cada Time de

Desenvolvimento, os integrantes devem ter um entendimento compartilhado do que
significa o trabalho estar completo, assegurando a transparência.
Com um Time de Desenvolvimento maduro, é esperado que a sua definição de
Tópico 4.5 - Executando um Sprint
Durante a execução de um Sprint, certas situações podem ocorrer e é sobre elas

que falaremos agora.
Mudanças
As mudanças são bem-vindas nas abordagens ágeis, mas como custo e prazo são
fixos, o Product owner deverá repriorizar os requisitos sempre que solicitar uma
mudança. Com isto, os requisitos que ficarem por último na priorização, serão
desenvolvidos somente se o custo e o prazo ainda estiverem de acordo com o
planejamento inicial.
A equipe de desenvolvimento precisa garantir que ao final do projeto, mesmo com

as mudanças, conseguirá entregar um produto mínimo viável (MVP – minimal
product viable).
Bugs
Se em um Sprint não se conseguir resolver todos os bugs da entrega, o seu

requisito não pode ser considerado como pronto.
O Product Owner deverá decidir se este requisito entra no próximo Sprint ou não.
Pode-se criar também um Sprint somente para corrigir bugs. Esta decisão pode ser
definida com o time de desenvolvimento.
Riscos
Caso o requisito a ser desenvolvido no Sprint tenha algum risco associado, as ações
definidas para este risco deverão ser tratadas durante o Sprint, isto é, dentro do
timeboxed do Sprint é preciso considerar o esforço necessário para estas ações.
Ferramentas de apoio:
Gráfico Burndown
O gráfico de burndown mostra a evolução do trabalho do Sprint. É criado no

planejamento do Sprint onde se coloca uma linha de planejamento com o total do
esforço ou requisitos a serem desenvolvidos. No decorrer dos dias, a equipe de
desenvolvimento vai atualizando o trabalho realizado e o gráfico mostra a redução
do esforço comparando com o que foi planejado.
Ao final do Sprint, todo o trabalho planejado deverá estar zerado. Como mostra a
figura a seguir:
Kanban
Não é tradicionalmente parte do framework Scrum, mas é uma boa ferramenta de

planejamento e funciona bem em conjunto com o framework.
Como nós vimos no modulo anterior, basicamente é um quadro - ou um App, folha

de papel, parede em branco, etc. - com três ou quatro :
Esta é uma ótima maneira de visualizar rapidamente o status de um projeto,

independentemente do uso do Scrum.
Chegamos ao final do Módulo 4!
Nele nós aprendemos o framework SCRUM com as suas características. Agora você
já pode usar as práticas ágeis nos seus projetos com SCRUM.
Quais são os próximos passos?
Retorne à sala virtual, participe do Fórum de Interação e responda as questões

propostas na atividade avaliativa.
Até o próximo módulo! Bons estudos!
Rua Tomé de Souza, 1065 – Savassi | Belo Horizonte – MG | (31) 3116-1000 (31) 3223-6251

Gestao Agil de Projetos Com SCRUM - Modulo 4

Enviado por

Dados do documento

Descrição 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

Gestao Agil de Projetos Com SCRUM - Modulo 4

Enviado por

Direitos autorais:

Formatos disponíveis

Núcleo de Educação a Distância

GERENCIANDO PROJETOS COM SCRUM

Módulo IV – Práticas, Métodos e Framework

GESTÃO ÁGIL DE PROJETOS COM SCRUM

Módulo IV – O Framework SCRUM

Seja bem-vindo ao Módulo 4 do curso de Gestão Ágil de Projetos com SCRUM!

Por onde vamos começar?

 Conhecer detalhadamente o Framework SCRUM e utilizar esta abordagem nos seus

MÓDULO 4 – O FRAMEWORK SCRUM

No Rugby, Scrum é a forma de recomeçar o jogo depois de uma interrupção.

Você deve estar se perguntando o porquê do Scrum ser classificado como

Em uma metodologia todos os processos são conhecidos e previamente definidos,

utilizada nos projetos Scrum é o quadro Kanban, que facilita a visualização do

O framework Scrum é simples e leve, utilizado para a gestão do desenvolvimento de

Não é de hoje que muitos profissionais de TI têm procurado novas formas de

Os ciclos de desenvolvimento são curtos, de no máximo 30 dias e, por este motivo,

Adotar Scrum requer conhecimento das limitações e entendimento que os pilares

do manifesto ágil, pois ele é base de qualquer metodologia ágil. É fundamental

Vários são os benefícios de se utilizar Scrum, dentre eles:

 Entregas frequentes de retorno ao investimento dos clientes;

Tópico 4.1 – Pilares

para que os observadores compartilhe

 Uma linguagem comum referindo-se ao processo deve ser compartilhada por

realizam o trabalho e por aqueles que aceitam o resultado do trabalho.

para minimizar mais desvios.

Tópico 4.2 - Valores

Tópico 4.3 - O time SCRUM

O Product Owner é o usuário, representante do(s) cliente(s). Quando o cliente não

O . Pode representar o desejo de um

Para que o PO tenha sucesso, toda

Dentro do framework Scrum ele é responsável pela manutenção do Produto, através

A razão de não ser detalhada é agilidade: ao invés de serem escritos e revistos em

Considera-se que o Backlog nunca está completo, ou seja, Histórias são

necessidades e influenciando as para maximizar sua colaboração com

 Facilita o engajamento de stakeholders e gerentes externos do projeto em

Dentro do framework Scrum, ele é o facilitador da equipe.

É responsável por interagir com o PO e com outras equipes para remover as

comuniquem-se efetivamente e busquem continuamente melhorar seus

O Scrum Master serve à o , incluindo:

A equipe Scrum é auto-organizada, permitindo que todas as decisões sejam

É recomendável que a equipe tenha um número entre 4 e 12 pessoas – mais que

Um Sprint é um evento timeboxed em que o time irá planejar, executar e

No Scrum cada evento possui um tempo máximo pré-determinado para

resultados, reunir feedback e controlar custos e riscos associados a um

O que pode ser pronto nesta Sprint?

O Time de Desenvolvimento trabalha para prever as

entregar no Sprint, ele determina a meta do Sprint.

Tendo definido o objetivo do Sprint e selecionado os itens de Backlog d

jamento do Sprint pelo Time de Desenvolvimento para

O Product Owner pode ajudar a clarificar os itens de Backlog do Prod

No final do planejamento do Sprint, o Time de Desenvolvimento deve ser capaz de

, os membros do Time de Desenvolvimento

 O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta do

completar o trabalho do Backlog do Sprint.

Todos os dias, o Time de Desenv

Desenvolvimento. Esta não é uma reunião para discussão técnica do projeto,

Sprint, o Time de Desenvolvimento e as partes interessadas colaboram sobre o que

-se a motivar e obter c

 Os participantes incluem o Time de Desenvolvimento e os Stakeholders

 Refletir sobre o processo;

responsabilidade pelo processo Scrum.

-lo mais efetivo e a .

Tópico 4.4 – Os artefatos SCRUM