28

Scrum

Embed Size (px)

DESCRIPTION

Arquivo utilizado durante workshop de SCRUM na UNA

Citation preview

Page 1: Scrum
Page 2: Scrum
Page 3: Scrum

O que não é Scrum?

O que é Scrum?

Papéis no Scrum

Fluxo do Scrum

O conceito de pronto

O que veremos?

Page 4: Scrum

Não é uma metodologia

Não é uma receita de bolo

Não é completo

Não é a solução para todos seus

problemas...

O que não é Scrum?

Page 5: Scrum

Não é uma metodologia

Não é uma receita de bolo

Não é completo

Não é a solução para todos seus

problemas...

O que não é Scrum?

Page 6: Scrum

Scrum é um processo iterativo e

incremental para o desenvolvimento

de produtos e gerenciamento de projetos.

É mais um framework que uma

metodologia, mais atitude do que

processo.

O que é SCRUM?

Page 7: Scrum

Não espere que Scrum lhe diga o que

fazer a cada problema ou desafio que

você encontre, ele apenas lhe ajudará a

ter transparência para enxergar estes

problemas e desafios, você decidirá o

que fazer para resolvê-los.

O que é SCRUM?

Page 8: Scrum

Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricação de automóveis e produtos de consumo, por Hirotaka Takeuchi e Ikujiro Nonaka no artigo "The New

Product Development Game" (Harvard Business Review, Janeiro-Fevereiro 1986).

Eles notaram que projetos usando equipes pequenas e multidisciplinares produziram os melhores resultados, e associaram estas equipes altamente eficazes à formação Scrum do Rugby (utilizada para reinício do jogo em certos casos)

O que é SCRUM?

Page 9: Scrum

modelo

sobreposto

modelo

tradicional

X

Page 10: Scrum

X

Modelo tradicional

Page 11: Scrum

X

Modelo sobreposto (iterativo e incremental)

Page 12: Scrum

“É o processo de design em que as

necessidades, desejos e limitações do ser

humano são levadas em conta durante todas

as fases de concepção e desenvolvimento de

um projeto”

O que é Design

Centrado no

usuário?

O três pilares do SCRUM

Page 13: Scrum

“É o processo de design em que as

necessidades, desejos e limitações do ser

humano são levadas em conta durante todas

as fases de concepção e desenvolvimento de

um projeto”

O que é Design

Centrado no

usuário?

“Estamos descobrindo maneiras melhores de

desenvolver software fazendo-o nós mesmos e ajudando

outros a fazê-lo. Através desse trabalho, passamos a valorizar:

O Manifesto Ágil

Ou seja, mesmo havendo valor nos itens à direita, valorizamos

mais os itens à esquerda." http://agilemanifesto.org/iso/ptbr/

Page 14: Scrum

O que é melhor quando se trabalha em

projetos em equipe? Estar envolvido,

ou estar comprometido?

Porcos e Galinhas...

Page 15: Scrum

• Responsável por garantir o retorno de Investimento

• Responsável por conhecer as necessidades dos clientes

• Proxy em ambientes com mais de um cliente

Papéis no SCRUM

Product Owner Scrum Master Time

• Responsável por remover impedimentos do time

• Responsável por garantir o uso de Scrum

• Protege o time de

interferências externas

• Multidisciplinar

• Auto organizado

• Produz produto com qualidade e valor para o cliente

Page 16: Scrum

X

Fluxo do Scrum

Page 17: Scrum

Fluxo do Scrum Visão: O Product Owner define a visão do produto. Esta visão é o que representa sua necessidade, é o que deve ser satisfeito ao fim do projeto.

Para definir esta Visão, o Product Owner (P.O.)

colhe informações junto a clientes, usuários

finais, time, gerentes, stakeholders, executivos,

etc.

Page 18: Scrum

Fluxo do Scrum Product Backlog: O P.O. cria uma lista inicial de necessidades que precisam ser produzidas para que a visão do produto seja atingida, para esta lista damos o nome de Product Backlog.

Os requisitos para o produto que o Time Scrum está desenvolvendo estão

listados no Product Backlog. O P.O. é o responsável por este artefato, o que

inclui: seu conteúdo, sua disponibilidade e sua priorização.

Um Product Backlog nunca está completo, ele evolui à medida que o

produto se desenvolve. Ele é dinâmico no sentido de que ele está

constantemente mudando para identificar o que o produto precisa para ser

apropriado, competitivo e útil.

Page 19: Scrum

Fluxo do Scrum Reunião de Planejamento:

É nesta reunião que o Product

Owner apresenta os itens de maior

prioridade do Product Backlog ao

Time.

Eles trabalham em conjunto para descobrir qual

funcionalidade deverá ser desenvolvida durante a

próxima Sprint. A decisão referente à quantidade de

itens que o Time produzirá na Sprint cabe somente ao

Time. Somente o Time pode saber o que ele é capaz de

realizar na próxima Sprint.

Page 20: Scrum

Fluxo do Scrum Meta: Tendo selecionado os itens do

Product Backlog, a Meta da Sprint é

delineada. A Meta do Sprint é uma

descrição que fornece orientação ao Time

sobre a razão pela qual ele está

produzindo o sistema ou produto.

META

O motivo para se ter

uma Meta da Sprint é

dar ao time espaço

para variação em se

tratando de

funcionalidade.

Sprint Backlog

Funcionalidade A

Funcionalidade B

Funcionalidade C

META

Page 21: Scrum

Fluxo do Scrum Sprint Backlog: Ao final da reunião

de planejamento nosso Sprint Backlog

deve estar pronto, contendo: itens de

backlog selecionados, suas respectivas

tarefas e a meta da Sprint.

O time se auto-

organiza para

delegar e se

encarregar do

trabalho contido no

Sprint Backlog.

Page 22: Scrum

Fluxo do Scrum Sprint: A Sprint é uma iteração.

Sprints são eventos de duração fixa.

Durante a Sprint, o Scrum Master

garante que não será feita nenhuma

mudança que possa afetar a Meta da

Sprint. Tanto a composição do time

quanto as metas devem permanecer

constantes durante a Sprint.

As Sprints podem ser canceladas antes que o prazo fixo da Sprint

tenha acabado. Somente o Product Owner tem a autoridade para

cancelar a Sprint, embora ele possa fazê-lo sob influência dos

stakeholders, do Time ou do Scrum Master.

Obs importante: Nunca estique uma Sprint querendo ganhar mais dias. Neste caso, finalize a

Sprint mesmo que não tenha alcançado a meta.

Page 23: Scrum

Fluxo do Scrum Reunião Diária: Através da

reunião diária (ou Daily Meeting) o

time ganha visibilidade de como está

o caminho para a meta, e planeja o dia

seguinte de trabalho. O Scrum Master

novamente é o facilitador desta

reunião.

Nesta reunião de 15 minutos, cada membro deve responder:

• O que fiz desde a última reunião?

• O que pretendo fazer até a próxima?

• Tive (estou tendo) algum impedimento?

Page 24: Scrum

Fluxo do Scrum Reunião de Revisão: Através da

revisão (ou Sprint Review) realizamos a

entrega do trabalho. Será nesta reunião

que o Time apresentará ao P.O (Product

Owner) o que foi feito e como foram feitas

as demandas da Sprint.

A reunião de revisão fornece input de valor para as Sprint Planning

Meetings seguintes.

Quem participa desta reunião?

• Time

• Scrum Master

• Product Owner (que pode convidar outras pessoas / clientes)

Page 25: Scrum

Fluxo do Scrum Reunião de Retrospectiva: Esta é a

última reunião de uma Sprint Scrum. Ela

também representa o espírito de inspeção

e adaptação dentro do Scrum. Podemos

avaliar o que foi bom e ruim junto ao time,

ao projeto ou até mesmo a empresa.

A finalidade da retrospectiva é inspecionar como correu a última

Sprint em se tratando de pessoas, das relações entre elas, dos

processos e das ferramentas. A inspeção deve identificar e

priorizar os principais itens que correram bem e aqueles que, se

feitos de modo diferente, poderiam ter deixado as coisas ainda

melhores.

Page 26: Scrum

Fluxo do Scrum Incremento do Produto: Ao se

utilizar Scrum, os produtos são construídos

iterativamente, de modo que cada Sprint

cria um incremento do produto, iniciando

pelo de maior valor e maior risco. Mais e

mais Sprints vão adicionando incrementos

ao produto.

Cada incremento é um pedaço potencialmente entregável do

produto completo. Quando já tiverem sido criados incrementos

suficientes para que o produto tenha valor e uso para seus

investidores, o produto é entregue.

Page 27: Scrum

No desenvolvimento de produtos, afirmar que a

funcionalidade está pronta pode levar alguém a

presumir que ela está pelo menos bem

codificada, refatorada, que tenha passado por

testes unitários, e que tenha passado por testes

de aceitação.

O conceito de PRONTO

Outros podem presumir que apenas o código tenha sido

desenvolvido. Se ninguém sabe qual a definição de “pronto”,

os outros dois pilares do controle de processos empíricos não

funcionam. Quando alguém descreve algo como “pronto”,

todos devem entender o que “pronto” significa.

Page 28: Scrum

Obrigado!

Guilherme Marques

http://www.guilhermemarques.com

@guimarques