Tutorial SCRUM v4

SCRUM, O Tutorial Definitivo
verso 4 | Jun 2013
O Tutorial
Definitivo
www.etcnologia.com.br
Rildo Santos (@rildosan)

(11) 99123-5358
(11) 99962-4260
rildo.santos@etecnologia.com.br
skype: rildo.f.santos
http://rildosan.com/
Verso 4 Jun 2013 | RFS
Todos os direitos reservados e protegidos 2006 e 2013
Programa: Menos Papel, Mais rvores
Qual o mundo que queremos ?

O primeiro passo para criar um mundo melhor, saber qual tipo de mundo que queremos
ter e qual tipo que deixaremos de herana para as prximas geraes.
Nossa misso: buscar pelo equilbrio do homem, da tecnologia e do meio ambiente.
Para cumprir esta misso necessrio: conscientizar, comprometer e AGIR.
O programa Menos Papel, Mais rvores, uma ao, com objetivo de

estimular o consumo sustentvel de papel dentro das organizaes.
Quer participar ?
- Reduza o uso de papel (e de madeira) o mximo possvel.
- S imprima se for extremamente necessrio.
- Evite comprar produtos com excesso de embalagem.
- Ao imprimir ou escrever, utilize os dois lados do papel.
- Use papel reciclado.
Objetivo:
Objetivo:
O Scrum um Mtodo gil para execuo de qualquer projeto ou trabalho.
O Objetivo deste Tutorial prover conhecimento, apresentar e discutir o SCRUM e suas
prticas aplicadas a projetos de desenvolvimento de software.
Pr-requisito:
No h.
Contedo:
1 Desafios do desenvolvimento de Software

2 Sobre o SCRUM
3 Entendendo SCRUM
4 Estudo de Caso
Facilitador: Rildo F. Santos (@rildosan)

Coach , Instrutor, Consultor e Palestrante de Mtodos geis, Gesto de Negcios, Inovao , Processos e
Tecnologia .
Minha Experincia:
Tenho mais de 10.000 horas de experincia em Gesto de Negcios, Gesto de Inovao, Governana e Engenharia de
Software. Sou formado em Administrao de Empresas, Ps-Graduado em Didtica do Ensino Superior e Mestre em
Engenharia de Software pela Universidade Mackenzie.
Fui instrutor de Tecnologia de Orientao a Objetos, UML e Linguagem Java (Sun MicroSystems e IBM).
Conheo Mtodos geis (SCRUM, XP, FDD, Lean e OpenUP), Arquitetura de Software, SOA (Arquitetura Orientado a
Servio), Processo Unificado, Business Intelligence, Gesto de Risco de TI entre outras tecnologias.
Sou professor de curso de MBA da Fiap e fui professor de ps-graduao da Fasp e IBTA.
Tenho conhecimento de Gesto de Negcio (Inteligncia de Negcio, Gesto por Processo, Inovao, Gesto de Projetos e
GRC - Governance, Risk ando Compliance), SOX, Basel II e PCI;
Experincia na implementao de Governana de TI e Gerenciamento de Servios de TI. Fluncia nos principais frameworks
e padres: ITIL, Cobit, ISO 20000, ISO 27001 e ISO 15999;
Participei de diversos projetos nos segmentos: Financeiro, Telecomunicaes, Seguro, Sade, Comunicao, Segurana
Pblica, Fazenda, Tecnologia, Varejo, Distribuio, Energia e Petrleo e Gs.
Possuo as certificaes: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified
Instrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games;
Sou membro do IIBA-International Institute of Business Analysis (Canada)
Onde estou:
Twitter: @rildosan
Blog: http://rildosan.blogspot.com/
Comunidade: http://etecnologia.ning.com
Contedo:

2 Sobre o SCRUM
3 Entendendo SCRUM
4 Estudo de Caso
Objetivo:
Parte 1 - Desafios do desenvolvimento de Software

Objetivo:
Apresentar e discutir os principais desafios dos projetos de desenvolvimento de software.
Pr-requisito:
No h.
Desafios do Desenvolvimento
de Software
1. Desafio: Responder ao cliente

Quanto tempo vai levar ?
O tempo outro grande desafio, raro
(posso at afirmar que no existe) um cliente
que diga: Demore o tempo que for necessrio,
pois, no temos pressa nenhuma.
Geralmente o cliente quer o software funcionando
Para ontem...
Quanto custar ?
Todo cliente quer saber quanto custar
o software...
O primeiro desafio conseguir responder qual o
custo do software e em quanto tempo o cliente vai ter o
software funcionando.
2. Desafio: Falha na Comunicao das equipes de TI
10
3. Desafio: Entender as necessidades dos clientes
Quando no se entende as necessidades dos clientes, no se pode entregar valor ao cliente.

11
4. Desafio: Compreender por que os projetos falham:
Informao
errada
13%
Requisitos
incompletos
12%
Outros
50%
Mudana de
Requisitos
12%
37% das falhas esto

relacionadas com
requisitos
Falta de
competncia
6%
Falta de
conhecimento
tcnico
7%
12
Craig Larman, Agile and Iterative Development: A Managers Guide, Addison Wesley Professional
(2004)
12
5. Desafio: Identificar o que necessidade e o que desejo
Uso de funcionalidades do Software

Contudo, a
maioria das
funcionalidades
nunca so
usadas pelos
usurios
Sempre
7%
Freqentemente
13%
Nunca
45%
As vezes
16%
Raramente
19%
13
Craig Larman, Agile and Iterative Development: A Managers Guide, Addison Wesley Professional
(2004)
13
6. Desafio: Aumentar produtividade da equipe de desenvolvimento:
Satisfao dos Clientes
Como aumentar a produtividade da equipe

de desenvolvimento de software ?
14
A falta de produtividade pode afetar o negcio

Qual a soluo ?
Contratar mais desenvolvedores...
Mas, ser que a contratao

de novas pessoas garante
o aumento de produtividade ?
The Mythical Man Month by Frederick Brooks, 1975*.

Quando um projeto est atrasado, contratar novas pessoas para ajudar no projeto pode servir apenas
para atras-lo ainda mais.
Pois, as novas pessoas precisam primeiro entender o que projeto, objetivos, escopo,
funcionalidades e etc, para depois comear a produzir, ou seja, temos que considerar o tempo que
ser gasto com explicaes, orientaes, comunicao e treinamento das novas pessoas, devemos
considerar o esforo da gesto de projetos que aumentar
Ao calcular o tempo que ser necessrio para desenvolver um software, temos que adicionar um
tempo extra, pois os desenvolvedores precisam de "tempo para pensar, tempo para pesquisar alm
do "tempo para desenvolver"
"Adicionar novas pessoas a um projeto de software atrasado s adiar a sua entrega."
A Lei de Brooks
15
7. Desafio: Escolher framework certo para desenvolver software ?
SCRUM,
Lean,
Kanban,
XP...
Cascata
RUP
16
8. Desafio: Como reter os bons profissionais ?
Quantas vezes j montamos boas equipe, mas de repente as pessoas comeam a

sair...a trocar de emprego.
A reteno de bons profissionais grande desafio da atualidade, pessoas trocam
muito mais de emprego do que a 10 anos atrs.
Insegurana, chefes tiranos, a falta de respeito, falta de reconhecimento e de e ambiente
estressante so as algumas das causas que fazem os profissionais de trocarem de
emprego. A maioria das pessoas mudam de emprego por problema com o seu chefe e no
por motivo de salrio.
17
Por que precisamos dos Mtodos geis ?
Problemas clssicos (ou tradicionais):

Stakeholders (Clientes):
- Tm dificuldades em externar suas necessidades
- Geralmente fazem mudanas de requisitos
- Precisam do software funcionando para
ontem
Desenvolvedores:
- No sabem ou no querem elicitar requisitos
- Dificilmente conseguem atender todas as
demandas de negcio
- Tem dificuldade em comunicar e entender
os clientes
Para enfrentar estes desafios:

Utilizao de mtodos geis,
como SCRUM, pode amenizar
estes problemas.
18
Cliente x Desenvolvedores:
Clientes:
- Alguns clientes tm dificuldades em externar
suas necessidades ou desejos de forma clara e objetiva
(No sabem o que querem)
- Geralmente fazem mudanas de requisitos durante o
desenvolvimento ou quando o software entregue.
- Sempre precisam do software funcionando para ontem

- No tm tempo e nem pacincia para falar com os
desenvolvedores.
Desenvolvedores:
- No sabem ou no querem conversar com o cliente
- Dificilmente conseguem atender o negcio e todas suas
demandas
- Tm dificuldade em se comunicar e entender os clientes
19
Como enfrentar estes desafios: O SCRUM sua sogra

O SCRUM pode ser uma forma para enfrentar estes desafios, O SCRUM no vai
aumentar a produtividade da equipe, no vai fazer voc entregar software mais cedo,
nem melhorar a qualidade do software e nem otimizar os custos do projeto de
desenvolvimento.
O SCRUM como sua SOGRA ele vai apontar os principais problemas, falhas e pontos
crticos (riscos) do projeto de desenvolvimento, aquilo que realmente precisa ser
melhorado, mas se as pessoas envolvidas com o projeto no tomarem nenhuma ao (ou
melhor: tomarem atitudes) os problemas continuaram a existir e levaram a maioria dos
projetos para a marcha da morte.
O Scrum vai deixar todos os problemas aparentes.
20
Contedo:

2 Sobre o SCRUM
3 Entendendo SCRUM
4 Estudo de Caso
21
Objetivo:
Parte 2 Sobre SCRUM:

Objetivo:
Apresentar Manifesto gil e o SCRUM, as principais caractersticas e prticas.
Pr-requisito:
No h.
22
Parte 2
Sobre o SCRUM
23
As Razes do Scrum:
TimeBoxes
Artigo: The New, New

Product Development Game
de Nonaka e Takeushi na
Hardvard Bussines Review
SmallTalk
Engineering Tools
Desenvolvimento
iterativo e
incremental
Reunio
diria
24 horas
Produto
Backlog
Sprint
Backlog
Produto
2-4 Semanas
24
O que TimeBox ?
durao fixa (imutvel).

um conceito diz que a quantidade de tempo imutvel, ou seja, tem durao
fixa - a quantidade de dias no poder aumentar. Assim, evita-se atrasos no prazo
de entrega e facilita o planejamento.
No Scrum as cerimnias e/ou eventos com durao fixa (Time-Boxes) so:
- Reunio de Planejamento da Release,
- Sprint (iterao),
- Reunio de Planejamento da Sprint,
- Reviso da Sprint.
- Retrospectiva da Sprint.
- Reunio Diria.
Exemplos de Timebox:
A Sprint (que uma iterao) que deve ser realizada de 2 a 4 semanas, no qual a
equipe de desenvolvedores dever produzir um entregvel de valor para o cliente
(mais frente discutiremos melhor isto).
A entrega de valor a meta da Sprint, a durao da Sprint dever ser combinada
com o cliente, antes do comeo da execuo da Sprint.
Se foi acertado que a Sprint tem a durao de 4 semanas, logo esta durao
ser fixa (no mudar).
Durante a Sprint so realizadas as Reunies Dirias, uma reunio diria tem a
durao fixa de 15 minutos.
Ao final da Sprint, feita a reunio de Reviso da Sprint. Para Sprints
de um ms, essa uma reunio com durao fixa de quatro horas.
Aps a Reviso da Sprint e antes da prxima Reunio de Planejamento
da Sprint, a Equipe Scrum tem a Reunio de Retrospectiva da Sprint.
essa reunio, te durao fixa de trs horas.
25
Abordagem Iterativo e Incremental:

Entrega 1
Entrega 2
Entrega 3
Incremental
Iterativo
Devido a complexidade, tamanho, mudanas de requisitos,

urgncia e necessidade de demonstrar valor mais rpido, fica
quase inconcebvel desenvolver software utilizando o modelo
cascata, ou seja, desenvolver todo o software em uma nica
vez.
Desenvolvimento Iterativo e incremental uma estratgia de
planejamento (que segue a linha dividir para conquistar) ,
onde o software construdo em partes, ou seja, em ciclos
(iteraes), a cada iterao feito um novo incremento (uma
parte do software funcional) at completar o software.
26
O qual propsito do SCRUM ?

Scrum vem sendo utilizado para o desenvolvimento de
produtos complexos desde o incio dos anos 90.
Scrum no um processo ou uma tcnica para o

desenvolvimento de produtos.
Ao invs disso, um framework dentro do qual voc pode
empregar diversos processos e tcnicas. O papel do Scrum
fazer transparecer a eficcia relativa das suas prticas de
desenvolvimento para que voc possa melhor-las, enquanto
prov um framework dentro do qual produtos complexos
podem ser desenvolvidos.
Por ser um framework, o SCRUM no uma ferramenta, nem

metodologia, nem processo e nem uma soluo completa para o
desenvolvimento de software, ele um framework (uma estrutura),
ou seja um guia de referncia , isto significa que o Scrum no
vai lhe dizer como fazer as coisas!
Por ser um framework, ele pode ser utilizado com as prticas de
engenharia de software e/ou metodologia de desenvolvimento que j
existem dentro da organizao.
O SCRUM pode ser utilizado para desenvolver qualquer produto e

no s software.
27
Qual a teoria do SCRUM ?

A TEORIA DO SCRUM:
Scrum, que fundamentado na teoria de controle de processos empricos*, emprega uma
abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos
O que so processos empricos ?

Antes de responder a pergunta, precisamos saber que existem dois tipos de processos:
Processo Definido:
So processos que se conhece todas as variveis, tm poucas ou nenhuma
mudana ao logo do processo, so repetitivos e so previsveis.
Geralmente existe uma documentao aplicada a execuo do processo.
Exemplo: Linha de produo
*Processos Empricos:
So aqueles processos que no se conhece todas as variveis, tm
mudanas ao logo do processo, no so repetitivos e so imprevisveis.
Geralmente baseado na experincia e no conhecimento de quem executa o
processo.
Exemplo: Desenvolvimento de Software.
Quando desenvolvemos um software as vezes no conhecemos todos os

requisitos, e os requisitos que so conhecidos mudam com certa frequncia
e geralmente todas as estimavas so feitas baseada no conhecimento das
pessoas, isto quer dizer, que o mesmo trabalho feito por equipes diferentes
a durao pode variar, pois, a equipe mais experiente deve realizar o
trabalho mais rpido do que a equipe menos experiente. Isso porque o
desenvolvimento de software um problema complexo, que se comporta de
forma imprevisvel.
28
Os pilares do SCRUM:
Trs pilares sustentam qualquer implementao de controle de processos empricos.
29
O primeiro pilar:
A transparncia garante que aspectos
do processo que afetam o resultado
devem ser visveis para aqueles que
gerenciam os resultados.
Esses aspectos no apenas devem ser

transparentes, mas tambm o que est
sendo visto deve ser conhecido.
Isto , quando algum que inspeciona
um processo acredita que algo est
pronto, isso deve ser equivalente
definio de pronto utilizada.
O segundo pilar:
Os diversos aspectos do processo devem ser inspecionados com uma frequncia suficiente
para que variaes inaceitveis no processo possam ser detectadas. A frequncia da
inspeo deve levar em considerao que qualquer processo modificado pelo prprio
ato da inspeo. O problema acontece quando a frequncia de inspeo necessria
excede a tolerncia do processo inspeo. Os outros fatores so a habilidade e a
aplicao das pessoas em inspecionar os resultados do trabalho.
30

O terceiro pilar:
Se o inspetor determinar, a partir da
inspeo, que um ou mais aspectos do
processo esto fora dos limites aceitveis e
que o produto resultante ser inaceitvel, ele
dever ajustar o processo ou o material
sendo processado. Esse ajuste deve ser
feito o mais rpido possvel para minimizar
desvios posteriores.
Existem trs pontos para inspeo e

adaptao em Scrum. A Reunio Diria (2)
utilizada para inspecionar o progresso em
direo Meta da Sprint e para realizar
adaptaes que otimizem o valor do prximo
dia de trabalho. Alm disso, as reunies de
Reviso da Sprint (3) e de Planejamento da
Sprint (1) so utilizadas para inspecionar o
progresso em direo Meta da Release e
para fazer as adaptaes que otimizem o
valor da prxima Sprint.
E a Retrospectiva da Sprint (4) utilizada
para revisar a Sprint passada e estabelecer
que adaptaes tornaro a prxima Sprint
mais eficiente, produtiva, recompensadora e
gratificante.
31
O Manifesto gil:
O SCRUM um Metodo gil

Fonte: http://agilemanifesto.org/iso/ptbr/
32
Princpios por trs do Manifesto gil:

Ns seguimos estes princpios:
Nossa maior prioridade satisfazer o cliente atravs da entrega contnua e adiantada de software com
valor agregado.
Mudanas nos requisitos so bem-vindas, mesmo tardiamente no desenvolvimento.
Processos geis tiram vantagem das mudanas visando vantagem competitiva para o cliente.
Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferncia
menor escala de tempo.
Pessoas de negcio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
Construa projetos em torno de indivduos motivados.
D a eles o ambiente e o suporte necessrio e confie neles para fazer o trabalho.
O mtodo mais eficiente e eficaz de transmitir informaes para e entre uma equipe de desenvolvimento
atravs de conversa face a face.
Software funcionando a medida primria de progresso.
Os processos geis promovem desenvolvimento sustentvel.
Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante
indefinidamente.
Contnua ateno excelncia tcnica e bom design aumenta a agilidade.
Simplicidade -- a arte de maximizar a quantidade de trabalho no realizado -- essencial.
As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizveis.

Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e ento refina e ajusta seu
comportamento de acordo.
33
Como Ser gil ?

Como ser gil ?
1 - Para ser gil preciso colocar em prtica os valores e os princpios do Manifesto gil.
Exemplo:
Se uma organizao implementou o SCRUM e aparentemente tudo ocorre bem...mas, se equipe no
est conseguindo entregar software funcionando ao cliente a quatro meses, podemos afirmar que
existe uma equipe gil ?
Vejamos o que diz o Manifesto gil:
Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferncia
menor escala de tempo.
Podemos concluir que a equipe no gil, pois alm da implementao do SCRUM, que um
mtodo gil, ela tambm dever levar em conta os valores e princpios do Manifesto gil, ou seja,
entregar software funcionando com certa regularidade.
34
Como Ser gil ?

Como ser gil ?
2 Alm de implementar o SCRUM para Gesto de Projetos de desenvolvimento de software

tambm adote prticas de Engenharia de Software gil, tais como XP e FDD.
35
Como Ser gil ?
Engenharia de Software 100% gil:

O SCRUM utilizado para Gesto de Projetos. J para as prticas de
Engenharia de Software podemos utilizar o FDD para os requisitos de
software e arquitetura e as Prticas do XP para o desenvolvimento de
software (codificao, testes e refactoring).
36
Equipe: Tradicional x Colaborativa

Como ser gil ?
3 Para trabalhar como o SCRUM preciso trabalhar em equipe:
Existem alguns tipos de equipe, vamos comparar o formato Tradicional e de auto Gesto:
auto Gesto
Tradicional
Mtodo de Gesto de Projetos Tradicionais.

- No tem auto gesto.
- No so auto-organizadas.
- So fortemente hierarquizada. Com liderana
baseada no comando-controle.
- Equipe formada por especialistas.
Mtodo gil
- ter auto gesto,
- ser Auto organizada;
- ser Interdisciplinar
- no ter Hierarquia formal,
- ter responsabilidade.
O Comando-controle: Pode levar ao baixo

A auto gesto: Requer alto comprometimento da
comprometimento e desmotivao sinnimo de equipe, que a chave para a produtividade. Equipe
baixa produtividade e produtos de baixa qualidade. motivada produz mais e melhor.
37
As Caractersticas da Equipe:
Como ser gil ?
3 Para trabalhar como o SCRUM preciso trabalhar em equipe:

Auto Gesto e Auto-organizao:
A equipe possui a auto gesto e auto-organizada. No deve haver
interferncia externa, nem o ScrumMaster ou Product Owner - pode dizer
como a equipe deve se organizar ou fazer inferncia na forma de trabalho da
equipe. A equipe deve ser capaz de se auto-organizar para dividir e fazer
trabalho.
Equipe de desenvolvedores muito parecida com um equipe de Volley Ball,
onde todos tem um nico objetivo e so interdisciplinares no jogo.
Interdisciplinares e Sem hierarquia formal:
Equipes tambm so interdisciplinares: os membros da equipe devem ter todo o conhecimento e
habilidades necessrias para entregar a meta da Sprint.
Membros da equipe geralmente possuem conhecimentos especializados, tais como: programao,
testes, controle de qualidade, anlise de negcios, arquitetura, desenho de interface de usurio e
modelagem de dados. No entanto, o conhecimento que os membros devem compartilhar - isto , a
habilidade de trabalhar um item do Product Backlog (ou um requisito) e transform-lo em um produto
(software funcionando) tendem a ser mais significativas do que aqueles que eles no dividem.
As pessoas que se recusam a programar porque so arquitetas ou designers no se adaptam bem a
equipe. Todos devem contribuir, mesmo que isso exija aprender novas habilidades ou lembrar-se de
antigas. Na equipe no h hierarquia nem ttulos, todos so iguais e no h excees a essa regra. As
equipes tambm no devem ter sub-equipe dedicados a reas particulares como testes, banco de
dados ou anlise de negcios.
Responsabilidade:
A equipe de desenvolvedores responsvel transformar os itens do Product Backlog em
funcionalidades potencialmente entregveis a cada Sprint.
38
Reforando: No existe a Bala de Prata

SCRUM no a Bala de Prata:
O SCRUM no a soluo completa para os
problemas de produtividade, complexidade,
custo, prazo e qualidade do processo de
desenvolvimento de software.
Veja Lei F. Brooks, No existe bala de prata
No existe soluo mgica para problemas complexos

Contudo, voc pode utilizar o SCRUM para:
- SCRUM ideal para desenvolvimento de software complexos onde os requisitos mudam rapidamente;
- SCRUM mtodo gil para gerenciar e controlar desenvolvimento de trabalho;
- SCRUM possibilita que voc utilize as praticas de engenharia existentes e que j so conhecidas;
- SCRUM baseado na abordagem interativa e incremental;
- Equipe de desenvolvedores (ou time) deve ter auto gesto;

- SCRUM o caminho para detectar e causa raiz e a remoo de qualquer coisa que esteja impedindo o
desenvolvimento e/ou entrega de software/produtos;
- SCRUM o caminho para maximizar a produtividade;
- SCRUM vai d transparncia ao processo de desenvolvimento de software.
39
Algumas empresas que esto usando SCRUM:
Quais empresas esto utilizando o

SCRUM?
Algumas empresas brasileiras
40
Exerccio
Leia o texto e complete a lacuna (no ltimo paragrafo):
O processo de captao de talentos no futebol:
Baseado no texto do Fabrcio Moreira*
Um dos aspectos mais importantes dos grandes clubes de futebol est relacionado captao de
talentos para compor suas categorias de base, e posteriormente formar esses atletas para ingressarem
no profissional. Para entendermos melhor os caminhos atualmente traados por esses candidatos a
futuros atletas de futebol precisamos analisar as formas que costumam chegar esses garotos at os
clubes brasileiros e iniciar os seus treinamentos junto s equipes de base.
Considerando que hoje esse processo de deteco difere em muito daqueles praticados anteriormente,
e que cada vez mais, tem se tornado precoce e competitivo, em que a concorrncia chega a ser
absurda. Se pudssemos ter acesso aos nmeros de garotos avaliados anualmente nos grandes clubes
em relao aos selecionados, chegaramos certamente a esta concluso.
O objetivo deste texto relatar os diversos mecanismos de captao de talentos em prtica nos grandes
clubes do futebol profissional brasileiro. Dentre os mecanismos, destacamos cinco principais e dois
secundrios. Podemos destacar alguns dos principais: as avaliaes peneiras; campeonatos e jogos
amistosos; indicaes; escolas licenciadas franquias e os observadores tcnicos. Entre as
secundrias, destacamos: as clnicas de futebol e o intercmbio internacional.
As chamadas peneiras so um dos mecanismos mais conhecidos e utilizados no meio do futebol.
Porm, um processo ___________________, baseado na observao dos treinadores em uma nica
situao (muitas vezes apenas de jogo e de curta durao). Neste caso, muitos clubes pr-selecionam
alguns garotos para continuarem os testes por pelo menos uma semana no clube, ou mais um dia, no
mnimo.
http://www.universidadedofutebol.com.br/2010/07/1,14757,UM+RELATO+SOBRE+O+PROCESSO+DE+CAPTACAO+DE+TALENTOS+NO+FUTEBOL.aspx?p=1
41
Contedo:

2 Sobre o SCRUM
3 Entendendo SCRUM
4 Estudo de Caso
42
Objetivo:
Parte 3 Entendendo SCRUM

Objetivo:
Apresentar de forma detalhada o framework SCRUM segundo o Guia do Scrum.
Pr-requisito:
No h.
43
Parte 3
Entendendo o SCRUM
44
Framework Scrum:
Scrum um framework para desenvolver e manter produtos complexos. Um framework dentro do qual
pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente
entregam produtos com o mais alto valor possvel. Scrum : Leve, Simples de entender e Extremamente
difcil de dominar
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Viso
Product
Backlog
Sprint
Backlog
Produto
2-4 Semanas
Reunies
Legenda:
Eventos (Reunies)
Papis
Product Owner (PO)

ScrumMaster (SM)
Equipe Scrum
Planejamento da Sprint
Diria
Reviso da Sprint
Retrospectiva da Sprint
Artefatos
Artefatos
Product Backlog
Sprint Backlog
Sprint Burndown
O framework Scrum consiste nas equipes do Scrum associadas a papis, eventos, artefatos e regras.
Cada componente dentro do framework serve a um propsito especfico e essencial para o uso e
sucesso do Scrum.
45
Framework Scrum: Eventos de Durao Fixa:
Regras
46
Framework Scrum: Regras
As Regras fazem o elo entre os eventos com durao fixa (time-boxes), os papis e os
artefatos do Scrum. As regras so descritas ao longo desta apresentao.
Alguns exemplos de Regras:
- Somente os membros da equipe de desenvolvimento podem falar durante uma Reunio Diria.
- Equipe deve possuir auto-gesto.;
- Somente o PO (Product Owner) definir e alterar a prioridade dos itens do Product Backlog.
- Uma pessoa no pode desempenhar o papel de PO e de Scrum Master no mesmo projeto.
- Somente o PO pode cancelar uma Sprint.
47
Framework Scrum: Papis e Equipe
Papis e Equipe
48
Papis SCRUM:
Equipe Scrum so projetados para otimizar flexibilidade e produtividade. Para esse fim, eles so autoorganizveis, interdisciplinares e trabalham em iteraes. Cada equipe possui trs papis:
Product Owner (PO), que responsvel por maximizar o valor do

trabalho que a equipe faz, PO tambm responsvel por:
- Definir a Viso do Produto
- Elaborar , Priorizar e manter o Product Backlog
- Definir ROI;
- Representar o cliente
- Aceitar ou rejeitar os entregveis
O ScrumMaster, que responsvel por garantir
que o processo (as prticas do SCRUM) seja
compreendido e seguido. responsvel ainda por:
- Remover impedimentos;
- Proteger a equipe;
- Ajudar o PO (quando necessrio);
- Ser o facilitador da equipe.
A equipe (ou time), responsvel pelo desenvolvimento do produto,
formada por desenvolvedores que devem ter as habilidades necessrias
para transformar os itens do Product Backlog em Produto.
A Equipe ainda responsvel por:
- Fazer estimativa;
- Definir as tarefas;
- Garantir a qualidade do produto;
- Apresentar o produto ao cliente
49
A Equipe SCRUM: ScrumMaster (SM) e Product Owner (PO):
O ScrumMaster responsvel por garantir que o Equipe Scrum esteja aderindo

aos valores do Scrum, s prticas e s regras. O ScrumMaster ajuda a Equipe
Scrum e a organizao a adotarem o Scrum.
O ScrumMaster educa a Equipe Scrum treinando-o e levando-o a ser mais produtivo
e a desenvolver produtos de maior qualidade. O ScrumMaster ajuda a Equipe
Scrum a entender e usar auto-gerenciamento e interdisciplinaridade.
O ScrumMaster tambm auxiliar a equipe a fazer o seu melhor em um ambiente
organizacional que pode ainda no ser otimizado para o desenvolvimento de
produtos complexos.
Quando o ScrumMaster ajuda a realizar essas mudanas, isso chamado de
remoo de impedimentos. No entanto, o ScrumMaster no gerencia a Equipe
Scrum; a Equipe Scrum auto-organizvel.
O Product Owner (PO) a nica pessoa responsvel pelo gerenciamento do
Product Backlog e por garantir o valor do trabalho realizado pela Equipe.
O PO mantm o Product Backlog (PB) e assegura que ele est visvel para todos.
Todos sabem quais itens tm a maior prioridade, de forma que todos sabem em que
se ir trabalhar.
O Product Owner deve ser uma pessoa, e no um comit. Podem existir comits
que aconselhem ou influenciem , mas somente o PO poder mudar a prioridade de
um item do PB. Empresas que adotam Scrum podem perceber que isso influencia
seus mtodos para definir prioridades e requisitos ao longo do tempo.
Para que o PO obtenha sucesso, todos na organizao precisam respeitar suas
decises. Somente o PO pode definir a prioridade dos itens que a equipe ir
trabalhar.
As decises do Product Owner so visveis no contedo e na priorizao do Product
Backlog. Essa visibilidade requer que o Product Owner faa seu melhor,
o que faz o papel de Product Owner exigente e recompensador ao mesmo
tempo.
50
A Equipe SCRUM: A Equipe

A Equipe (time) de desenvolvedores transformam o Product Backlog em incrementos
de funcionalidades potencialmente entregveis em cada Sprint.
A equipe deve ser formada por pessoas comprometidas em atingir as metas das
Sprints .
A equipe deve ser interdisciplinar: os membros da equipe devem ter todo o

conhecimento e habilidades necessrias para entregar a meta da Sprint.
Membros da equipe geralmente possuem conhecimentos especializados, tais como:
programao, testes, controle de qualidade, anlise de negcios, arquitetura,
desenho de interface de usurio e modelagem de dados. No entanto, o
conhecimento que os membros devem compartilhar - isto , a habilidade de
trabalhar um item do Product Backlog (ou um requisito) e transform-lo em um
produto (software funcionando) tendem a ser mais significativas do que aqueles que
eles no dividem.
As pessoas que se recusam a programar porque so arquitetas ou designers no
se adaptam bem a equipe. Todos devem contribuir, mesmo que isso exija
aprender novas habilidades ou lembrar-se de antigas. Na equipe no h hierarquia
nem ttulos, todos so iguais e no h excees a essa regra. As equipes tambm
no devem ter sub-equipe dedicados a reas particulares como testes, banco de
dados ou anlise de negcios.
A equipe possui a auto gesto e auto-organizada. No deve haver interferncia
externa, nem o ScrumMaster ou Product Owner ningum pode dizer como a equipe
deve se organizar ou fazer inferncia na forma de trabalho da equipe. A equipe deve
ser capaz de se auto-organizar para dividir e fazer trabalho. A equipe deve ser autosuficiente, cada membro da equipe aplica sua especialidade a todos os problemas.
A sinergia que resulta disso melhora a eficincia e eficcia geral da equipe como
um todo.
51
Equipe: Comprometimento e Tamanho:
Envolvidos
Comprometidos
Stakeholders
(clientes e usurios finais)
Product Onwer
Equipe
SCRUM Master
O tamanho timo para uma equipe de 7 pessoas, mais ou menos duas pessoas. Quando h
menos do que cinco membros em uma equipe, h menor interao e, como resultado, h menor
ganho de produtividade. Mais do que isso, a equipe poder encontrar limitaes de conhecimento
durante partes da Sprint e no ser capaz de entregar uma parte pronta do produto. Se h mais do
que 9 membros, h simplesmente a necessidade de muita coordenao. Equipe grandes geram
muita complexidade para que um processo emprico consiga gerenciar. Contudo, temos encontrado
algumas equipes bem-sucedidas que excederam os limites superior e inferior dessa faixa de tamanhos.
O PO e o ScrumMaster no esto includos nessa conta, a menos que tambm sejam porcos. A
composio da equipe pode mudar ao final da Sprint. Toda vez que a equipe muda, a produtividade
ganha atravs da auto-organizao reduzida. Deve-se tomar cuidado ao mudar a composio da
equipe.
52
Eventos
53
Eventos:Viso Geral
Eventos com durao fixa (time-boxes) :
Os eventos com durao fixa so utilizados para criar para criar regularidade, os seguintes eventos
tm a durao fixa:
- Reunio de Planejamento da Release
- Reunio de Planejamento da Sprint,
- Sprint,
- Reunio Diria,
- Reviso da Sprint
- Retrospectiva da Sprint.
A Sprint:
Parte central, ou o corao do Scrum, a Sprint, que uma iterao de um ms ou menos, de
durao consistente com o esforo de desenvolvimento. Todas as Sprints utilizam o mesmo
modelo de Scrum e todas as Sprints tm como resultado um incremento do produto final que
potencialmente entregvel. Cada Sprint comea imediatamente aps a anterior.
Reunio
Diria
Sprint
Product Backlog
Produto
Sprint Backlog
54
REUNIO DE PLANEJAMENTO DA RELEASE

O propsito do planejamento da release o de estabelecer um plano e metas que a equipe Scrum e o
resto da organizao possam entender e comunicar. O planejamento da release responde s
questes:
- Como podemos transformar a viso em um produto vencedor da melhor maneira
possvel?
- Como podemos alcanar ou exceder a satisfao do cliente e o Retorno sobre
Investimento (ROI) desejados?
O Plano da Release, que o artefato resultante dessa reunio, estabelece a meta da release, as
maiores prioridades do Product Backlog, os principais riscos e as caractersticas gerais e
funcionalidades que estaro contidas na release. Ele estabelece tambm uma data de entrega e
custo provveis que devem se manter se nada mudar. A organizao pode ento inspecionar o
progresso e fazer mudanas nesse plano da release a cada Sprint.
O planejamento da release opcional. Contudo, se a equipe Scrum iniciar o trabalho sem essa
reunio, a ausncia de seu artefato aparecer como um impedimento que dever ser resolvido.
O trabalho para resolver o impedimento se tornar um item do Product Backlog.
Ao se utilizar Scrum, os produtos so construdos iterativamente, de modo que cada Sprint cria
um incremento do produto, iniciando pelo de maior valor e maior risco. Mais e mais Sprints vo
adicionando incrementos ao produto. Cada incremento um pedao potencialmente entregvel do
produto completo. Quando j tiverem sido criados incrementos suficientes para que o produto tenha
valor e uso para seus investidores, o produto entregue.
Muitas organizaes j possuem um processo de planejamento de release, e na maior parte
desses processos o planejamento feito no incio do trabalho da release e no modificado com
o passar do tempo.
55
REUNIO DE PLANEJAMENTO DA RELEASE (continuao)
No planejamento de release do Scrum, so definidos uma meta geral e resultados provveis. Esse
planejamento geralmente no requer mais do que 15-20% do tempo que uma organizao costumava
utilizar para produzir um plano de release tradicional. No entanto, uma release com Scrum realiza
planejamento no momento da execuo de cada reunio de Reviso de Sprint e de Planejamento
de Sprint, da mesma forma que realiza um planejamento dirio no momento da execuo de cada
Reunio Diria. De forma geral, os esforos para uma release com Scrum provavelmente consomem
ligeiramente mais esforo do que os esforos para um planejamento de release tradicional.
O planejamento da release requer estimar e priorizar o Product Backlog para a release. H
diversas tcnicas para faz-lo que esto fora do alcance do Scrum, mas que apesar disso so teis
quando usadas com ele.
Artefato resultante dessa reunio: Plano de Release
Plano de Release do Produto

Release #
Viso do Produto
Release #1
Release #2
Release #3
Viso do
Planejamento
Product
Backlog
Release BurnDown
Sprint #
1
6
56
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Viso
Produto
Backlog
Sprint
Backlog
Sprint
2-4 Semanas
Produto
57

REUNIO DE PLANEJAMENTO DA SPRINT
A Reunio de Planejamento da Sprint o momento no qual a iterao planejada. fixada em oito
horas de durao para uma Sprint de um ms. Para Sprints mais curtas, aloca-se para essa
reunio aproximadamente 5% do tamanho total da Sprint, e ela consiste de duas partes. A primeira
parte, um evento com durao fixa de 4 horas, o momento no qual decidido o qu ser feito
na Sprint. A segunda parte, tambm um evento com durao fixa de 4 horas, o momento no
qual a equipe entende como desenvolver essa funcionalidade em um incremento do produto
durante a Sprint.
Na 1 a equipe Scrum trata da questo: o qu?.
O Product Owner apresenta a equipe o que mais prioritrio no Product Backlog.
Eles trabalham em conjunto para definir qual funcionalidade dever ser desenvolvida durante a
prxima Sprint. As entradas para essa reunio so o Product Back, o incremento mais recente ao
produto, a capacidade da equipe e o histrico de desempenho da equipe.
Cabe somente a equipe a deciso de quanto itens do Product Backlog ela deve selecionar.
Somente a Equipe pode avaliar o que ele capaz de realizar na prxima Sprint.
Meta da Sprint:
Uma vez selecionado o Product Backlog , a Meta da Sprint delineada. A Meta da Sprint o
objetivo que ser atingido atravs da implementao do Product Backlog. Ela uma descrio que
fornece orientao a equipe sobre a razo pela qual ele est desenvolvendo o incremento. A
Meta da Sprint um subconjunto da Meta da Release.
O motivo para se ter uma Meta da Sprint dar a equipe alguma margem com relao funcionalidade.
Por exemplo, a meta para a Sprint acima poderia tambm ser: Automatizar a funcionalidade de
modificao de conta de clientes atravs de um middleware seguro capaz de recuperar transaes.
Conforme a equipe trabalha, ela mantm a meta em mente. Para satisfazer a meta, elaa implementa a
funcionalidade e a tecnologia.
Se o trabalho se mostrar mais difcil do que a equipe esperava, a equipe ento ir colaborar
com o Product Owner e implementar a funcionalidade apenas parcialmente.
58

REUNIO DE PLANEJAMENTO DA SPRINT (Continuao):
Sprint Backlog
Na segunda parte da Reunio de Planejamento da Sprint, a equipe trata a questo:
como?.
Durante as quatro horas seguintes da Reunio de Planejamento da Sprint, a equipe
Fazer UI
define como transformar o Backlog do Produto selecionado durante a Reunio de
Planejamento (o qu) em um incremento pronto. A equipe geralmente comea
Fazer as
projetando o trabalho. Enquanto projeta, a equipe identifica tarefas. Essas tarefas
Tabelas
so pedaos detalhados do trabalho necessrio para converter os itens do Product
Backlog em software funcional. As tarefas devem ser decompostas para que
possam ser feitas em menos de um dia. Essa lista de tarefas chamada de Sprint
Incluir novo
cliente
Backlog que um artefato do SCRUM. A equipe se auto-organiza para se encarregar
e se responsabilizar pelo trabalho contido na Sprint Backlog , tanto durante a Reunio
de Planejamento da Sprint quanto no prprio momento da execuo da Sprint.
O Product Owner est presente durante a segunda parte da Reunio de
Planejamento da Sprint para esclarecer o Product Backlog e para ajudar a
efetuar trocas. Se a equipe concluir que ele tem trabalho demais ou de menos,
ele pode renegociar os itens do Product Backlog escolhido com o Product Owner.
A equipe tambm pode convidar outras pessoas , tais como clientes finais e/ou
especialista de negcio, a participarem da reunio para fornecerem conselhos
tcnicos ou sobre o domnio em questo.
Geralmente, uma equipe nova percebe pela primeira vez se ir ganhar ou perder
como uma equipe - no individualmente - nessa reunio. A equipe percebe que
deve contar consigo mesmo. Conforme ele percebe isso, ele comea a se autoorganizar para assumir as caractersticas e comportamento de uma verdadeiro
equipe.
consultar
cliente
alterar
cliente
Fazer Testes
Unitrios
Artefato resultante dessa reunio: Sprint Backlog

59
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Viso
Produto
Backlog
Sprint
Backlog
Produto
Sprint
2-4 Semanas
60

A SPRINT
A Sprint uma iterao. Sprints so eventos com durao fixa. Durante a Sprint, o ScrumMaster
garante que no ser feita nenhuma mudana que possa afetar a Meta da Sprint. Tanto a composio
da equipe quanto as metas de qualidade devem permanecer constantes durante a Sprint. As
Sprints contm e consistem na reunio de Planejamento de Sprint, o trabalho de
desenvolvimento, a Reviso da Sprint e a Retrospectiva da Sprint. As Sprints ocorrem uma aps
a outra, sem intervalos entre elas.
Um projeto serve para cumprir alguma funo. Em desenvolvimento de software, o projeto
utilizado para desenvolver um produto ou sistema. Cada projeto consiste em uma definio do
que ser desenvolvido, um plano para desenvolv-lo, o trabalho realizado de acordo com o
plano e o produto resultante. Cada projeto possui um horizonte, que o perodo de tempo para
o qual o plano vlido. Se o horizonte for longo demais, a definio poder ter mudado, variveis
demais podero ter surgido, o risco poder ser grande demais etc. Scrum um framework para
projetos cujo horizonte no superior ao perodo de um ms, onde j h complexidade suficiente tal
que um horizonte mais longo seria arriscado demais. A previsibilidade do projeto deve ser
controlada pelo menos a cada ms, e o risco de que o projeto saia de controle ou se torne
imprevisvel contido pelo menos a cada ms.
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 influncia
das partes interessadas, da equipeou do ScrumMaster. Sob que tipo de circunstncias pode ser
necessrio cancelar uma Sprint? A gerncia pode precisar cancelar uma Sprint se a Meta da Sprint
se tornar obsoleta. Isso pode ocorrer se a empresa mudar de direo ou se as condies do
mercado ou tecnologia mudarem. Em geral, uma Sprint deve ser cancelada se ela no fizer mais
sentido dadas as circunstncias atuais, todavia isso deve ser uma exceo. Porm, por causa da curta
durao das Sprints, raramente isso faz sentido.
Artefato resultante dessa iterao: Parte do produto

61
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Viso
Produto
Backlog
Sprint
Backlog
Produto
Sprint
2-4 Semanas
62
REUNIO DIRIA
A equipe deve se encontrar diariamente para uma reunio de 15 minutos chamada Reunio
Diria. Essa reunio sempre feita no mesmo horrio e no mesmo local durante as Sprints.
Durante a reunio, cada membro explica:
1. O que ele realizou desde a ltima reunio diria;
2. O que ele vai fazer antes da prxima reunio diria; e
3. Quais obstculos esto em seu caminho.
As Reunies Dirias melhoram a comunicao, eliminam outras reunies, identificam e

removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rpida de
decises e melhoram o nvel de conhecimento de todos acerca do projeto.
O ScrumMaster deve garantir que a equipe realize essa reunio. A equipe responsvel por
conduzir a Reunio Diria. O ScrumMaster ensina a equipe a manter a Reunio Diria com curta
durao, reforando as regras e assegurando que as pessoas falem brevemente. O ScrumMaster
tambm enfatiza a regra de que galinhas no esto autorizadas a falar e nem a interferir de modo
algum na Reunio Diria.
A Reunio Diria no uma reunio de status. Ela s para as pessoas que esto
transformando os itens do Product Backlog um incremento (a equipe), e para mais ningum. A
equioe se comprometeu com uma Meta da Sprint, e a esses itens do product Backlog. A
Reunio Diria uma inspeo do progresso na direo da Meta da Sprint (as trs
perguntas).
Geralmente acontecem reunies subsequentes para realizar adaptaes ao trabalho que est por
vir na Sprint. A inteno otimizar a probabilidade de que a equipe alcance sua Meta. Essa uma
reunio fundamental de inspeo e adaptao no processo emprico do Scrum.
63
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Viso
Produto
Backlog
Sprint
Backlog
Produto
Sprint
2-4 Semanas
64
REVISO DA SPRINT
Ao final da Sprint, feita a reunio de Reviso da Sprint. Para Sprints de um ms, essa uma
reunio com durao fixa de 4 horas. Para Sprints de duraes mais curtas, essa reunio no deve
tomar mais do que 5% do total da Sprint. Durante a Reviso da Sprint, a equipe Scrum e as partes
interessadas colaboram sobre o que acabou de ser feito.
Baseados nisso e em mudanas no Product Backlog feitas durante a Sprint, eles colaboram sobre
quais so as prximas coisas que podem ser feitas. Essa uma reunio informal, com a
apresentao da funcionalidade, que tem a inteno de promover a colaborao sobre o que fazer em
seguida.
A reunio inclui ao menos os seguintes elementos. O Product Owner identifica o que foi feito e o
que no foi feito. A equipe discute sobre o que correu bem durante a Sprint e quais problemas foram
enfrentados, alm de como esses problemas foram resolvidos. A equipe ento demonstra o trabalho
que est pronta e responde a questionamentos. O Product Owner ento discute o Product Backlog
da maneira como esse se encontra.
Ele faz projees de datas de concluso provveis a partir de vrias hipteses de velocidade. Em
seguida, o grupo inteiro colabora sobre o que foi visto e o que isso significa com relao ao que fazer
em seguida. A Reviso da Sprint fornece entradas valiosas para as reunies de Planejamento de
Sprints seguintes.
65
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Viso
Produto
Backlog
Sprint
Backlog
Produto
Sprint
2-4 Semanas
66

RETROSPECTIVA DA SPRINT
Aps a Reviso da Sprint e antes da prxima reunio de Planejamento da Sprint, a equipe Scrum
tem a reunio de Retrospectiva da Sprint.
Nessa reunio, com durao fixa de trs horas, o ScrumMaster encoraja a equipe a revisar, dentro
do modelo de trabalho e das prticas do processo do Scrum, seu processo de
desenvolvimento, de forma a torn-lo mais eficaz e gratificante para a prxima Sprint. Existem
diversas tcnica que so teis em uma Retrospectiva.
A finalidade da Retrospectiva inspecionar como foi a ltima Sprint em se tratando de pessoas,
das relaes entre elas, dos processos e das ferramentas. A inspeo 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. Isso inclui a composio da equipe, os preparativos para
reunies, ferramentas, definio de pronto, mtodos de comunicao e processos para
transformar itens do Product Backlog em alguma coisa pronta.
No final da Retrospectiva da Sprint, a equipe Scrum deve ter identificado as aes de melhoria
factveis que ser implementada na prxima Sprint. Essas mudanas se tornam a adaptao para
a inspeo emprica.
67
Framework Scrum: Artefatos
Artefatos
68
Scrum tem quatro artefatos principais:

- Product Backlog: uma lista priorizada de tudo que pode ser necessrio no produto.
- Sprint Backlog: uma lista de tarefas para transformar o Product Backlog , por uma Sprint, em
um incremento do produto potencialmente entregvel. Um burndown uma medida do
backlog restante pelo tempo.
- Release Burndown: Mede o Product Backlog restante ao longo do tempo de um Plano de
Release do Produto.
- Sprint Burndown: Mede os itens da Sprint Backlog restantes ao longo do tempo de uma Sprint.
69
PRODUCT BACKLOG e RELEASE BURNDOWN

Os requisitos para o produto que a equipe est desenvolvendo esto listados no Product Backlog
O Product Owner (PO) o responsvel pelo Product Backlog , por sua criao, por seu
contedo, por sua disponibilidade e por sua priorizao.
O Product Backlog nunca est completo. A seleo inicial para o seu desenvolvimento somente
mostra os requisitos inicialmente conhecidos e melhor entendidos. O Product Backlog evolui medida
que o produto e o ambiente em que ele ser usado evoluem. O Backlog dinmico, no sentido de
que ele est constantemente mudando para identificar o que o produto necessita para ser
apropriado, competitivo e til. Enquanto existir um produto, o Product Backlog tambm existir.
O Product Backlog representa tudo que necessrio para desenvolver e lanar um produto de
sucesso. uma lista de todas as caractersticas, funes, tecnologias, melhorias e correes de
defeitos que constituem as mudanas que sero efetuadas no produto para releases futuras. Os
itens do Product Backlog possuem os atributos de descrio, prioridade e estimativa. A prioridade
determinada por risco, valor e necessidade. H diversas tcnicas para dar valor a esses atributos.
O Product Backlog ordenado por prioridade, os itens com as maiores prioridades devem ter o
desenvolvimento imediato.
Quanto mais alta sua prioridade, mais urgente ele , mais se pensou sobre ele e h mais
consenso no que diz respeito ao seu valor. Os itens do Backlog de maior prioridade, possuem mais
informaes e detalhes do que os itens do Backlog de menor prioridade. mais fcil de fazer a
estimativa quando existem mais informaes e mais detalhes.
70
PRODUCT BACKLOG e RELEASE BURNDOWN (continuao):

Quando um produto utilizado, que seu valor aumenta e que o cliente fornece feedback, o
Product Backlog poder se tornar uma lista maior e mais aprofundada. Os requisitos nunca param
de mudar. O Product Backlog um documento vivo. Mudanas nos requisitos de negcios,
condies do mercado, tecnologia e equipe causam mudanas no Product Backlog. Para
minimizar o retrabalho, apenas os itens de maior prioridade precisam ser mais detalhados. Os
itens do Product Backlog que ocuparo a Equipe Scrum pelas vrias Sprints seguintes devero ter
granularidade mais fina (mais detalhados), tendo sido decompostos de forma tal que cada um dos
itens possa ser feito dentro da durao da Sprint.
Frequentemente, mltiplas equipes trabalham juntas no mesmo produto. Um nico Product
Backlog usado para descrever o trabalho a ser realizado no produto. Ento, um atributo que
agrupe os itens aplicado no Backlog do Produto.
O agrupamento pode ocorrer por conjuntos de caractersticas, por tecnologia ou por arquitetura,
e ele frequentemente utilizado como uma forma de se organizar o trabalho por equipe.
O grfico de Release Burndown registra a soma das estimativas dos esforos restantes do Product
Backlog ao longo do tempo. O esforo estimado deve estar em qualquer unidade de medida de
trabalho que a equipe e a organizao tenham decidido usar. As unidades de tempo geralmente
so Sprints.
As estimativas dos itens do Product Backlog so inicialmente calculadas durante o Planejamento
da Release, e posteriormente medida que itens forem sendo criados. Durante a preparao do
Product Backlog , os itens so revistos e revisados.
Entretanto, eles podem ser atualizados em qualquer momento. A equipe responsvel por todas
as estimativas. O Product Owner (PO) pode influenciar a equipe, ajudando-o a entender e a
escolher as mudanas, mas a estimativa final feita pelo equipe. O Product Owner mantm o
Product Backlog e o Release Burndown do Backlog atualizados e publicados todo o tempo. Uma
linha de tendncia pode ser traada baseada na mudana do trabalho restante.
71

PRODUCT BACKLOG: Exemplo
Product Backlog
Tema*
Item
Prioridade
Pontos (estimados)
Venda de
Passagem
Vender passagens reas
Alta
40
Venda de
Passagem
Consulta de disponibilidade de
passagens reas
Alta
13
Check-in
Fazer check-in
Alta
40
Check-in
Cancelar Check-in
Alta
Programa de
Fidelidade
Adeso ao programa de
fidelidade
Mdia
20
Programa de
Fidelidade
Consultar os pontos do
programa de fidelidade
Mdia
Atendimento ao
cliente
Fazer registro de comentrios,

sugestes e reclamaes dos
clientes
Baixa
Atendimento ao
cliente
Responder ao cliente (por email)
Baixa
Nota: O que Tema ?

Tema utilizado para agrupar Estrias do Usurios relacionadas, as estrias so representam o detalhamento dos itens do Backlog, ao usar o
conceito de tema, ele poder facilitar as atividades de priorizao e de estimativa.
72

RELEASE BURNDOWN: Exemplo
Release Burndown
Release Burndown registra a
soma das estimativas dos esforos
restantes do Product Backlog ao
longo do tempo. O esforo
estimado deve estar em qualquer
unidade de medida de trabalho
que a equipe e a organizao
tenham decidido usar. As
unidades de tempo geralmente
so Sprints.
139
100
Pontos (estimados)
150
90
50
52
20
0
Sprint #1
Sprint #2
Sprint #13
Sprint #4
Sprints
73

SPRINT BACKLOG E SPRINT BURNDOWN:
A Sprint Backlog consiste nas tarefas que a equipe executa para transformar os itens do Product
Backlog em um incremento pronto. Muitas deles so elaboradas durante a Reunio de
Planejamento da Sprint.
A Sprint Backlog todo trabalho que a equipe identifica como necessrio para alcanar a Meta da
Sprint. Os itens do Sprint Backlog devem ser decompostos. A decomposio deve ser suficiente
para que mudanas no progresso possam ser entendidas na Reunio Diria.
A equipe modifica a Sprint Backlog no decorrer da Sprint. Quando chega s tarefas individuais, a
equipe pode descobrir que mais ou menos tarefas sero necessrias, ou que uma determinada
tarefa levar mais ou menos tempo do que era esperado. medida que novo trabalho surge, a
equipe o adiciona a Sprint Backlog.
medida que se trabalha nas tarefas ou que elas so completadas, as horas estimadas de trabalho
restantes para cada tarefa so atualizadas. Quando se verifica que determinadas tarefas so
desnecessrias, elas so removidas.
Somente a equipe pode modificar a Sprint Backlog durante uma Sprint, pode mudar o seu contedo
ou as suas estimativas. A Sprint Backlog um retrato em tempo real altamente visvel do
trabalho que a equipe planeja efetuar durante a Sprint, e ela pertence unicamente a equipe.
74
SPRINT BACKLOG E SPRINT BURNDOWN: Exemplo
Na reunio de Planejamento da
Sprint, PO dever apresentar a
viso do produto, Product Backlog
e seus Itens, comentando o nvel
de prioridade de cada item. Os
membros da equipe devem
selecionar os itens com os maiores
nveis de prioridades para fazer
parte da Sprint.
Estria do Usurio
Titulo: Fazer Check-in
Como cliente de negcio, eu quero fazer check-in

pela web para que fique menos tempo em filas.
Pontos: ?
A estria do usurio auxilia no

entendimento do que deve ser
feito, ela permite fazer a
estimativa de velocidade da
equipe e tambm , utilizada
como lembrete e para as
atividades de planejamento.
Geralmente a estimativa feita
em pontos (pontos de estria)
Prioridade: Alta
75

SPRINT BACKLOG E SPRINT BURNDOWN: Exemplo
Estria do Usurio

Pontos: ?
Prioridade: Alta
Fazer
interface
do usurio
Fazer Check-in
Impresso
do Ticket
Criar
Componentes
de validao
Executar
testes
unitrios
Integrar
com Sistema
de Reserva
Executar
testes de
aceitao
Quebrar a estria do Usurio em

tarefas:
- Para facilitar a estimativa de
velocidade da equipe, considere
quebrar a estria em tarefas, isto
pode fazer que todos os membros
da equipe visualizem todas as
tarefas que devem ser feitas para
implementar o item do backlog.
Mas, ainda precisamos estimar os
pontos...
Sprint Backlog
A Sprint Backlog um
artefato resultante da reunio
de Planejamento da Sprint
76
Estimando os pontos da Estria do Usurio:

Uma breve introduo sobre estimativa:
Estimar Difcil ?
- Estimativa (mundo real) representa um valor aproximado.
- Estimativa (em desenvolvimento de software) algumas pessoas acham que representa um valor exato.
Contudo, devemos estimar as Estrias do Usurio para saber se elas cabem dentro de uma Sprint.
Uma vez que os pontos so estimados eles ajudam a definir a velocidade da equipe, a partir deste
parmetro, podemos chegar a concluso se estria cabe ou no dentro da Sprint. Se ela no couber a
opo quebrar esta estria em estrias menores.
Exemplo de Estrias do Usurio:
Prioridade: ?
Titulo: Pagamento com Carto de Crdito

Quem ?
como um cliente
O que ?
Pessoal, qual
estimativa para
essa estria...
preciso de uma interface de pagamento por carto de
crdito que seja intuitiva e fcil de usar.

Por que ?
Com objetivo de facilitar os pagamentos.
Pontos: ?
Product Owner
77

Quando trabalhamos com mtodos geis temos pelo menos duas formas para estimar a velocidade da
equipe: Ideal Days e Pontos de Estria. Recomendamos utilizar os Pontos de Estria.
Ideal Days:
Mais fcil para iniciantes
Fcil de explicar
Pontos de Estria:
Valores relativos
Mais abstrato
Dias Ideais (Ideal Days)
Baseado na durao de tarefas.

- Dias ou horas unidade bem definida, contudo o tempo ideal
quase nunca igual ao tempo real...
- mais fcil de estimar, mas pode ser tornar difcil de estimar se
consideramos todas as interrupes e variaes
Pontos de Estria (Story Points)

Baseia-se no tamanho da estria influenciado pela:
- Nvel de dificuldade, complexidade e experincia ( emprico);
Foco nas funcionalidades;
O importante so os valores relativos;
Pontos so medidas sem unidade;
Equipe diferentes podem ter pontos diferentes para a mesma
estrias.
Principais tcnicas:
Opinio de especialista;
Analogia;
Decomposio (Dividir para conquistar).
78
Estimativa* e o Planning Poker:

Para fazer estimativa de velocidade da equipe ou de durao da Sprint, antes preciso o escrever as
estrias do usurio.
O Planning Poker uma prtica que ajuda na estimativa de uma estria ou de uma tarefa e baseada
no consenso de toda a equipe.
Geralmente o Planning Poker usa um conjunto de cartas com valores especficos que
podem representar pontos relativos e praticado como se fosse um jogo de cartas. Os
pontos devem estar em uma escala no linear, por e exemplo a Fibonacci:
(1,2,3,5,8,13,...) + 20, 40, 100 ou em outra escala
Jogando o Planning Poker:
Antes de comear o jogo necessrio definir um valor de referncia. Por exemplo: Identificar a estria
que pode ser atribudo a menor quantidade pontos, esta estria ser utilizada como referncia para
pontuao das demais estrias.
O PO apresenta uma estria e pede para os membros da equipe fazer a estimativa de velocidade...
1. Rodada
40
100
Pessoal, qual
estimativa para
essa estria...
40
40
Product Owner
Quando todas as cartas

estiverem lanadas, elas
so viradas e caso no
haja consenso nos
pontos, as diferenas so
discutidas de forma
breve, e uma nova
rodada acontece at que
haja concesso.
Equipe
N. Rodada
40
40
40
40
Equipe
79

SPRINT BACKLOG: Exemplo
Estria do Usurio

Pontos: 40
Prioridade: Alta
Fazer
interface
do usurio
Fazer Check-in
Impresso
do Ticket
Criar
Componentes
de validao
Executar
testes
unitrios
Integrar
com Sistema
de Reserva
Executar
testes de
aceitao
Planning Poker, estria do usurio

e pontos de estria, nada disso faz
parte do framework Scrum,
contudo so tcnicas e ferramentas
complementares ao framework.
Elas so altamente utilizadas para
fazer a estimativa de velocidade da
equipe.
E finalmente temos a Sprint
Backlog e podemos criar o Sprint
Burndonw.
Sprint Backlog
A Sprint Backlog todo trabalho que a equipe identifica como necessrio para alcanar a Meta da Sprint.
80
SPRINT BACKLOG E SPRINT BURNDOWN:

A Sprint Burndown (ou Burndown ) um grfico da
quantidade restante de trabalho do Sprint Backlog em
uma determinada Sprint ao longo do tempo da Sprint.
Para criar esse grfico, determine quanto trabalho resta
somando as estimativas do Backlog a cada dia da
Sprint.
A quantidade de trabalho restante para uma Sprint a

soma do trabalho restante para tudo da Sprint Backlog.
Acompanhe essas somas diariamente e utilize-as para criar
um grfico que mostre o trabalho restante ao longo do
tempo. Traando uma linha atravs dos pontos no
grfico, a equipe pode gerenciar seu progresso em
completar o trabalho de uma Sprint.
A durao no considerada em Scrum. O trabalho
restante e a data so as nicas variveis de interesse.
Uma das regras do Scrum est ligada ao objetivo de cada
Sprint, que ter como resultado incrementos de
funcionalidade potencialmente entregveis que estejam de
acordo com uma definio de pronto.
Dica:
Sempre que possvel, desenhe a Sprint Burndown em um
quadro que esteja na rea de trabalho da equipe. mais
provvel que a equipe veja um grfico grande e visvel do que
um grfico de feito em uma planilha de calculo.
A Sprint Burndown um artefato

que deve ser utilizado exclusivamente
pela equipe.
Se PO tentar fazer a gesto do
projeto com base na Sprint
Burndown considerado como
micro-gerenciamento e que pode
levar ao comando-controle...
O PO deve fazer a gesto do projeto
olhando a Release Burndown.
81

SPRINT BURNDOWN : Exemplo
A transparncia, que dos pilares do Scrum, garante que

aspectos do processo que afetam o resultado devem ser visveis
para aqueles que gerenciam os resultados. O Quadro de Tarefas
deixam a Sprint com visibilidade e transparncia.
O Quadro de Tarefas tambm

no parte do framework
Scrum, ele parte de uma
tcnica chamada Gesto
Vista, que tem como objetivo
facilitar a comunicao e dar
visibilidade (transparncia).
82
Framework Scrum: Definio de Pronto
Pronto
83
Definio de Pronto (*DoD):

Uma conversa comum entre o cliente e o desenvolvedor:
[Cliente] E a como anda o desenvolvimento da aplicao ?

[Desenvolvedor] Est pronta...
[Cliente] Isso quer dizer que eu posso implementa-la ?
[Desenvolvedor] Bem...ainda no, preciso fazer mais alguns testes...
[Cliente] Mas, aplicao no estava pronta..
Definir claramente quando o produto estar pronto,
pois:
Pronto, para desenvolvedor significa:
- Encerrou a codificao...
Pronto, para PO significa:
- Quando foi entregue...
Pronto, para os usurios finais e/ou clientes significa:

- Quando o software comeou a funcionar em ambiente
de produo...
Evite: A sndrome dos 90% feito (pronto).

84
A Definio de PRONTO
Scrum exige que a equipe desenvolva um incremento de funcionalidade do produto a cada
Sprint. Esse incremento deve ser potencialmente entregvel, pois o Product Owner (PO)
pode optar por implantar a funcionalidade imediatamente. Para isso ser possvel, o
incremento deve ser um pedao completo do produto. Ele deve estar pronto. Cada
incremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado,
garantindo que todos os incrementos funcionem juntos.
No desenvolvimento de produtos, afirmar que a funcionalidade est pronta pode levar algum a
presumir que ela est pelo menos bem codificada, refatorada, que tenha passado por testes
unitrios, que tenha sido feito o build e que tenha passado por testes de aceitao.
Outros podem presumir que apenas o cdigo tenha sido desenvolvido.
Se no houve definio de pronto, os outros dois pilares do controle de processos empricos no
funcionam. Quando algum descreve algo como pronto, todos devem entender o que pronto
significa.
Pronto define o que a equipe quer dizer quando se compromete a aprontar um item de
Product Backlog em uma Sprint. Alguns produtos no contm documentao, de forma que sua
definio de pronto no inclui documentao. Um incremento completamente pronto inclui toda
a anlise, projeto, refatoramento, programao, documentao e testes para o incremento e todos os
itens do Product Backlog no incremento. Os testes incluem testes de unidade, de
sistema, de usurio e de regresso, bem como testes no-funcionais como de performance, de
estabilidade, de segurana e de integrao.
Pronto inclui tambm qualquer internacionalizao necessria. Algumas equipes ainda no so
capazes de incluir em sua definio de pronto tudo o que necessrio para a implantao. Isto
deve estar claro para o Product Owner. Esse trabalho restante dever ser feito antes que o
produto possa ser implantado e utilizado.
85
A Definio de PRONTO e NO PRONTO

Algumas organizaes so incapazes de desenvolver um incremento completo dentro de uma
Sprint. Elas podem ainda no ter infraestrutura automatizada de testes para completar todos os
testes. Nesse caso, duas categorias so criadas para cada incremento: o trabalho pronto e
o trabalho no pronto. O trabalho no pronto a poro de cada incremento que ter que ser
completada mais tarde. O Product Owner sabe exatamente o que ele est inspecionando ao final
da Sprint, porque o incremento atende definio de pronto e o Product Owner entende essa definio.
O trabalho no pronto adicionado a um item do Product Backlog o chamado trabalho no pronto, de
forma que ele se acumula e isso refletido corretamente no grfico de Release Burndown Release.
Essa tcnica cria transparncia no progresso em direo entrega. A inspeo e a adaptao na
Reviso da Sprint sero to precisas quanto essa transparncia for.
Exemplo:
Se uma equipe no capaz de realizar os testes de performance, regresso, estabilidade,
segurana e integrao para cada item do Product Backlog, a proporo desse trabalho em
relao ao trabalho que pode ser pronto (anlise, projeto, refatoramento, programao,
documentao, testes unitrio e testes de usurio) calculada.
Vamos supor que essa proporo de seis peas de pronto e quatro peas de no pronto. Se a
equipe terminar um item de Product Backlog de seis unidades de trabalho (a equipe est
estimando baseado no que ele sabe como aprontar), quatro unidades sero acrescidas ao
item do Product Backlog denominado trabalho no pronto quando eles tiverem terminado.
Sprint a Sprint, o trabalho no pronto de cada incremento vai se acumulando e deve ser
tratado antes da entrega do produto. Esse trabalho acumulado linearmente, embora haja algum
tipo de acmulo exponencial que dependente das caractersticas de cada organizao.
Sprints so adicionados ao final de cada release para completar o trabalho no pronto. O
nmero de Sprints imprevisvel, visto que o acmulo de trabalho no pronto no linear.
86
Exerccios:
Responda Verdadeiro ou Falso para as declaraes:
1 - Quando as regras no so declaradas, espera-se que os usurios de Scrum descubram o que

devem fazer. No tente descobrir uma soluo perfeita, porque geralmente o problema muda
rapidamente. Ao invs disso, tente algo e veja como se sai. Os mecanismos de inspeo-e-adaptao
inerentes natureza emprica do Scrum iro lhe guiar.
[
] Verdadeiro
] Falso
2 - O ScrumMaster trabalha com os clientes e a gerncia para identificar e designar um Product Owner.
O ScrumMaster ensina ao Product Owner como fazer seu trabalho. Espera-se dos Product Owners que
eles saibam como conseguir otimizar valor atravs do Scrum. Se eles no souberem, consideramos o
ScrumMaster responsvel.
[
] Verdadeiro
] Falso
3 - O ScrumMaster pode ser um membro da equipe; por exemplo, um desenvolvedor realizando tarefas
da Sprint. No entanto, isso frequentemente leva a conflitos quando o ScrumMaster deve escolher entre
remover impedimentos ou realizar tarefas.
[
] Verdadeiro
] Falso
4 - O ScrumMaster nunca deve ser o Product Owner.

[
] Verdadeiro
] Falso
87
Exerccios:
Responda Verdadeiro ou Falso para as questes:
5 - O Product Owner pode ser um membro da equipe, trabalhando tambm na realizao das tarefas.
Mas, essa responsabilidade adicional pode reduzir a sua habilidade de lidar com as partes
interessadas.
] Verdadeiro
] Falso
6 Se a equipe sentir que se comprometeu com mais do que podia, ele se encontra com o Product
Owner para remover ou reduzir o escopo da Sprint Backlog (itens do Product Backlog selecionado para
a Sprint). Se a equipe sentir que sobrar tempo ele pode trabalhar junto ao Product Owner para
selecionar mais do itens do Product Backlog.
[
] Verdadeiro
] Falso
7- Geralmente, somente 60-70% do total da Sprint Backlog ser definido na Reunio de Planejamento
da Sprint. O restante deixado para ser detalhado mais tarde ou so dadas estimativas grandes que
sero decompostas mais tarde na Sprint.
[
] Verdadeiro
] Falso
8 - Os itens do Product Backlog so comumente representados como Estrias do Usurio. Casos de

Uso tambm so apropriados.
[
] Verdadeiro
] Falso
88
Exerccios:
Responda Verdadeiro ou Falso para as questes:
9 - Testes de aceitao fazem parte da Estria de Usurio, so utilizados parar substituir descries
textuais mais detalhadas com uma descrio testvel.
] Verdadeiro
] Falso
10 - O Release Burndown registra a soma das estimativas dos esforos restantes do Product Backlog
ao longo do tempo. O esforo estimado deve estar em qualquer unidade de medida de trabalho que a
equipe Scrum e a organizao tenham decidido usar. As unidades de tempo geralmente so
Estrias do Usurio.
[
] Verdadeiro
] Falso
89
Contedo:

2 Sobre o SCRUM
3 Entendendo SCRUM
4 Estudo de Caso
90
Objetivo:
Estudo de Caso
Objetivo:
Apresentar um Estudo de Caso para demonstrar como aplicar as prticas do SCRUM em
projeto de desenvolvimento de Software.
Pr-requisito:
Conhecimento das prticas Scrum.
91
Estudo de Caso
Estudo de Caso
92
Framework SCRUM
Planejamento
da Release
Reunio
diria
Planejamento
da Sprint
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Product
Backlog
Sprint
Backlog
Produto
Sprint
(2-4 Semanas)
Viso
Legenda:
Reunies
Artefatos
Reunies
Artefatos
Papis
Product Owner (PO)
ScrumMaster (SM)
Equipe (time)
Planejamento da Release
Planejamento da Sprint
Diria
Reviso da Sprint
Product Backlog
Sprint Backlog
Sprint Burndown
Release Burndown
Sprint Burndown
Release Burndown
93
Estudo de Caso: Viso
Primeiro passo: definir a Viso do Produto.
Planejamento
da Release
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Produto
Backlog
Sprint
Backlog
Sprint
2-4 Semanas
Produto
Viso
1
94
Estudo de Caso: Viso do Produto

Para definir a viso do Produto, primeiro necessrio entender qual a real necessidade do cliente:
A necessidade:
Um hotel, quer incrementar um novo canal de consultas e vendas de reservas de
apartamentos. A sugesto foi criar um Portal de Reservas para vender os servios.
Aps entender a necessidade do cliente, hora de definir a Viso do Produto:

Declarao da Viso do Produto:
Para o Hotel que necessita de um Sistema o Portal de Reservas On-Line um

software baseado na web, intuitivo e fcil de usar que fornece a possibilidade fazer a
consultas e reservas de apartamentos.
Diferente de outros sistemas, o produto oferece um canal direto de acesso ao cliente.
95
Aps a definio da Viso do Produto, devemos definir a primeira verso do Product Backlog:
Funcionalidades do produto
O Product Backlog, inicialmente uma lista que representa tudo que necessrio para desenvolver e
lanar um produto. A lista deve conter todas as caractersticas, funes, tecnologias, melhorias e
correes de defeitos que constituem as mudanas que sero efetuadas no produto para futuras
releases . O Product Backlog dinmico, no sentido de que ele est constantemente mudando
para identificar o que o produto necessita.
96
97

Exerccio:
Podemos fazer a declarao da Viso do Produto sem entender a real necessidade do cliente ?
98
Estudo de Caso: Reunio de Planejamento da Release
Segundo passo: Realizar a Reunio de Planejamento da Release, o resultado desta reunio o

Plano de Release e o Release Burndown (artefato Scrum).
Planejamento
da Release
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Produto
Backlog
Sprint
Backlog
Sprint
2-4 Semanas
Produto
Viso
2
99

O propsito da Reunio de Planejamento da Release o de estabelecer o Plano de Release, as Metas
e Release Burndown (que um artefato do Scrum) que a Equipe Scrum e o resto da organizao
possam entender e comunicar.
O planejamento da release responde s questes:
- Como podemos transformar a viso em um produto da melhor maneira possvel?
- Como podemos alcanar ou exceder a satisfao do cliente ?
- Como podemos alcanar o ROI (retorno sobre investimento) ?
O Plano de Release estabelece a meta da release, as maiores prioridades do Product Backlog,
os principais riscos e as caractersticas gerais e funcionalidades que estaro contidas na release.
Ele estabelece tambm uma data de entrega e custos provveis que devem se manter se nada mudar. A
organizao pode ento inspecionar o progresso e fazer mudanas nesse Plano de Release a cada
Sprint.
O planejamento da release requer estimar e priorizar o Product Backlog para a release. H diversas
tcnicas para faz-lo que esto fora do alcance do Scrum (lembre-se o SCRUM framework ele no
indica nenhuma tcnica), mas que apesar disso so teis quando usadas com ele.
Release
Burndown
(artefato)
Entradas
Viso do Produto
Planejamento
da Release
Product Backlog (priorizado)
Product Backlog (viso inicial)
Sadas
Equipe SCRUM
Plano de Release
100
Viso inicial do Product Backlog, antes da reunio de Planejamento da

Sprint, ele tem somente as funcionalidades do produto, agrupadas por
tema (este agrupamento opcional).
O Plano de Release
base para atualizao
do Product Backlog
Agora ele apresenta o
nvel de prioridade e
quantidade de pontos
estimados dos itens.
O PO responsvel
pela priorizao dos
itens e a Equipe
responsvel pela
estimativa.
O Plano de Release
elaborado nessa
reunio. Nesse plano
define-se o prazo de
entrega do produto e
nvel de prioridade
dos itens do backlog
2
Plano de Release
Reserva
Promoes
Relacionamento
ao cliente
Programa de
Fidelidade
Tour Virtual
5 Releases
Nvel de
Prioridade
Alto
Mdio
Mdio
Mdio
Baixo
1 Alto, 3 mdio
e 1 baixo
Prazo
(estimado)
30 dias
15 dias
7 dias
15 dias
15 dias
82 dias
Releases
101
Release Burndown
120
O Product Owner responsvel

por manter o Product Backlog e
o Release Burndown atualizados
e publicados todo o tempo.
Uma linha de tendncia pode ser
traada baseada na mudana do
trabalho restante.
108
80
Pontos (estimados)
Com Product Backlog atualizado e o Plano de Release, o PO poder construir o Release Burndown, que um
dos artefatos do SCRUM. As estimativas dos itens do Product Backlog so inicialmente calculadas durante
a Reunio de Planejamento da Release.
O Release Burndown registra a soma das estimativas dos esforos restantes do Product Backlog ao longo do
tempo. O esforo estimado deve estar em qualquer unidade de medida de trabalho que a equipe e a
organizao tenham decidido usar. As unidades de tempo geralmente so Sprints.
68
40
48
40
20
0
Release #1
Release #2
Release #3
Release #4
Release #5
Releases
102
103

Exerccio:
O que aconteceria se a equipe SCRUM no fizer a Reunio de Planejamento da Release ?
104
Estudo de Caso: Reunio de Planejamento da Sprint
Terceiro passo: Realizar a Reunio de Planejamento da Sprint, o resultado desta reunio so os

artefatos Sprint Backlog e Sprint Burndown.
Planejamento
da Release
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Produto
Backlog
Sprint
Backlog
Sprint
2-4 Semanas
Produto
Viso
3
105
Product Backlog: Sistema de Reserva On-Line
A Reunio de Planejamento da Sprint o momento no qual a iterao planejada. No nosso

exemplo a durao fixada em 8 horas, pois, a Sprint tem a estimativa de um ms.
Essa reunio dividida em duas partes:
1. Parte da Reunio (4 horas):
A equipe Scrum trata da questo: o qu?.
O PO apresenta a equipe o que mais
prioritrio no Product Backlog. Todos trabalham
em conjunto para definir qual funcionalidade
dever ser desenvolvida durante a prxima
Sprint. O Product Backlog est ordenado de
acordo com nvel de prioridade dos itens.
A equipe deve selecionar o item de maior
prioridade e definir qual ser a meta da Sprint.
2. Parte da Reunio (4 horas):

A equipe trata a questo: como?.
Durante as 4 horas seguintes a equipe define como
transformar o item selecionado em incremento do
produto pronto e potencialmente entregvel.
O PO estar presente para esclarecer dvidas e para
ajudar a efetuar trocas, se necessrio. Se a equipe
concluir que ela tem trabalho demais ou de menos,
ela pode renegociar os itens do Product Backlog
escolhido com o PO
106
Detalhando os itens do Produto Backlog em estrias do usurio:

Para facilitar o entendimento dos
itens do Product Backlog ele so
descritos em estrias do usurio
elas auxiliam no entendimento do
que deve ser feito, permite fazer
a estimativa de velocidade da
equipe e tambm , utilizada
como lembrete e para as
atividades de planejamento.
Geralmente a estimativa feita
em pontos (pontos de estria)
Como escrever uma Estria do Usurio ?

Conversaes sobre a estria, entre os usurios e desenvolvedores, de modo a detalhar o item do
Product Backlog e esclarecer todas as dvidas sobre do que deve ser feito.
Estria do Usurio
Titulo: Fazer Reserva de Apartamentos
Como cliente de negcio, eu quero fazer reserva de
apartamentos pela web para facilitar o meu
planejamento.
Pontos: ?
Prioridade: Alta
Carto: Estria do Usurio so tradicionalmente

escritas em um carto. Carto podem ter notas,
estimativas, comentrio observaes e etc
Conversas: Detalhes que podem surgir durante as
conversas com PO (Product Owner) e/ou cliente.
Confirmao: Testes de aceitao confirmam se

a Estria do Usurio foi codificada da forma correta.
Testes de aceitao so tipo Caixa Preta.
Boa Prtica: A Estria do Usurio deve prover o entendimento do que deve ser feito e deve facilitar a estimativa
de velocidade da equipe.
107

Detalhando as Estrias do Usurio em Tarefas:
Estria do Usurio

planejamento.
Prioridade: Alta
Pontos: ?
Tarefas de Negcio
Fazer Reserva
de Apartamentos
Devemos buscar meios para facilitar

a estimativa de velocidade da
equipe, quebrar a estria do usurio
em tarefas pode fazer que todos os
membros da equipe visualizem todas
as tarefas que devem ser feitas para
implementar a Estria do Usurio.
Testes de aceitao devem ser
escritos para detalhar melhor a
estria do usurio, geralmente eles
so escritos no verso do carto.
Tarefas Tcnicas
Consulta de
Reserva de
Apartamento
Criar
Interfaces
Do Usurio
Cadastro de
Fila de Espera
Criar
Tabelas
Cadastro de
Cliente
Executar
testes
unitrios
Confirmao
da Reserva
Executar
testes de
aceitao
108
Estimativa e o Planning Poker:

Para fazer estimativa de velocidade da equipe ou de durao da Sprint, antes preciso o escrever as
estrias do usurio.
O Planning Poker uma prtica que ajuda na estimativa de uma estria ou de uma tarefa e baseada
no consenso de toda a equipe.
Geralmente o Planning Poker usa um conjunto de cartas com valores especficos que
podem representar pontos relativos e praticado como se fosse um jogo de cartas. Os
pontos devem estar em uma escala no linear, por e exemplo a Fibonacci:
(1,2,3,5,8,13,...) + 20, 40, 100 ou em outra escala
Jogando o Planning Poker:
Antes de comear o jogo necessrio definir um valor de referncia. Por exemplo: Identificar a estria
que pode ser atribudo a menor quantidade pontos, esta estria ser utilizada como referncia para
pontuao das demais estrias.
O PO apresenta uma estria e pede para os membros da equipe fazer a estimativa de velocidade...
1. Rodada
40
100
Pessoal, qual
estimativa para
essa estria...
40
40
Product Owner
Quando todas as cartas

estiverem lanadas, elas
so viradas e caso no
haja consenso nos
pontos, as diferenas so
discutidas de forma
breve, e uma nova
rodada acontece at que
haja concesso entre os
membros da equipe.
Equipe
Ensima Rodada
40
40
40
40
Equipe
109
Estria do Usurio

planejamento.
Prioridade: Alta
Pontos: 40
Tarefas de Negcio
Fazer Reserva
de Apartamentos
Planning Poker, Estria do Usurio

e Pontos de Estria, nada disto faz
parte do framework Scrum,
contudo, so tcnicas e ferramentas
complementares ao framework.
Elas so utilizadas para ajudar na
estimativa de velocidade da equipe.
E finalmente temos a Sprint
Backlog, mas antes de fazermos o
Sprint Burndown, devemos fazer a
definio de Pronto.
Tarefas Tcnicas
Consulta de
Reserva de
Apartamento
Criar
Interfaces
Do Usurio
Cadastro de
Fila de Espera
Criar
Tabelas
Cadastro de
Cliente
Executar
testes
unitrios
Confirmao
da Reserva
Executar
testes de
aceitao
Sprint Backlog
A Sprint Backlog todo trabalho que a

equipe identifica como necessrio para
alcanar a Meta da Sprint.
110

Definio de Pronto:
Scrum exige que a equipe desenvolva um incremento de funcionalidade do produto a cada
Sprint. Esse incremento deve ser potencialmente entregvel, pois o Product Owner (PO) pode
optar por implantar a funcionalidade imediatamente. Para isso ser possvel, o incremento deve ser um
pedao completo do produto. Ele deve estar pronto. Cada incremento deve ser adicionado a todos
os incrementos anteriores e exaustivamente testado, garantindo que todos os incrementos funcionem
juntos.
Uma conversa comum entre o cliente e o desenvolvedor:
[Cliente] E a como anda o desenvolvimento da aplicao ?
[Desenvolvedor] Est pronta...
[Cliente] Isso quer dizer que eu posso implementa-la ?
[Desenvolvedor] Bem...ainda no, preciso fazer mais alguns testes...
[Cliente] Mas, aplicao no est pronta..
Definir claramente quando o produto estar pronto,

pois:
Pronto, para desenvolvedor significa:
- Encerrou a codificao...
Pronto, para PO significa:
- Quando foi entregue...
Pronto, para os usurios finais e/ou clientes significa:
- Quando o software comeou a funcionar em ambiente
de produo...
Equipe SCRUM: Definiu que o pronto software rodando em ambiente de produo.

111

A transparncia, que dos pilares do Scrum, ela garante que aspectos do processo que afetam
o resultado sejam visveis para aqueles que gerenciam os resultados. O Quadro de Tarefas deixa a
Sprint com visibilidade e transparncia necessria. Entretanto, o Quadro de Tarefas para o uso
exclusiva da equipe, que responsvel pela sua atualizao.
Task Board (Quadro de Tarefas)

Para Fazer
Fazendo
Pronto
Sprint Burndown
Consulta de
Reserva de
Apartamento
Pontos
40
Cadastro de
Fila de Espera
30
20
Cadastro de
Cliente
10
Confirmao
da Reserva
Semanas
Meta da Sprint
Entregar a funcionalidade de
reserva de apartamentos em
30 dias.
112
113

Esclarecendo algumas dvidas:
Por que 40 pontos em uma Sprint de 30 dias ?

a primeira vez que a equipe utiliza o SCRUM para o desenvolver
um software, logo ela no tem experincia e nem histrico de
velocidade de desenvolvimento, que possa ser usado para definir a
quantidade de tempo que ela levar para fazer 40 pontos.
Para no correr riscos, a equipe optou por trabalhar com uma folga.
Com o decorrer das Sprints e novos projetos ser possvel calibrar
melhor a velocidade da equipe.
O Quadro de Tarefas importante ?
O Quadro de Tarefas (Task Board) tambm no parte do

Framework Scrum, ele parte de uma tcnica chamada Gesto
Vista, que tem como objetivo facilitar a comunicao e dar
transparncia (visibilidade). Lembre-se que a transparncia um
dos pilares do SCRUM.
Qual a durao em dias recomendvel quando uma equipe
comea a trabalhar com Scrum ?
Quando uma equipe comea com o Scrum, Sprints de duas
semanas o permite aprender sem cair nas armadilhas da incerteza.
114

Exerccio:
O que aconteceria se a equipe considerar que o item do Product Baclog: Os clientes podero
fazer reserva de apartamentos um pico ?
115
Estudo de Caso: Reunio Diria
Quarto passo: Aps a reunio de Reunio de Planejamento da Sprint, efetivamente a Sprint

comea, o prxima passo so as Reunies Dirias.
Planejamento
da Release
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Produto
Backlog
Sprint
Backlog
Sprint
2-4 Semanas
Produto
Viso
4
116
A equipe deve se encontrar diariamente para uma reunio de 15 minutos chamada Reunio
Diria. Essa reunio sempre feita com as pessoas de p, no mesmo horrio e no mesmo local
durante as Sprints.
Durante a reunio, cada deve membro explicar:

1. O que foi realizado desde a ltima reunio diria;
2. O que vai ser feito antes da prxima reunio diria;
3. Foi encontrado algum obstculo (impedimento).
As Reunies Dirias melhoram a comunicao, eliminam outras reunies, identificam e
removem impedimentos para o desenvolvimento, ressaltam e promovem a
tomada rpida de decises e aperfeioa o nvel de conhecimento de todos
acerca do projeto.
O ScrumMaster responsvel por garantir que a equipe realize essa reunio.
Contudo, a prpria equipe responsvel por conduzir a reunio. O ScrumMaster deve
orientar a equipe a manter a Reunio Diria com curta durao (15 minutos), reforando
as regras e assegurando que as pessoas falem brevemente. O ScrumMaster
tambm enfatiza a regra de que as pessoas que no participam da equipe no podem
SCRUM Master
atrapalhar e nem a interferir de modo algum a reunio. Ela s para as pessoas que
esto transformando os itens do Product Backlog um incremento (produto), e para
mais ningum.
A Reunio Diria no uma reunio de status. A equipe se comprometeu com a Meta da Sprint,
e os itens do Product Backlog. A Reunio Diria uma inspeo do progresso na direo da
Meta da Sprint (as trs perguntas).
Geralmente acontecem reunies subsequentes para realizar adaptaes ao trabalho que est por vir
na Sprint. A inteno otimizar a probabilidade de que a equipe alcance sua Meta. Essa uma reunio
fundamental de inspeo e adaptao no processo emprico do Scrum.
117
Na primeira reunio a Equipe decide qual tarefa vai ser feita primeiro. Aps a escolha da tarefa
o Task Board (Quadro de Tarefas) atualizado.
Consulta de
Reserva de
Apartamento
OK
OK
OK
Equipe
SCRUM Master
Questes:
3. Foi encontrado algum obstculo.
15 Minutos
118
As reunio se repetem ao longo dos dias e a cada reunio a Task Board atualizado (as tarefas e
Sprint Burndown).
O que vai ser feito antes da

prxima reunio diria?
Comear a tarefa
Cadastro de Cliente
O que foi feito desde a

ltima reunio diria ?
Terminamos a tarefa
Consulta de Reserva
de Apartamentos...
OK
Foi encontrado
algum obstculo ?
No
OK
Movimentao
do post-it para
a coluna: Pronto
Atualizao do Sprint
Burndown
Equipe
SCRUM Master
Questes:
15 Minutos
119
Durante as reunies dirias todos os impedimentos (ou obstculos) identificados so registrados no

Quadro de Tarefas. Eles representam um risco a Sprint. O Risco de no se atingir a meta, logo eles devem
ser removidos. Geralmente os impedimentos so escritos em Post it de cor rosa.
15 Minutos
OK
OK
OK
Equipe
SCRUM Master
Encontrei um
obstculo
(impedimento).
Questes:
120
Estudo de Caso: Impedimento
Cabe ao SCRUM Master remover todos os impedimentos, identificados e demonstrados no Quadro de

Tarefas, para que estes no afetem o desempenho da equipe nem a meta da Sprint. Caso contrrio, o
impedimento poder comprometer a meta e a entrega de valor que deve ocorrer no final da Sprint.
O que um impedimento ?
Impedimento tudo aquilo que
impede a equipe de realizar seu
trabalho e atingir a meta da
Sprint.
Um impedimento pode ser um
problema de rede, falhas no
servidor, falta de servidor para
testes, a lentido do banco de
dados do ambiente de teste ou
falta de informao para
implementao de uma tarefa.
SCRUM Master
SCRUM Master
dever remover este
impedimento
Aps remoo do impedimento o SCRUM podemos registrar em

base de conhecimento a causa raiz do impedimento, esta
informao dever ser utilizada para melhorar o processo, logo ser
discutida na Retrospectiva da Sprint.
121

Quando todas as tarefas esto prontas, e a Equipe atualiza o Quadro de Tarefas e o Sprint
Burndown.
15 Minutos
OK
OK
OK
OK
Equipe
SCRUM Master
122
123
Reunio de Planejamento da Sprint

Exerccio:
O que pode acontecer se um impedimento no for removido ?
Quem pode cancelar a Sprint ?
124
Estudo de Caso: Reunio de Reviso da Sprint
Quinto passo: Aps o final da Sprint (quando todas as tarefas esto prontas) comea a Reunio de
Reviso da Sprint. Objetivo primrio desta reunio apresentar ao PO que foi feito durante a
Sprint.
Planejamento
da Release
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Produto
Backlog
Sprint
Backlog
Sprint
2-4 Semanas
Produto
Viso
5
125
Reviso da Sprint:
Reunio da Reviso da Sprint
Produto pronto
OK
Product
Owner
OK
4 horas
OK
Equipe
SCRUM Master
Equipe apresenta que foi produzido e faz entrega para PO, que avalia o valor da entrega. PO
poder aceitar ou rejeitar a entrega do produto.
126
Reunio de Reviso da Sprint

A Reunio de Reviso da Sprint, para Sprints de 1 ms, essa
uma reunio com durao fixa de 4 horas. Para Sprints de
duraes mais curtas, essa reunio no deve tomar mais do que
5% do total da Sprint. Durante a Reviso da Sprint, a Equipe
Scrum e as partes interessadas colaboram sobre o que
acabou de ser feito.
Baseados nisso e em mudanas no Product Backlog feitas
durante a Sprint, eles colaboram sobre quais so as prximas
coisas que podem ser feitas. Essa uma reunio informal,
com a apresentao da funcionalidade, que tem a inteno de
promover a colaborao sobre o que fazer em seguida.
O Product Owner identifica o que foi feito e o que no foi feito. A
equipe discute sobre o que correu bem durante a Sprint e quais
problemas foram enfrentados, alm de como esses problemas
foram resolvidos. A equipe ento demonstra o trabalho que est
pronto e responde a questionamentos. O Product Owner
ento discute o Product Backlog da maneira como esse se
encontra.
Ele faz projees de datas de concluso provveis a partir de
vrias hipteses de velocidade. Em seguida, o grupo inteiro
colabora sobre o que foi visto e o que isso significa com relao
ao que fazer em seguida. A Reviso da Sprint fornece
entradas valiosas para as reunies de Planejamento de Sprints
seguintes.
127
O Release Burndown atualizado.

Lembre-se: O Release Burndown registra a soma das estimativas dos esforos restantes do Product
Backlog ao longo do tempo. O esforo estimado deve estar em qualquer unidade de medida de trabalho
que a equipe e a organizao tenham decidido usar. As unidades de tempo geralmente so Sprints.
128
Product Backlog atualizado.

Lembrem: PO responsvel por manter atualizado Release Burndown e Product Backlog.
129
Quadro de Viso do Projeto(Produto)
Objetivo deste quadro mostrar de forma transparente as informaes e andamento do projeto no

contexto do produto.
Este quadro a principal ferramenta de gesto do Product Owner

131
Estudo de Caso: Reunio de Reviso da Sprint
132

Exerccio:
O que aconteceria se PO no aceitasse a entrega ?
Podemos considerar que a entrega da Sprint foi feita mesmo que ela no esteja em conformidade
com a definio de Pronto ?
133
Reunio de Retrospectiva da Sprint
Sexto passo: Aps a reunio de Reunio de Reviso da Sprint, realizada a Reunio de

Retrospectiva da Sprint. O propsito desta reunio inspecionar como correu a ltima Sprint em se
tratando de pessoas, das relaes entre elas, dos processos e das ferramentas.
Planejamento
da Release
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Produto
Backlog
Sprint
Backlog
Sprint
2-4 Semanas
Produto
Viso
6
134
Reunio Retrospectiva da Sprint
impedimentos
As retrospectivas so a essncia do conceito de Inspeo e Adaptao.
Problemas no
Servidor de Teste
SCRUM Master
????
Velocidade da
equipe...
Equipe
3 horas
Equipe discute o qu deu errado e o qu deu certo... O que precisa ser melhorado para a prxima
Sprint
135
Reunio de Retrospectiva da Sprint:
A Reunio de Retrospectiva da Sprint a ltima reunio

de uma Sprint.
Nessa reunio, com durao fixa de 3 horas, o
ScrumMaster deve encorajar a equipe a revisar, dentro
do modelo de trabalho e das prticas do processo do
Scrum, seu processo de desenvolvimento, de forma a
torn-lo mais eficaz e gratificante para a prxima
Sprint. Existem diversas tcnicas que so teis em uma
Retrospectiva (por ser um framework Scrum no indica
diretamente nenhuma tcnica)
A finalidade da Retrospectiva inspecionar como foi a
ltima Sprint em se tratando de pessoas, das relaes
entre elas, dos processos e das ferramentas. A inspeo
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. Isso inclui a composio da equipe, os
preparativos para reunies, ferramentas, definio de
pronto, mtodos de comunicao e processos para
transformar itens do Product Backlog em alguma coisa
pronta.
No final da Retrospectiva da Sprint, a equipe Scrum deve
ter identificado as aes de melhoria factveis que ser
implementada na prxima Sprint. Essas mudanas se
tornam a adaptao para a inspeo emprica.
136
Lies Aprendidas, o que deve melhorado para a prxima Sprint:
OK
Consulta de
Reserva de
Apartamento
Velocidade da equipe
=
Atitude:
Para uma equipe (time) SCRUM
funcionar ser necessrio
mudana de atitude, caso
contrrio isto poder afetar
o desempenho da equipe
Cadastro de
Fila de Espera
Cadastro de
Cliente
Confirmao
da Reserva
O Que Deve
Ser Melhorado
Pontos de
Ateno
Impedimentos:
Ser necessrio mais

ateno na hora de
estimar as estrias do
usurio.
Problemas no
Servidor de Teste
Planejamento:
Prestar ateno na hora do
planejamento da Sprint, para
identificar se todos os recursos
necessrio esto disponveis
137
Reunio de Retrospectiva da Sprint
138
Comear nova iterao (nova Sprint)
Repetir o ciclo Scrum:
Planejamento
da Release
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Produto
Backlog
Sprint
Backlog
Sprint
2-4 Semanas
Produto
Viso
139

Exerccio:
O PO deve participar da Reunio de Retrospectiva da Sprint ?
Durante este estudo de caso no foi apresentado as prticas e ferramentas de Engenharia de

Software, tais como TDD, SCM e etc, explique o motivo:
140
Quer mais ?
Os membros da comunidade podem participar dos eventos, treinamentos e cursos gratuitos.

Comunidade: http://etecnologia.ning.com/
Para participar da comunidade basta se cadastrar: http://bit.ly/czZlez

A misso da comunidade compartilhar conhecimento, trocar experincias e prover
aprendizado.
141
Referncias
Scrum Guide
Agile Collection (SCRUM, FDD e XP) nova verso
1 Scrum Experience [O Tutorial SCRUM]

- Tutorial SCRUM, demonstra as prticas SCRUM para o gerenciamento de projetos
de software.
2 SCRUM Product Owner:
- Este eBook descreve o SCRUM enfatizando a atuao do Product Owner.
apresentado responsabilidades, tcnicas e ferramentas que so utilizadas pelo PO
para a garantir o ROI na gesto de projetos g...
3 Engenharia de Software 100% Agil (SCRUM, FDD e XP)
- Esta apresentao faz uma demonstrao de como combinar os mtodos geis:
SCRUM, FDD e XP para tornar o Ciclo de Desenvolvimento de Software gil, ou
seja, a Engenharia de Software 100% gil.
4 Engenharia de Software gil: SCRUM e FDD
- SCRUM e o FDD so Mtodos geis que so utilizados para desenvolvimento de
software. Fizemos uma pequena demonstrao de como utilizar o SCRUM e FDD
(Featured Driven Development)
5 Escrevendo Estrias do Usurio Eficazes
- Este tutorial demonstra como "escrever as estrias do usurio de forma eficaz."
tambm apresentado as principais tcnicas, boas prticas e ferramentas.
6 Workshop Como Criar, Estimar, Priorizar e Manter o Product Backlog

- Este tutorial demonstra como usar as melhores prticas e tcnicas para "Como
criar, estimar, priorizar e manter o Product Backlog".
7 Workshop SCRUM Product Owner - Delrio de PO em dia de Vero
Esta apresentao sobre o SCRUM Product Owner que aborda prticas, ferramentas
e responsabilidades do PO. Tambm demonstrado como os "delrios" do PO pode
afetar negativamente os membros da equipe e o resultado do projeto.
142
Licena:
143
Notas:
Marcas Registradas:
Todos os termos mencionados que so reconhecidos como Marca Registrada e/ou comercial so de
responsabilidades de seus proprietrios. O autor informa no estar associada a nenhum produto e/ou
fornecedor que apresentado neste material. No decorrer deste, imagens, nomes de produtos e
fabricantes podem ter sido utilizados, e desde j o autor informa que o uso apenas ilustrativo para fins
educativo, no visando ao lucro, favorecimento ou desmerecimento da marca ou produto.
Melhoria e Reviso:
Este material esta em processo constante de reviso e melhoria, se voc encontrou algum problema
ou erro envie um e-mail para ns.
Criticas e Sugestes:
Ns estamos abertos para receber criticas e sugestes que possam melhorar o material, por favor
envie um e-mail para ns.
Imagens:
Google, Flickr e Banco de Imagem.
Rildo F dos Santos (rildo.santos@etecnologia.com.br)

144
O Tutorial
Definitivo
www.etcnologia.com.br
Rildo F Santos
(11) 9123-5358
(11) 9962-4260
twitter: @rildosan
skype: rildo.f.santos
http://rildosan.blogspot.com/

Tutorial SCRUM v4

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tutorial SCRUM v4

Uploaded by

Copyright:

Available Formats

SCRUM, O Tutorial Definitivo

verso 4 | Jun 2013

Rildo Santos (@rildosan)

Verso 4 Jun 2013 | RFS

Todos os direitos reservados e protegidos 2006 e 2013

SCRUM, O Tutorial Definitivo

Programa: Menos Papel, Mais rvores

Qual o mundo que queremos ?

Para cumprir esta misso necessrio: conscientizar, comprometer e AGIR.

O programa Menos Papel, Mais rvores, uma ao, com objetivo de

Verso 4 Jun 2013 | RFS

Todos os direitos reservados e protegidos 2006 e 2013

SCRUM, O Tutorial Definitivo

Todos os direitos reservados e protegidos 2006 e 2013

SCRUM, O Tutorial Definitivo

1 Desafios do desenvolvimento de Software

Todos os direitos reservados e protegidos 2006 e 2013

Facilitador: Rildo F. Santos (@rildosan)

SCRUM, O Tutorial Definitivo

Verso 4 Jun 2013 | RFS

Todos os direitos reservados e protegidos 2006 e 2013

SCRUM, O Tutorial Definitivo

1 Desafios do desenvolvimento de Software

Todos os direitos reservados e protegidos 2006 e 2013

SCRUM, O Tutorial Definitivo

Parte 1 - Desafios do desenvolvimento de Software

Todos os direitos reservados e protegidos 2006 e 2013

SCRUM, O Tutorial Definitivo

Todos os direitos reservados e protegidos 2006 e 2013

SCRUM, O Tutorial Definitivo

1. Desafio: Responder ao cliente

Verso 4 Jun 2013 | RFS

Todos os direitos reservados e protegidos 2006 e 2013

SCRUM, O Tutorial Definitivo

2. Desafio: Falha na Comunicao das equipes de TI

Verso 4 Jun 2013 | RFS

Todos os direitos reservados e protegidos 2006 e 2013

SCRUM, O Tutorial Definitivo

3. Desafio: Entender as necessidades dos clientes

Quando no se entende as necessidades dos clientes, no se pode entregar valor ao cliente.

Todos os direitos reservados e protegidos 2006 e 2013

4. Desafio: Compreender por que os projetos falham:

SCRUM, O Tutorial Definitivo

37% das falhas esto

Verso 4 Jun 2013 | RFS

Todos os direitos reservados e protegidos 2006 e 2013

5. Desafio: Identificar o que necessidade e o que desejo

SCRUM, O Tutorial Definitivo

Uso de funcionalidades do Software

Verso 4 Jun 2013 | RFS

Todos os direitos reservados e protegidos 2006 e 2013

6. Desafio: Aumentar produtividade da equipe de desenvolvimento:

SCRUM, O Tutorial Definitivo

Satisfao dos Clientes

Como aumentar a produtividade da equipe

Verso 4 Jun 2013 | RFS

Todos os direitos reservados e protegidos 2006 e 2013

A falta de produtividade pode afetar o negcio

SCRUM, O Tutorial Definitivo

Mas, ser que a contratao

The Mythical Man Month by Frederick Brooks, 1975*.

Todos os direitos reservados e protegidos 2006 e 2013

7. Desafio: Escolher framework certo para desenvolver software ?

SCRUM, O Tutorial Definitivo