You are on page 1of 144

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

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

SCRUM, O Tutorial Definitivo

Contedo:

1 Desafios do desenvolvimento de Software


2 Sobre o SCRUM
3 Entendendo SCRUM
4 Estudo de Caso
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

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.

SCRUM, O Tutorial Definitivo

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

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

SCRUM, O Tutorial Definitivo

Contedo:

1 Desafios do desenvolvimento de Software


2 Sobre o SCRUM
3 Entendendo SCRUM
4 Estudo de Caso
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

SCRUM, O Tutorial Definitivo

Desafios do Desenvolvimento
de Software
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

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

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

10

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.


Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

11

4. Desafio: Compreender por que os projetos falham:

SCRUM, O Tutorial Definitivo

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)

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

12

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

SCRUM, O Tutorial Definitivo

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)

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

13

6. Desafio: Aumentar produtividade da equipe de desenvolvimento:

SCRUM, O Tutorial Definitivo

Satisfao dos Clientes

Como aumentar a produtividade da equipe


de desenvolvimento de software ?

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

14

A falta de produtividade pode afetar o negcio


Qual a soluo ?
Contratar mais desenvolvedores...

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

15

7. Desafio: Escolher framework certo para desenvolver software ?

SCRUM,
Lean,
Kanban,
XP...

SCRUM, O Tutorial Definitivo

Cascata

RUP

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

16

8. Desafio: Como reter os bons profissionais ?

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

17

Por que precisamos dos Mtodos geis ?

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

18

Cliente x Desenvolvedores:

SCRUM, O Tutorial Definitivo

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

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

19

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

20

SCRUM, O Tutorial Definitivo

Contedo:

1 Desafios do desenvolvimento de Software


2 Sobre o SCRUM
3 Entendendo SCRUM
4 Estudo de Caso
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

21

SCRUM, O Tutorial Definitivo

Objetivo:

Parte 2 Sobre SCRUM:


Objetivo:
Apresentar Manifesto gil e o SCRUM, as principais caractersticas e prticas.
Pr-requisito:
No h.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

22

SCRUM, O Tutorial Definitivo

Parte 2

Sobre o SCRUM
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

23

As Razes do Scrum:
TimeBoxes

SCRUM, O Tutorial Definitivo

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

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

24

O que TimeBox ?

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

25

Abordagem Iterativo e Incremental:


Entrega 1

Entrega 2

Entrega 3

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

26

O qual propsito do SCRUM ?


Scrum vem sendo utilizado para o desenvolvimento de
produtos complexos desde o incio dos anos 90.

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

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

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

28

Os pilares do SCRUM:

SCRUM, O Tutorial Definitivo

Trs pilares sustentam qualquer implementao de controle de processos empricos.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

29

Os pilares do SCRUM:
Trs pilares sustentam qualquer implementao de controle de processos empricos.

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

30

Os pilares do SCRUM:

SCRUM, O Tutorial Definitivo

Trs pilares sustentam qualquer implementao de controle de processos empricos.


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.

Verso 4 Jun 2013 | RFS

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.

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

31

SCRUM, O Tutorial Definitivo

O Manifesto gil:

O SCRUM um Metodo gil


Fonte: http://agilemanifesto.org/iso/ptbr/

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

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.

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

33

Como Ser gil ?


Como ser gil ?
1 - Para ser gil preciso colocar em prtica os valores e os princpios do Manifesto gil.

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

34

Como Ser gil ?


Como ser gil ?

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

35

SCRUM, O Tutorial Definitivo

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).
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

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

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

37

As Caractersticas da Equipe:
Como ser gil ?

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

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.

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

39

SCRUM, O Tutorial Definitivo

Algumas empresas que esto usando SCRUM:

Quais empresas esto utilizando o


SCRUM?

Algumas empresas brasileiras

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

40

Exerccio
Leia o texto e complete a lacuna (no ltimo paragrafo):
O processo de captao de talentos no futebol:

SCRUM, O Tutorial Definitivo

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

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

41

SCRUM, O Tutorial Definitivo

Contedo:

1 Desafios do desenvolvimento de Software


2 Sobre o SCRUM
3 Entendendo SCRUM
4 Estudo de Caso
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

42

SCRUM, O Tutorial Definitivo

Objetivo:

Parte 3 Entendendo SCRUM


Objetivo:
Apresentar de forma detalhada o framework SCRUM segundo o Guia do Scrum.
Pr-requisito:
No h.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

43

SCRUM, O Tutorial Definitivo

Parte 3

Entendendo o SCRUM
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

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

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

45

SCRUM, O Tutorial Definitivo

Framework Scrum: Eventos de Durao Fixa:

Regras
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

46

Framework Scrum: Regras

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

47

SCRUM, O Tutorial Definitivo

Framework Scrum: Papis e Equipe

Papis e Equipe
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

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:

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

49

A Equipe SCRUM: ScrumMaster (SM) e Product Owner (PO):

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

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 .

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

51

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

52

SCRUM, O Tutorial Definitivo

Framework Scrum: Eventos de Durao Fixa:

Eventos
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

53

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

Produto

Sprint Backlog
rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

54

Framework Scrum: Eventos de Durao Fixa:

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

55

Framework Scrum: Eventos de Durao Fixa:

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

6
Todos os direitos reservados e protegidos 2006 e 2013

56

Framework Scrum: Eventos de Durao Fixa:

SCRUM, O Tutorial Definitivo

Planejamento
da Sprint

Reunio
diria

Reviso
da Sprint

Retrospectiva
da Sprint

24 horas
Viso

Produto
Backlog

Sprint
Backlog
Sprint
2-4 Semanas

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Produto

Todos os direitos reservados e protegidos 2006 e 2013

57

SCRUM, O Tutorial Definitivo

Framework Scrum: Eventos de Durao Fixa:


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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

58

SCRUM, O Tutorial Definitivo

Framework Scrum: Eventos de Durao Fixa:


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


Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

59

SCRUM, O Tutorial Definitivo

Framework Scrum: Eventos de Durao Fixa:

Planejamento
da Sprint

Reunio
diria

Reviso
da Sprint

Retrospectiva
da Sprint

24 horas
Viso

Produto
Backlog

Sprint
Backlog
Produto
Sprint
2-4 Semanas

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

60

SCRUM, O Tutorial Definitivo

Framework Scrum: Eventos de Durao Fixa:


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


Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

61

SCRUM, O Tutorial Definitivo

Framework Scrum: Eventos de Durao Fixa:

Planejamento
da Sprint

Reunio
diria

Reviso
da Sprint

Retrospectiva
da Sprint

24 horas
Viso

Produto
Backlog

Sprint
Backlog
Produto
Sprint
2-4 Semanas

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

62

Framework Scrum: Eventos de Durao Fixa:

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

63

SCRUM, O Tutorial Definitivo

Framework Scrum: Eventos de Durao Fixa:

Planejamento
da Sprint

Reunio
diria

Reviso
da Sprint

Retrospectiva
da Sprint

24 horas
Viso

Produto
Backlog

Sprint
Backlog
Produto
Sprint
2-4 Semanas

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

64

Framework Scrum: Eventos de Durao Fixa:

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

65

SCRUM, O Tutorial Definitivo

Framework Scrum: Eventos de Durao Fixa:

Planejamento
da Sprint

Reunio
diria

Reviso
da Sprint

Retrospectiva
da Sprint

24 horas
Viso

Produto
Backlog

Sprint
Backlog
Produto
Sprint
2-4 Semanas

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

66

Framework Scrum: Eventos de Durao Fixa:


RETROSPECTIVA DA SPRINT

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

67

SCRUM, O Tutorial Definitivo

Framework Scrum: Artefatos

Artefatos
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

68

SCRUM, O Tutorial Definitivo

Framework Scrum: Artefatos

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

69

Framework Scrum: Artefatos

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

70

Framework Scrum: Artefatos

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

71

Framework Scrum: Artefatos


PRODUCT BACKLOG: Exemplo

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

72

Framework Scrum: Artefatos


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)

SCRUM, O Tutorial Definitivo

150

90

50

52

20
0

Sprint #1

Sprint #2

Sprint #13

Sprint #4

Sprints

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

73

Framework Scrum: Artefatos


SPRINT BACKLOG E SPRINT BURNDOWN:

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

74

Framework Scrum: Artefatos

SCRUM, O Tutorial Definitivo

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: ?

Verso 4 Jun 2013 | RFS

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

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

75

Framework Scrum: Artefatos


SPRINT BACKLOG E SPRINT BURNDOWN: Exemplo

Estria do Usurio

SCRUM, O Tutorial Definitivo

Titulo: Fazer Check-in

Como cliente de negcio, eu quero fazer check-in


pela web para que fique menos tempo em filas.
Pontos: ?

Prioridade: Alta

Fazer
interface
do usurio

Fazer Check-in

Verso 4 Jun 2013 | RFS

Impresso
do Ticket

Criar
Componentes
de validao

Executar
testes
unitrios

Integrar
com Sistema
de Reserva

Executar
testes de
aceitao

rildo.santos@etecnologia.com.br

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
Todos os direitos reservados e protegidos 2006 e 2013

76

Estimando os pontos da Estria do Usurio:


Uma breve introduo sobre estimativa:

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

77

Estimando os pontos da Estria do Usurio:


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.

SCRUM, O Tutorial Definitivo

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).

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

78

Estimando os pontos da Estria do Usurio:

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

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
rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

79

Framework Scrum: Artefatos


SPRINT BACKLOG: Exemplo

Estria do Usurio

SCRUM, O Tutorial Definitivo

Titulo: Fazer Check-in

Como cliente de negcio, eu quero fazer check-in


pela web para que fique menos tempo em filas.
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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

80

Framework Scrum: Artefatos

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

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.

Todos os direitos reservados e protegidos 2006 e 2013

81

Framework Scrum: Artefatos


SPRINT BURNDOWN : Exemplo

SCRUM, O Tutorial Definitivo

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).

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

82

SCRUM, O Tutorial Definitivo

Framework Scrum: Definio de Pronto

Pronto
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

83

Definio de Pronto (*DoD):


Uma conversa comum entre o cliente e o desenvolvedor:

SCRUM, O Tutorial Definitivo

[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).


Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

84

Framework Scrum: Definio de Pronto

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

85

Framework Scrum: Definio de Pronto

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

86

Exerccios:
Responda Verdadeiro ou Falso para as declaraes:

SCRUM, O Tutorial Definitivo

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

Verso 4 Jun 2013 | RFS

] Falso
rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

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.

SCRUM, O Tutorial Definitivo

] 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

Verso 4 Jun 2013 | RFS

] Falso
rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

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.

SCRUM, O Tutorial Definitivo

] 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

Verso 4 Jun 2013 | RFS

] Falso

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

89

SCRUM, O Tutorial Definitivo

Contedo:

1 Desafios do desenvolvimento de Software


2 Sobre o SCRUM
3 Entendendo SCRUM
4 Estudo de Caso
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

90

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

91

SCRUM, O Tutorial Definitivo

Estudo de Caso

Estudo de Caso
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

92

Framework SCRUM

SCRUM, O Tutorial Definitivo

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)

Verso 4 Jun 2013 | RFS

Planejamento da Release
Planejamento da Sprint
Diria
Reviso da Sprint
Retrospectiva da Sprint

Product Backlog
Sprint Backlog
Sprint Burndown
Release Burndown

rildo.santos@etecnologia.com.br

Sprint Burndown
Release Burndown

Todos os direitos reservados e protegidos 2006 e 2013

93

Estudo de Caso: Viso

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

94

Estudo de Caso: Viso do Produto


Para definir a viso do Produto, primeiro necessrio entender qual a real necessidade do cliente:

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

95

Estudo de Caso: Viso do Produto

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

96

SCRUM, O Tutorial Definitivo

Estudo de Caso: Viso do Produto

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

97

Estudo de Caso: Viso do Produto


Exerccio:

SCRUM, O Tutorial Definitivo

Podemos fazer a declarao da Viso do Produto sem entender a real necessidade do cliente ?

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

98

Estudo de Caso: Reunio de Planejamento da Release

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

99

SCRUM, O Tutorial Definitivo

Estudo de Caso: Reunio de Planejamento da Release


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

Verso 4 Jun 2013 | RFS

Plano de Release

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

100

Estudo de Caso: Reunio de Planejamento da Release

SCRUM, O Tutorial Definitivo

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

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

101

Estudo de Caso: Reunio de Planejamento da Release

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)

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

102

SCRUM, O Tutorial Definitivo

Estudo de Caso: Reunio de Planejamento da Release

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

103

Estudo de Caso: Reunio de Planejamento da Release


Exerccio:

SCRUM, O Tutorial Definitivo

O que aconteceria se a equipe SCRUM no fizer a Reunio de Planejamento da Release ?

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

104

Estudo de Caso: Reunio de Planejamento da Sprint

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

105

Estudo de Caso: Reunio de Planejamento da Sprint

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

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

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

106

Estudo de Caso: Reunio de Planejamento da Sprint

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

107

Estudo de Caso: Reunio de Planejamento da Sprint


Detalhando as Estrias do Usurio em Tarefas:

Estria do Usurio
Titulo: Fazer Reserva de Apartamentos
Como cliente de negcio, eu quero fazer reserva de

SCRUM, O Tutorial Definitivo

apartamentos pela web para facilitar o meu


planejamento.
Prioridade: Alta

Pontos: ?

Tarefas de Negcio

Fazer Reserva
de Apartamentos

Verso 4 Jun 2013 | RFS

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

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

108

Estudo de Caso: Reunio de Planejamento da Sprint

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

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
rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

109

Estudo de Caso: Reunio de Planejamento da Sprint

Estria do Usurio
Titulo: Fazer Reserva de Apartamentos

SCRUM, O Tutorial Definitivo

Como cliente de negcio, eu quero fazer reserva de


apartamentos pela web para facilitar o meu

planejamento.
Prioridade: Alta

Pontos: 40

Tarefas de Negcio

Fazer Reserva
de Apartamentos

Verso 4 Jun 2013 | RFS

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

rildo.santos@etecnologia.com.br

Sprint Backlog

A Sprint Backlog todo trabalho que a


equipe identifica como necessrio para
alcanar a Meta da Sprint.
Todos os direitos reservados e protegidos 2006 e 2013

110

SCRUM, O Tutorial Definitivo

Estudo de Caso: Reunio de Planejamento da Sprint


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.


Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

111

Estudo de Caso: Reunio de Planejamento da Sprint


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.

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

112

SCRUM, O Tutorial Definitivo

Estudo de Caso: Reunio de Planejamento da Sprint

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

113

Estudo de Caso: Reunio de Planejamento da Sprint


Esclarecendo algumas dvidas:

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

114

Estudo de Caso: Reunio de Planejamento da Sprint


Exerccio:

SCRUM, O Tutorial Definitivo

O que aconteceria se a equipe considerar que o item do Product Baclog: Os clientes podero
fazer reserva de apartamentos um pico ?

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

115

Estudo de Caso: Reunio Diria

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

116

Estudo de Caso: Reunio Diria

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

117

Estudo de Caso: Reunio Diria

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

Questes:
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.
rildo.santos@etecnologia.com.br

15 Minutos
Todos os direitos reservados e protegidos 2006 e 2013

118

Estudo de Caso: Reunio Diria

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

Questes:
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.
rildo.santos@etecnologia.com.br

15 Minutos
Todos os direitos reservados e protegidos 2006 e 2013

119

Estudo de Caso: Reunio Diria

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

Encontrei um
obstculo
(impedimento).

Questes:
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.
rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

120

Estudo de Caso: Impedimento

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

121

Estudo de Caso: Reunio Diria


Quando todas as tarefas esto prontas, e a Equipe atualiza o Quadro de Tarefas e o Sprint
Burndown.

SCRUM, O Tutorial Definitivo

15 Minutos

OK

OK

OK

OK

Equipe

SCRUM Master
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

122

SCRUM, O Tutorial Definitivo

Estudo de Caso: Reunio Diria

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

123

Reunio de Planejamento da Sprint


Exerccio:

SCRUM, O Tutorial Definitivo

O que pode acontecer se um impedimento no for removido ?

Quem pode cancelar a Sprint ?

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

124

Estudo de Caso: Reunio de Reviso da Sprint

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

125

Reviso da Sprint:

Reunio da Reviso da Sprint

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

126

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

127

Reunio de Reviso da Sprint

SCRUM, O Tutorial Definitivo

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.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

128

Reunio de Reviso da Sprint

SCRUM, O Tutorial Definitivo

Product Backlog atualizado.


Lembrem: PO responsvel por manter atualizado Release Burndown e Product Backlog.

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

129

Quadro de Viso do Projeto(Produto)

SCRUM, O Tutorial Definitivo

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


Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

131

SCRUM, O Tutorial Definitivo

Estudo de Caso: Reunio de Reviso da Sprint

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

132

Reunio de Planejamento da Sprint


Exerccio:

SCRUM, O Tutorial Definitivo

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 ?

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

133

Reunio de Retrospectiva da Sprint

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

134

Retrospectiva da Sprint
Reunio Retrospectiva da Sprint

impedimentos

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

135

Reunio de Retrospectiva da Sprint:

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

136

Retrospectiva da Sprint
Lies Aprendidas, o que deve melhorado para a prxima Sprint:

SCRUM, O Tutorial Definitivo

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
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

137

SCRUM, O Tutorial Definitivo

Reunio de Retrospectiva da Sprint

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

138

Comear nova iterao (nova Sprint)

SCRUM, O Tutorial Definitivo

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

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

139

Reunio de Planejamento da Sprint


Exerccio:

SCRUM, O Tutorial Definitivo

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:

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

140

Quer mais ?

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

141

Referncias
Scrum Guide
Agile Collection (SCRUM, FDD e XP) nova verso

SCRUM, O Tutorial Definitivo

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.
Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

142

SCRUM, O Tutorial Definitivo

Licena:

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

143

Notas:
Marcas Registradas:

SCRUM, O Tutorial Definitivo

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)


Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013

144

SCRUM, O Tutorial Definitivo

O Tutorial
Definitivo

www.etcnologia.com.br

Rildo F Santos
(11) 9123-5358
(11) 9962-4260

rildo.santos@etecnologia.com.br
twitter: @rildosan
skype: rildo.f.santos
http://rildosan.blogspot.com/

Verso 4 Jun 2013 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos 2006 e 2013