Professional Documents
Culture Documents
O Tutorial
Definitivo
www.etcnologia.com.br
rildo.santos@etecnologia.com.br
skype: rildo.f.santos
http://rildosan.com/
rildo.santos@etecnologia.com.br
rildo.santos@etecnologia.com.br
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
Contedo:
rildo.santos@etecnologia.com.br
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
rildo.santos@etecnologia.com.br
Contedo:
rildo.santos@etecnologia.com.br
Objetivo:
rildo.santos@etecnologia.com.br
Desafios do Desenvolvimento
de Software
Verso 4 Jun 2013 | RFS
rildo.santos@etecnologia.com.br
rildo.santos@etecnologia.com.br
rildo.santos@etecnologia.com.br
10
rildo.santos@etecnologia.com.br
11
Informao
errada
13%
Requisitos
incompletos
12%
Outros
50%
Mudana de
Requisitos
12%
Falta de
competncia
6%
Falta de
conhecimento
tcnico
7%
12
Craig Larman, Agile and Iterative Development: A Managers Guide, Addison Wesley Professional
(2004)
rildo.santos@etecnologia.com.br
12
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)
rildo.santos@etecnologia.com.br
13
rildo.santos@etecnologia.com.br
14
rildo.santos@etecnologia.com.br
15
SCRUM,
Lean,
Kanban,
XP...
Cascata
RUP
rildo.santos@etecnologia.com.br
16
rildo.santos@etecnologia.com.br
17
rildo.santos@etecnologia.com.br
18
Cliente x Desenvolvedores:
Clientes:
- Alguns clientes tm dificuldades em externar
suas necessidades ou desejos de forma clara e objetiva
(No sabem o que querem)
- Geralmente fazem mudanas de requisitos durante o
desenvolvimento ou quando o software entregue.
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
rildo.santos@etecnologia.com.br
19
rildo.santos@etecnologia.com.br
20
Contedo:
rildo.santos@etecnologia.com.br
21
Objetivo:
rildo.santos@etecnologia.com.br
22
Parte 2
Sobre o SCRUM
Verso 4 Jun 2013 | RFS
rildo.santos@etecnologia.com.br
23
As Razes do Scrum:
TimeBoxes
SmallTalk
Engineering Tools
Desenvolvimento
iterativo e
incremental
Reunio
diria
24 horas
Produto
Backlog
Sprint
Backlog
Produto
2-4 Semanas
rildo.santos@etecnologia.com.br
24
O que TimeBox ?
rildo.santos@etecnologia.com.br
25
Entrega 2
Entrega 3
Incremental
Iterativo
rildo.santos@etecnologia.com.br
26
rildo.santos@etecnologia.com.br
27
*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.
rildo.santos@etecnologia.com.br
28
Os pilares do SCRUM:
rildo.santos@etecnologia.com.br
29
Os pilares do SCRUM:
Trs pilares sustentam qualquer implementao de controle de processos empricos.
O primeiro pilar:
A transparncia garante que aspectos
do processo que afetam o resultado
devem ser visveis para aqueles que
gerenciam os resultados.
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.
rildo.santos@etecnologia.com.br
30
Os pilares do SCRUM:
rildo.santos@etecnologia.com.br
31
O Manifesto gil:
rildo.santos@etecnologia.com.br
32
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.
rildo.santos@etecnologia.com.br
33
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.
rildo.santos@etecnologia.com.br
34
rildo.santos@etecnologia.com.br
35
rildo.santos@etecnologia.com.br
36
Tradicional
Mtodo gil
- ter auto gesto,
- ser Auto organizada;
- ser Interdisciplinar
- no ter Hierarquia formal,
- ter responsabilidade.
rildo.santos@etecnologia.com.br
37
As Caractersticas da Equipe:
Como ser gil ?
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
38
- 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;
rildo.santos@etecnologia.com.br
39
rildo.santos@etecnologia.com.br
40
Exerccio
Leia o texto e complete a lacuna (no ltimo paragrafo):
O processo de captao de talentos no futebol:
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
rildo.santos@etecnologia.com.br
41
Contedo:
rildo.santos@etecnologia.com.br
42
Objetivo:
rildo.santos@etecnologia.com.br
43
Parte 3
Entendendo o SCRUM
Verso 4 Jun 2013 | RFS
rildo.santos@etecnologia.com.br
44
Framework Scrum:
Scrum um framework para desenvolver e manter produtos complexos. Um framework dentro do qual
pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente
entregam produtos com o mais alto valor possvel. Scrum : Leve, Simples de entender e Extremamente
difcil de dominar
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Viso
Product
Backlog
Sprint
Backlog
Produto
2-4 Semanas
Reunies
Legenda:
Eventos (Reunies)
Papis
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
45
Regras
Verso 4 Jun 2013 | RFS
rildo.santos@etecnologia.com.br
46
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.
rildo.santos@etecnologia.com.br
47
Papis e Equipe
Verso 4 Jun 2013 | RFS
rildo.santos@etecnologia.com.br
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:
rildo.santos@etecnologia.com.br
49
rildo.santos@etecnologia.com.br
50
rildo.santos@etecnologia.com.br
51
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
52
Eventos
Verso 4 Jun 2013 | RFS
rildo.santos@etecnologia.com.br
53
Eventos:Viso Geral
Eventos com durao fixa (time-boxes) :
Os eventos com durao fixa so utilizados para criar para criar regularidade, os seguintes eventos
tm a durao fixa:
- Reunio de Planejamento da Release
- Reunio de Planejamento da Sprint,
- Sprint,
- Reunio Diria,
- Reviso da Sprint
- Retrospectiva da Sprint.
A Sprint:
Parte central, ou o corao do Scrum, a Sprint, que uma iterao de um ms ou menos, de
durao consistente com o esforo de desenvolvimento. Todas as Sprints utilizam o mesmo
modelo de Scrum e todas as Sprints tm como resultado um incremento do produto final que
potencialmente entregvel. Cada Sprint comea imediatamente aps a anterior.
Reunio
Diria
Sprint
Product Backlog
Verso 4 Jun 2013 | RFS
Produto
Sprint Backlog
rildo.santos@etecnologia.com.br
54
rildo.santos@etecnologia.com.br
55
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
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
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Viso
Produto
Backlog
Sprint
Backlog
Sprint
2-4 Semanas
rildo.santos@etecnologia.com.br
Produto
57
rildo.santos@etecnologia.com.br
58
consultar
cliente
alterar
cliente
Fazer Testes
Unitrios
rildo.santos@etecnologia.com.br
59
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Viso
Produto
Backlog
Sprint
Backlog
Produto
Sprint
2-4 Semanas
rildo.santos@etecnologia.com.br
60
rildo.santos@etecnologia.com.br
61
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Viso
Produto
Backlog
Sprint
Backlog
Produto
Sprint
2-4 Semanas
rildo.santos@etecnologia.com.br
62
REUNIO DIRIA
A equipe deve se encontrar diariamente para uma reunio de 15 minutos chamada Reunio
Diria. Essa reunio sempre feita no mesmo horrio e no mesmo local durante as Sprints.
Durante a reunio, cada membro explica:
1. O que ele realizou desde a ltima reunio diria;
2. O que ele vai fazer antes da prxima reunio diria; e
3. Quais obstculos esto em seu caminho.
rildo.santos@etecnologia.com.br
63
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Viso
Produto
Backlog
Sprint
Backlog
Produto
Sprint
2-4 Semanas
rildo.santos@etecnologia.com.br
64
REVISO DA SPRINT
Ao final da Sprint, feita a reunio de Reviso da Sprint. Para Sprints de um ms, essa uma
reunio com durao fixa de 4 horas. Para Sprints de duraes mais curtas, essa reunio no deve
tomar mais do que 5% do total da Sprint. Durante a Reviso da Sprint, a equipe Scrum e as partes
interessadas colaboram sobre o que acabou de ser feito.
Baseados nisso e em mudanas no Product Backlog feitas durante a Sprint, eles colaboram sobre
quais so as prximas coisas que podem ser feitas. Essa uma reunio informal, com a
apresentao da funcionalidade, que tem a inteno de promover a colaborao sobre o que fazer em
seguida.
A reunio inclui ao menos os seguintes elementos. O Product Owner identifica o que foi feito e o
que no foi feito. A equipe discute sobre o que correu bem durante a Sprint e quais problemas foram
enfrentados, alm de como esses problemas foram resolvidos. A equipe ento demonstra o trabalho
que est pronta e responde a questionamentos. O Product Owner ento discute o Product Backlog
da maneira como esse se encontra.
Ele faz projees de datas de concluso provveis a partir de vrias hipteses de velocidade. Em
seguida, o grupo inteiro colabora sobre o que foi visto e o que isso significa com relao ao que fazer
em seguida. A Reviso da Sprint fornece entradas valiosas para as reunies de Planejamento de
Sprints seguintes.
rildo.santos@etecnologia.com.br
65
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Viso
Produto
Backlog
Sprint
Backlog
Produto
Sprint
2-4 Semanas
rildo.santos@etecnologia.com.br
66
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.
rildo.santos@etecnologia.com.br
67
Artefatos
Verso 4 Jun 2013 | RFS
rildo.santos@etecnologia.com.br
68
rildo.santos@etecnologia.com.br
69
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.
rildo.santos@etecnologia.com.br
70
rildo.santos@etecnologia.com.br
71
Product Backlog
Tema*
Item
Prioridade
Pontos (estimados)
Venda de
Passagem
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
Baixa
Atendimento ao
cliente
Baixa
rildo.santos@etecnologia.com.br
72
Release Burndown
Release Burndown registra a
soma das estimativas dos esforos
restantes do Product Backlog ao
longo do tempo. O esforo
estimado deve estar em qualquer
unidade de medida de trabalho
que a equipe e a organizao
tenham decidido usar. As
unidades de tempo geralmente
so Sprints.
139
100
Pontos (estimados)
150
90
50
52
20
0
Sprint #1
Sprint #2
Sprint #13
Sprint #4
Sprints
rildo.santos@etecnologia.com.br
73
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.
rildo.santos@etecnologia.com.br
74
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
Prioridade: Alta
rildo.santos@etecnologia.com.br
75
Estria do Usurio
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
rildo.santos@etecnologia.com.br
Sprint Backlog
A Sprint Backlog um
artefato resultante da reunio
de Planejamento da Sprint
Todos os direitos reservados e protegidos 2006 e 2013
76
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: ?
Product Owner
Verso 4 Jun 2013 | RFS
rildo.santos@etecnologia.com.br
77
Ideal Days:
Mais fcil para iniciantes
Fcil de explicar
Pontos de Estria:
Valores relativos
Mais abstrato
rildo.santos@etecnologia.com.br
78
100
Pessoal, qual
estimativa para
essa estria...
40
40
Product Owner
Verso 4 Jun 2013 | RFS
Equipe
N. Rodada
40
40
40
40
Equipe
rildo.santos@etecnologia.com.br
79
Estria do Usurio
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
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
80
rildo.santos@etecnologia.com.br
81
rildo.santos@etecnologia.com.br
82
Pronto
Verso 4 Jun 2013 | RFS
rildo.santos@etecnologia.com.br
83
rildo.santos@etecnologia.com.br
84
A Definio de PRONTO
Scrum exige que a equipe desenvolva um incremento de funcionalidade do produto a cada
Sprint. Esse incremento deve ser potencialmente entregvel, pois o Product Owner (PO)
pode optar por implantar a funcionalidade imediatamente. Para isso ser possvel, o
incremento deve ser um pedao completo do produto. Ele deve estar pronto. Cada
incremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado,
garantindo que todos os incrementos funcionem juntos.
No desenvolvimento de produtos, afirmar que a funcionalidade est pronta pode levar algum a
presumir que ela est pelo menos bem codificada, refatorada, que tenha passado por testes
unitrios, que tenha sido feito o build e que tenha passado por testes de aceitao.
Outros podem presumir que apenas o cdigo tenha sido desenvolvido.
Se no houve definio de pronto, os outros dois pilares do controle de processos empricos no
funcionam. Quando algum descreve algo como pronto, todos devem entender o que pronto
significa.
Pronto define o que a equipe quer dizer quando se compromete a aprontar um item de
Product Backlog em uma Sprint. Alguns produtos no contm documentao, de forma que sua
definio de pronto no inclui documentao. Um incremento completamente pronto inclui toda
a anlise, projeto, refatoramento, programao, documentao e testes para o incremento e todos os
itens do Product Backlog no incremento. Os testes incluem testes de unidade, de
sistema, de usurio e de regresso, bem como testes no-funcionais como de performance, de
estabilidade, de segurana e de integrao.
Pronto inclui tambm qualquer internacionalizao necessria. Algumas equipes ainda no so
capazes de incluir em sua definio de pronto tudo o que necessrio para a implantao. Isto
deve estar claro para o Product Owner. Esse trabalho restante dever ser feito antes que o
produto possa ser implantado e utilizado.
Verso 4 Jun 2013 | RFS
rildo.santos@etecnologia.com.br
85
rildo.santos@etecnologia.com.br
86
Exerccios:
Responda Verdadeiro ou Falso para as declaraes:
] 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
] Verdadeiro
] Falso
rildo.santos@etecnologia.com.br
87
Exerccios:
Responda Verdadeiro ou Falso para as questes:
5 - O Product Owner pode ser um membro da equipe, trabalhando tambm na realizao das tarefas.
Mas, essa responsabilidade adicional pode reduzir a sua habilidade de lidar com as partes
interessadas.
] Verdadeiro
] Falso
6 Se a equipe sentir que se comprometeu com mais do que podia, ele se encontra com o Product
Owner para remover ou reduzir o escopo da Sprint Backlog (itens do Product Backlog selecionado para
a Sprint). Se a equipe sentir que sobrar tempo ele pode trabalhar junto ao Product Owner para
selecionar mais do itens do Product Backlog.
[
] Verdadeiro
] Falso
7- Geralmente, somente 60-70% do total da Sprint Backlog ser definido na Reunio de Planejamento
da Sprint. O restante deixado para ser detalhado mais tarde ou so dadas estimativas grandes que
sero decompostas mais tarde na Sprint.
[
] Verdadeiro
] Falso
] Verdadeiro
] Falso
rildo.santos@etecnologia.com.br
88
Exerccios:
Responda Verdadeiro ou Falso para as questes:
9 - Testes de aceitao fazem parte da Estria de Usurio, so utilizados parar substituir descries
textuais mais detalhadas com uma descrio testvel.
] Verdadeiro
] Falso
10 - O Release Burndown registra a soma das estimativas dos esforos restantes do Product Backlog
ao longo do tempo. O esforo estimado deve estar em qualquer unidade de medida de trabalho que a
equipe Scrum e a organizao tenham decidido usar. As unidades de tempo geralmente so
Estrias do Usurio.
[
] Verdadeiro
] Falso
rildo.santos@etecnologia.com.br
89
Contedo:
rildo.santos@etecnologia.com.br
90
Objetivo:
Estudo de Caso
Objetivo:
Apresentar um Estudo de Caso para demonstrar como aplicar as prticas do SCRUM em
projeto de desenvolvimento de Software.
Pr-requisito:
Conhecimento das prticas Scrum.
Verso 4 Jun 2013 | RFS
rildo.santos@etecnologia.com.br
91
Estudo de Caso
Estudo de Caso
Verso 4 Jun 2013 | RFS
rildo.santos@etecnologia.com.br
92
Framework SCRUM
Planejamento
da Release
Reunio
diria
Planejamento
da Sprint
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Product
Backlog
Sprint
Backlog
Produto
Sprint
(2-4 Semanas)
Viso
Legenda:
Reunies
Artefatos
Reunies
Artefatos
Papis
Product Owner (PO)
ScrumMaster (SM)
Equipe (time)
Planejamento da Release
Planejamento da Sprint
Diria
Reviso da Sprint
Retrospectiva da Sprint
Product Backlog
Sprint Backlog
Sprint Burndown
Release Burndown
rildo.santos@etecnologia.com.br
Sprint Burndown
Release Burndown
93
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
94
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.
rildo.santos@etecnologia.com.br
95
Aps a definio da Viso do Produto, devemos definir a primeira verso do Product Backlog:
Funcionalidades do produto
O Product Backlog, inicialmente uma lista que representa tudo que necessrio para desenvolver e
lanar um produto. A lista deve conter todas as caractersticas, funes, tecnologias, melhorias e
correes de defeitos que constituem as mudanas que sero efetuadas no produto para futuras
releases . O Product Backlog dinmico, no sentido de que ele est constantemente mudando
para identificar o que o produto necessita.
Verso 4 Jun 2013 | RFS
rildo.santos@etecnologia.com.br
96
rildo.santos@etecnologia.com.br
97
Podemos fazer a declarao da Viso do Produto sem entender a real necessidade do cliente ?
rildo.santos@etecnologia.com.br
98
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
99
Entradas
Viso do Produto
Planejamento
da Release
Product Backlog (priorizado)
Sadas
Equipe SCRUM
Plano de Release
rildo.santos@etecnologia.com.br
100
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
rildo.santos@etecnologia.com.br
101
Release Burndown
120
108
80
Pontos (estimados)
Com Product Backlog atualizado e o Plano de Release, o PO poder construir o Release Burndown, que um
dos artefatos do SCRUM. As estimativas dos itens do Product Backlog so inicialmente calculadas durante
a Reunio de Planejamento da Release.
O Release Burndown registra a soma das estimativas dos esforos restantes do Product Backlog ao longo do
tempo. O esforo estimado deve estar em qualquer unidade de medida de trabalho que a equipe e a
organizao tenham decidido usar. As unidades de tempo geralmente so Sprints.
68
40
48
40
20
0
Release #1
Release #2
Release #3
Release #4
Release #5
Releases
Verso 4 Jun 2013 | RFS
rildo.santos@etecnologia.com.br
102
rildo.santos@etecnologia.com.br
103
rildo.santos@etecnologia.com.br
104
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
105
rildo.santos@etecnologia.com.br
106
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
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
107
Estria do Usurio
Titulo: Fazer Reserva de Apartamentos
Como cliente de negcio, eu quero fazer reserva de
Pontos: ?
Tarefas de Negcio
Fazer Reserva
de Apartamentos
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
108
100
Pessoal, qual
estimativa para
essa estria...
40
40
Product Owner
Verso 4 Jun 2013 | RFS
Equipe
Ensima Rodada
40
40
40
40
Equipe
rildo.santos@etecnologia.com.br
109
Estria do Usurio
Titulo: Fazer Reserva de Apartamentos
planejamento.
Prioridade: Alta
Pontos: 40
Tarefas de Negcio
Fazer Reserva
de Apartamentos
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
110
rildo.santos@etecnologia.com.br
111
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
112
rildo.santos@etecnologia.com.br
113
rildo.santos@etecnologia.com.br
114
O que aconteceria se a equipe considerar que o item do Product Baclog: Os clientes podero
fazer reserva de apartamentos um pico ?
rildo.santos@etecnologia.com.br
115
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
116
A equipe deve se encontrar diariamente para uma reunio de 15 minutos chamada Reunio
Diria. Essa reunio sempre feita com as pessoas de p, no mesmo horrio e no mesmo local
durante as Sprints.
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
117
Na primeira reunio a Equipe decide qual tarefa vai ser feita primeiro. Aps a escolha da tarefa
o Task Board (Quadro de Tarefas) atualizado.
Consulta de
Reserva de
Apartamento
OK
OK
OK
Equipe
SCRUM Master
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
As reunio se repetem ao longo dos dias e a cada reunio a Task Board atualizado (as tarefas e
Sprint Burndown).
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
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
120
SCRUM Master
SCRUM Master
dever remover este
impedimento
rildo.santos@etecnologia.com.br
121
15 Minutos
OK
OK
OK
OK
Equipe
SCRUM Master
Verso 4 Jun 2013 | RFS
rildo.santos@etecnologia.com.br
122
rildo.santos@etecnologia.com.br
123
rildo.santos@etecnologia.com.br
124
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
125
Reviso da Sprint:
Produto pronto
OK
Product
Owner
OK
4 horas
OK
Equipe
SCRUM Master
Equipe apresenta que foi produzido e faz entrega para PO, que avalia o valor da entrega. PO
poder aceitar ou rejeitar a entrega do produto.
Verso 4 Jun 2013 | RFS
rildo.santos@etecnologia.com.br
126
rildo.santos@etecnologia.com.br
127
rildo.santos@etecnologia.com.br
128
rildo.santos@etecnologia.com.br
129
rildo.santos@etecnologia.com.br
131
rildo.santos@etecnologia.com.br
132
Podemos considerar que a entrega da Sprint foi feita mesmo que ela no esteja em conformidade
com a definio de Pronto ?
rildo.santos@etecnologia.com.br
133
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
134
Retrospectiva da Sprint
Reunio Retrospectiva da Sprint
impedimentos
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
135
rildo.santos@etecnologia.com.br
136
Retrospectiva da Sprint
Lies Aprendidas, o que deve melhorado para a prxima Sprint:
OK
Consulta de
Reserva de
Apartamento
Velocidade da equipe
=
Atitude:
Para uma equipe (time) SCRUM
funcionar ser necessrio
mudana de atitude, caso
contrrio isto poder afetar
o desempenho da equipe
Cadastro de
Fila de Espera
Cadastro de
Cliente
Confirmao
da Reserva
O Que Deve
Ser Melhorado
Pontos de
Ateno
Impedimentos:
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
137
rildo.santos@etecnologia.com.br
138
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
rildo.santos@etecnologia.com.br
139
rildo.santos@etecnologia.com.br
140
Quer mais ?
rildo.santos@etecnologia.com.br
141
Referncias
Scrum Guide
Agile Collection (SCRUM, FDD e XP) nova verso
rildo.santos@etecnologia.com.br
142
Licena:
rildo.santos@etecnologia.com.br
143
Notas:
Marcas Registradas:
Todos os termos mencionados que so reconhecidos como Marca Registrada e/ou comercial so de
responsabilidades de seus proprietrios. O autor informa no estar associada a nenhum produto e/ou
fornecedor que apresentado neste material. No decorrer deste, imagens, nomes de produtos e
fabricantes podem ter sido utilizados, e desde j o autor informa que o uso apenas ilustrativo para fins
educativo, no visando ao lucro, favorecimento ou desmerecimento da marca ou produto.
Melhoria e Reviso:
Este material esta em processo constante de reviso e melhoria, se voc encontrou algum problema
ou erro envie um e-mail para ns.
Criticas e Sugestes:
Ns estamos abertos para receber criticas e sugestes que possam melhorar o material, por favor
envie um e-mail para ns.
Imagens:
Google, Flickr e Banco de Imagem.
rildo.santos@etecnologia.com.br
144
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/
rildo.santos@etecnologia.com.br