31/03/2010

Gerenciamento
de
Projetos

SCRUM

O que é Scrum?

•É um processo iterativo e incremental para o

desenvolvimento de qualquer produto e
gerenciamento de qualquer projeto;

•É mais um framework que uma metodologia, mais

atitute que um processo;

1
 31/03/2010

Scrum

• Processo empírico de gerenciamento e controle

• Inspeção e adaptação em loops de feedback

• Usado para gerenciar projetos desde 1990

• Entrega frequente de funcionalidades com valor

para o cliente
• Escalável a projetos distribuídos, grandes e largos

• Compatível com CMMI Nível 3 e ISO9001

• Extremamente simples, mas resistente

O Manifesto Ágil

“Estamos descobrindo maneiras melhores de desenvolver software

fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse
trabalho, passamos a valorizar:

Indivíduos e interação entre eles mais que processos e ferramentas

Produto em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os

itens à esquerda."

http://agilemanifesto.org

2
 31/03/2010

O que
Nova é Scrum?
versão do Scrum?

Processos: Reunião de planejamento, Retrospectiva, Reunião

diária, Planejamento de Release e Sprints, ...

Ferramentas: Quadro Kanban, Ferramentas, Post-it, User

Stories, Burndown...

Pessoas: ScrumMaster, Product Owner, Time, ...

Cultura: Time multi-disciplinar, Auto-gerenciamento, Valores,

Envolvimento do cliente, Entrega frequente, Liderança-
colaboração, Respeito, ...

Papéis no Scrum

• Product Owner
Responsável por garantir o ROI (Retorno de Investimento);
Responsável por conhecer as necessidades do(s) cliente(s);
Integrador em ambientes com mais de um cliente;

• ScrumMaster
Responsável por remover os impedimentos do time;
Responsável por garantir o uso de Scrum;
Protege o time de interferências externas;

• Time
Definir metas das iterações;
Auto-gerenciamento;
Produzir produto com qualidade e valor para o cliente;

3
 31/03/2010

Estrutura do Scrum
Product Owner ScrumMaster Time

Estrutura do Scrum

• O Product Owner define a Visão do Produto.

Esta Visão é o que representa sua necessidade, é
o que deve ser satisfeito ao fim do projeto;
• Para definir esta Visão o PO colhe informações
junto a clientes, usuários final, time, gerentes,
stakeholders, executivos, etc.;

4
 31/03/2010

Estrutura do Scrum

• O PO cria uma lista inicial de necessidades que

precisam ser produzidas para que a Visão do
projeto seja bem sucedida;
• Esta lista de necessidades é chamada de
Product Backlog.

Estrutura do Scrum
• O PO cria uma lista inicial de necessidades que
precisam ser produzidas para que a Visão do
projeto seja bem sucedida;
• Esta lista de necessidades é chamada de
Product Backlog;
• O ScrumMaster deve auxiliar o PO na elaboração
desta lista.

5
 31/03/2010

Estrutura do Scrum
• No início de cada iteração (Sprint) o time deve se
reunir para realizar a Planning Meeting;
• Nesta reunião o time realizará o planejamento do
que será entregue ao final do ciclo da Sprint (que
deve ser de 2 a 4 semanas).

Estrutura do Scrum
• Na primeira parte da Planning Meeting o PO
deverá: definir a meta da Sprint e falar para o time
sobre os Itens mais prioritários do Product
Backlog;
• O time deve estimar os Itens em tamanho (caso
ainda não estejam estimados) e selecionar o que
acredita que possa ser feito durante a Sprint. Essa
lista selecionada chama-se Selected Product
Backlog;
• O facilitador desta reunião é o ScrumMaster.

6
 31/03/2010

Estrutura do Scrum
• Na segunda parte da Planning Meeting o time
deverá colher mais detalhes dos Itens do Selected
Product Backlog e decompô-los em tarefas,
gerando assim o Sprint Backlog;
• Para isso pode ser necessária a ajuda de
Especialistas;
• Após a decomposição, cada membro do time
deve selecionar as tarefas que deseja executar
durante a Sprint (sempre negociando com o time)
e estimá-las em horas;
• O facilitador desta reunião é o ScrumMaster.

Estrutura do Scrum

• Durante a execução da Sprint, valem as

práticas de engenharia definidas para o projeto;
• O ScrumMaster, através da sua capacidade de
liderança e colaboração, facilita o trabalho do time
removendo os impedimentos encontrados e
garantindo a boa aplicação do Scrum;
• Durante a Sprint o time pode sentir necessidade
de consultar Especistas ou mesmo o Product
Owner;.

7
 31/03/2010

Estrutura do Scrum
• Diariamente o time realiza uma reunião de 15
minutos (Daily Meeting) na qual cada membro
deve responder:
• O que fiz desde a última reunião?
• O que pretendo fazer até a próxima?
• Tive (estou tendo) algum impedimento?
• Através desta reunião o time ganha visibilidade
de como está o caminho para a meta e planeja o
dia seguinte de trabalho;
• O ScrumMaster novamente é o facilitador, e deve
lembrar-se que a reunião é para o time e não para
ele.

Estrutura do Scrum
• Ao final da execução da Sprint deve ser realizada
a Review Meeting, reunião que tem como
propósito apresentar o que foi feito para o Product
Owner e convidados;
• O time é quem realiza a apresentação, que deve
ser feita no formato de demo;
• Product Owner avalia se a Meta da Sprint foi
alcançada;
• Product Owner faz anotações que poderão se
tranformar em novos Itens para o Product Backlog.

8
 31/03/2010

Estrutura do Scrum
• A última cerimônia de um Sprint Scrum é a
Retrospectiva;
• Reunião de lições aprendidas, facilitada pelo
ScrumMaster, na qual o time deve avaliar: o que
foi bom na última Sprint? O que deve ser
melhorado? Quem está no controle?
• Esta reunião representa o espírito de Inspeção-
Adaptação dentro do Scrum;
• É uma reunião do time, mas – caso seja de
acordo de todos seus membros – o PO também
pode participar.

Conceito de Sprint

•A Sprint é um time-box de 2 a 4 semanas no qual o time do

projeto irá produzir uma parte do produto definida pelo cliente

•O conceito de Sprint nos remete à necessidade de estarmos

frequentemente entregando algo de valor para o cliente.
Diferentemente dos modelos tradicionais”, onde você desenvolve o
produto em um longo período de tempo e, apenas no final – com o
produto “pronto” - o entrega ao cliente, em Scrum você sempre
entregará “parte” do produto em pequenos intervalos de tempo,
sendo que esta “parte” é a prioridade do cliente, ou seja, o que ele
realmente está precisando naquele momento

•Uma Sprint deve ser empreendida por um time multi-disciplinar

com não mais que 9 membros

•Cada Sprint deve ter uma meta específica que represente o

desejo do cliente para aquele time-box específico

9
 31/03/2010

Incremento do produto
•Ao final de cada Sprint, o time deve ter produzido um incremento
potencialmente entregável do produto

• Com alta qualidade, testado, completo e pronto

S1 S2 S3 S4
S1, S2, S3 e S4 são produtos potencialmente entregáveis

R1

R1 é um entregável!

Uma Sprint deve ter objetivo SMART

• Specific – Específico

• Measurable – Mensurável

• Achivable – Atingível

• Realistic – Realista

• Timed – Datado

10
 31/03/2010

Sempre entregar valor!

• Sempre entregar valor para o cliente ao final de cada Sprint

•Nunca esquecer: o deadline é sagrado, as funcionalidades é o que

podem variar

•Se houver necessidade de incluir tarefas técnicas, arquiteturais,

estudos, ou qualquer tipo de tarefa que não forneça valor visível
para o cliente: fazer balanceamento entre estas tarefas e as com
alto ROI

Tamanho de Sprints

•O tamanho ideal de uma Sprint é o tamanho que

seu time e cliente achar ideal. Encontre o seu!

• Observe:
• Mudança contante no topo do Product Backlog: ideal
trabalhar com Sprints curtos
• Síndrome do estudante presente: ideal trabalhar com
Sprints curtos
• Dificuldade de entregar valor para o cliente ao fim das
Sprints: ideal trabalhar com Sprints curtos
• Time e/ou cliente exaustos com loops tão curtos: ideal
trabalhar com Sprints longos

11
 31/03/2010

Tamanho de Release

•O Product Owner é quem possui a visão de

qual o período ideal para distribuir uma nova
versão do produto

• Observe:
• Não adianta entrega produto tão rapidamente de
forma a tornar impossível o acompanhamento de
atualização do cliente
• Um Release deve ser algo integrado e de grande
valor para o cliente

Sem mudanças durante a Sprint

•O que o time se comprometeu a entregar – e o

que foi acordado com o Product Owner – é o que
deve ser entregue.

•Quando mudar o conteúdo da Sprint se torna

regra:
• Cliente deixa de sentir necessidade de fazer um
planejamento de qualidade, bem como de estar atento a
uma boa composição e priorização do Product Backlog;
afinal, se pode mudar a qualquer momento, para que se
preocupar com isso?
• Time ignora meta, afinal “com certeza” ela mudará
• Time perde foco e motivação
• Stress impera

12
 31/03/2010

Terminando a Sprint antes da sua finalização

• Umas Sprint pode ser terminada antes da sua

finalização nas seguintes situações:

• O time sente que não conseguirá atingir a meta

• O Product Owner percebe que mudanças em fatores
externos influenciarão diretamente no valor da meta da
Sprint

•Caso uma Sprint seja cancelada deve se iniciar

imediatamente o planejamento da próxima Sprint

Responsabilidades do ScrumMaster

• Remover a barreira entre desenvolvimento e cliente

• Ensinar o cliente a maximir o ROI e atingir seus objetivos
através do Scrum
• Melhorar o dia-a-dia dos membros do time facilitando a
criatividade e fortalecimento
• Combater a ilusão do comando-controle
• Priorizar os impedimentos e combatê-los
• Determinar onde Scrum está, comparado com onde
poderia estar
• Auxiliar o Product Owner com o Product Backlog
• Garantir o uso do Scrum
• Facilitar reuniões

13
 31/03/2010

Como escolher um ScrumMaster?

• Responsável
• Comunicativo
• Humilde
• Facilitador
• Comprometido
• Influente
• Conhecedor

Responsabilidades do Product Owner

• Definir a visão do produto (product vision);

• Gerenciar o retorno de investimento (ROI);
• Apresentar ao time os requisitos necessários para a entrega
do produto;
• Priorizar cada requisito de acordo com seu valor para o
negócio/cliente;
• Gerenciar a entrada de novos requisitos e suas priorizações;
• Planejar entregas (releases);
• Atuar como facilitador quando mais de um cliente estiver
envolvido no projeto;
• Garantir que Especialistas de Domínio estejam disponíveis
para o time;

14
 31/03/2010

Product Backlog
• O primeiro passo em um projeto Scrum é de responsabilidade do Product Owner,
que deve articular a visão do produto;

• O Product Backlog representa esta visão, ele deve ser apresentado no formato de
uma lista com itens priorizados e ordenados de acordo com o valor que representam
para o cliente e negócio;

• O Product Backlog irá existir por todo o ciclo de vida do projeto (e não da sprint), e
é regularmente atualizado pelo Product Owner para refletir as mudanças e
necessidades do cliente, mudanças estratégicas ou tecnológicas, novas idéias,
enfim...mudanças;

• Um Product Backlog é composto de vários tipos de itens: funcionalidades,

requisitos de desenvolvimento, exploração técnica, estudo, documentação, bugs,
etc.

• Apenas um Product Backlog deve existir, e ele deve definir uma visão de tudo que
precisa ser feito;

Story-Writing Workshop

• Story-Writing Workshops são reuniões que incluem

desenvolvedores, usuários, cliente, product owner e
qualquer pessoa que possa contribuir no processo de
descoberta de stories;

• Durante este workshop os participantes escrevem a

quantidade de stories que conseguiresm;

• Prioridades não são associadas;

• Bons workshops combinam os melhores elementos de

brainstorming e prototipação de desenho;

15
 31/03/2010

Teste de aceitação

• Uma das melhores formas de se expressar em uma storie

alguns dos detalhes discutidos entre cliente (Product Owner,
Especialista de Domínio, ...) é a escrita de Testes de
Aceitação;

Como um usuário eu posso

exportar dados em XML
• Testar abrir no Microsoft
para poder integrar minhas
Excel o arquivo exportado;
informações com outros
sistemas

Teste de aceitação

• Testar com Visa,

MasterCard e Aura (passar)

Como um cliente • Testar com cartões

cadastrado eu posso expirados (falhar)
pagar meu
bilhete com cartão de • Testa com valores acima
do limite (falhar)
crédito para agilizar
minha compra • Testar com cartão de
pessoa física (falhar)

16
 31/03/2010

Teste de aceitação

• Escrever Testes de Aceitação antes da codificação;

• O cliente é quem deve especificar Testes de Aceitação;

• Teste DEVEM fazer parte do processo;

• Automatização de Testes de Aceitação

• FitNesse (FIT based)

• Tipos de testes
• User Interface testing;
• Usability testing;
• Performance testing;
• Stress testing;

Daily Meeting

• O que fiz desde a última reunião?

• O que pretendo fazer até a próxima;

• Estou tendo impedimentos?

17
 31/03/2010

As armadilhas das reuniões diárias

• Reunião diária não é coffee-break

• Reunião diária não é bate-papo

•Reunião diária não é “conversa sobre a

relação”

• Reunião diária não é julgamento

Review Meeting

• Apresentação do resultado da iteração para

os clientes

• Todos os envolvidos no projeto participam

18
 31/03/2010

Possíveis consequências da Review Meeting

• Devolver ao Product Backlog funcionalidades não terminadas e repriorizá-las

•Remover do Product Backlog funcionalidades que foram finalizadas

antecipadamente

• Trabalhar com o ScrumMaster para reformular a equipe

• Repriorização do Product Backlog

•Solicitar o fechamento de um Release com as funcionalidades demonstradas,

sozinhas ou com o incremento de Sprints anteriores

• Escolhar não avançar mais com o projeto e não autorizar outra Sprint

• Solicitar que o progresso do projeto seja acelerado autorizando a inclusão de

times adicionais para trabalhar no Product Backlog

Retrospectivas

• Melhoria de processos no final de cada Sprint

• Falicitada pelo ScrumMaster

• O que foi bom? O que deve ser melhorado?

• O ScrumMaster prioriza os itens citados de acordo com

a direção do time
• O time propõe soluções para a maioria dos problemas
que a atrapalham/irritam
• Retrospectivas são a essência do conceito de inspeção
e adaptação

19
 31/03/2010

Priorização do Product Backlog

• O Product Owner é o responsável por manter o Product Backlog

priorizado. Esta priorização preferencialmente deve acontecer antes
do início da Sprint Planning Meeting, mas pode ser refinada no seu
decorrer

• Boas técnicas de priorização:

• Kano
• Theme Screening
• Priorization Poker

Sprint Planning Meeting

• A Sprint Planning Meeting ou Reunião de Planejamento, é dividida

em duas partes, e entra em cena no início de cada Sprint.

• Além de todos os comprometidos (PO, SM e Time), alguns

envolvidos podem ser convidados a participar em determinados
momentos da reunião, desde que agreguem valor à mesma e
tenham seu convite aprovado pelo Product Owner.

• Pela prática, percebemos que a duração desta reunião segue a

seguinte tabela:

20
 31/03/2010

Planejamento de Release

Continua planejando Releases até que a Visão do produto seja alcançada

Selecionar
um tamanho
de Sprint

Determinar as Estimar os Estimar Selecionar

condições de Itens do velocidade Itens e data
satisfação Backlog
do Release
Priorizar
User Stories

Estimando o Product Backlog

• O esforço estimado para os itens do Product Backlog deve ser

negociado entre o time e o Product Owner, sempre praticando o
bom senso e não sendo influenciados por alguma pressão
exercida por nenhuma das partes;

• Existem diversas técnicas de estimativas que podem ser

utilizadas em projetos Scrum. O Planning Poker é uma das mais
populares, onde, através de cartas com numeração seguindo a
tabela de Fibonacci, os membros do time “sugerem” um tamanho
(size) para os itens do Product Backlog.

21
 31/03/2010

Estimando o Product Backlog

1 2 3 5 8 13 21

Por que o Planning Poker funciona?

•Porque o Planning Poker apresenta múltiplas opiniões de

especialistas quanto à estimativa de um item, e como Scrum trabalha
com times multi-funcionais, é sempre importante ter um consenso
quanto a este fator;

•Porque o Planning Poker estimula o dialogo durante os rounds, e

cada membro do time tem que explicar para todos os outros membros
o porque estimou o item com aquele tamanho. Todo este processo
gera compartilhamento de conhecimento;

• Estudos mostram que estimas feitas em grupo vem sendo bem mais
bem sucedidas que estimativas individuais;

22
 31/03/2010

Do tamanho para a duração

Tamanho Cálculo Duração

30 pag. por
300 páginas 10 semanas
semana

Scrum Board (Kanban)

16

23
 31/03/2010

Sprint Burndown

Project Burndown

24
 31/03/2010

Redefinição de Artefatos

Se todos os artefatos e documentação requeridos por uma

organização não tem sido totalmente definidos e não são bem
conhecidos pelo time de desenvolvimento, o seguinte trabalho
deve ser feito antes de entregar muitos incrementos:

“Definir TODA a documentação e artefatos que são parte de

cada incremento de funcionalidades do produto, sempre
respeitando a cultura da empresa”

Times Scrum

• Times Scrum são:

• Auto-organizados
• Multidisciplinares
• Compostos por no máximo 9 integrantes
• Comprometidos com o trabalho
• Responsáveis por fazer aquilo que for necessário para atingir a
meta da Sprint
• Comunicativos
• Organizadas em um espaço físico apropriado para o trabalho
• Responsáveis pela resolução de conflitos

25
 31/03/2010

Times Scrum
• Regras de times Scrum:

• Nunca usam a palavra “você” porque a outra pessoa pode se

sentir no centro do problema e agir na defensiva
• Nunca se remete a uma história (“Há três meses atrás você
disse que...”)
• Seja pontual nas reuniões; se atrasar peça desculpas e pague
uma “penalidade”
• Se todo mundo está falando ao mesmo tempo, use algum
objeto para determinar quem fala. Aquele que está com o objeto
fala, o resto escuta
• A opinião de todos é importante e precisa ser entendida e
levada em consideração
• Sem “palavrões”

Critérios de sucesso para times Scrum

• Times pequenos
• Missão clara

• Liderança apropriada

• Todos os papéis necessários: ScrumMaster, Analista de

Negócios, Tester, Desenvolvedor, Escritor Técnico, etc.
• Bom entendimento das necessidades do cliente

• Garantia de que os recursos e pessoas necessárias estão

disponíveis
• Auto-gerenciamento fluente

• Práticas de engenharia e de outras disciplinas presentes

26