Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
O Tutorial
www.etcnologia.com.br
Rildo F Santos
rildo.santos@etecnologia.com.br
twitter: @rildosan
(11) 9123-5358 skype: rildo.f.santos
(11) 9962-4260 http://rildosan.blogspot.com/
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010
SCRUM, O Tutorial® Conteúdo:
2 – Sobre o SCRUM
3 – Entendendo SCRUM
4 – Estudo de Caso
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 2
SCRUM, O Tutorial® Objetivo:
Objetivo:
O Scrum é um Método Ágil para execução de qualquer projeto ou trabalho.
Pré-requisito:
Não há.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 3
Programa: “Menos Papel, Mais Árvores ®”
O primeiro passo para criar um mundo melhor, é saber qual tipo de mundo que queremos
ter e qual tipo que deixaremos de herança para as próximas gerações.
Minha Experiência:
Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia de
Software. Sou formado em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre em
Engenharia de Software pela Universidade Mackenzie.
Fui instrutor de Tecnologia de Orientação a Objetos, UML e Linguagem Java (Sun MicroSystems e IBM).
SCRUM, O Tutorial®
Conheço Métodos Ágeis (SCRUM, XP, FDD, Lean e OpenUP), Arquitetura de Software, SOA (Arquitetura Orientado a
Serviço), Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias.
Sou professor de curso de MBA da Fiap e fui professor de pós-graduação da Fasp e IBTA.
Tenho conhecimento de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de Projetos e
GRC - Governance, Risk ando Compliance), SOX, Basel II e PCI;
Experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Fluência nos principais frameworks
e padrões: ITIL, Cobit, ISO 20000, ISO 27001 e ISO 15999;
Participei de diversos projetos nos segmentos: Financeiro, Telecomunicações, Seguro, Saúde, Comunicação, Segurança
Pública, Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás.
Possuo as certificações: 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;
Onde estou:
Twitter: @rildosan
Blog: http://rildosan.blogspot.com/
Comunidade: http://etecnologia.ning.com
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 5
SCRUM, O Tutorial® Conteúdo:
2 – Sobre o SCRUM
3 – Entendendo SCRUM
4 – Estudo de Caso
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 6
SCRUM, O Tutorial® Objetivo:
Objetivo:
Apresentar e discutir os principais desafios dos projetos de desenvolvimento de software.
Pré-requisito:
Não há.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 7
SCRUM, O Tutorial®
Desafios do Desenvolvimento
de Software
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 8
1º. Desafio: Responder ao cliente
Quanto tempo vai levar ?
O tempo é outro grande desafio, é raro
(posso até afirmar que não existe) um cliente
que diga: “Demore o tempo que for necessário,
pois, não temos pressa nenhuma”.
Geralmente o cliente quer o software funcionando
SCRUM, O Tutorial®
Para ontem...
Quanto custará ?
Todo cliente quer saber quanto custará
o software...
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 9
SCRUM, O Tutorial® 2º. Desafio: Falha na Comunicação das equipes de TI
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 10
SCRUM, O Tutorial® 3º. Desafio: Entender as necessidades dos clientes
Quando não se entende as necessidades dos clientes, não se pode entregar valor ao cliente.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 11
4º. Desafio: Compreender por que os projetos falham:
Informação
errada
13%
Requisitos
incompletos
12%
SCRUM, O Tutorial®
Outros
50% Mudança de
Requisitos
12%
Falta de
conhecimento
técnico
37% das falhas estão Falta de
7%
Craig Larman, Agile and Iterative Development: A Manager’s Guide, Addison Wesley Professional
12
(2004)
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 12
5º. Desafio: Identificar o que é necessidade e o que é desejo
Uso de funcionalidades do Software
Sempre
Contudo, a 7% Freqüentemente
maioria das 13%
funcionalidades Nunca
45%
nunca são
SCRUM, O Tutorial®
usadas pelos
usuários
As vezes
16%
Raramente
19%
Craig Larman, Agile and Iterative Development: A Manager’s Guide, Addison Wesley Professional
13
(2004)
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 13
6º. Desafio: Aumentar produtividade da equipe de desenvolvimento:
Satisfação dos Clientes
SCRUM, O Tutorial®
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 14
A falta de produtividade pode afetar o negócio
Qual é a solução ?
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 começar a produzir, ou seja, temos que considerar o tempo que
será gasto com explicações, orientações, comunicação e treinamento das novas pessoas, devemos
considerar o esforço da gestão de projetos que aumentará
Ao calcular o tempo que será necessário para desenvolver um software, temos que adicionar um
tempo extra, pois os desenvolvedores precisam de "tempo para pensar“, “tempo para pesquisar” além
do "tempo para desenvolver"
UP SCRUM,
Lean,
ASD,
XP, FDD...
SCRUM, O Tutorial®
RUP
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 16
8º. Desafio: Como reter os bons profissionais ?
Quantas vezes já montamos boas equipe, mas de repente as pessoas começam a
sair...a trocar de emprego.
A retenção de bons profissionais é grande desafio da atualidade, pessoas trocam
muito mais de emprego do que a 10 anos atrás.
emprego. A maioria das pessoas mudam de emprego por problema com o seu chefe e não
por motivo de salário.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 17
Por que precisamos dos Métodos Ágeis ?
Problemas clássicos (ou tradicionais):
Stakeholders (Clientes):
- Têm dificuldades em externar suas necessidades
- Geralmente fazem mudanças de requisitos
- Precisam do software funcionando para
ontem
Desenvolvedores:
- Não sabem ou não querem elicitar requisitos
- Dificilmente conseguem atender todas as
SCRUM, O Tutorial®
demandas de negócio
- Tem dificuldade em comunicar e entender
os clientes
Para enfrentar estes desafios:
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 18
Cliente x Desenvolvedores:
Clientes:
- Alguns clientes têm dificuldades em externar
suas necessidades ou desejos de forma clara e objetiva
(Não sabem o que querem)
Desenvolvedores:
- Não sabem ou não querem conversar com o cliente
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 19
Como enfrentar estes desafios: “O SCRUM é sua sogra”
O SCRUm pode ser uma forma para enfrentar estes desafios, O SCRUM não vai
aumentar a produtividade da equipe, não 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
críticos (riscos) do projeto de desenvolvimento, aquilo que realmente precisa ser
melhorado, mas se as pessoas envolvidas com o projeto não tomarem nenhuma ação (ou
SCRUM, O Tutorial®
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 20
Se trabalhamos com desenvolvimento Ágil:
Logo temos:
A prioridade é satisfazer o cliente, entregando o mais rápido possível e de forma contínua software que
tenha valor:
Para satisfazer o cliente é preciso entendê-lo. A estória ajuda a melhorar o entendimento da necessidade do
cliente para que ocorra a entrega de valor.
SCRUM, O Tutorial®
Pontos: 5
A Estória de Usuário é uma “ferramenta” simples que pode ajudar. Uma Estória de Usuário nada mais
é que um cartão com algumas frases, escrita pelo cliente e desenvolveres em linguagem comum,
sobre algo que o software deve fazer.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 21
Exercícios:
1- É possível entregar valor ao cliente (software funcionado, segundo o Manifesto Ágil), sem
entender a necessidade dele ?
SCRUM, O Tutorial®
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 22
SCRUM, O Tutorial® Conteúdo:
2 – Sobre o SCRUM
3 – Entendendo SCRUM
4 – Estudo de Caso
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 23
SCRUM, O Tutorial® Objetivo:
Objetivo:
Apresentar Manifesto Ágil e o SCRUM, as principais características e práticas.
Pré-requisito:
Não há.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 24
SCRUM, O Tutorial® Parte 2
Sobre o SCRUM
rildo.santos@etecnologia.com.br
Versão 1 Nov 2010 | RFS Todos os direitos reservados e protegidos © 2006 e 2010 25
As Raízes do Scrum:
TimeBoxes
Artigo: “The New, New
Product Development Game Desenvolvimento
de Nonaka e Takeushi na iterativo e
Hardvard Bussines Review SmallTalk incremental
Engineering Tools
SCRUM, O Tutorial®
Reunião
diária
24 horas
Sprint
Produto Backlog
Backlog Produto
2-4 Semanas
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010
26
O que é TimeBox ?
É duração fixa (imutável).
É um conceito diz que a quantidade de tempo é imutável, ou seja, tem duração
fixa - a quantidade de dias não poderá aumentar. Assim, evita-se atrasos no prazo
de entrega e facilita o planejamento.
Exemplos de Timebox:
A Sprint (que é uma iteração) que deve ser realizada de 2 a 4 semanas, no qual a
equipe de desenvolvedores deverá produzir um entregável de valor para o cliente
(mais frente discutiremos melhor isto).
A entrega de valor é a meta da Sprint, a duração da Sprint deverá ser combinada
com o cliente, antes do começo da execução da Sprint.
Se foi acertado que a Sprint tem a duração de 4 semanas, logo esta duração
será fixa (não mudará).
Durante a Sprint são realizadas as Reuniões Diárias, uma reunião diária tem a
duração fixa de 15 minutos.
Ao final da Sprint, é feita a reunião de Revisão da Sprint. Para Sprints
de um mês, essa é uma reunião com duração fixa de quatro horas.
Após a Revisão da Sprint e antes da próxima Reunião de Planejamento
da Sprint, a Equipe Scrum tem a Reunião de Retrospectiva da Sprint.
essa reunião, te duração fixa de três horas.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 27
Abordagem Iterativo e Incremental:
Entrega 1 Entrega 2 Entrega 3
Incremental
SCRUM, O Tutorial®
Iterativo
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010
29
Qual é a teoria do SCRUM ?
A TEORIA DO SCRUM:
Scrum, que é fundamentado na teoria de controle de processos empíricos*, emprega uma
abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos
O que são processos empíricos ?
Antes de responder a pergunta, precisamos saber que existem dois tipos de processos:
Processo Definido:
São processos que se conhece todas as variáveis, têm poucas ou nenhuma
SCRUM, O Tutorial®
*Processos Empíricos:
São aqueles processos que não se conhece todas as variáveis, têm
mudanças ao logo do processo, não são repetitivos e são imprevisíveis.
Geralmente baseado na experiência e no conhecimento de quem executa o
processo.
Exemplo: Desenvolvimento de Software.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010
31
Os pilares do SCRUM:
Três pilares sustentam qualquer implementação de controle de processos empíricos.
O primeiro pilar:
O segundo pilar:
Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente
para que variações inaceitáveis no processo possam ser detectadas. A frequência da
inspeção deve levar em consideração que qualquer processo é modificado pelo próprio
ato da inspeção. O problema acontece quando a frequência de inspeção necessária
excede a tolerância do processo à inspeção. Os outros fatores são a habilidade e a
aplicação das pessoas em inspecionar os resultados do trabalho.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010
32
Os pilares do SCRUM:
Três pilares sustentam qualquer implementação de controle de processos empíricos.
O terceiro pilar:
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010
33
SCRUM, O Tutorial® O Manifesto Ágil:
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 34
Princípios por trás do Manifesto Ágil:
Nós seguimos estes princípios:
Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com
valor agregado.
Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.
Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à
SCRUM, O Tutorial®
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 35
Como Ser Ágil ?
Como ser ágil ?
1 - Para “ser ágil” é preciso colocar em prática os valores e os princípios do Manifesto Ágil.
Exemplo:
Se uma organização implementou o SCRUM e aparentemente tudo ocorre bem...mas, se equipe não
está conseguindo entregar “software funcionando” ao cliente a quatro meses, podemos afirmar que
existe uma equipe ágil ?
SCRUM, O Tutorial®
Podemos concluir que a equipe não é ágil, pois além da implementação do SCRUM, que é um
método ágil, ela também deverá levar em conta os valores e princípios do Manifesto Ágil, ou seja,
entregar software funcionando com certa regularidade.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 36
Como Ser Ágil ?
Como ser ágil ?
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 37
SCRUM, O Tutorial® Como Ser Ágil ?
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 39
As Características da Equipe:
Como ser ágil ?
trabalho.
Equipe de desenvolvedores é muito parecida com um equipe de Volley Ball,
onde todos tem um único objetivo e são interdisciplinares no jogo.
Interdisciplinares e Sem hierarquia formal:
Equipes também são interdisciplinares: os membros da equipe devem ter todo o conhecimento e
habilidades necessárias para entregar a meta da Sprint.
Membros da equipe geralmente possuem conhecimentos especializados, tais como: programação,
testes, controle de qualidade, análise de negócios, arquitetura, desenho de interface de usuário 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 não dividem.
As pessoas que se recusam a programar porque são arquitetas ou designers não se adaptam bem a
equipe. Todos devem contribuir, mesmo que isso exija aprender novas habilidades ou lembrar-se de
antigas. Na equipe não há hierarquia nem títulos, todos são iguais e não há exceções a essa regra. As
equipes também não devem ter sub-equipe dedicados a áreas particulares como testes, banco de
dados ou análise de negócios.
Responsabilidade:
A equipe de desenvolvedores é responsável transformar os itens do Product Backlog em
funcionalidades potencialmente entregáveis a cada Sprint.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 40
Reforçando: “Não existe a Bala de Prata”
SCRUM não é a Bala de Prata:
- SCRUM é ideal para desenvolvimento de software complexos onde os requisitos mudam rapidamente;
- SCRUM possibilita que você utilize as praticas de engenharia existentes e que já são conhecidas;
- SCRUM é o caminho para detectar e causa raiz e a remoção de qualquer coisa que esteja impedindo o
desenvolvimento e/ou entrega de software/produtos;
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 41
SCRUM, O Tutorial® Algumas empresas que estão usando SCRUM:
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 42
Exercício
Leia o texto e complete a lacuna (no último paragrafo):
Um dos aspectos mais importantes dos grandes clubes de futebol está relacionado à captação de
talentos para compor suas categorias de base, e posteriormente formar esses atletas para ingressarem
no profissional. Para entendermos melhor os caminhos atualmente traçados por esses candidatos a
SCRUM, O Tutorial®
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 detecção difere em muito daqueles praticados anteriormente,
e que cada vez mais, tem se tornado precoce e competitivo, em que a concorrência chega a ser
absurda. Se pudéssemos ter acesso aos números de garotos avaliados anualmente nos grandes clubes
em relação aos selecionados, chegaríamos certamente a esta conclusão.
O objetivo deste texto é relatar os diversos mecanismos de captação de talentos em prática nos grandes
clubes do futebol profissional brasileiro. Dentre os mecanismos, destacamos cinco principais e dois
secundários. Podemos destacar alguns dos principais: as avaliações “peneiras”; campeonatos e jogos
amistosos; indicações; escolas licenciadas “franquias” e os observadores técnicos. Entre as
secundárias, destacamos: as clínicas de futebol e o intercâmbio internacional.
As chamadas “peneiras” são um dos mecanismos mais conhecidos e utilizados no meio do futebol.
Porém, é um processo ___________________, baseado na observação dos treinadores em uma única
situação (muitas vezes apenas de jogo e de curta duração). Neste caso, muitos clubes pré-selecionam
alguns garotos para continuarem os testes por pelo menos uma semana no clube, ou mais um dia, no
mínimo.
http://www.universidadedofutebol.com.br/2010/07/1,14757,UM+RELATO+SOBRE+O+PROCESSO+DE+CAPTACAO+DE+TALENTOS+NO+FUTEBOL.aspx?p=1
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010
43
SCRUM, O Tutorial® Conteúdo:
2 – Sobre o SCRUM
3 – Entendendo SCRUM
4 – Estudo de Caso
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 44
SCRUM, O Tutorial® Objetivo:
Objetivo:
Apresentar de forma detalhada o framework SCRUM segundo o Guia do Scrum.
Pré-requisito:
Não há.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 45
SCRUM, O Tutorial® Parte 3
Entendendo o SCRUM
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 46
Framework Scrum:
O framework Scrum é formado por um conjunto pela Equipe (Time) Scrum e seus papéis: Product
Owner (PO), Scrum Master (SM) e equipe de desenvolvedores, eventos com duração Fixa (Time-
Boxes), artefatos e regras.
24 horas
Legenda:
Reuniões
Artefatos
Eventos (Reuniões)
Papéis Artefatos
Planejamento da Release
• Product Owner (PO) Planejamento da Sprint • Product Backlog
• ScrumMaster (SM) Diária • Sprint Backlog
• Equipe Scrum Revisão da Sprint • Sprint Burndown
Retrospectiva da Sprint • Release Burndown Sprint Burndown
Release Burndown
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010
47
SCRUM, O Tutorial® Framework Scrum: Eventos de Duração Fixa:
Regras
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 48
Framework Scrum: Regras
As Regras fazem o elo entre os eventos com duração fixa (time-boxes), os papéis e os
artefatos do Scrum. As regras são descritas ao longo desta apresentação.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 49
SCRUM, O Tutorial® Framework Scrum: Papéis e Equipe
Papéis e Equipe
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 50
Papéis SCRUM: Papéis
Equipe Scrum são projetados para otimizar flexibilidade e produtividade. Para esse fim, eles são
auto-organizáveis, interdisciplinares e trabalham em iterações. Cada equipe possui três papéis:
- Definir ROI;
- Representar o cliente
- Aceitar ou rejeitar os entregáveis
produtos complexos.
Quando o ScrumMaster ajuda a realizar essas mudanças, isso é chamado de
“remoção de impedimentos”. No entanto, o ScrumMaster não gerencia a Equipe
Scrum; a Equipe Scrum é auto-organizável.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 53
SCRUM, O Tutorial® Equipe: Comprometimento e Tamanho:
Envolvidos Comprometidos
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 interação e, como resultado, há menor
ganho de produtividade. Mais do que isso, a equipe poderá encontrar limitações de conhecimento
durante partes da Sprint e não ser capaz de entregar uma parte “pronta” do produto. Se há mais do
que 9 membros, há simplesmente a necessidade de muita coordenação. Equipe grandes geram
muita complexidade para que um processo empírico 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 não estão incluídos nessa conta, a menos que também sejam porcos. A
composição da equipe pode mudar ao final da Sprint. Toda vez que a equipe muda, a produtividade
ganha através da auto-organização é reduzida. Deve-se tomar cuidado ao mudar a composição da
equipe.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 54
SCRUM, O Tutorial® Framework Scrum: Eventos de Duração Fixa:
Eventos
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 55
Eventos:Visão Geral
Eventos com duração fixa (time-boxes) :
Os eventos com duração fixa são utilizados para criar para criar regularidade, os seguintes eventos
têm a duração fixa:
- Reunião de Planejamento da Release
- Reunião de Planejamento da Sprint,
- Sprint,
- Reunião Diária,
- Revisão da Sprint
SCRUM, O Tutorial®
- Retrospectiva da Sprint.
A Sprint:
Parte central, ou o coração do Scrum, é a Sprint, que é uma iteração de um mês ou menos, de
duração consistente com o esforço de desenvolvimento. Todas as Sprints utilizam o mesmo
modelo de Scrum e todas as Sprints têm como resultado um incremento do produto final que é
potencialmente entregável. Cada Sprint começa imediatamente após a anterior.
Reunião
Diária
Produto
Sprint
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 56
Framework Scrum: Eventos de Duração Fixa:
REUNIÃO DE PLANEJAMENTO DA RELEASE
O propósito do planejamento da release é o de estabelecer um plano e metas que a equipe Scrum e o
resto da organização possam entender e comunicar. O planejamento da release responde às
questões:
O Plano da Release, que é o artefato resultante dessa reunião, estabelece a meta da release, as
maiores prioridades do Product Backlog, os principais riscos e as características gerais e
funcionalidades que estarão contidas na release. Ele estabelece também uma data de entrega e
custo prováveis que devem se manter se nada mudar. A organização pode então inspecionar o
progresso e fazer mudanças nesse plano da release a cada Sprint.
O planejamento da release é opcional. Contudo, se a equipe Scrum iniciar o trabalho sem essa
reunião, a ausência 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 são construídos iterativamente, de modo que cada Sprint cria
um incremento do produto, iniciando pelo de maior valor e maior risco. Mais e mais Sprints vão
adicionando incrementos ao produto. Cada incremento é um “pedaço” potencialmente entregável do
produto completo. Quando já tiverem sido criados incrementos suficientes para que o produto tenha
valor e uso para seus investidores, o produto é entregue.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 57
Framework Scrum: Eventos de Duração Fixa:
REUNIÃO DE PLANEJAMENTO DA RELEASE (continuação)
No planejamento de release do Scrum, são definidos uma meta geral e resultados prováveis. Esse
planejamento geralmente não requer mais do que 15-20% do tempo que uma organização costumava
utilizar para produzir um plano de release tradicional. No entanto, uma release com Scrum realiza
planejamento no momento da execução de cada reunião de Revisão de Sprint e de Planejamento
de Sprint, da mesma forma que realiza um planejamento diário no momento da execução de cada
Reunião Diária. De forma geral, os esforços para uma release com Scrum provavelmente consomem
SCRUM, O Tutorial®
Release BurnDown
Sprint #
1 2 3 4 5 6
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 58
Framework Scrum: Eventos de Duração Fixa:
24 horas
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 59
Framework Scrum: Eventos de Duração Fixa:
REUNIÃO DE PLANEJAMENTO DA SPRINT
A Reunião de Planejamento da Sprint é o momento no qual a iteração é planejada. É fixada em oito
horas de duração para uma Sprint de um mês. Para Sprints mais curtas, aloca-se para essa
reunião aproximadamente 5% do tamanho total da Sprint, e ela consiste de duas partes. A primeira
parte, um evento com duração fixa de 4 horas, é o momento no qual é decidido “o quê” será feito
na Sprint. A segunda parte, também é um evento com duração fixa de 4 horas, é o momento no
qual a equipe entende “como” desenvolverá essa funcionalidade em um incremento do produto
durante a Sprint.
SCRUM, O Tutorial®
Meta da Sprint:
Uma vez selecionado o Product Backlog , a Meta da Sprint é delineada. A Meta da Sprint é o
objetivo que será atingido através da implementação do Product Backlog. Ela é uma descrição que
fornece orientação a equipe sobre a razão 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 relação à funcionalidade.
Por exemplo, a meta para a Sprint acima poderia também ser: “Automatizar a funcionalidade de
modificação de conta de clientes através de um “middleware” seguro capaz de recuperar transações.”
Conforme a equipe trabalha, ela mantém a meta em mente. Para satisfazer a meta, elaa implementa a
funcionalidade e a tecnologia.
Se o trabalho se mostrar mais difícil do que a equipe esperava, a equipe então irá colaborar
com o Product Owner e implementar a funcionalidade apenas parcialmente.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 60
Framework Scrum: Eventos de Duração Fixa:
REUNIÃO DE PLANEJAMENTO DA SPRINT (Continuação):
Na segunda parte da Reunião de Planejamento da Sprint, a equipe trata a questão: Sprint Backlog
“como?”.
Durante as quatro horas seguintes da Reunião de Planejamento da Sprint, a equipe Fazer UI
define como transformará o Backlog do Produto selecionado durante a Reunião de
Planejamento (o quê) em um incremento pronto. A equipe geralmente começa
projetando o trabalho. Enquanto projeta, a equipe identifica tarefas. Essas tarefas Fazer as
Tabelas
são “pedaços” detalhados do trabalho necessário para converter os itens do Product
SCRUM, O Tutorial®
24 horas
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 62
Framework Scrum: Eventos de Duração Fixa:
A SPRINT
A Sprint é uma iteração. Sprints são eventos com duração fixa. Durante a Sprint, o ScrumMaster
garante que não será feita nenhuma mudança que possa afetar a Meta da Sprint. Tanto a composição
da equipe quanto as metas de qualidade devem permanecer constantes durante a Sprint. As
Sprints contêm e consistem na reunião de Planejamento de Sprint, o trabalho de
desenvolvimento, a Revisão da Sprint e a Retrospectiva da Sprint. As Sprints ocorrem uma após
a outra, sem intervalos entre elas.
Um projeto serve para cumprir alguma função. Em desenvolvimento de software, o projeto é
SCRUM, O Tutorial®
utilizado para desenvolver um produto ou sistema. Cada projeto consiste em uma definição 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 período de tempo para
o qual o plano é válido. Se o horizonte for longo demais, a definição poderá ter mudado, variáveis
demais poderão ter surgido, o risco poderá ser grande demais etc. Scrum é um framework para
projetos cujo horizonte não é superior ao período de um mês, 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 mês, e o risco de que o projeto saia de controle ou se torne
imprevisível é contido pelo menos a cada mês.
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 influência
das partes interessadas, da equipeou do ScrumMaster. Sob que tipo de circunstâncias pode ser
necessário cancelar uma Sprint? A gerência pode precisar cancelar uma Sprint se a Meta da Sprint
se tornar obsoleta. Isso pode ocorrer se a empresa mudar de direção ou se as condições do
mercado ou tecnologia mudarem. Em geral, uma Sprint deve ser cancelada se ela não fizer mais
sentido dadas as circunstâncias atuais, todavia isso deve ser uma exceção. Porém, por causa da curta
duração das Sprints, raramente isso faz sentido.
Artefato resultante dessa iteração: Parte do produto
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 63
Framework Scrum: Eventos de Duração Fixa:
24 horas
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 64
Framework Scrum: Eventos de Duração Fixa:
REUNIÃO DIÁRIA
A equipe deve se encontrar diariamente para uma reunião de 15 minutos chamada Reunião
Diária. Essa reunião é sempre feita no mesmo horário e no mesmo local durante as Sprints.
Durante a reunião, cada membro explica:
1. O que ele realizou desde a última reunião diária;
2. O que ele vai fazer antes da próxima reunião diária; e
3. Quais obstáculos estão em seu caminho.
SCRUM, O Tutorial®
O ScrumMaster deve garantir que a equipe realize essa reunião. A equipe é responsável por
conduzir a Reunião Diária. O ScrumMaster ensina a equipe a manter a Reunião Diária com curta
duração, reforçando as regras e assegurando que as pessoas falem brevemente. O ScrumMaster
também enfatiza a regra de que galinhas não estão autorizadas a falar e nem a interferir de modo
algum na Reunião Diária.
A Reunião Diária não é uma reunião de status. Ela é só para as pessoas que estão
transformando os itens do Product Backlog um incremento (a equipe), e para mais ninguém. A
equioe se comprometeu com uma Meta da Sprint, e a esses itens do product Backlog. A
Reunião Diária é uma inspeção do progresso na direção da Meta da Sprint (as três
perguntas).
Geralmente acontecem reuniões subsequentes para realizar adaptações ao trabalho que está por
vir na Sprint. A intenção é otimizar a probabilidade de que a equipe alcance sua Meta. Essa é uma
reunião fundamental de inspeção e adaptação no processo empírico do Scrum.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 65
Framework Scrum: Eventos de Duração Fixa:
24 horas
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 66
Framework Scrum: Eventos de Duração Fixa:
REVISÃO DA SPRINT
Ao final da Sprint, é feita a reunião de Revisão da Sprint. Para Sprints de um mês, essa é uma
reunião com duração fixa de 4 horas. Para Sprints de durações mais curtas, essa reunião não deve
tomar mais do que 5% do total da Sprint. Durante a Revisão da Sprint, a equipe Scrum e as partes
interessadas colaboram sobre o que acabou de ser feito.
Baseados nisso e em mudanças no Product Backlog feitas durante a Sprint, eles colaboram sobre
quais são as próximas coisas que podem ser feitas. Essa é uma reunião informal, com a
SCRUM, O Tutorial®
apresentação da funcionalidade, que tem a intenção de promover a colaboração sobre o que fazer em
seguida.
A reunião inclui ao menos os seguintes elementos. O Product Owner identifica o que foi feito e o
que não foi feito. A equipe discute sobre o que correu bem durante a Sprint e quais problemas foram
enfrentados, além de como esses problemas foram resolvidos. A equipe então demonstra o trabalho
que está pronta e responde a questionamentos. O Product Owner então discute o Product Backlog
da maneira como esse se encontra.
Ele faz projeções de datas de conclusão prováveis a partir de várias hipóteses de velocidade. Em
seguida, o grupo inteiro colabora sobre o que foi visto e o que isso significa com relação ao que fazer
em seguida. A Revisão da Sprint fornece entradas valiosas para as reuniões de Planejamento de
Sprints seguintes.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 67
Framework Scrum: Eventos de Duração Fixa:
24 horas
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 68
Framework Scrum: Eventos de Duração Fixa:
RETROSPECTIVA DA SPRINT
Após a Revisão da Sprint e antes da próxima reunião de Planejamento da Sprint, a equipe Scrum
tem a reunião de Retrospectiva da Sprint.
Nessa reunião, com duração fixa de três horas, o ScrumMaster encoraja a equipe a revisar, dentro
do modelo de trabalho e das práticas do processo do Scrum, seu processo de
desenvolvimento, de forma a torná-lo mais eficaz e gratificante para a próxima Sprint. Existem
SCRUM, O Tutorial®
No final da Retrospectiva da Sprint, a equipe Scrum deve ter identificado as ações de melhoria
factíveis que será implementada na próxima Sprint. Essas mudanças se tornam a adaptação para
a inspeção empírica.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 69
SCRUM, O Tutorial® Framework Scrum: Artefatos
Artefatos
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 70
SCRUM, O Tutorial® Framework Scrum: Artefatos
- Product Backlog: é uma lista priorizada de tudo que pode ser necessário no produto.
- Sprint Backlog: é uma lista de tarefas para transformar o Product Backlog , por uma Sprint, em
um incremento do produto potencialmente entregável. 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.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 71
Framework Scrum: Artefatos
PRODUCT BACKLOG e RELEASE BURNDOWN
Os requisitos para o produto que a equipe está desenvolvendo estão listados no Product Backlog
O Product Owner (PO) é o responsável pelo Product Backlog , por sua criação, por seu
conteúdo, por sua disponibilidade e por sua priorização.
O Product Backlog nunca está completo. A seleção 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 é dinâmico, no sentido de
SCRUM, O Tutorial®
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 também existirá.
O Product Backlog representa tudo que é necessário para desenvolver e lançar um produto de
sucesso. É uma lista de todas as características, funções, tecnologias, melhorias e correções de
defeitos que constituem as mudanças que serão efetuadas no produto para releases futuras. Os
itens do Product Backlog possuem os atributos de descrição, prioridade e estimativa. A prioridade é
determinada por risco, valor e necessidade. Há diversas técnicas 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
informações e detalhes do que os itens do Backlog de menor prioridade. É mais fácil de fazer a
estimativa quando existem mais informações e mais detalhes.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 72
Framework Scrum: Artefatos
PRODUCT BACKLOG e RELEASE BURNDOWN (continuação):
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. Mudanças nos requisitos de negócios,
condições do mercado, tecnologia e equipe causam mudanças no Product Backlog. Para
minimizar o retrabalho, apenas os itens de maior prioridade precisam ser mais detalhados. Os
itens do Product Backlog que ocuparão a Equipe Scrum pelas várias Sprints seguintes deverão ter
SCRUM, O Tutorial®
granularidade mais fina (mais detalhados), tendo sido decompostos de forma tal que cada um dos
itens possa ser feito dentro da duração da Sprint.
Frequentemente, múltiplas equipes trabalham juntas no mesmo produto. Um único Product
Backlog é usado para descrever o trabalho a ser realizado no produto. Então, um atributo que
agrupe os itens é aplicado no Backlog do Produto.
O agrupamento pode ocorrer por conjuntos de características, por tecnologia ou por arquitetura,
e ele é frequentemente utilizado como uma forma de se organizar o trabalho por equipe.
O gráfico de Release Burndown registra a soma das estimativas dos esforços restantes do Product
Backlog ao longo do tempo. O esforço estimado deve estar em qualquer unidade de medida de
trabalho que a equipe e a organização tenham decidido usar. As unidades de tempo geralmente
são Sprints.
As estimativas dos itens do Product Backlog são inicialmente calculadas durante o Planejamento
da Release, e posteriormente à medida que itens forem sendo criados. Durante a preparação do
Product Backlog , os itens são revistos e revisados.
Entretanto, eles podem ser atualizados em qualquer momento. A equipe é responsável por todas
as estimativas. O Product Owner (PO) pode influenciar a equipe, ajudando-o a entender e a
escolher as mudanças, mas a estimativa final é feita pelo equipe. O Product Owner mantém o
Product Backlog e o Release Burndown do Backlog atualizados e publicados todo o tempo. Uma
linha de tendência pode ser traçada baseada na mudança do trabalho restante.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 73
Framework Scrum: Artefatos
PRODUCT BACKLOG: Exemplo
Product Backlog
Tema* Item Prioridade Pontos (estimados)
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 74
Framework Scrum: Artefatos
RELEASE BURNDOWN: Exemplo
Release Burndown
139
estimado deve estar em qualquer
unidade de medida de trabalho
que a equipe e a organização
100 tenham decidido usar. As
unidades de tempo geralmente
Pontos (estimados)
90
são Sprints.
50 52
20
0
Sprint #1 Sprint #2 Sprint #13 Sprint #4
Sprints
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 75
Framework Scrum: Artefatos
SPRINT BACKLOG E SPRINT BURNDOWN:
A Sprint Backlog consiste nas tarefas que a equipe executa para transformar os itens do Product
Backlog em um incremento “pronto”. Muitas deles são elaboradas durante a Reunião de
Planejamento da Sprint.
A Sprint Backlog é todo trabalho que a equipe identifica como necessário para alcançar a Meta da
Sprint. Os itens do Sprint Backlog devem ser decompostos. A decomposição deve ser suficiente
SCRUM, O Tutorial®
A equipe modifica a Sprint Backlog no decorrer da Sprint. Quando chega às tarefas individuais, a
equipe pode descobrir que mais ou menos tarefas serão necessárias, 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 são completadas, as horas estimadas de trabalho
restantes para cada tarefa são atualizadas. Quando se verifica que determinadas tarefas são
desnecessárias, elas são removidas.
Somente a equipe pode modificar a Sprint Backlog durante uma Sprint, pode mudar o seu conteúdo
ou as suas estimativas. A Sprint Backlog é um retrato em tempo real altamente visível do
trabalho que a equipe planeja efetuar durante a Sprint, e ela pertence unicamente a equipe.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 76
Framework Scrum: Artefatos
SPRINT BACKLOG E SPRINT BURNDOWN: Exemplo
Na reunião de Planejamento da
Sprint, PO deverá apresentar a
visão do produto, Product Backlog
e seus Itens, comentando o nível
de prioridade de cada item. Os
SCRUM, O Tutorial®
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 77
Framework Scrum: Artefatos
SPRINT BACKLOG E SPRINT BURNDOWN: Exemplo
Estória do Usuário
Titulo: “Fazer Check-in” Quebrar a estória do Usuário em
tarefas:
- Para facilitar a estimativa de
velocidade da equipe, considere
Como cliente de negócio, eu quero fazer check-in quebrar a estória em tarefas, isto
pode fazer que todos os membros
SCRUM, O Tutorial®
Criar Executar
Fazer Check-in Componentes testes
de validação unitários
Integrar Executar
com Sistema testes de
de Reserva aceitação A Sprint Backlog é um
artefato resultante da reunião
de Planejamento da Sprint
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 78
Estimando os pontos da “Estória do Usuário”:
Uma breve introdução sobre estimativa:
Estimar é Difícil ?
- Estimativa (mundo real) representa um valor aproximado.
- Estimativa (em desenvolvimento de software) algumas pessoas acham que representa um valor exato.
Contudo, devemos estimar as Estórias do Usuário para saber se elas “cabem” dentro de uma Sprint.
Uma vez que os pontos são estimados eles ajudam a definir a velocidade da equipe, a partir deste
SCRUM, O Tutorial®
parâmetro, podemos chegar a conclusão se estória cabe ou não dentro da Sprint. Se ela não couber a
opção é quebrar esta estória em estórias menores.
Quem ?
como um cliente
O que ?
preciso de uma interface de pagamento por cartão de
Pessoal, qual
estimativa para crédito que seja intuitiva e fácil de usar.
essa estória...
Por que ?
Com objetivo de facilitar os pagamentos.
Pontos: ?
Product Owner
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 79
Estimando os pontos da “Estória do Usuário”:
Quando trabalhamos com métodos ágeis temos pelo menos duas formas para estimar a velocidade da
equipe: Ideal Days e Pontos de Estória. Recomendamos utilizar os Pontos de Estória.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 80
Estimando os pontos da “Estória do Usuário”:
Estimativa* e o Planning Poker:
Para fazer estimativa de velocidade da equipe ou de duração da Sprint, antes é preciso o escrever as
estórias do usuário.
O Planning Poker é uma “prática” que ajuda na estimativa de uma estória ou de uma tarefa e é baseada
no consenso de toda a equipe.
Geralmente o Planning Poker usa um conjunto de cartas com valores específicos que
podem representar pontos relativos e é praticado como se fosse um jogo de cartas. Os
pontos devem estar em uma escala não linear, por e exemplo a Fibonacci:
SCRUM, O Tutorial®
haja concesso.
Estória do Usuário
Titulo: “Fazer Check-in” Planning Poker, estória do usuário
e pontos de estória, nada disso faz
parte do framework Scrum,
contudo são técnicas e ferramentas
Como cliente de negócio, eu quero fazer check-in complementares ao framework.
Elas são altamente utilizadas para
SCRUM, O Tutorial®
Criar Executar
Fazer Check-in Componentes testes
de validação unitários
Integrar Executar
com Sistema testes de
de Reserva aceitação
A Sprint Backlog é todo trabalho que a equipe identifica como necessário para alcançar a Meta da Sprint.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 82
Framework Scrum: Artefatos
SPRINT BACKLOG E SPRINT BURNDOWN:
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 83
Framework Scrum: Artefatos
SPRINT BURNDOWN : Exemplo O Quadro de Tarefas também
A transparência, que é dos pilares do Scrum, garante que não parte do framework
Scrum, ele parte de uma
aspectos do processo que afetam o resultado devem ser visíveis técnica chamada Gestão à
para aqueles que gerenciam os resultados. O Quadro de Tarefas Vista, que tem como objetivo
deixam a Sprint com visibilidade e transparência. facilitar a comunicação e dar
visibilidade (transparência).
SCRUM, O Tutorial®
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 84
SCRUM, O Tutorial® Framework Scrum: Definição de Pronto
Pronto
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 85
Definição de Pronto (*DoD):
Uma conversa comum entre o cliente e o desenvolvedor:
No desenvolvimento de produtos, afirmar que a funcionalidade está pronta pode levar alguém a
presumir que ela está pelo menos bem codificada, refatorada, que tenha passado por testes
unitários, que tenha sido feito o “build” e que tenha passado por testes de aceitação.
Outros podem presumir que apenas o código tenha sido desenvolvido.
Se não houve definição de “pronto”, os outros dois pilares do controle de processos empíricos não
funcionam. Quando alguém 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 não contêm documentação, de forma que sua
definição de “pronto” não inclui documentação. Um incremento completamente “pronto” inclui toda
a análise, projeto, refatoramento, programação, documentação e testes para o incremento e todos os
itens do Product Backlog no incremento. Os testes incluem testes de unidade, de
sistema, de usuário e de regressão, bem como testes não-funcionais como de performance, de
estabilidade, de segurança e de integração.
“Pronto” inclui também qualquer internacionalização necessária. Algumas equipes ainda não são
capazes de incluir em sua definição de “pronto” tudo o que é necessário para a implantação. Isto
deve estar claro para o Product Owner. Esse trabalho restante deverá ser feito antes que o
produto possa ser implantado e utilizado.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 87
Framework Scrum: Definição de Pronto
A Definição de PRONTO e “NÃO PRONTO”
O trabalho “não pronto” é adicionado a um item do Product Backlog o chamado “trabalho não pronto”, de
forma que ele se acumula e isso é refletido corretamente no gráfico de Release Burndown Release.
Essa técnica cria transparência no progresso em direção à entrega. A inspeção e a adaptação na
Revisão da Sprint serão tão precisas quanto essa transparência for.
Exemplo:
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 88
Exercícios:
Responda Verdadeiro ou Falso para as declarações:
1 - Quando as regras não são declaradas, espera-se que os usuários de Scrum descubram o que
devem fazer. Não tente descobrir uma solução perfeita, porque geralmente o problema muda
rapidamente. Ao invés disso, tente algo e veja como se sai. Os mecanismos de inspeção-e-adaptação
inerentes à natureza empírica do Scrum irão lhe guiar.
[ ] Verdadeiro [ ] Falso
SCRUM, O Tutorial®
2 - O ScrumMaster trabalha com os clientes e a gerência 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 através do Scrum. Se eles não souberem, consideramos o
ScrumMaster responsável.
[ ] 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
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 89
Exercícios:
Responda Verdadeiro ou Falso para as questões:
5 - O Product Owner pode ser um membro da equipe, trabalhando também na realização das tarefas.
Mas, essa responsabilidade adicional pode reduzir a sua habilidade de lidar com as partes
interessadas.
[ ] Verdadeiro [ ] Falso
SCRUM, O Tutorial®
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 Reunião de Planejamento
da Sprint. O restante é deixado para ser detalhado mais tarde ou são dadas estimativas grandes que
serão decompostas mais tarde na Sprint.
[ ] Verdadeiro [ ] Falso
8 - Os itens do Product Backlog são comumente representados como “Estórias do Usuário”. Casos de
Uso também são apropriados.
[ ] Verdadeiro [ ] Falso
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 90
Exercícios:
Responda Verdadeiro ou Falso para as questões:
9 - Testes de aceitação fazem parte da Estória de Usuário, são utilizados parar substituir descrições
textuais mais detalhadas com uma descrição testável.
[ ] Verdadeiro [ ] Falso
10 - O Release Burndown registra a soma das estimativas dos esforços restantes do Product Backlog
SCRUM, O Tutorial®
ao longo do tempo. O esforço estimado deve estar em qualquer unidade de medida de trabalho que a
equipe Scrum e a organização tenham decidido usar. As unidades de tempo geralmente são
Estórias do Usuário.
[ ] Verdadeiro [ ] Falso
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 91
SCRUM, O Tutorial® Conteúdo:
2 – Sobre o SCRUM
3 – Entendendo SCRUM
4 – Estudo de Caso
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 92
SCRUM, O Tutorial® Objetivo:
Estudo de Caso
Objetivo:
Apresentar um Estudo de Caso para demonstrar como aplicar as práticas do SCRUM em
projeto de desenvolvimento de Software.
Pré-requisito:
Conhecimento das práticas Scrum.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 93
SCRUM, O Tutorial® Estudo de Caso
Estudo de Caso
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 94
Framework SCRUM
24 horas
Product Sprint
Backlog Backlog
Produto
Sprint
(2-4 Semanas)
Visão
Legenda:
Reuniões
Artefatos
Reuniões
Papéis Artefatos
• Planejamento da Release
• Product Owner (PO) • Planejamento da Sprint • Product Backlog
• ScrumMaster (SM) • Diária • Sprint Backlog
• Equipe (time) • Revisão da Sprint • Sprint Burndown
• Retrospectiva da Sprint • Release Burndown •Sprint Burndown
• Release Burndown
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 95
Estudo de Caso: Visão
Primeiro passo: definir a Visão do Produto.
24 horas
Produto Sprint
Backlog Backlog
Produto
Sprint
2-4 Semanas
Visão
1
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 96
Estudo de Caso: Visão do Produto
Para definir a visão do Produto, primeiro é necessário entender qual é a real necessidade do cliente:
A necessidade:
Um hotel, quer incrementar um novo canal de consultas e vendas de reservas de
apartamentos. A sugestão foi criar um Portal de Reservas para vender os serviços.
SCRUM, O Tutorial®
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 97
Estudo de Caso: Visão do Produto
Após a definição da Visão do Produto, devemos definir a primeira “versão” do Product Backlog:
SCRUM, O Tutorial®
Funcionalidades do produto
O Product Backlog, inicialmente é uma lista que representa tudo que é necessário para desenvolver e
lançar um produto. A lista deve conter todas as características, funções, tecnologias, melhorias e
correções de defeitos que constituem as mudanças que serão efetuadas no produto para futuras
releases . O Product Backlog é dinâmico, no sentido de que ele está constantemente mudando
para identificar o que o produto necessita.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 98
SCRUM, O Tutorial® Estudo de Caso: Visão do Produto
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 99
Estudo de Caso: Visão do Produto
Exercício:
Podemos fazer a declaração da Visão do Produto sem entender a real necessidade do cliente ?
SCRUM, O Tutorial®
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 100
Estudo de Caso: Reunião de Planejamento da Release
Segundo passo: Realizar a Reunião de Planejamento da Release, o resultado desta reunião é o
Plano de Release e o Release Burndown (artefato Scrum).
24 horas
Produto Sprint
Backlog Backlog
Produto
Sprint
2-4 Semanas
Visão
2
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 101
Estudo de Caso: Reunião de Planejamento da Release
O propósito da Reunião 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 organização
possam entender e comunicar.
O planejamento da release responde às questões:
- Como podemos transformar a visão em um produto da melhor maneira possível?
- Como podemos alcançar ou exceder a satisfação do cliente ?
- Como podemos alcançar o ROI (retorno sobre investimento) ?
O Plano de Release estabelece a meta da release, as maiores prioridades do Product Backlog,
SCRUM, O Tutorial®
Planejamento
da Release
Product Backlog (priorizado)
Product Backlog (visão inicial)
Saídas
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 102
Estudo de Caso: Reunião de Planejamento da Release
Visão inicial do Product Backlog, antes da reunião de Planejamento da
1 Sprint, ele tem somente as funcionalidades do produto, agrupadas por
tema (este agrupamento é opcional).
O Plano de Release
é base para atualização
do Product Backlog
SCRUM, O Tutorial®
3
2
Plano de Release
Relacionamento Programa de
Releases Reserva Promoções Tour Virtual 5 Releases
ao cliente Fidelidade
Release Burndown
SCRUM, O Tutorial®
120
O Product Owner é responsável
por manter o Product Backlog e
o Release Burndown atualizados
108 e publicados todo o tempo.
Uma linha de tendência pode ser
80
traçada baseada na mudança do
Pontos (estimados)
trabalho restante.
68
40
48 40
20
0
Release #1 Release #2 Release #3 Release #4 Release #5
Releases
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 104
SCRUM, O Tutorial® Estudo de Caso: Reunião de Planejamento da Release
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 105
Estudo de Caso: Reunião de Planejamento da Release
Exercício:
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 106
Estudo de Caso: Reunião de Planejamento da Sprint
Terceiro passo: Realizar a Reunião de Planejamento da Sprint, o resultado desta reunião são os
artefatos Sprint Backlog e Sprint Burndown.
24 horas
Produto Sprint
Backlog Backlog
Produto
Sprint
2-4 Semanas
Visão
3
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 107
Estudo de Caso: Reunião de Planejamento da Sprint
Product Backlog: Sistema de Reserva On-Line
SCRUM, O Tutorial®
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 108
Estudo de Caso: Reunião de Planejamento da Sprint
Detalhando os itens do Produto Backlog em estórias do usuário:
Para facilitar o entendimento dos
itens do Product Backlog ele são
descritos em estórias do usuário
elas auxiliam no entendimento do
que deve ser feito, permite fazer
a estimativa de velocidade da
equipe e também é, utilizada
como lembrete e para as
atividades de planejamento.
SCRUM, O Tutorial®
Boa Prática: A Estória do Usuário deve prover o entendimento do que deve ser feito e deve facilitar a estimativa
de velocidade da equipe.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 109
Estudo de Caso: Reunião de Planejamento da Sprint
Detalhando as Estórias do Usuário em Tarefas:
Devemos buscar meios para facilitar
Estória do Usuário a estimativa de velocidade da
Titulo: “Fazer Reserva de Apartamentos” equipe, quebrar a estória do usuário
em tarefas pode fazer que todos os
Como cliente de negócio, eu quero fazer reserva de membros da equipe visualizem todas
as tarefas que devem ser feitas para
apartamentos pela web para facilitar o meu implementar a Estória do Usuário.
Testes de aceitação devem ser
planejamento.
escritos para detalhar melhor a
SCRUM, O Tutorial®
Consulta de Criar
Reserva de Interfaces
Apartamento Do Usuário
Cadastro de Criar
Fila de Espera Tabelas
Fazer Reserva
de Apartamentos
Cadastro de Executar
Cliente testes
unitários
Confirmação Executar
da Reserva testes de
aceitação
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 110
Estudo de Caso: Reunião de Planejamento da Sprint
Estimativa e o Planning Poker:
Para fazer estimativa de velocidade da equipe ou de duração da Sprint, antes é preciso o escrever as
estórias do usuário.
O Planning Poker é uma “prática” que ajuda na estimativa de uma estória ou de uma tarefa e é baseada
no consenso de toda a equipe.
Geralmente o Planning Poker usa um conjunto de cartas com valores específicos que
podem representar pontos relativos e é praticado como se fosse um jogo de cartas. Os
pontos devem estar em uma escala não linear, por e exemplo a Fibonacci:
SCRUM, O Tutorial®
Consulta de Criar
Reserva de Interfaces
Apartamento Do Usuário Sprint Backlog
Cadastro de Criar
Fila de Espera Tabelas
Fazer Reserva
de Apartamentos
Cadastro de Executar
Cliente testes
unitários
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 112
Estudo de Caso: Reunião de Planejamento da Sprint
Definição de Pronto:
Scrum exige que a equipe desenvolva um incremento de funcionalidade do produto a cada
Sprint. Esse incremento deve ser potencialmente entregável, pois o Product Owner (PO) pode
optar por implantar a funcionalidade imediatamente. Para isso ser possível, o incremento deve ser um
pedaço 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.
SCRUM, O Tutorial®
Consulta de Pontos
Reserva de 40
Apartamento
Cadastro de 30
Fila de Espera
20
Cadastro de
Cliente 10
0
Confirmação 1 2 3 4
da Reserva
Semanas
Meta da Sprint
Entregar a funcionalidade de
reserva de apartamentos em
30 dias.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 114
SCRUM, O Tutorial® Estudo de Caso: Reunião de Planejamento da Sprint
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 115
Estudo de Caso: Reunião de Planejamento da Sprint
Esclarecendo algumas dúvidas:
Para não correr riscos, a equipe optou por trabalhar com uma folga.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 116
Estudo de Caso: Reunião de Planejamento da Sprint
Exercício:
O que aconteceria se a equipe considerar que o item do Product Baclog: “Os clientes poderão
fazer reserva de apartamentos” é um “épico” ?
SCRUM, O Tutorial®
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 117
Estudo de Caso: Reunião Diária
Quarto passo: Após a reunião de Reunião de Planejamento da Sprint, efetivamente a Sprint
começa, o próxima passo são as Reuniões Diárias.
24 horas
Produto Sprint
Backlog Backlog
Produto
Sprint
2-4 Semanas
Visão
4
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 118
Estudo de Caso: Reunião Diária
A equipe deve se encontrar diariamente para uma reunião de 15 minutos chamada Reunião
Diária. Essa reunião é sempre feita com as pessoas de pé, no mesmo horário e no mesmo local
durante as Sprints.
A Reunião Diária não é uma reunião de status. A equipe se comprometeu com a Meta da Sprint,
e os itens do Product Backlog. A Reunião Diária é uma inspeção do progresso na direção da
Meta da Sprint (as três perguntas).
Geralmente acontecem reuniões subsequentes para realizar adaptações ao trabalho que está por vir
na Sprint. A intenção é otimizar a probabilidade de que a equipe alcance sua Meta. Essa é uma reunião
fundamental de inspeção e adaptação no processo empírico do Scrum.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 119
Estudo de Caso: Reunião Diária
Na primeira reunião a Equipe decide qual tarefa vai ser feita primeiro. Após a escolha da tarefa
o Task Board (Quadro de Tarefas) é atualizado.
Consulta de
SCRUM, O Tutorial®
Reserva de
Apartamento
OK
OK ? OK
Equipe
Questões:
1. O que foi realizado desde a última reunião diária;
SCRUM Master 2. O que vai ser feito antes da próxima reunião diária;
3. Foi encontrado algum obstáculo. 15 Minutos
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 120
Estudo de Caso: Reunião Diária
As reunião se repetem ao longo dos dias e a cada reunião a Task Board é atualizado (as tarefas e
Sprint Burndown).
OK ?
Equipe
Questões:
1. O que foi realizado desde a última reunião diária;
SCRUM Master 2. O que vai ser feito antes da próxima reunião diária;
3. Foi encontrado algum obstáculo. 15 Minutos
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 121
Estudo de Caso: Reunião Diária
Durante as reuniões diárias todos os impedimentos (ou obstáculos) identificados são registrados no
Quadro de Tarefas. Eles representam um risco a Sprint. O Risco de não se atingir a meta, logo eles devem
ser removidos. Geralmente os impedimentos são escritos em “Post it” de cor rosa.
15 Minutos
SCRUM, O Tutorial®
OK
OK
OK ?
Encontrei um
obstáculo
(impedimento).
Equipe
Questões:
1. O que foi realizado desde a última reunião diária;
SCRUM Master 2. O que vai ser feito antes da próxima reunião diária;
3. Foi encontrado algum obstáculo.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 122
Estudo de Caso: Impedimento
Cabe ao “SCRUM Master” remover todos os impedimentos, identificados e demonstrados no Quadro de
Tarefas, para que estes não afetem o desempenho da equipe nem a meta da Sprint. Caso contrário, 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
SCRUM, O Tutorial®
SCRUM Master
SCRUM Master
deverá remover este
impedimento
15 Minutos
SCRUM, O Tutorial®
OK OK
OK ? OK
Equipe
SCRUM Master
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 124
SCRUM, O Tutorial® Estudo de Caso: Reunião Diária
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 125
Reunião de Planejamento da Sprint
Exercício:
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 126
Estudo de Caso: Reunião de Revisão da Sprint
Quinto passo: Após o final da Sprint (quando todas as tarefas estão prontas) começa a Reunião de
Revisão da Sprint. Objetivo primário desta reunião é apresentar ao PO que foi feito durante a
Sprint.
24 horas
Produto Sprint
Backlog Backlog
Produto
Sprint
2-4 Semanas
Visão
5
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 127
Revisão da Sprint:
Reunião da Revisão da Sprint
Produto “pronto”
SCRUM, O Tutorial®
OK
Product
Owner
OK OK
Equipe
4 horas 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.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 128
Reunião de Revisão da Sprint
A Reunião de Revisão da Sprint, para Sprints de 1 mês, essa é
uma reunião com duração fixa de 4 horas. Para Sprints de
durações mais curtas, essa reunião não deve tomar mais do que
5% do total da Sprint. Durante a Revisão da Sprint, a Equipe
Scrum e as partes interessadas colaboram sobre o que
acabou de ser feito.
Baseados nisso e em mudanças no Product Backlog feitas
durante a Sprint, eles colaboram sobre quais são as próximas
SCRUM, O Tutorial®
O Product Owner identifica o que foi feito e o que não foi feito. A
equipe discute sobre o que correu bem durante a Sprint e quais
problemas foram enfrentados, além de como esses problemas
foram resolvidos. A equipe então demonstra o trabalho que está
pronto e responde a questionamentos. O Product Owner
então discute o Product Backlog da maneira como esse se
encontra.
Ele faz projeções de datas de conclusão prováveis a partir de
várias hipóteses de velocidade. Em seguida, o grupo inteiro
colabora sobre o que foi visto e o que isso significa com relação
ao que fazer em seguida. A Revisão da Sprint fornece
entradas valiosas para as reuniões de Planejamento de Sprints
seguintes.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 129
Reunião de Revisão da Sprint
O Release Burndown é atualizado.
Lembre-se: “O Release Burndown registra a soma das estimativas dos esforços restantes do Product
Backlog ao longo do tempo. O esforço estimado deve estar em qualquer unidade de medida de trabalho
que a equipe e a organização tenham decidido usar. As unidades de tempo geralmente são Sprints. “
SCRUM, O Tutorial®
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 130
Reunião de Revisão da Sprint
Product Backlog é atualizado.
Lembrem: “PO é responsável por manter atualizado Release Burndown e Product Backlog.”
SCRUM, O Tutorial®
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 131
SCRUM, O Tutorial® Estudo de Caso: Reunião de Revisão da Sprint
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 132
Reunião de Planejamento da Sprint
Exercício:
O que aconteceria se PO não aceitasse a entrega ?
SCRUM, O Tutorial®
Podemos considerar que a entrega da Sprint foi feita mesmo que ela não esteja em conformidade
com a definição de Pronto ?
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 133
Reunião de Retrospectiva da Sprint
Sexto passo: Após a reunião de Reunião de Revisão da Sprint, é realizada a Reunião de
Retrospectiva da Sprint. O propósito desta reunião é inspecionar como correu a última Sprint em se
tratando de pessoas, das relações entre elas, dos processos e das ferramentas.
24 horas
Produto Sprint
Backlog Backlog
Produto
Sprint
2-4 Semanas
Visão
6
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 134
Retrospectiva da Sprint
Reunião Retrospectiva da Sprint
As retrospectivas são a essência do conceito de Inspeção e Adaptação.
impedimentos
Problemas no
Servidor de Teste
=
SCRUM, O Tutorial®
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 próxima
Sprint
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 135
Reunião de Retrospectiva da Sprint:
A Reunião de Retrospectiva da Sprint é a última reunião
de uma Sprint.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 136
Retrospectiva da Sprint
Lições Aprendidas, o que deve melhorado para a próxima Sprint:
Pontos de O Que Deve
OK
Atenção Ser Melhorado
Atitude:
Cadastro de Para uma equipe (time) SCRUM
Fila de Espera
funcionar será necessário
mudança de atitude, caso
contrário isto poderá afetar
Cadastro de
Cliente o desempenho da equipe
Planejamento:
Prestar atenção na hora do
planejamento da Sprint, para
identificar se todos os recursos
necessário estão disponíveis
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 137
SCRUM, O Tutorial® Reunião de Retrospectiva da Sprint
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 138
Começar nova iteração (nova Sprint)
Repetir o ciclo Scrum:
24 horas
Produto Sprint
Backlog Backlog
Produto
Sprint
2-4 Semanas
Visão
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 139
Reunião de Planejamento da Sprint
Exercício:
O PO deve participar da Reunião de Retrospectiva da Sprint ?
SCRUM, O Tutorial®
Durante este estudo de caso não foi apresentado as práticas e ferramentas de Engenharia de
Software, tais como TDD, SCM e etc, explique o motivo:
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 140
Quer mais ?
Os membros da comunidade podem participar dos eventos, treinamentos e cursos gratuitos.
Comunidade: http://etecnologia.ning.com/
SCRUM, O Tutorial®
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 142
SCRUM, O Tutorial® Licença:
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 143
Notas:
Marcas Registradas:
Todos os termos mencionados que são reconhecidos como Marca Registrada e/ou comercial são de
responsabilidades de seus proprietários. O autor informa não 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, não visando ao lucro, favorecimento ou desmerecimento da marca ou produto.
SCRUM, O Tutorial®
Melhoria e Revisão:
Este material esta em processo constante de revisão e melhoria, se você encontrou algum problema
ou erro envie um e-mail para nós.
Criticas e Sugestões:
Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor
envie um e-mail para nós.
Imagens:
Google, Flickr e Banco de Imagem.
O Tutorial
www.etcnologia.com.br
Rildo F Santos
rildo.santos@etecnologia.com.br
twitter: @rildosan
(11) 9123-5358 skype: rildo.f.santos
(11) 9962-4260 http://rildosan.blogspot.com/
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010