SCRUM Apostila

Rafael Sabbagh
Certified Scrum Trainer (CST), Scrum Alliance ScrumMaster, Scrum Coach & Scrum Trainer Palestrante em eventos e congressos:
@rsabbagh
Organizador:
Participante:
2009-2011 Rafael Sabbagh
Um pouco de histria
Um pouco de histria...
Dcada de 50: a gesto de projetos reconhecida como disciplina, nascida a
partir da administrao Henri Fayol:
Seu trabalho a base para a gesto de projetos tradicional O gestor possui 5 funes bsicas:
Planejar
Organizar Comandar
Controlar Coordenar
Ferramentas como o grfico de Gantt so adotadas para listar, acompanhar e controlar a execuo das tarefas contidas em um projeto
At ento a gesto de projetos voltada para grandes projetos de engenharia e construo civil 2009-2011 Rafael Sabbagh
Dcada de 60: o desenvolvimento de software comea a ganhar
complexidade
Projetos de software: uso de medotologias tradicionais ento aplicadas a projetos de engenharia e construo civil
Problemas comeam a surgir:

desenvolvimento de software exige mudanas frequentes o cliente no sabe exatamente o que ele quer at ver partes do software pronto
Porm, Meredith & Mantel acreditam que problemas de comunicao e entendimento do que deve ser feito so responsveis por falhas nos projetos
1970: Winston Royce publica artigo
criticando a abordagem tradicional para desenvolvimento de software
Waterfall
Waterfall segue o conceito Big Design Up Front (BDUF).
BDUF: reviso exaustiva da especificao pode garantir a ausncia de mudanas crticas na fase de execuo
BDUF: adequado apenas para projetos estveis, com pouca ou nenhuma mudana
Mudanas devem ser evitadas a todo custo. Se no for possvel evit-las, o gerente de projetos deve gerenci-las.
1990: DeGrace & Stahl listam fatores que tornam questionvel o
uso de BDUF para projetos de software:
Requisitos no so completamente compreendidos no incio do projeto; Usurios s sabem exatamente o que querem aps ver uma verso inicial do produto; Requisitos mudam durante o processo de desenvolvimento; Novas ferramentas e tecnologias desenvolvimento imprevisveis tornam a estratgia de
Grfico de Complexidade para Projetos de Software
Distante da Concordncia
Anarquia
Requisitos
Complexo
Prximo Concordncia
Simples
Prximo Certeza
Tecnologia
Distante da Certeza
Fonte: Agile Project Management with Scrum, Ken Schwaber, 2004
Uso de Funcionalidades pelo Cliente
Fonte: Standish Group, 2002
Agilidade
Agilidade
2001: representantes de processos

leves de desenvolvimento de software se reuniram para discutirem sobre o que seus processos possuam em comum
Os 12 Princpios geis
1. Nossa maior prioridade satisfazer o cliente atravs da entrega contnua e adiantada de software com valor agregado. 2. Mudanas nos requisitos so bem-vindas, mesmo tardiamente no desenvolvimento. Processos geis tiram vantagem das mudanas visando vantagem competitiva para o cliente. 3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferncia menor escala de tempo. 4. Pessoas de negcio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. 5. Construa projetos em torno de indivduos motivados. D a eles o ambiente e o suporte necessrio e confie neles para fazer o trabalho. 6. O mtodo mais eficiente e eficaz de transmitir informaes para e entre uma equipe de desenvolvimento atravs de conversa face a face.
Os 12 Princpios geis
7. Software funcionando a medida primria de progresso. 8. Os processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente. 9. Contnua ateno excelncia tcnica e bom design aumenta a agilidade. 10. Simplicidade--a arte de maximizar a quantidade de trabalho no realizado-- essencial. 11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizveis. 12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e ento refina e ajusta seu comportamento de acordo.
Entrega de Valor: Agile x Waterfall

release Waterfall
Entrega de Valor
r e l e a s e s
g e i s
Tempo
Plan Driven x Value Driven

Agile
Custo Tempo
Waterfall
Fixo
Requisitos
Value Driven Plan Driven

Estimado
Custo Tempo Requisitos
O que Scrum
Scrum...
... um framework gil simples para desenvolvimento de produtos complexos em ambientes complexos; ...no um processo ou tcnica: dentro de Scrum podem-se empregar diversos processos e tcnicas; ...utiliza a abordagem iterativa e incremental para melhorar a previsibilidade e o controle de riscos;
Scrum...
...gera entrega frequente de valor para o cliente; ...torna os problemas das prticas de desenvolvimento transparentes, para que se possa melhor-las; ...utiliza inspeo e adaptao para melhoria contnua do produto e dos processos de desenvolvimento;
Scrum...
...utiliza times auto-organizados, que definem as melhores formas de desenvolverem as funcionalidades de maior valor ... orientado a valor, e no a planos
... focado na ordenao do trabalho baseada no maior valor de negcio para o cliente;
10
O que Scrum As Origens do Scrum

Scrum: Origens
Ken Schwaber, incio dos anos 90: desenvolvimento em sua empresa do que se tornaria o Scrum Jeff Suttherland, 1993: desenvolvimento do Scrum na Easel Corporation Ken Schwaber : formalizao do Scrum na OOPSLA95 Anos seguintes: Schwaber e Sutherland colaboram para unificar seus trabalhos Publicao do livro Agile Software Development with Scrum, por Ken Schwaber e Mike Beedle
11
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 Mltiplo aprendizado Controle sutil Transferncia organizacional de aprendizado
Scrum: Origens
The New New Product Development Game, de Takeuchi e Nonaka (1986) O nome Scrum vem do Rugby!
12
Scrum: Origens
Sistema Toyota de Produo e Produo Enxuta
Produo puxada pelo cliente Produo de valor em fluxo estvel e contnuo, sem paradas, lotes, filas ou departamentos Qualidade embutida no processo: jidoka Melhoria contnua: kaizen Combate ao desperdcio:
muda: etapas sem valor muri: sobrecarga nas pessoas e equipamentos mura: desbalanos nos ritmos de produo
O que Scrum Os Pilares do Scrum

13
Os Pilares do Scrum
Processos Definidos X Processos Empricos
Processos definidos:
Ambientes controlados
ex: linhas de produo
Mesmas entradas, mesmas sadas
Processos empricos:
Complexos e imprevisveis Diferentes entradas, diferentes sadas
Scrum embasado na Teoria de Controle de Processos Empricos

Pilares: Transparncia, Inspeo e Adaptao
Os Pilares do Scrum
#1: Transparncia
Ver: aspectos que afetam o resultado do projeto devem ser visveis para os que gerenciam estes resultados O que visto deve ser compreendido: se quem inspeciona o processo acredita que est pronto, isso deve corresponder definio de pronto utilizada
14
Os Pilares do Scrum
#2: Inspeo
Investigar: deve haver inspeo no processo com frequncia suficiente para se detectar variaes inaceitveis
Os Pilares do Scrum
#3: Adaptao
Melhorar: ao se detectar variaes inaceitveis, o processo dever ser ajustado o to rpido quanto possvel para se minimizar desvios ainda maiores
15
Introduo
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, prticas e regras esto sendo compreendidos e seguidos
16
Introduo ao Scrum do Resumo Ciclo do Scrum

Resumo do Ciclo do Scrum

A VISO DO PRODUTO e o PRODUCT ROADMAP devem ser criados antes do incio do desenvolvimento
17

O representante do cliente, chamado de PRODUCT OWNER, levanta com os stakeholders os requisitos de maior prioridade no momento

Ele ento insere esses requisitos em uma lista ordenada, chamada PRODUCT BACKLOG
18

O Product Owner e o Time se renem 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
19

O que fiz O que farei Quais foram os impedimentos Em cada dia, o Time faz a DAILY SCRUM, uma reunio de 15 minutos para promover visibilidade e comunicao entre os membros do Time

DEFINIO DE DONE __ ____ ____ ________ __ _____ ___ __
Ao final do ciclo de desenvolvimento, o Time ter produzido um incremento no produto pronto, que significa valor para o cliente
20

O Time ento se rene com o Product Owner e stakeholders na SPRINT REVIEW e apresenta o que foi feito na Sprint

E, em seguida, o Time se rene para a SPRINT RETROSPECTIVE, onde verifica o que funcionou bem e o que pode melhorar nas prximas Sprints
21

...e o ciclo recomea.
Papis: Time de Scrum
22
Product Owner: Atribuies

Responsvel por garantir e maximizar o ROI do cliente a partir do trabalho do Time
Gerencia o Product Backlog: garante a visibilidade, insere, remove, modifica e ordena os itens Gerencia os stakeholders do projeto
identifica os stakeholders e seu nvel de apoio comunica-se com eles para entender suas necessidades balanceia as diferentes necessidades dos stakeholders influencia os stakeholders
Gerencia a Viso do Produto: estabelece, mantm e comunica Gerencia os Releases do produto para o cliente
Product Owner: Atribuies

Responsvel por garantir e maximizar o ROI do cliente a partir do trabalho do Time
Participa ativamente das Sprints
Disponvel para o Time Sprint Planning / Sprint Review (e Release Planning)
Aceita ou rejeita na Sprint Review o trabalho realizado pelo Time Gerencia o oramento: garante que h oramento suficiente para o projeto durante todo seu desenvolvimento
23
Product Owner: Caractersticas

nico (s pode haver um!)
No comit, no h substitutos Influenciado por outros (Time, stakeholders e at mesmo um time de negcios) Tem a voz final sobre o Product Backlog
Disponvel
para tirar dvidas do Time e tomar decises sobre o produto para falar com os stakeholders e atualizar o Product Backlog frequentemente
Representativo
com suficiente poder e conhecimento necessrio para tomar decises rpidas e corretas sobre o produto
Time de Desenvolvimento: Atribuies

Gera valor para o cliente construindo incrementos do produto com alta qualidade
Trabalha sobre o Product Backlog, em direo viso do produto Entrega valor frequentemente para o cliente Auto-organiza-se para realizar o trabalho
com poder para gerenciar seu trabalho de desenvolvimento, responsvel por seus resultados comunicao: melhores Times so pequenos (7 2 membros) e co-localizados
Comunica-se frequentemente com o P.O. dvidas e decises sobre o produto Informa os impedimentos ao ScrumMaster assim que detectados
24
Time de Desenvolvimento: Caractersticas

Multidisciplinar
todo conhecimento e habilidades necessrias para gerar o trabalho pronto (DoD), incluindo qualidade os melhores Times so Feature Teams no h ttulos no Time fertilizao cruzada: um aprendendo do outro
Suficientemente pequeno (7 2) para garantir comunicao Motivado, com a confiana e apoio necessrios Tecnicamente excelente Comprometido a alcanar as metas da Sprint/Release os melhores Times so 100% dedicados ao projeto (sem multitasking)
ScrumMaster: Atribuies
Garante que aos valores do Scrum, prticas e regras esto sendo seguidos
Remove os impedimentos que atrapalham o trabalho do Time Facilita as reunies do Scrum Facilita o trabalho do Time e sua relao 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 organizao Ajuda a escolher e ensina o P.O. (ou garante que aprenda)
25
ScrumMaster: Caractersticas
Competente em soft skills: facilitador, negociador, comunicador, gerncia de conflitos etc. Corajoso para realizar as mudanas necessrias e remover os impedimentos presente durante todo o trabalho do Time isento o suficiente para garantir que no haja desvios no processo, para facilitar o consenso, para no interferir nas decises do Time e para ajudar o Time a melhorar seu trabalho
ScrumMaster
26
Product Backlog
O que o Product Backlog?

Lista de requisitos do produto itens com desejos de negcios do cliente, melhorias no produto, correes de bugs, tarefas tcnicas etc. Meio para se alcanar a viso do produto Itens ordenados por prioridade de desenvolvimento
itens do alto: < granularidade, > detalhe itens de baixo: > granularidade, < detalhe
Lista incompleta e dinmica em constante evoluo ambiente evolui e clientes e Time aprendem sobre o produto
27

Product Owner o nico responsvel por gerenciar o Product Backlog atualizar, ordenar e dar visibilidade Seus itens possuem descrio e estimativa
A ordenao determinada por: valor que gerar ao cliente, risco e necessidade
28
Product Backlog ...

Ordenado: itens so ordenados de acordo com a prioridade de sua implementao de forma a maximizar o ROI do cliente Estimvel: julgar e formar uma opinio sobre o tamanho do Product Backlog ou de uma parte relevante dele (ex. prxima Sprint ou Release) Emergente: incompleto, dinmico, em constante evoluo mudana no ambiente e no produto Gradualmente refinado: de acordo com a ordenao
Ordenando o Product Backlog

Desenvolvidos mais cedo
Sprint
Release
Futuras Releases
29
Estimando o Product Backlog

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!

Acurcia mais importante que preciso!
30

Story Points
Unidade de medida para determinar o tamanho do item do Product Backlog (geralmente User Stories) Story points significam o tamanho do esforo relativo necessrio 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 tcnicas para realizar a estimativa do Product Backlog o PLANNING POKER
8
STORY POINTS Inicialmente, o Time escolhe o item de menor esforo 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 estimlo, tendo como base os itens j estimados - triangulao
31

Jogando o PLANNING POKER
13
Para um item, todos os membros do Time escolhem uma estimativa nas cartas no 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!
2

T-Shirt Sizing
GG
32
Definio de Pronto
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 algum diz que algo est pronto, todos devem entender o que isso significa Ex. de software: codificado, testado e documentado
Product Backlog Grooming

Product Backlog necessita ateno e cuidados constantes Grooming um processo que assegura que o Product Backlog seja Ordenado, Estimvel, 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 prprio processo de grooming: sesses dirias curtas, sesses semanais, workshop etc.
por Roman Pichler
33
Product Backlog Grooming

Passos para Grooming:
Descobrir e descrever novos itens; modificar ou remover os existentes Ordenar alto: mais importente baixo: menos importente; quais itens na prxima release, ordem de implementao Itens de alta prioridade preparados (DoR): decompostos e refinados; claros: entendimento comum; factveis: pequenos o suficiente para a sprint; testveis: podem ser validados Time estima novos itens e corrige os antigos
por Roman Pichler

Definio de Preparado (ready, DoR)

Preparado = item do Product Backlog est disponvel e preparado para discusso pelo Product Owner na Sprint Planning DoR descreve um estado em que os itens do Product Backlog devem estar para estarem qualificados para discusso na Sprint Planning Objetivo claro para o Time, previne estragar a Sprint O qu, Como, estimado, pequeno o suficiente
por Jeff Sutherland / Serge Beaumont
34
User Stories
para itens do Product Backlog
User Stories
Quem?
O qu? Por qu?
Como um <PERFIL>, eu posso/gostaria/devo <FUNO> para <VALOR>
Como um COMPRADOR, eu posso PESQUISAR LIVROS para ESCOLHER O QUE VOU COMPRAR
35
User Stories: os trs Cs

CARD (carto)
Descrio da story suficiente para identificar o requisito e para lembrar do que se trata a story
CONVERSATION (conversas)
Conversas sobre a story, por onde de fato o requisito comunicado do cliente aos programadores
CONFIRMATION (confirmao)
Testes que documentam os detalhes da story e podem ser usados para determinar quando ela est completa
User Stories: INVEST
Uma User Story deve ser:
Independent Negotiable Valuable Estimable Small Testable
Independente das outras stories Negocivel, detalhes sero negociados Valiosa para o cliente
Estimvel pelos desenvolvedores

Pequena em esforo de implementao Testvel para permitir a confirmao
36
User Stories: Stories, Temas e Epics

STORY
PICO
STORY STORY
STORY
STORY
STORY
TEMA
STORY STORY STORY STORY STORY
STORY
STORY
STORY
User Stories: Testes de Aceitao

Como um usurio,eu posso exportar dados em XML para poder integrar minhas informaes com outros sistemas
Testes de Aceitao
Servem para verificar que as user stories implementadas funcionam como o cliente pediu So escritos pelo cliente, antes da codificao, com a ajuda dos desenvolvedores
Abrir no Excel o arquivo XML exportado Confrontar campo a campo com o modelo estabelecido
37
User Stories: Story-Writing Workshop

Reunio que inclui desenvolvedores, usurios, cliente e qualquer pessoa que possa contribuir na descoberta de stories Os participantes escrevem quantas stories conseguirem, sem se preocupar com priorizao Uso de brainstorming e prototipao rpida, de baixa fidelidade
Critrios de Aceitao
Product Owner escreve os critrios de aceitao para cada item desejado antes da Sprint Planning Durante a Sprint Planning, os critrios de aceitao so discutidos e negociados com o Time Enunciados pequenos e fceis de se entender Definem os limites para um item
Adaptado de um artigo de Sandy Mamoli
38
Critrios de Aceitao
Ajudam o P.O. a responder o que ele precisa para que essa funcionalidade propicie valor
Ajuda o Time a ganhar uma compreenso 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

Critrios de Aceitao
Exemplo: como um aluno, quero me registrar online, para no me deslocar ou enfrentar filas
Os campos obrigatrios do formulrio devem estar claramente indicados Caso o usurio submeta o formulrio sem completar todos os campos obrigatrios, esses campos devem ser indicados e o formulrio no submetido Um email de confirmao deve ser enviado aps submeter o formulrio
39
Ciclo do Scrum
Sprint Planning Meeting
40
O que a Sprint Planning Meeting?

Planejamento da iterao:
Time e Product Owner defininem que itens do Product Backlog sero implementados na Sprint e os quebram em tarefas Sprint Backlog Reunio de 8h (Sprints de 1 ms) ou 5% da Sprint Product Owner presente
1a. Parte: O qu?

Escolha de itens mais prioritrios do Product Backlog a serem implementados Definio da Meta da Sprint
2a. Parte: Como?

Time quebra itens em tarefas e estima o tempo (quando usado) para realizao de cada tarefa
O que a Sprint Planning Meeting?

Resultado: Sprint Backlog inicial + Meta
Itens Tarefas a fazer Tarefas em andamento Feito
Meta
41
Medindo a Velocidade do Time

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, no pode ser usada para comparar diferentes Times Quo mais constante for a formao do Time e a durao das Sprints, melhor funciona
Sprint Backlog
42
O que o Sprint Backlog?

Composto por uma lista dos itens que sero desenvolvidos durante a Sprint, as tarefas correspondentes, o andamento e as estimativas Os itens so selecionados do Backlog na Sprint Planning Meeting Product
Cada item quebrado em tarefas. Parte das tarefas definida no Planning, parte ao longo da Sprint

As tarefas podem ser estimadas ou no, mas deve-se traar o Sprint Burndown O Sprint Backlog modificado ao longo da Sprint
estimativas (quando h) so atualizadas tarefas podem surgir para os itens j existentes
Deve ter alta visibilidade Pertence ao Time

43
Medindo a Velocidade do Time

A velocidade de um Time a mdia de pontos entregues pelo Time nas ltimas Sprints Deve ser usada para ajudar o Time a decidir quantos pontos de itens conseguir pegar na prxima Sprint relativo a cada Time, ou seja, no possvel comparar velocidade entre times diferentes Funciona bem quando o Time e a durao das Sprints se mantm constantes
44
Estimar as Tarefas?
Estimativa por horas
Na segunda parte da Sprint Planning, cada membro estima as tarefas que ele ir realizar pelo nmero de horas que acredita que levar De preferncia, cada tarefa < 1 dia e > 2 horas Devem ser atualizadas sempre que pertinente O Sprint Burndown reflete o nmero 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 alm da usada para tarefas
Traando o Sprint Burndown

Estimativa por horas
Sprint Burndown um grfico 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 direo ao final de um sprint feito inicialmente no Sprint Planning Meeting e deve ser atualizado a cada dia da Sprint
45

Usando os pontos dos itens
Sprint Burndown um grfico 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 direo ao final de um sprint feito inicialmente no Sprint Planning Meeting e deve ser atualizado a cada dia da Sprint
46
A Sprint
O que a Sprint?
Sprint a iterao (ciclo) de desenvolvimento
Sprint Planning Meeting Trabalho de Desenvolvimento Sprint Review Sprint Retrospective
Cada Sprint deve ter uma meta Tm durao fixa (de 2 semanas a 1 ms) e ocorrem uma atrs da outra No deve haver nenhuma mudana que afete a meta da Sprint
47
O que a Sprint?
Cada Sprint deve ter como sada um incremento entregvel do produto que satisfaa meta Ao final da Sprint, todo trabalho entregvel deve estar pronto O deadline no pode ser mudado. Somente o escopo pode variar (desde que no afete a meta da Sprint)
O que a Sprint?
A Sprint deve sempre produzir valor entregvel, mesmo que haja mais trabalho de arquitetura ou infraestrutura
Itens que geram valor visvel para o cliente Itens de arquitetura, infraestrutura etc.
Sprint 1
Sprint 2
Sprint 3
Sprint 4
Sprint 5
48
Cancelamento da Sprint
A Sprint pode ser cancelada se a Meta da Sprint perder o sentido Somente o Product Owner pode decidir pelo cancelamento da Sprint exceo, deve ser raro
Inicia-se imediatamente uma nova 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 mudanas necessrias no alterem a meta da Sprint
Sprints curtas: mudanas muito frequentes, entregas mais frequentes, projetos curtos
Sprints longas: mudanas menos frequentes, overhead de reunies

49
Daily Scrum
O que a Daily Scrum?

Reunio de 15 minutos realizada todo dia no mesmo local, mesma hora.
Visibilidade Comunicao Deciso rpida
Cada membro do Time detalha:

O que ele completou desde a ltima Daily Scrum; O que ele vai fazer antes da prxima Daily Scrum; Quais obstculos esto em seu caminho.
O ScrumMaster deve remover os obstculos encontrados O Sprint Burndown deve ser atualizado!
50
Sprint Review
O que a Sprint Review?

Reunio informal onde o Time mostra stakeholders o que foi feito durante a Sprint
Reunio de 4h (Sprints de 1 ms) ou 5% da Sprint Product Owner presente
aos
Time demonstra o que fez e responde a perguntas PO verifica o que foi e o que no foi feito na Sprint e estabelece se a meta foi atingida Entrada para a Sprint Planning seguinte
51
Sprint Retrospective
O que a Sprint Retrospective?

Reunio para inspecionar como correu a Sprint com relao aos processos:
Reunio de 3h Em geral, Product Owner no deve estar presente
Identificar e priorizar:
O que foi bem?
O que pode melhorar?
Identificar aes para melhorias - adaptao

52

Cinco passos:
Preparao Colher dados Gerar insights Decidir o que fazer Fechar a retrospectiva

O que foi bem? O que pode melhorar? Aes de melhoria
53
Gesto de Releases
O que uma Release?

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
Release 1 Sprint 1 Sprint 2 Sprint 3 Sprint 4
Release 2 Sprint 5 Sprint 6 Sprint 7 Sprint 8
54
Gesto de Release
Cenrio #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
Gesto de Release
Cenrio #2 Plano de Release
Itens do Product Backlog devem estar estimados pelo Time e ordenados pelo Product Owner Para cada Release, realizar a reunio de Release Planning Meeting para criar o Plano de Release Fazer releases cedo e frequentemente Acompanhar o progresso atravs do Release Burndown Atualizar o Plano de Release a cada Sprint
55
Reunio de Release Planning

Reunio (no obrigatria) realizada para cada release para criar o Plano de Release:
Meta da Release: caminho para a Viso do Produto data da entrega Itens ordenados do Product Backlog que, a princpio, sero entregues nas Sprints da Release
No um compromisso Veja que itens cabem na Release usando o nmero calculado de Sprints, estimativas no refinadas do Time para os itens e a velocidade do Time Geralmente, distribua os itens apenas pelas duas primeiras Sprints
Reunio de Release Planning

Plano de Release Sprint 1 Sprint 2 Sprints 3-6
56
Traando o Release Burndown

Release Burndown um grfico que mostra a soma dos pontos de esforos estimados restantes dos itens da Release pelo tempo
Y: pontos de esforos estimados restantes X: iteraes (Sprints)
Serve para acompanhar o progresso em direo a uma entrega feito inicialmente no Release Planning Meeting e deve ser atualizado no final de cada Sprint
Traando o Release Burndown
57
Escalando Scrum
Escalando Scrum
Problema: projeto grande demais Time deve ter no mximo 9 membros
?
58
Escalando Scrum
Soluo: diversos Times no mesmo projeto
Escalando Scrum
Scrum of Scrums
Mecanismo para coordenao 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 dependncias, integrao e sobreposies de trabalho
59
Escalando Scrum
Scrum of Scrums
Mesmo Product Backlog para todos os itens Funciona quando no h grandes dependncias entre o trabalho dos Times
Minimizar dependncias, ortogonalizar o trabalho dos Times
Questes:
O que o Time fez desde a ltima reunio? O que o Time pretende fazer at a prxima reunio? 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
60
Scrum Alliance
http://www.scrumalliance.org
61
Scrum Alliance
Certificaes da Scrum Alliance
Obrigado!
Rafael Sabbagh
sabbagh@gmail.com rsabbagh http://rsabbagh.com http://facebook.com/SabbaghTC
62

SCRUM Apostila

Enviado por

Dados do documento

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 Apostila

Enviado por

Direitos autorais:

Formatos disponíveis

Rafael Sabbagh

2009-2011 Rafael Sabbagh

Problemas comeam a surgir:

2009-2011 Rafael Sabbagh

2009-2011 Rafael Sabbagh

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

2009-2011 Rafael Sabbagh

Uso de Funcionalidades pelo Cliente

Fonte: Standish Group, 2002

2009-2011 Rafael Sabbagh

2009-2011 Rafael Sabbagh

2001: representantes de processos

2009-2011 Rafael Sabbagh

Entrega de Valor: Agile x Waterfall

2009-2011 Rafael Sabbagh

Plan Driven x Value Driven

Value Driven Plan Driven

2009-2011 Rafael Sabbagh

O que Scrum As Origens do Scrum

2009-2011 Rafael Sabbagh

O que Scrum Os Pilares do Scrum

Mesmas entradas, mesmas sadas

Scrum embasado na Teoria de Controle de Processos Empricos

2009-2011 Rafael Sabbagh

2009-2011 Rafael Sabbagh

Time de Desenvolvimento (o Time)

Introduo ao Scrum do Resumo Ciclo do Scrum

Resumo do Ciclo do Scrum

2009-2011 Rafael Sabbagh

Resumo do Ciclo do Scrum

2009-2011 Rafael Sabbagh

Resumo do Ciclo do Scrum

2009-2011 Rafael Sabbagh

Resumo do Ciclo do Scrum

2009-2011 Rafael Sabbagh

Resumo do Ciclo do Scrum

2009-2011 Rafael Sabbagh

Resumo do Ciclo do Scrum

2009-2011 Rafael Sabbagh

Resumo do Ciclo do Scrum

2009-2011 Rafael Sabbagh

Resumo do Ciclo do Scrum

2009-2011 Rafael Sabbagh

Resumo do Ciclo do Scrum

2009-2011 Rafael Sabbagh

Resumo do Ciclo do Scrum

2009-2011 Rafael Sabbagh

Papis: Time de Scrum

2009-2011 Rafael Sabbagh

Product Owner: Atribuies

2009-2011 Rafael Sabbagh

Product Owner: Atribuies

2009-2011 Rafael Sabbagh

Product Owner: Caractersticas

2009-2011 Rafael Sabbagh

Time de Desenvolvimento: Atribuies

Time de Desenvolvimento: Caractersticas

2009-2011 Rafael Sabbagh

2009-2011 Rafael Sabbagh

2009-2011 Rafael Sabbagh

O que o Product Backlog?

O que o Product Backlog?

A ordenao determinada por: valor que gerar ao cliente, risco e necessidade

2009-2011 Rafael Sabbagh