SCRUM Apostila

1

© 2009-2011 Rafael Sabbagh

Rafael Sabbagh

• Certified Scrum Trainer (CST), Scrum Alliance

• ScrumMaster, Scrum Coach & Scrum Trainer

• Palestrante em eventos e congressos:

Participante:

Organizador:

@rsabbagh


Um pouco de

história

2


Um pouco de história...

• Década de 50: a gestão de projetos é reconhecida como disciplina, nascida a

partir da administração

• Henri Fayol:

– Seu trabalho é a base para a gestão de projetos tradicional

– O gestor possui 5 funções básicas:

• Ferramentas como o gráfico de Gantt são

adotadas para listar, acompanhar e controlar a

execução das tarefas contidas em um projeto

• Até então a gestão de projetos é voltada para grandes projetos de engenharia e

construção civil

Planejar Organizar Comandar Controlar Coordenar



• Década de 60: o desenvolvimento de software começa a ganhar

complexidade

• Projetos de software: uso de medotologias tradicionais então aplicadas

a projetos de engenharia e construção civil

• Problemas começam a surgir:

– desenvolvimento de software exige mudanças frequentes

– o cliente não sabe exatamente o que ele quer até ver partes do software pronto

• Porém, Meredith & Mantel acreditam que “problemas de comunicação e

entendimento do que deve ser feito são responsáveis por falhas nos

projetos”

3



Waterfall

1970: Winston Royce publica artigo

criticando a abordagem tradicional para

desenvolvimento de software



• Waterfall segue o conceito Big Design Up Front (BDUF).

• BDUF: “revisão exaustiva da especificação pode garantir a ausência de mudanças críticas na fase de execução”

• BDUF: adequado apenas para projetos estáveis, com pouca ou nenhuma mudança

– Mudanças devem ser evitadas a todo custo.

– Se não for possível evitá-las, o gerente de projetos deve gerenciá-las.

4





• 1990: DeGrace & Stahl listam fatores que tornam questionável o uso de BDUF para projetos de software:

– Requisitos não são completamente compreendidos no início do projeto;

– Usuários só sabem exatamente o que querem após ver uma versão inicial do produto;

– Requisitos mudam durante o processo de desenvolvimento;

– Novas ferramentas e tecnologias tornam a estratégia de desenvolvimento imprevisíveis

5


Fonte: Agile Project Management with Scrum, Ken Schwaber, 2004

Gráfico de Complexidade para Projetos de Software

Anarquia

Complexo

Simples

Tecnologia

Req

uis

ito

s

Próximo à Certeza

Distante da Certeza

Próximo à Concordância

Distante da Concordância



Uso de Funcionalidades pelo Cliente

Fonte: Standish Group, 2002

6


Agilidade


Agilidade 2001: representantes de processos

leves de desenvolvimento de software

se reuniram para discutirem sobre o que

seus processos possuíam em comum

7


Os 12 Princípios Ágeis

1. Nossa maior prioridade é satisfazer o cliente através da entrega

contínua e adiantada de software com valor agregado.

2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no

desenvolvimento. Processos ágeis tiram vantagem das mudanças

visando vantagem competitiva para o cliente.

3. Entregar frequentemente software funcionando, de poucas semanas a

poucos meses, com preferência à menor escala de tempo.

4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente

em conjunto por todo o projeto.

5. Construa projetos em torno de indivíduos motivados. Dê a eles o

ambiente e o suporte necessário e confie neles para fazer o trabalho.

6. O método mais eficiente e eficaz de transmitir informações para e entre

uma equipe de desenvolvimento é através de conversa face a face.


Os 12 Princípios Ágeis

7. Software funcionando é a medida primária de progresso.

8. Os processos ágeis promovem desenvolvimento sustentável. Os

patrocinadores, desenvolvedores e usuários devem ser capazes de

manter um ritmo constante indefinidamente.

9. Contínua atenção à excelência técnica e bom design aumenta a

agilidade.

10.Simplicidade--a arte de maximizar a quantidade de trabalho não

realizado--é essencial.

11.As melhores arquiteturas, requisitos e designs emergem de equipes

auto-organizáveis.

12.Em intervalos regulares, a equipe reflete sobre como se tornar mais

eficaz e então refina e ajusta seu comportamento de acordo.

8


Entrega de Valor: Agile x Waterfall

Tempo

Entr

ega d

e V

alo

r

r e l e a s e s Á g e i s

release Waterfall

0


Plan Driven x Value Driven

Fixo

Estimado

Plan

Driven

Value

Driven

Requisitos

Requisitos Custo Tempo

Custo Tempo

Waterfall Agile

9


O que é

Scrum


Scrum...

• ...é um framework ágil simples para desenvolvimento de produtos complexos em ambientes complexos;

• ...não é um processo ou técnica: dentro de Scrum podem-se empregar diversos processos e técnicas;

• ...utiliza a abordagem iterativa e incremental para melhorar a previsibilidade e o controle de riscos;

10


Scrum...

• ...torna os problemas das práticas de desenvolvimento transparentes, para que se possa melhorá-las;

• ...gera entrega frequente de valor para o cliente;

• ...utiliza inspeção e adaptação para melhoria contínua do produto e dos processos de desenvolvimento;


Scrum...

• ...é orientado a valor, e não a planos

• ...utiliza times auto-organizados, que definem as melhores formas de desenvolverem as funcionalidades de maior valor

...é focado na ordenação do trabalho baseada no maior valor de negócio para o cliente;

11


O que é

Scrum As Origens

do Scrum


Scrum: Origens

• Ken Schwaber, início dos anos 90: desenvolvimento em sua

empresa do que se tornaria o Scrum

• Jeff Suttherland, 1993: desenvolvimento

do Scrum na Easel Corporation

• Ken Schwaber : formalização do Scrum na OOPSLA’95

• Anos seguintes: Schwaber e Sutherland

colaboram para unificar seus trabalhos

• Publicação do livro “Agile Software

Development with Scrum”, por Ken

Schwaber e Mike Beedle

12


Scrum: Origens

• “The New New Product Development

Game”, de Takeuchi e Nonaka (1986)

• Equipes de desenvolvimento de

novos produtos de empresas

americanas e japonesas

• Instabilidade embutida

• Equipes auto-organizadas

• Fases sobrepostas de desenvolvimento

• Múltiplo aprendizado

• Controle sutil

• Transferência organizacional de

aprendizado


Scrum: Origens

O nome Scrum vem do Rugby!

• “The New New Product Development

Game”, de Takeuchi e Nonaka (1986)

13


Scrum: Origens

• Sistema Toyota de Produção

e Produção Enxuta

– Produção “puxada” pelo cliente

– Produção de valor em fluxo estável e contínuo, sem

paradas, lotes, filas ou departamentos

– Qualidade embutida no processo: jidoka

– Melhoria contínua: kaizen

– Combate ao desperdício:

• muda: etapas sem valor

• muri: sobrecarga nas pessoas e equipamentos

• mura: desbalanços nos ritmos de produção


O que é

Scrum Os Pilares

do Scrum

14


Processos Definidos X Processos Empíricos

• Processos definidos:

– Ambientes controlados

• ex: linhas de produção

– Mesmas entradas, mesmas saídas

• Processos empíricos:

– Complexos e imprevisíveis

– Diferentes entradas, diferentes saídas

• Scrum é embasado na

Teoria de Controle de Processos Empíricos

– Pilares: Transparência, Inspeção e Adaptação

Os Pilares do Scrum


Os Pilares do Scrum

• #1: Transparência

– Ver: aspectos que afetam o

resultado do projeto devem ser

visíveis para os que gerenciam

estes resultados

O que é visto deve ser compreendido: se

quem inspeciona o processo acredita que está

pronto, isso deve corresponder à definição de

pronto utilizada

15


Os Pilares do Scrum

• #2: Inspeção

– Investigar: deve haver inspeção no

processo com frequência suficiente para se

detectar variações inaceitáveis


Os Pilares do Scrum

• #3: Adaptação

– Melhorar: ao se detectar variações

inaceitáveis, o processo deverá ser ajustado

o tão rápido quanto possível para se

minimizar desvios ainda maiores

16


Introdução ao Scrum


Time de Scrum

• Product Owner

– Garante e maximiza o ROI do cliente a partir do

trabalho do Time

• Time de Desenvolvimento (o Time)

– Gera valor para o cliente construindo incrementos do

produto com alta qualidade

• ScrumMaster

– Garante que aos valores do Scrum, práticas e regras

estão sendo compreendidos e seguidos

17


Introdução

ao Scrum Resumo do

Ciclo do Scrum


A VISÃO DO PRODUTO e o

PRODUCT ROADMAP

devem ser criados antes do

início do desenvolvimento

Resumo do Ciclo do Scrum

18


O representante do cliente, chamado de

PRODUCT OWNER, levanta com os

stakeholders os requisitos de maior

prioridade no momento



Ele então insere esses

requisitos em uma lista

ordenada, chamada

PRODUCT BACKLOG


19



O Product Owner e o Time se reúnem na

SPRINT PLANNING MEETING e geram o

SPRINT BACKLOG: o que será feito e

como será feito neste ciclo de

desenvolvimento (SPRINT)


O Time faz o trabalho de

desenvolvimento do incremento

do produto que foi planejado,

buscando atingir a Meta da Sprint


20


Em cada dia, o Time faz a DAILY

SCRUM, uma reunião de 15 minutos para

promover visibilidade e comunicação

entre os membros do Time


O que fiz

O que farei

Quais foram os

impedimentos


Ao final do ciclo de desenvolvimento,

o Time terá produzido um

incremento no produto pronto, que

significa valor para o cliente


DEFINIÇÃO

DE DONE

__ ____ ____

________ __

_____ ___ __

21


O Time então se reúne com o

Product Owner e stakeholders na

SPRINT REVIEW e apresenta o

que foi feito na Sprint



E, em seguida, o Time se reúne para a

SPRINT RETROSPECTIVE, onde verifica

o que funcionou bem e o que pode

melhorar nas próximas Sprints


22


...e o ciclo recomeça.



Papéis:

Time de Scrum

23


Product Owner: Atribuições

• Gerencia o Product Backlog: garante a visibilidade, insere, remove, modifica e ordena os itens

• Gerencia os stakeholders do projeto – identifica os stakeholders e seu nível de apoio

– comunica-se com eles para entender suas necessidades

– balanceia as diferentes necessidades dos stakeholders

– influencia os stakeholders

• Gerencia a Visão do Produto: estabelece, mantém e comunica

• Gerencia os Releases do produto para o cliente

Responsável por garantir e maximizar o ROI do cliente a partir do trabalho do Time


Product Owner: Atribuições

• Participa ativamente das Sprints – Disponível para o Time

– Sprint Planning / Sprint Review (e Release Planning)

• Aceita ou rejeita na Sprint Review o trabalho realizado pelo Time

• Gerencia o orçamento: garante que há orçamento suficiente para o projeto durante todo seu desenvolvimento

Responsável por garantir e maximizar o ROI do cliente a partir do trabalho do Time

24


Product Owner: Características

• Único (só pode haver um!) – Não é comitê, não há substitutos

– Influenciado por outros (Time, stakeholders e até mesmo um time de negócios)

– Tem a voz final sobre o Product Backlog

• Disponível – para tirar dúvidas do Time e tomar decisões sobre o produto

– para falar com os stakeholders e atualizar o Product Backlog frequentemente

• Representativo – com suficiente poder e conhecimento necessário para tomar decisões rápidas e

corretas sobre o produto


Time de Desenvolvimento: Atribuições

• Trabalha sobre o Product Backlog, em direção à visão do produto

• Entrega valor frequentemente para o cliente

• Auto-organiza-se para realizar o trabalho – com poder para gerenciar seu trabalho de desenvolvimento, responsável por

seus resultados

– comunicação: melhores Times são pequenos (7 ± 2 membros) e co-localizados

• Comunica-se frequentemente com o P.O. – dúvidas e decisões sobre o produto

• Informa os impedimentos ao ScrumMaster assim que detectados

Gera valor para o cliente construindo incrementos do produto com alta qualidade

25


Time de Desenvolvimento: Características

• Multidisciplinar – todo conhecimento e habilidades necessárias para gerar o trabalho pronto

(DoD), incluindo qualidade

– os melhores Times são Feature Teams

– não há títulos no Time

– fertilização cruzada: um aprendendo do outro

• Suficientemente pequeno (7 ± 2) para garantir comunicação

• Motivado, com a confiança e apoio necessários

• Tecnicamente excelente

• Comprometido a alcançar as metas da Sprint/Release – os

melhores Times são 100% dedicados ao projeto (sem multitasking)


ScrumMaster: Atribuições

• Remove os impedimentos que atrapalham o trabalho do Time

• Facilita as reuniões do Scrum

• Facilita o trabalho do Time e sua relação com o P.O.

• Ensina (ou garante que aprenda) e encoraja o Time a melhorar seu trabalho, com qualidade e produtividade, e a se auto-organizar

• Alinha as necessidades do Time e as da organização

• Ajuda a escolher e ensina o P.O. (ou garante que aprenda)

Garante que aos valores do Scrum, práticas e regras estão sendo seguidos

26


ScrumMaster: Características

• Competente em soft skills: facilitador, negociador, comunicador, gerência de conflitos etc.

• Corajoso para realizar as mudanças necessárias e remover os impedimentos

• presente durante todo o trabalho do Time

• isento o suficiente para garantir que não haja desvios no processo, para facilitar o consenso, para não interferir nas decisões do Time e para ajudar o Time a melhorar seu trabalho


ScrumMaster

27


Product Backlog


• Lista de requisitos do produto – itens com desejos

de negócios do cliente, melhorias no produto,

correções de bugs, tarefas técnicas etc.

• Meio para se alcançar a visão do produto

• Itens ordenados por prioridade de desenvolvimento

– itens do alto: < granularidade, > detalhe

– itens de baixo: > granularidade, < detalhe

• Lista incompleta e dinâmica em constante evolução

– ambiente evolui e clientes e Time aprendem sobre o

produto

O que é o Product Backlog?

28


• Product Owner é o único responsável por gerenciar o

Product Backlog – atualizar, ordenar e dar visibilidade

• Seus itens possuem descrição e estimativa

• A ordenação é determinada por: valor que gerará ao

cliente, risco e necessidade




29


• Ordenado: itens são ordenados de acordo com a

prioridade de sua implementação – de forma a

maximizar o ROI do cliente

• Estimável: julgar e formar uma opinião sobre o

tamanho do Product Backlog ou de uma parte

relevante dele (ex. próxima Sprint ou Release)

• Emergente: incompleto, dinâmico, em constante

evolução – mudança no ambiente e no produto

• Gradualmente refinado: de acordo com a ordenação

Product Backlog é...


Ordenando o Product Backlog

Sprint

Release

Futuras Releases

Desenvolvidos

mais cedo

30


• Estimar ajuda o Time a conhecer sua velocidade e ser capaz de se compromenter com itens de acordo

• Estimar ajuda o Product Owner a criar o Plano de Release, baseado na velocidade do Time

• Estimar ajuda a medir o progresso em uma release usando o Release Burndown

• Estimativas feitas pelo Time!

Estimando o Product Backlog


• Acurácia é mais importante que precisão!


31


• Story Points

– Unidade de medida para determinar o tamanho do

item do Product Backlog (geralmente User Stories)

– Story points significam o tamanho do esforço relativo necessário para desenvolver o item

– É uma medida relativa (entre os itens)

– Fibonacci: 0, 1, 2, 3, 5, 8, 13, 21, 34... (ou, adaptado: 0, 1, 2, 3, 5, 8, 13, 20, 40...)



• Uma das técnicas para realizar a estimativa do Product Backlog é o PLANNING POKER

8

• Inicialmente, o Time escolhe o item de menor esforço e atribui o tamanho de 2

• O Time escolhe um item e joga o Planning Poker para estimá-lo, tendo como base o item de tamanho 2

• O Time escolhe mais um item e joga o Planning Poker para estimá-lo, tendo como base os itens já estimados - triangulação

STORY POINTS


32


Jogando o PLANNING POKER

2

13 • Para um item, todos os membros do Time

escolhem uma estimativa nas cartas – não mostrar até que todos tenham escolhido

• Todos mostram as cartas ao mesmo tempo

• Os membros com a maior e a menor estimativa devem justificar

• Jogam-se novamente as cartas, até o consenso – ScrumMaster facilita!



• T-Shirt Sizing

P M G GG


33


• Ao final da Sprint, o trabalho desenvolvido deve estar

pronto

• Mas o que significa “pronto”?

• O Time e o Product Owner devem definir o que significa

pronto

• Quando alguém diz que algo está pronto, todos devem

entender o que isso significa

• Ex. de software: codificado, testado e documentado

Definição de Pronto


• Product Backlog necessita atenção e cuidados constantes

• Grooming é um processo que assegura que o Product

Backlog seja Ordenado, Estimável, Emergente e

Gradualmente Refinado

– pré-requisito para uma Sprint Planning bem-sucedida

• Feito colaborativamente pelo Product Owner e pelo Time (Time geralmente dedica 10% de seu tempo)

• Cada Time Scrum tem seu próprio processo de grooming:

sessões diárias curtas, sessões semanais, workshop etc.

Product Backlog Grooming

por Roman Pichler

34


Passos para Grooming:

• Descobrir e descrever novos itens; modificar ou remover os

existentes

• Ordenar – alto: mais importente baixo: menos importente;

quais itens na próxima release, ordem de implementação

• Itens de alta prioridade preparados (DoR): decompostos e

refinados; claros: entendimento comum; factíveis: pequenos o

suficiente para a sprint; testáveis: podem ser validados

• Time estima novos itens e corrige os antigos por Roman Pichler

Product Backlog Grooming


• Preparado = item do Product Backlog está disponível e

preparado para discussão pelo Product Owner na

Sprint Planning

• DoR descreve um estado em que os itens do Product

Backlog devem estar para estarem qualificados para

discussão na Sprint Planning

• Objetivo claro para o Time, previne “estragar” a Sprint

• O quê, Como, estimado, pequeno o suficiente

Definição de Preparado (ready, DoR)

por Jeff Sutherland / Serge Beaumont

35


User Stories para itens do Product Backlog


User Stories

Quem?

O quê?

Por quê?

Como um <PERFIL>, eu

posso/gostaria/devo

<FUNÇÃO> para <VALOR>

Como um COMPRADOR, eu

posso PESQUISAR LIVROS

para ESCOLHER O QUE

VOU COMPRAR

36


User Stories: os três C’s

CARD

(cartão)

CONVERSATION

(conversas)

CONFIRMATION

(confirmação)

Descrição da story

suficiente para

identificar o requisito

e para lembrar do que

se trata a story Conversas sobre a

story, por onde de

fato o requisito é

comunicado do

cliente aos

programadores Testes que documentam

os detalhes da story e

podem ser usados para

determinar quando ela

está completa


User Stories: INVEST

Independent

Negotiable

Valuable

Estimable

Small

Testable

Independente das

outras stories

Negociável, detalhes

serão negociados

Valiosa para o cliente

Estimável pelos

desenvolvedores

Pequena em esforço

de implementação

Testável para permitir

a confirmação

Uma

User

Story

deve

ser:

37


User Stories: Stories, Temas e Epics

ÉPICO

STORY

STORY

STORY

STORY

STORY

STORY

TEMA

STORY STORY

STORY

STORY STORY

STORY STORY STORY


User Stories: Testes de Aceitação

Como um usuário,eu posso

exportar dados em XML para poder

integrar minhas informações com

outros sistemas

•Abrir no Excel o arquivo XML

exportado

•Confrontar campo a campo com o

modelo estabelecido

Testes de Aceitação

•Servem para verificar que as user

stories implementadas funcionam como

o cliente pediu

•São escritos pelo cliente, antes da

codificação, com a ajuda dos

desenvolvedores

38


• Reunião que inclui desenvolvedores, usuários, cliente

e qualquer pessoa que possa contribuir na

descoberta de stories

• Os participantes escrevem quantas stories

conseguirem, sem se preocupar com priorização

• Uso de brainstorming e prototipação rápida, de

baixa fidelidade

User Stories: Story-Writing Workshop


• Product Owner escreve os critérios de aceitação para

cada item desejado antes da Sprint Planning

• Durante a Sprint Planning, os critérios de aceitação

são discutidos e negociados com o Time

• Enunciados pequenos e

fáceis de se entender

• Definem os limites para um item

Adaptado de um artigo de Sandy Mamoli

Critérios de Aceitação

39


• Ajudam o P.O. a responder o que ele precisa para que

essa funcionalidade propicie valor

• Ajuda o Time a ganhar uma compreensão compartilhada

sobre a Story/funcionalidade

• Ajudam programadores/testers a gerar os testes

• Ajudam programadores a saber quando devem parar de

adicionar mais funcionalidades a uma story


Adaptado de um artigo de Sandy Mamoli


• Exemplo: “como um aluno, quero me registrar

online, para não me deslocar ou enfrentar filas”

– Os campos obrigatórios do formulário devem estar

claramente indicados

– Caso o usuário submeta o formulário sem completar

todos os campos obrigatórios, esses campos devem

ser indicados e o formulário não é submetido

– Um email de confirmação deve ser enviado após

submeter o formulário


40


Ciclo do Scrum


Sprint Planning Meeting

41


O que é a Sprint Planning Meeting?

• Planejamento da iteração: – Time e Product Owner defininem que itens do Product

Backlog serão implementados na Sprint e os quebram em tarefas – Sprint Backlog

– Reunião de 8h (Sprints de 1 mês) ou 5% da Sprint

– Product Owner presente

• 1a. Parte: O quê? – Escolha de itens mais prioritários do Product Backlog a

serem implementados

– Definição da Meta da Sprint

• 2a. Parte: Como? – Time quebra itens em tarefas e estima o tempo (quando

usado) para realização de cada tarefa


O que é a Sprint Planning Meeting?

• Resultado: Sprint Backlog inicial + Meta

Itens Tarefas

a fazer

Tarefas em

andamento Feito

Meta

42


• A velocidade do Time é a media de story points

entregue pelo Time nas últimas Sprints

• É usado para ajudar o Time a decidir quantos com

pontos irá cometer na Sprint sendo planejada

• É uma medida relativa a cada Time, ou seja, não

pode ser usada para comparar diferentes Times

• Quão mais constante for a formação do

Time e a duração das Sprints, melhor

funciona

Medindo a Velocidade do Time


Sprint Backlog

43


O que é o Sprint Backlog?

• Composto por uma lista dos itens que serão desenvolvidos durante a Sprint, as tarefas correspondentes, o andamento e as estimativas

• Os itens são selecionados do Product Backlog na Sprint Planning Meeting

• Cada item é quebrado em tarefas. Parte das tarefas é definida no Planning, parte ao longo da Sprint



• As tarefas podem ser estimadas ou não, mas deve-se traçar o Sprint Burndown

• O Sprint Backlog é modificado ao longo da Sprint – estimativas (quando há) são atualizadas

– tarefas podem surgir para os itens já existentes

• Deve ter alta visibilidade

• Pertence ao Time

44




• A velocidade de um Time é a média de pontos

entregues pelo Time nas últimas Sprints

• Deve ser usada para ajudar o Time a decidir quantos

pontos de itens conseguirá pegar na próxima Sprint

• É relativo a cada Time, ou seja, não é possível

comparar velocidade entre times diferentes

• Funciona bem quando o Time e a duração das Sprints

se mantêm constantes

Medindo a Velocidade do Time

45


Estimar as Tarefas?

Estimativa por horas

• Na segunda parte da Sprint Planning, cada membro estima as tarefas que ele irá realizar pelo número de horas que acredita que levará

• De preferência, cada tarefa é < 1 dia e > 2 horas

• Devem ser atualizadas sempre que pertinente

• O Sprint Burndown reflete o número de horas restantes totais de todas as tarefas

• Desvantagens: – Diminui o senso de propriedade de grupo

– Dificuldade no trabalho em par eventual

– Cria mais uma escala além da usada para tarefas


Traçando o Sprint Burndown

Estimativa por horas

• Sprint Burndown é um gráfico que mostra a soma das horas estimadas restantes das tarefas da Sprint pelo tempo

– Y: horas estimadas restantes das tarefas

– X: dias da Sprint

• Serve para acompanhar o progresso em direção ao final de um sprint

• É feito inicialmente no Sprint Planning Meeting e deve ser atualizado a cada dia da Sprint

46




Usando os pontos dos itens

• Sprint Burndown é um gráfico que mostra a soma dos pontos estimados restantes dos itens da Sprint (a partir das tarefas realizadas e restantes) pelo tempo

– Y: pontos estimados restantes

– X: dias da Sprint

• Serve para acompanhar o progresso em direção ao final de um sprint

• É feito inicialmente no Sprint Planning Meeting e deve ser atualizado a cada dia da Sprint


47


A Sprint


• Sprint é a iteração (ciclo) de desenvolvimento – Sprint Planning Meeting

– Trabalho de Desenvolvimento

– Sprint Review

– Sprint Retrospective

• Cada Sprint deve ter uma meta

• Têm duração fixa (de 2 semanas a 1 mês) e ocorrem uma atrás da outra

• Não deve haver nenhuma mudança que afete a meta da Sprint

O que é a Sprint?

48


O que é a Sprint?

• Cada Sprint deve ter como saída

um incremento entregável do

produto que satisfaça à meta

• Ao final da Sprint, todo trabalho entregável deve estar

pronto

• O deadline não pode ser mudado. Somente o escopo

pode variar (desde que não afete a meta da Sprint)


O que é a Sprint?

• A Sprint deve sempre produzir valor entregável,

mesmo que haja mais trabalho de arquitetura ou

infraestrutura

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

Iten

s q

ue

ge

ram

va

lor v

isív

el p

ara

o c

lien

te

Ite

ns

de

arq

uit

etu

ra,

infr

ae

str

utu

ra e

tc.

49


• A Sprint pode ser cancelada se a Meta da Sprint perder o sentido

• Somente o Product Owner pode decidir pelo cancelamento da Sprint

• É exceção, deve ser raro

• Inicia-se imediatamente uma nova Sprint

Cancelamento da Sprint


O Tamanho da Sprint

• O tamanho da Sprint é fixo! (1-4 semanas) Só pode ser alterado se for detectada a necessidade na Sprint Retrospective

• Horizonte curto suficiente para que mudanças necessárias não alterem a meta da Sprint

• Sprints curtas: mudanças muito frequentes,

entregas mais frequentes, projetos curtos

• Sprints longas: mudanças menos frequentes, overhead de reuniões

50


Daily Scrum


O que é a Daily Scrum?

• Reunião de 15 minutos realizada todo dia no mesmo local, à mesma hora.

– Visibilidade

– Comunicação

– Decisão rápida

• Cada membro do Time detalha:

– O que ele completou desde a última Daily Scrum;

– O que ele vai fazer antes da próxima Daily Scrum;

– Quais obstáculos estão em seu caminho.

• O ScrumMaster deve remover os obstáculos encontrados

• O Sprint Burndown deve ser atualizado!

51


Sprint Review


O que é a Sprint Review?

• Reunião informal onde o Time mostra aos

stakeholders o que foi feito durante a Sprint

– Reunião de 4h (Sprints de 1 mês) ou 5% da Sprint

– Product Owner presente

• Time demonstra o que fez e responde a perguntas

• PO verifica o que foi e o que não foi feito na Sprint e

estabelece se a meta foi atingida

• Entrada para a Sprint Planning seguinte

52


Sprint Retrospective


O que é a Sprint Retrospective?

• Reunião para inspecionar como correu a Sprint com relação aos processos: – Reunião de 3h

– Em geral, Product Owner não deve estar presente

• Identificar e priorizar:

– O que foi bem?

– O que pode melhorar?

• Identificar ações para melhorias - adaptação

53


• Cinco passos:

– Preparação

– Colher dados

– Gerar insights

– Decidir o que fazer

– Fechar a retrospectiva



O que foi bem? O que pode melhorar? Ações de melhoria


54


Gestão de

Releases


• É a entrega para o cliente de um incremento no produto

• Deve ser decidida pelo Product Owner, de acordo com as necessidades do cliente

• A Release só pode ser feita quando incrementos no produto suficientes tiverem sido feitos para gerar valor para o cliente

Sprint 1 Sprint 2 Sprint 3 Sprint 4

Release 1

Sprint 5 Sprint 6

Release 2…

O que é uma Release?

Sprint 7 Sprint 8

55


Cenário #1

• Sem Plano de Release

• Fazer releases cedo e frequentemente

• Product Owner decide fazer a Release quando incrementos suficientes do produto criaram valor para os clientes

Gestão de Release


Cenário #2 – Plano de Release

• Itens do Product Backlog devem estar estimados pelo Time e ordenados pelo Product Owner

• Para cada Release, realizar a reunião de Release Planning Meeting para criar o Plano de Release

• Fazer releases cedo e frequentemente

• Acompanhar o progresso através do Release Burndown

• Atualizar o Plano de Release a cada Sprint

Gestão de Release

56


• Reunião (não obrigatória) realizada para cada release para criar o Plano de Release:

– Meta da Release: caminho para a Visão do Produto

– data da entrega

– Itens ordenados do Product Backlog que, a princípio, serão entregues nas Sprints da Release

• Não é um compromisso

• Veja que itens cabem na Release usando o número calculado de Sprints, estimativas não refinadas do Time para os itens e a velocidade do Time

• Geralmente, distribua os itens apenas pelas duas primeiras Sprints

Reunião de Release Planning


Sprint 1 Sprint 2 Sprints 3-6

Plano de Release

Reunião de Release Planning

57


Traçando o Release Burndown

• Release Burndown é um gráfico que mostra a soma dos pontos de esforços estimados restantes dos itens da Release pelo tempo

– Y: pontos de esforços estimados restantes

– X: iterações (Sprints)

• Serve para acompanhar o progresso em direção a uma entrega

• É feito inicialmente no Release Planning Meeting e deve ser atualizado no final de cada Sprint


Traçando o Release Burndown

58


Escalando

Scrum


Escalando Scrum

• Problema: projeto grande demais

• Time deve ter no máximo 9 membros

?

59


Escalando Scrum

• Solução: diversos Times no mesmo projeto


Escalando Scrum

• Scrum of Scrums

– Mecanismo para coordenação de diversos Times

trabalhando no mesmo projeto

– Daily Scrum adicional (Daily Scrum of Scrums), formada por um membro de cada Time do mesmo projeto, visando sincronizar o trabalho de todos os Times e tratar de problemas

– Foco em dependências, integração e sobreposições de trabalho

60


Escalando Scrum

• Scrum of Scrums

– Mesmo Product Backlog para todos os itens

– Funciona quando não há grandes dependências entre o trabalho dos Times

• Minimizar dependências, ortogonalizar o trabalho dos Times

– Questões:

• O que o Time fez desde a última reunião?

• O que o Time pretende fazer até a próxima reunião?

• O que está/esteve atrapalhando o Time?

• O Time gerará impedimentos para outros Times?


Escalando Scrum

• Extendendo: Scrum of Scrums of Scrums

© Mountain Goat Software

61



Scrum Alliance

http://www.scrumalliance.org

62


Scrum Alliance

Certificações da Scrum Alliance


Obrigado!

Rafael Sabbagh

[email protected]

rsabbagh

http://rsabbagh.com

http://facebook.com/SabbaghTC

SCRUM Apostila

Documents

Transcript of SCRUM Apostila