Minicurso SCRUM

Scrum
Gestão ágil de projetos
Autores:
Fábio Abrantes Diniz

Íthalo Bruno de Moura

Thiago Reis da Silva

Diego Grosmanniz

Scrum
Apresentadores:



31% são cancelados
53% custam o dobro do estimado
Apenas 16% são completados no
prazo e custo estimados
* dados do CHAOS report

Falta de envolvimento do usuário

Requisitos e especificações incompletas

Falta de suporte da direção

Falta de Pessoas e Recursos

Falta de ESTIMATIVAS!!!

Falhar é uma maneira muito
forte de aprendizado, mas é
preciso parar de
apontar culpados

Olá, Scrum!
Por que o nome Scrum?

O nome é proveninente de uma jogada do Rugby, onde
é demostrada a força de trabalho em equipe.

O Scrum do Rugby é formado por até 8 pessoas de
cada equipe.

O objetivo do Scrum no Rugby é avançar a bola oval no
campo adversário o máximo possível. Para isso é
necessário um ótimo trabalho em equipe.

Scrum é também um meio de
evidenciar os
problemas

Mas Scrum não
é bala de
prata*

* Não mata vampiros & afins
* Exige trabalho duro e comprometimento

Quem usa o Scrum

• Microsoft
• Yahoo
• Google
• Lockheed Martin
• Philips
• Siemens
• Nokia
• BBC

Scrum tem sido usado para

• Software comercial
• Desenvolvimento interno (empresa)
• Desenvolvimento contratado (terceirização)
• Aplicações financeiras
• Sistemas embarcados
• Jogos
• Sistemas para controle de satélites
• Websites
• Telefones celulares

Características do Scrum

• As equipes se auto-organizam

• O produto evolui em uma série de “Sprints”
mensais

• Os requerimentos são listados em um “Product
Backlog”

• Não há prática de engenharia prescrita (o Scrum
adequa-se a todas)

• É uma das “metodologias ágeis”

Product Owner

• O representante do cliente

Scrum Master

• O Scrum Master lidera o time de
desenvolvimento

Scrum Team

• Scrum Team São os membros que
formam o time de desenvolvedores,
designers, consiste de 5 a 9 pessoas.

Papéis e Responsabilidades

► Define as funcionalidades do produto assim como conteúdo e
data das liberações;
Product Owner
► Responsável pela rentabilidade do produto;
► Prioriza as funcionalidades de acordo com o valor do mercado;
► Pode mudar as funcionalidades e priorizar a cada 30 dias;
► Aceita ou rejeita os resultados do trabalho.

► Garante que a equipe está completamente funcional e produtiva;
Scrum Master ► Facilita comunicação entre papéis e remove impedimentos;
► Protege a equipe contra interferências externas;
► Assegura que o processo é seguido;
► Coordena os encontros diários, revisão e planejamento da
iteração.
►Estimar itens do backlog
Team ► Tem o direito de realizar quaisquer atividades para alcançar
o objetivo da iteração desde que respeite os guidelines do
projeto;
► Auto organizados para entregar o que o PO quer.

© 2006 BenQ Mobile 26

Ciclo de Vida

Ciclo de vida do Scrum
Fonte: Adaptado de Improve It (2008)

O Product Backlog é uma lista de
todas as funcionalidades desejadas no
produto, estimadas pelo time e priorizadas
pelo
Product Owner.

O Product Backlog
Emergente
Priorizado e estimado
Maior prioridade, mais detalhes
Priorização é tarefa do PO
Alinhado ao plano de negócios

O Product Backlog
Emergente
Qualquer um pode contribuir

Sprints

• Representa um Time Box (uma iteração), dentro do
qual um conjunto de atividades deve ser executado

• Ocorre em um período de duas a quatro semanas

• Baseia-se na idéia de que um período constante
leva a um melhor “ritmo”

• O produto é projetado, codificado e testado durante
o Sprint

• No início de cada Sprint, faz-se um Sprint
Planning Meeting

Sprints
- Sprint Planning Meeting -
• É uma reunião de planejamento na qual:
o O Product Owner prioriza os itens do Product
Backlog
o O Scrum Team determina que atividades será
capaz de implementar durante o novo Sprint e
cria o Sprint Backlog
o O Scrum Team e o Product Owner definem um
objetivo para o Sprint
• O sucesso do Sprint será avaliado mais adiante no
Sprint Review Meeting em relação ao objetivo
traçado para o Sprint

Sprints
- Sprint Backlog -
• É uma lista de tarefas que o Scrum Team se
compromete a fazer em um Sprint

• Seus itens são extraídos do Product Backlog com
base nas prioridades definidas pelo Product
Owner
• Uma estimativa do tempo necessário para a
implementação das funcionalidades

• O Scrum Master mantém o Sprint Backlog
atualizado

Sprints
- Daily Scrum -
– É uma reúnião diária da equipe dentro do Sprint, que
tem por objetivo:
o Disseminar conhecimento sobre o que foi feito no
dia anterior
o Identificar impedimentos
o Priorizar o trabalho a ser realizado no dia que se
inicia
– Os impedimentos identificados devem ser tratados
pelo Scrum Master o mais rapidamente possível

Obs: o Daily Scrum não deve ser usado
como uma reunião para resolução de
problemas

Sprints
- Daily Scrum -
• Três Questões para todos:

• O que fizeste ontem?
• O que vais fazer Hoje?
• Há Algum obstáculo?

• Obs: As respostas não são um
relatório para o Scrum Master. Elas
são comprimissos dentro do Scrum
Team.

Sprints
- Sprint Review Meeting -
O ScrumTeam e o SCRUM Master
apresentam ao Product Owner os resultados
alcançados durante o sprint.

Sprints
- Sprint Retrospective -
O Sprint Retrospective ocorre ao final
de um Sprint e serve para identificar o
que funcionou bem, o que pode ser
melhorado e que ações serão tomadas
para melhorar.

Todos participam:
–Scrum Master
–Product Owner
–Scrum Team

Sprints
- Sprint Retrospective -
Em uma das maneiras de se conduzir
um Sprint Retrospective, a equipe
discute o que gostaria de:

– Iniciar a fazer
– Parar de fazer
– Continuar fazendo

Estudo de Caso: O Projeto XMPM (1)
Características do Projeto

• Software desktop destinado a usuários finais de celulares BenQ-
Siemens
• Projeto complexo com 300,000 LOC possuindo um ciclo de vida
médio

→ Interação complexa com o ambiente físico (celular)
→ O software deve suportar diferentes modelos de celulares e rodar em
diferentes distribuições do Linux
→ Uma série de versões intermediárias (builds) precisam ser
desenvolvidas e testadas.
→ Desenvolvido por três parceiros situados fisicamente em localidades
diferentes.
→ Necessidade de boa comunicação entre as equipes de
desenvolvimento.
→ Definição clara de papéis e responsabilidades.


Características do Produto
→ Suporte a 9 (nove) diferentes idiomas;
→ Possui instalador gráfico para as seguintes
distribuições (supporte oficial):
- Suse 10
- Ubuntu 5.10
- Mandriva 2006
XMPM

→ Algumas das funcionalidades do XMPM incluem:
- Sincromização de contatos, tarefas, notas e calendário entre o
telefone celular BenQ-Siemens e KDE-Kontact.
- Acesso à internet através de uma conexão GPRS.
- Acessa ao sistema de arquivos e suporte a diferentes formatos de
música.


Práticas adaptadas para o contexto do projeto

Sprint:
- No projeto XMPM foram usados 5 sprints e cada sprint com duração
de aproximadamente 30 dias.

- Sprints de 30 dias fornecem uma melhor visibilidade dos objetivos do pro
e comprometimento da equipe.
- Iterações mais curtas podem melhorar a visibilidade do projeto
e permitir que riscos e incertezas sejam eliminados
o mais rápido possível.


Planejamento do Sprint:

- Duas reuniões são conduzidas no ínicio de cada iteração.
- A primeira é realizada internamente com o product owner e visa refinar e
priorizar o backlog do produto.

- A segunda é realizada com os parceiros e visa criar o backlog do sprint
de modo a atender os objetivos da iteração.




Revisão do Sprint:
- A equipe apresenta no final de cada iteração os resultados
obtidos (software funcionando) para o product owner e parceiros.

- Esta prática impõe que a equipe trabalhe arduamente para alcançar os
objetivos prometidos para a iteração.


Reunião de Retrospectiva:

- O Scrum master e a
equipe participam desta
reunião.

- O que deu certo durante
o sprint e o que poderia
ser melhorado.


Reuniões Diárias do Scrum:
- As reuniões diárias ajudam a saber o quê cada membro da
equipe está fazendo, compartilhar conhecimento e fornece uma
boa visão para o Scrum Master.

- O quê você fez desde o último report?
- O quê você irá fazer até a próxima reunião?
-Existe algum bloqueio para alcançar os objetivos
da iteração?
- Alguma lição aprendida ou decisão tomada?



Builds Diários:
- Builds diários no branch de cada parceiro e um build semanal
no ramo principal do projeto (uso de padrões de gerência de
configuração).


Práticas sendo adaptadas para o contexto do projeto

Teste antes do desenvolvimento:
- Esta prática força o desenvolvedor pensar
sobre o que o código deveria fazer antes de
realmente implementá-lo.
- Caso o desenvolvedor não seja capaz de
escrever o caso de teste para o código então
provavelmente existem problemas de projeto.
- Depois de criar e executar o teste unitário, o
mesmo torna-se apenas uma instância de testes
de regressão.

- Esta prática é simples em conceito, mas
requer intensa preparação técnica.


Resumo e Perspectiva
Resumo

• O fator terceirização adiciona mais complexidade ao uso do
Scrum.
• As práticas melhoram a visibilidade do projeto e reduzem riscos e
incertezas no início do ciclo de desenvolvimento.
• A prática “revisão do sprint” exige que a equipe se esforce para
cumprir com os objetivos prometidos da iteração.
• A prática “teste antes do desenvolvimento” evita a criação de
classes complexas e assegura a qualidade do código.

Perspectiva

• Adaptação dos métodos ágeis para desenvolvimento de
sistemas embarcados.


Conclusão

Scrum é uma metodologia de gerenciamento de projetos que está se
tornando cada vez mais comum na industria de software. É bastante
eficiente quando utilizado por equipes pequenas, mas pode
tranquilamente ser usado em projetos com grandes equipes.

O Scrum tem como vantagens a velocidade, um bom controle do
cronograma, diminuição dos riscos e incertezas e a visibilidade -
graças às constantes reuniões.

Por outro lado, a grande desvantagem do Scrum é a sensação de
informalidade, devida a falta de documentação formal do
software.

• http://br.groups.yahoo.com/group/scrum-brasil/
• http://blogdoabu.blogspot.com/2008/11/planning-poker.html
• http://planningpoker.com/
• http://netfeijao.blogspot.com/2008/10/estimativas-geis-
planning-poker.html
• Ken Schwaber. Agile Project Management with Scrum. Ed.
Microsoft Press 2004
• Abrahamsson, Pekka, Salo, Outi, Ronkainen, Jussi &Warsta,
Juhani. Agile Software Development Method, Review and
Analysis. Espoo 2002. VTT Publications 478. 107p
• Henrik Kniberg. Scrum and XP Direto das trincheiras. Ed.
Enterprise Software Development Community, 2007.

Planning Poker
An agile estimating
technique for agile and
Scrum teams
Apresentadores:

É difícil estimar tempos
de execução

Time*

*Tudo eu! Tudo eu!

Responsabilidades:
• Estimar itens do backlog

• Se comprometer a entregar um incremento
funcional de software
• Gerenciar o próprio progresso

• Auto organizados para entregar o que o PO quer

Reunião de Estimativa:
• Preparação para o Sprint Planning
• Estimar baseado no tamanho, nunca
em tempo
• Atualizar Product Backlog com as
estimativas
• Importante para o PO criar o release
plan

O Product Backlog
Emergente
Qualquer um pode contribuir
Sempre visível

Scrum foca em

tamanho e
não em duração

Estimar em tamanho
relativo é mais simples

Planning Poker
• É um método eficiente que estima o
tamanho dos requisitos em times que
adotam métodos ágeis (SCRUM, XP).1

• O método foi primeiramente descrito por
James Grenning em 2002 e, mais tarde
popularizado por Mike Cohn no livro Agile
Estimating and Planning.

1 – É uma variação do método de estimativa Wideband Delphi (1940)

Planning Poker
• As estimativas acontecem em reuniões:
– Geralmente 4 ou 8 horas.
– Paticipantes:
• Todos os membros do time do Scrum;
• O PO somente esclarece os requisitos e não
estima junto a equipe;
• O Scrum Master registra os resultados, não
interferindo nas estimativas do time;
• A equipe não deve ser superior a dez pessoas.

O Processo
1. Cada membro do time recebe um deck
de cartas:
 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? e
“pausa”.

http://en.wikipedia.org/wiki/Planning_poker

O Processo
2. Os itens a serem estimados são lidos pelo
PO ou SM
 A equipe decide qual o menor item de backlog
disponível.

http://blogdoabu.blogspot.com/2008/11/planning-poker.html

O Processo
3. Após a estimativa inicial, esse item é
marcado como “2” pontos
 Serve para definir uma referência de tamanho
e complexidade para ser usada nas demais
estimativas.
 E deve ficar registrado para uso nas futuras
reuniões.
 Em casos excepcionais o time pode decidir mudar
esta estória de referência por uma outra.

O Processo
4. Para cada estória o SM ou PO lê a
descrição e os critérios da aceitação da
mesma.
 São respondidos questionamentos a
respeito da estória;
 Manter a discussão em alto nível, não entrar em
detalhes.
 Tempo prefixado (timebox) nesta etapa.

O Processo
5. Cada desenvolvedor escolhe em silêncio
a carta que representa sua estimativa.
 O moderador pede para todos mostrarem
as cartas.

http://blogdoabu.blogspot.com/2008/11/planning-poker.html

O Processo
6. Se todas as estimativas convergirem, a
estimativa está feita e o processo volta
ao início, para um novo item.
 Se houver uma grande variação na
estimativa, aqueles que apresentaram o(s)
maior(es) e o(s) menor(es) valor(es) se
justificam.
 O processo se repete até todas as
estimativas convergirem.

Dinâmica
• Grupo

• São Paulo
• Rio Grande do Norte
• Paraíba
• Goiás
• Amazonas
• Sergipe
• Paraná

Conclusões
• O Planning Poker é uma prática eficiente de
estimação de requisitos
• Por ser uma técnica bastante flexível, se
enquadra
• É uma prática que envolve todo o time
– Ajuda times novos a se conhecerem
• Realmente funciona!!!

Referências
• http://br.groups.yahoo.com/group/scrum-brasil/
• http://blogdoabu.blogspot.com/2008/11/planning-poker.html
• http://planningpoker.com/
• http://netfeijao.blogspot.com/2008/10/estimativas-geis-planning-
poker.html
• Ken Schwaber. Agile Project Management with Scrum. Ed. Microsoft
Press 2004
• Abrahamsson, Pekka, Salo, Outi, Ronkainen, Jussi &Warsta, Juhani.
Agile Software Development Method, Review and Analysis. Espoo
2002. VTT Publications 478. 107p
• Henrik Kniberg. Scrum and XP Direto das trincheiras. Ed. Enterprise
Software Development Community, 2007.

Minicurso SCRUM

Mais conteúdo relacionado

Mais procurados

Semelhante a Minicurso SCRUM

Mais de Thiago Reis da Silva

Minicurso SCRUM