Material Workshop Scrum foundation - Fernando Cunha

INSTRUTOR: FERNANDO CUNHA
Email: fecunhainfo@gmail.com
https://www.linkedin.com/in/fernandocunha2

Agenda- Parte I
• INTRODUÇÃO
• HISTÓRIA
• SCRUM
• VALORES DO SCRUM
• PILARES
• PAPÉIS E RESPONSABILIDADES
• EVENTOS E ARTEFATOS

Agenda – Parte ||
• HISTÓRIAS
• ESTIMATIVAS
• BURNDOWN CHARTS
• MITO OU VERDADE
• FERRAMENTAS
• CONCLUSÃO
• AVALIAÇÃO

O que é!?
O QUE É DESENVOLVIMENTO ÁGIL?
ou Método ágil é um conjunto de metodologias de
desenvolvimento de software.
O desenvolvimento ágil, tal como qualquer metodologia de
software, providencia uma estrutura conceitual para reger projetos
de engenharia de software, ou seja, projetos que visam entregar
um software como produto.

Um pouco de história...
As definições modernas de desenvolvimento de software ágil evoluíram a
partir da metade de 1990. Surgiram em virtude da grande regimentação e
micro gerenciamento usado o modelo em cascata para desenvolvimento.
Alguns métodos ágeis:
• Scrum (1986);
• Crystal Clear;
• Programação extrema (XP)(1996);
• Adaptive Software Development;
• Feature Driven Development;
• Dynamic Systems Development Method (1995);

O Manifesto Ágil
Em 2001, um grupo de profissionais, entre eles os criados do Scrum Jeff
Sutherland e Ken Schwaber (criadores do Scrum), criaram o "The Agile Manifest",
contendo 12 princípios:
01 - Satisfazer o cliente através da entrega continua e adiantada de software com
valor agregado;
02 - Mudanças nos requisitos são bem-vindas;
03 - Entregar frequentemente software funcionando;
04 – Pessoas, negócios e desenvolvedores no mesmo time;
05 - Indivíduos motivados;
06 - Colaboração - conversas face a face;

O Manifesto Ágil
07 - Software funcionando é a medida do progresso;
08 - Os processos ágeis promovem desenvolvimento sustentável;
09 - Continua atenção a excelência técnica e bom design aumenta a
agilidade;
10 - Simplicidade - a arte de maximizar a quantidade de trabalho não
realizado é essencial;
11 - As melhores arquiteturas, requisitos e design surgem de equipes auto
organizáveis;
12 - Em intervalos regulares, a equipe reflete sobre como se tornar mais
eficaz;

Scrum
É um framework com o qual as pessoas podem resolver problemas
complexos e adaptáveis.
Scrum consiste em um Time Scrum e seus Papéis, Eventos e Artefatos.
Ele se baseia na teoria de controle empírico, onde diversos imprevistos
ocorrem.
Time Scrum = auto organizado
Valores de Scrum:
Foco - Coragem
Sinceridade - Comprometimento
Respeito

Scrum
Pilares:
01 - Transparência
Seja mais específico?
02 – Inspeção
Inspecionar o que?
03 – Adaptação
Dê um exemplo por favor?
Todos os jargões devem ser compartilhados (Definition of Done, a definição de “pronto” dos
clientes e da equipe são a mesma).
Averiguar com frequência os artefatos (backlog do produto, backlog do Sprint, burndown…) e
progressos do projeto, para encontrar problemas ou oportunidades;
Principalmente através dos eventos:
Sprint Planning Meeting - Daily Scrum - Sprint Review - Sprint Retrospective;

Product Owner
Esse papel é o responsável pela Visão do que você vai construir ou entregar em seu projeto.
Dentro de suas responsabilidades, o Product Owner(PO) leva em consideração os riscos e os
benefícios, o que é possível, o que pode ser feito, em outras palavras, é quem diz o que
precisa e o que não precisa ser feito em relação ao produto que está sendo desenvolvido.
“Sem um Product Owner, não há Scrum” Jeff Sutherland
“Para que o Product Owner tenha sucesso,
toda a organização deve respeitar as suas decisões. “ Guia do Scrum™
Ele o responsável pelo resultado do projeto e conhece as necessidades

Scrum Master
Ele vai orientar o restante da equipe em relação à estrutura de processos do Scrum,
além de ajudar a eliminar qualquer obstáculo que os esteja deixando mais lentos ou
que impeça o progresso das atividades.
é o responsável também pela aplicação das regras. Uma parte fundamental desse
papel é proteger a equipe e mantê-la focada nas tarefas em mãos.
“O Scrum Master faz isso para garantir que o Time Scrum
adere à teoria, práticas e regras do Scrum” Guia do Scrum™
O que ele é:
• Facilitador (garante que o processo seja seguido)
• Protege o time
• Remove impedimentos
• Auxiliar o PO
O que ele não é:
• Programador
• Analista de negócio
• Líder da equipe, pois a equipe é auto-organizada

Developer Team
Em Scrum, todo o desenvolvimento é feito pelo Development Team.
Para isso, é necessário que ele seja composto de pessoas de diferentes perfis profissionais,
como: analistas, arquitetos, designers, desenvolvedores, testadores etc.
“O Development Team deve ser auto-suficiente”
O Time é responsável por desenvolver incrementos potencialmente entregáveis do produto,
segundo a Definition of Done (DOD) pré-estabelecida.
O time auto-gerenciado tem autoridade sobre o trabalho que fazem, assim também como são
responsáveis por ele.
“Responsável por desenvolver o produto...”
“Promove a colaboração...”
• Normalmente pequeno (até 8 pessoas);
• Reforçam o conceito de DONE!
• Não ficam esperando por tarefas, vão e pegam (Pro-
Ativos).
• Orientado a entrega.

Quem é o gerente?
No Scrum não existe uma gerência centralizada, no entanto, existe a gerencia descentralizada:
Product Owner, gerenciando o que de ser entregue, Scrum Master auxiliando a equipe para o Scrum
seja executado e a equipe que é autogerenciada.

Developer Team
Os 4 estágios da auto-organização, por Bruce Tuckman (psicólogo 1965)
Forming:
É o início da formação do Time, onde ninguém ainda se conhece;
Storming:
É quando os membros do time passam a se conhecer e ainda não estão habituados ao
comportamento
uns dos outros.
Norming:
É quando o membros começam a aparar as arestas, criando algumas normas ou regras
implícitas;
Performing:
Quando o time começa a funcionar de forma sincronizada e com isso melhorando o
desempenho. O Scrum Master tem papel fundamental atuando como facilitador
principalmente.

• Histórias / Tarefas
• Product backlog
• Sprint backlog
• Burndown charts
Artefatos
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum meeting
Eventos

Sprint
O Scrum possui alguns eventos de duração fixa (time-boxed) realizados em intervalos
regulares.
Cada um destes eventos são oportunidades para inspeção e adaptação.
Sprint
Todo o desenvolvimento em Scrum é feito de forma iterativa e incremental, essas
interações
são chamadas Sprints.
Cada Sprint tem duração de até um mês, mas geralmente tem duração de duas semanas,
o que permite feedbacks constantes do Product Owner (PO) quanto ao produto sendo
desenvolvido.
A Sprint consiste em um container de outros eventos que são:
Sprint Planning, Daily Scrum, Sprint Review e Sprint Restrospective

Sprint Planning
Objetivo: Planejar o que será feito na Sprint
Quando: Sempre antes do início de cada Sprint
Quem participa:
Scrum Master, Developer Team e Product Owner se
necessário
Tempo: 8 horas para Sprint de 1 mês e é reduzido de
forma proporcional.

Sprint Planning
Funcionamento:
A reunião é dividida em duas partes e tem igual duração.
Parte 01:
O Development Team faz a previsão das funcionalidades que serão
desenvolvidas durante o Sprint.
Somente o Development Team é capaz de avaliar o que consegue
realizar durante a Sprint.
A saída dessa reunião é a Meta do Sprint, ou seja, o itens selecionados
do (Product Backlog), que deverão serem desenvolvidos. (esboço do
Sprint Backlog).

Sprint Planning
Parte 02:
É uma reunião de planejamento que o Development Team
decide como transformará os itens selecionados em um
incremento durante o Sprint.
Como o time é autogerenciado, se coordena para
decompor os itens em unidades de uma dia ou menos, o
suficiente para os primeiros dias do Sprint.
Após essa organização o Sprint Backlog está completo.

Daily Scrum
Objetivo: Comunicação e sincronização do trabalho. Ela
faz parte do ciclo de Inspeção e adaptação do Scrum.
Através dessa análise diária é possível corrigir algum
problema no processo.
Quando: Diariamente
Quem participa:
Scrum Master, Developer Team e Product Owner
(opcional)
Tempo: 15 minutos

Daily Scrum
Funcionamento:
Cada membro da equipe responde para os outros
membros:
• O que fiz desde a última Daily Scrum?
• O que pretendo fazer até a próxima Daily
Scrum?
• Existe algo me impedindo de concluir alguma
tarefa?

Daily Scrum
Funcionamento:
Após a última atualização do – Guia do Scrum™ 2013
• O que fiz ontem que ajudou o time a atingir a
meta do sprint?
• O que vou fazer hoje para ajudar o time a
atingir a meta do sprint?
• Existe algum impedimento que não permita a
mim ou ao time atingir a meta do sprint?

Sprint Review
Objetivo: Inspecionar o que o Development Team
produziu, colher opiniões dos presentes da reunião e caso
necessário, adaptar o plano para o Sprint seguinte.
Nessa cerimônia o PO valida ou não o Sprint.
Quando: No final de cada Sprint
Quem participa:
Scrum Master ,Developer Team e Product Owner ou
qualquer interessado no Produto.
Tempo: 2 horas

Sprint Review
Funcionamento:
• O Time comenta dos problemas enfrentados e soluções
encontradas
• O Time demonstra algumas funcionalidades produzidas
no Sprint
• O PO valida ou não o Sprint, de acordo com a Meta
estabelecida
• Se necessário o Time adapta o plano para o novo
Sprint

Sprint Retrospective
Objetivo: Aprimoramento do processo, a interação com os membros
do Time Scrum, as práticas utilizadas, o que funcionou e o que precisa
ser melhorado na próxima Sprint.
*Os membros do Time, não devem encarar alguma crítica como
pessoal
Quando: Imediatamente após o Sprint Review.
Quem participa:
Scrum Master ,Developer Team e Product Owner (opcional)
Tempo: 3 horas, caso a Sprint seja de 1 mês.

Ciclo de Reuniões Completo
a
Estimativa Planning 1 Planning 2 Daily Review Retrospective
• Estima o tamanho das próximas Histórias relevantes,
gerando o product backlog priorizado;
• Preparação para o release planning;
• Visão de negócio;
• 2 horas

Ciclo de Reuniões Completo
a
• Define o objetivo da iteração e quais Histórias serão
atacadas;
• Agenda todas as próximas reuniões com seus objetivos e
participantes;
• Selected Backlog é criado;
• Discute-se pontos de atenção.
• 4 horas para Sprint de 01 mês

Planejamento do Sprint (Planning 2)
a
Preparando-se para a guerra...
• Tarefas são criadas e tempos estimados
COLABORATIVAMENTE!
• Tarefas são menores que um dia;
• Cada membro escolhe suas tarefas;
• Sprint Backlog é criado;
• 4 horas para Sprints de 1 mês

Scrum meeting
a
A hora da verdade...
• 15 minutos diários!
• Todos ficam em pé.
• Não é para se resolver problemas.
• Somente pessoas do time são envolvidas.
• Um fala por vez.
• Ajuda a evitar reuniões desnecessárias.

Sprint Review
a
O que aconteceu durante o Sprint.
• Tem a forma de uma demo;
• Tudo que o time completou é
apresentado;
• O PO aceita ou não o Sprint;
• Normalmente leva 2 horas;

Retrospectiva do Sprint
a
Lavando roupa suja.
• 3 hrs para Sprint de 1 mês;
• Discute-se o que não funcionou e o
que funcionou.
• O time todo participa, inclusive o
cliente pode ser convidado!

Tempos e reuniões
a
Estimativa
Prioriza e prepara o Product BL
2 horas
Planning 1
Seleciona os itens do Product
Backlog
1 hora
Planning 2
Cria-se as tarefas e owners
2 horas
Daily
Revê o andamento do projeto
15 minutos
Review
Verifica se as metas foram
atingidas
1 hora
Retrospective
Analisa os pontos fortes e
fracos
15 a 30 min

a
Estimativa
Planning 1
Planning 2
Daily
Review
Retrospectiv
a
24h
• O ciclo se repete até o fim de todos itens do
Backlog;
• É muito importante trabalhar com versionamento
de código fonte e documentação;
• Para cada novo Sprint sugere-se criar uma Branch de
desenvolvimento;
• Ao fim de cada Sprint, cria-se uma TAG para
representar o entregável IMUTÁVEL;
• Então esta TAG é comitada para o HEAD (merge);
Boas Práticas de Engenharia de
Software

• Product Backlog
• Sprint Backlog
• Definition of Done – Regras
• Product Increment – Entrega
• Task Boards

O que é:
É uma lista ordenada criada pelo Time Scrum, mas onde
somente o PO pode inserir, remover e reordenar os itens e que cada
item deve ter um valor de negócio associado (Business Value), onde
podemos medir o retorno do projeto e priorizar a realização dos itens.
Objetivo:
• Criação de todos os itens desejáveis do Produto.
Product Backlog

Product Backlog
a
Pontos importantes:
• Além dos itens de negócio ou funcionais, os itens não-funcionais também
devem constar na lista como:
Desenvolvimento de arquitetura, análise de tempo de resposta e itens
de infraestrutura.
• O formato utilizado para estes itens é o de User Stories.
• Os itens mais importantes ou os de maior conhecimento, ficam no topo e
serão implementados antes.

O que é:
É o conjunto de itens selecionados para serem
implementados durante a Sprint, mais o plano para
transformá-los em um incremento.
Objetivo:
Tornar visível o trabalho necessário para o Team
Development atinja a meta do Sprint.
Para isso somente o Time, pode adicionar tarefas, caso
descubram, no decorrer do Sprint, que mais trabalho
seja necessário.
É utilizado o task board para facilitar a visibilidade das
atividades.
Sprint Backlog

a
Entendendo os diferentes Blacklogs
BlacklogProduct
São todos os itens
desejados no
produto como um
todo. Sejam
funcionais ou não
funcionais. Release
São os itens que
irão ser
contemplados em
um release. Um
release tem um
planejamento
maior, pode ter
janelas de meses ou
anos dependendo
Sprint
São os itens que
serão
implementados no
intervalo
estabelecidos do
Sprint, e farão parte
portando do ciclo
de
desenvolvimento.

O que é:
Como Scrum não define quaisquer práticas de
engenharia de software para o Development Team, por
outro lado recomenda-se que utilize práticas ágeis
para garantir a qualidade do entregável.
Objetivo:
É ter uma definição do que é uma funcionalidade
“pronta”.
Por exemplo: teste unitários e integrados ok e
homologada pelo PO.
O DoD é importante para que todo o time saiba o que
é “pronto”, desde do cliente ao Development
Definition of Done

Ao final de cada Sprint, o Development Team entrega o incremento do
produto, resultado do que foi produzido durante o Sprint.
Esse resultado permite que o Product Owner (PO) perceba o valor do
investimento e decida ou não coloca-lo em produção e esse é um dos
princípios do Scrum.
Product Increment

Scrum – Visão Geral do Ciclo de Vida
a

Objetivos dos quadros
O objetivos dos quadros é dar maior visibilidade no andamento das histórias.
O quadro padrão do Scrum possui 4 colunas, são elas:
Sprint
Backlog
To Do Doing Done
É onde ficam
as Estorias a
serem
desenvolvida
s no Sprint
São as
tarefas
pertencentes
as estórias
que estão
aptas a
serem
realizadas
São as
tarefas
pertencentes
as estórias
que estão
em
desenvolvim
ento por
algum
membro do
time
São as
tarefas
finalizadas.
A estória é
movida para
essa colunas
, somente
após todas
as tarefas
tenha sido
finalizadas

Objetivos dos quadros
Para melhorar a visibilidade, o card de tarefa, poderá ter o nome de quem a está executando. Outro ponto
importante é a necessidade de incluir outras colunas, como por exemplo :
“Em Testes”, “Aguardando validação”, no entanto, cuidado para não virar um quadro Kanban.
Sprint
Backlog
To Do Doing Done
É onde ficam
as Estorias a
serem
desenvolvida
s no Sprint
São as
tarefas
pertencentes
as estórias
que estão
aptas a
serem
realizadas
São as
tarefas
pertencentes
as estórias
que estão
em
desenvolvim
ento por
algum
membro do
time
São as
tarefas
finalizadas.
A estória é
movida para
essa colunas
, somente
após todas
as tarefas
tenha sido
finalizadas
Testing

Kanban
Kanban foi um método criado pela Toyota, com o objetivo de sinalizar os passos de sua
produção.
O quadro Kanban possui algumas diferenças importantes em relação ao quadro Scrum.
As mais importantes são:
KANBAN SCRUM
WIP* – limitado diretamente
No Kanban quando chega no limite de WIP, o
trabalho para, pois é um sistema puxado
WIP – limitado por Sprint
No Scrum o trabalho para somente quando as
atividades do Sprint finalizam
TimeBox opcionais TimeBox por Sprint
Estimativa opcional Estimativa prescrita
Não possui Papéis definidos Possui 3 papéis (visto anteriormente)
Não possui colunas obrigatórias e a mesmas
podem ser subdividas
Possui 4 colunas padrões
WIP* – Work In Progress

Exercício 01:
Crie um quadro Kanban, e crie as colunas levando em
consideração um equipe de infraestrutura de
sustentação.
Obs: coloque os WIPs de cada coluna.

• HISTÓRIAS
• ESTIMATIVAS
• REPORTS
• MITO OU VERDADE
• FERRAMENTAS
• CONCLUSÃO
• AVALIAÇÃO

•História de Usuário
• História Técnica
•Estrutura da História
•Técnicas para escrever
histórias
Histórias

História
Definição: Segundo AgileAlliance, a estórias são escritas através de entrevista com o
cliente ou com o PO, e o time divide o trabalho através de incrementos funcionais,
chamados de “users stories”.
Uma outra definição da Adaptworks, um pouco mais direta é que a Estória representa
uma funcionalidade ou característica do produto “narrada” pelo ponto de vista do usuário.
Lembrando que cada estória deverá entregar um Valor ao produto, que está sendo
desenvolvido.

Estrutura de uma História de Usuário
Quem? O que? Por que?
Como um <usuário>,
Gostaria de
<funcionalidade>
para <valor de negócio>
Exemplo 01:
Como um auxiliar de contabilidade,
Gostaria de poder
emitir boletos bancários para
facilitar o controles dos
recebimentos.
Exemplo 02:
Como um Cliente,
Eu gostaria de visualizar
os planos existentes
para decidir qual plano
devo comprar.

Técnica de Validação de Histórias
I NDEPENDENTE
N EGOCIÁVEL
V ALIOSA
E STIMÁVEL
P EQUENA
T ESTÁVEL

Os 3Cs segundo Ron Jeffries
Cards – histórias são escritas em cartões ou post-its
(cards), naturalmente forçando as histórias serem
pequenas
Conversation – A história escrita no cartão serve como
um lembrete, tornando-se um convite ao diálogo
(conversation)
Confirmation– O cliente define (implícita ou
explicitamente) um maneira de validar (confirmation)
esse pedido. Geralmente com testes de aceitação.

História Técnica versus História de
Usuário
Muitas vezes dentro dos projetos, no deparamos com requisitos técnicos e que
em nenhum momento foi solicitado pelo o usuário ou PO, por exemplo, efetuar
uma migração de um banco de dados e instalar e configurar um servidor.
Porém esses requisitos para o usuário final não agregam valor ao produto de
forma direta, no entanto, sabemos que são mandatórios e até mesmo impedem
que algum requisito funcional (user story) seja implementado.
O que fazer então?

Usuário
Trazendo um pouco para o desenvolvimento cascata, esses requisitos
geralmente são do tipo não-funcionais, no entanto, para
convencermos o PO e o Cliente do projeto, devemos vinculá-los ao
um ou mais requisitos funcionais (user story).
E com isso atualizar a estimativa de uma determinada historia afim de
auxiliar o PO a escolher ou não adicionar a história em um
determinado Sprint.
Requisitos funcionais
definem as funcionalidades do sistema como deve
reagir em condições específicas e como se comportar
em determinadas situações. Podem ainda declarar o
que o sistema não deve fazer. (PAULA FILHO, 2000).
Requisitos não funcionais
são restrições sobre serviços ou funções oferecidas
pelo sistema. Dentre elas destacam-se restrições de
tempo, sobre o processo de desenvolvimento e de
padrões. A descrição das restrições complementa a
definição de requisitos (PAULA FILHO, 2000).

“Entendi, quer dizer então que uma User Story pode conter um ou
mais requisitos funcionais ou requisitos de usuário e um Technical
Story pode conter um ou mais requisitos não-funcionais e essas
histórias podem estar vinculadas?”
USER STORY
Como um auxiliar de contabilidade,
Gostaria de poder
emitir boletos bancários para
facilitar o controles dos
recebimentos.
USER STORY
Como um Cliente,
Eu gostaria de visualizar os planos
existentes
para decidir qual plano devo
comprar
TECHNICAL STORY
Como Arquiteto de Sistemas
gostaria de projetar um servidor IIS
versão 8 com banco de dados
SQLSERVER versão 9 para suportar
a aplicação de ERP XPTO
Sim!
Usuário

a
Mapeamento de Histórias X Tarefas X Tarefa micro
• Como um administrador do site, desejo efetuar a manutenção dos usuários do mesmo;
• Adicionar/Editar usuário
• Consultar Usuários (12h)
• Consultar Usuários
• Esclarecer requisitos (1h)
• Escrever caso de teste (2h)
• Design GUI (2h)
• Implementar Stored Procedure de busca de usuário (3h)
• Integrar SP com Tela (2h)
• Executar Test Cases e evidenciar (2h)
História
Tarefas
Macro
Tarefa
Micro

a
Mapeamento de Épico X História X Tarefa
• Implementar cálculo de Dólar Marroquino;
• Como um analista de crédito do Banco Bradesco eu desejo poder consultar o Forecast do Dólar
marroquino ;
• Desenho da arquitetura (4h);
• Criar layout do XML de invocação do fluxo (4h);
• Criar página de parametrização do cálculo (8h);
• Alterar motor de calculo para implementar algoritmo do Dólar Marroquino (24h);
• Exportação de XLS de vértices e fatores (12h);
• Escrever Test Cases.... Escrever Documentação... Arquitetura.. Executar TC...
Épico
História
Tarefas

Exercício 02:
Em dupla, crie 2 histórias de usuário utilizando a técnica "INVEST"
Após isso quebre em tarefas (mínimo duas tarefas por Historia)

•Planning Poker
• Sequência Fibonacci
•Velocidade da equipe
Estimativas

Estimativas de Software
Estimativa de software compõe uma das disciplinas de Engenharia Softwar
e tem como objetivo elaborar:
o esforço, prazo e o custo de uma determinada funcionalidade.“Segundo Martin Flower, os desenvolvedores, que são
naturalmente otimistas, tendem a estimar para baixo.
Isso acontece mesmo que não sofram, pelo menos
explicitamente, pressão para reduzir suas estimativas.”
“E segundo Siobhan Keaveney e Kieran Conboy, no artigo
Custo de estimativas no desenvolvimento de projetos
ágeis, demonstram que quanto menores as iterações (tanto
em escopo quanto em tempo),
maior será a precisão das estimativas de um projeto..”

Estimativas História do Usuário
Quando utilizamos “História” é comum utilizarmos uma outra unidade
de medida, ao invés do usual “tempo” utilizado frequentemente em
metodologias Tradicionais, no caso de “História”, utilizamos a medida
Story Points.
Ela é uma unidade de medida relativa que leva em consideração o
esforço necessário para realizar determinada tarefa.
Para estimar o Development Team utiliza a User Story com menor esforço e a
Utiliza como base para estimar as outras.

Planning Poker
Uma das melhores formas de estimar Story Point é através do Planning Poker.
Funcionamento:
• Cada membro fica com um baralho contendo uma carta com cada ponto correspondente.
(sequência de Fibonacci)
• Após o PO explicar a história, cada um mostra o quanto acha que será o custo da história.
• Após discussões e explicações, o time mostra novamente a carta correspondente.
Pontos importantes:
• Como o time é multidisciplinar, vários experts fazem a estimativa;
• O diálogo e justificativas permitem maior entendimento da história;
• Estudos mostram que em média de estimativas individuais levam a melhores resultados;
• O planning poker utiliza a sequencia de Fibonacci,
• por ela ser uma função quadrática e resultando em um faixa de valor;

Velocidade do Time
A velocidade do Development Team é sempre medido também em Story Points, por exemplo
Quantos Story Points foram entregues pelo time em determinada Sprint.
Essa velocidade é utilizada pelo PO para fazer o planejamento dos próximos Sprints.
Como eu faço para cobrar do clientes
Story Points?
Livro: Agile Estimating And Planning
Mike Cohn

Exercício 03:
Junte 2 duplas e baseando nas Historias de cada um,
simule um estimativa utilizando Planning Poker.
Para simular o carta do Poker, utilize a sequência
Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144)

Burndown
Objetivo:
Medir o progresso da Sprint
Funcionamento:
• No eixo horizontal os dias da Sprint, do primeiro dia
ao último;
• No eixo vertical os pontos que foram planejados
para compor a Sprint, partindo do máximo de
pontos da Sprint (velocidade da equipe) até zero

Burndown
Exemplo:
Temos 8 Histórias no Sprint, totalizando 60 pontos, no dia 10/01 a equipe
produziu mais do que o previsto, já no dia 11/01 produziu menos do que o
previsto, ou seja, a leitura do gráfico quando a linha azul é igual ou superior a
vermelha, a velocidade da equipe está boa e vice-versa.

CFD – Cumulative Flow Diagram
Objetivo:
Demonstrar a quantidade de trabalho acumulado demonstrando a
saúde do fluxo do processo Scrum, levando em consideração as
semanas do projeto.

CFD – Cumulative Flow Diagram
demonstra as entregas (isto
depende da sua definição de
“pronto” DoD
Trabalho em progresso (work-
in-progress (WIP )trabalhos
iniciados mas não terminados).
demonstra o escopo (ou
backlog) do projeto.

Mito ou Verdade
• Scrum não tem documentação?
Mito!
na verdade Scrum é um framework que define o processo de trabalho, boas práticas e
disciplinas de Engenharia de Software podem e devem ser inseridas conforme a
necessidade da sua organização.
Scrum não determina como criar, por exemplo, algum artefato, ele se remete apenas ao
processo.
Junto a Scrum, especificamos nosso software. Normalmente utilizamos UML.

Mito ou Verdade
O PMI (Project Manager Institute) dá valor ao
movimento Agile e até possui uma certificação
específica para isso?
Verdade!
• Desde de 2011 o PMI certifica profissionais para práticas ágeis
(PMI-ACP)

Mito ou Verdade
Scrum pode ser utilizado em projeto de qualquer
tamanho ou natureza?
Mito!
• É possível utilizar em projetos grandes, no entanto, os resultados
são mais facilmente alcançados em projetos de TI e com equipes
pequenas, de 5 a 9 integrantes.

Mito ou Verdade
Até 2018 75% da TI terá métodos ágeis?
Verdade!
• De acordo com o Gartner, a TI bimodal (misturando os métodos
ortodoxos de trabalho com métodos ágeis)
• associa dois modos de TI, um enfatizando escalabilidade, eficiência,
segurança e precisão e um outro não sequencial, enfatizando
agilidade e velocidade.

Mito ou Verdade
A gestão com Scrum é uma anarquia.
Mito!
• O Scrum exige que tudo seja planejado, o time é
responsável pela organização e execução do
trabalho, e se compromete a realizar o melhor
trabalho possível em prol a meta da Sprint, além
do PO ser responsável pelo ROI do projeto.

a
Ferramentas
• https://trello.com/
• http://myscrumhalf.com/?lang=en
• https://kanbanflow.com/
• https://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry
/ferramenta_scrum_gratu_c3_adta_free96?lang=en RATIONAL TEAM
CONCERT
• https://jazz.net/downloads/jazz-foundation/releases/6.0.1
• https://msdn.microsoft.com/pt-br/library/ff731587.aspx - TFS Microsoft

Conclusões
a
Benefícios com adoção do Scrum
• Respostas rápidas a mudanças;
• Maior qualidade;
• Aumento de produtividade;
• Maior assertividade e visibilidade;
• Cooperação e autonomia;
• Não adianta dizer que Scrum não funciona, se o processo está sendo
executada de forma errada
• Scrum não resolve os problemas técnicos, como elaboração de
documentação e de requisitos complexos, mas colabora para isso
• Projetos desenvolvidos em Scrum, não finalizam mais rápido, a diferença
é a entrega do produto de forma diferente;
• A chave do Scrum é a comunicação, como em qualquer outra
metodologia de desenvolvimento de software
• Devido ao auto-gerenciamento do time, o mesmo é responsável pela a
entrega, ou seja, se o time falhar todos falham
Fernando Cunha

10 questões objetivas.
Tempo: 30 minutos
Avaliação

a
Referências
• Scrum - Guia de Referência - Adaptworks Treinamentos
• INNOVIT - GESTÃO DE PROJETOS E MELHORIA DE PROCESSOS - Agile Aliance
• PAULA FILHO, Wilson de Pádua. Engenharia de Software: fundamentos, métodos e
padrões. São Paulo: LTC Editora, 2000.
• http://agilemanifesto.org/iso/ptbr/
• http://www.mindmaster.com.br/scrum-11-passos/
• http://www.mindmaster.com.br/scrum-master/
• http://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf
• https://www.youtube.com/watch?v=9__bzr_lX88
• http://www.mindmaster.com.br/manutencao-de-sistemas/
• http://www.infoq.com/br/news/2009/05/kniberg-kanban-v-scrum
• http://scrumguides.org/scrum-guide.html

a
Referências
• http://guide.agilealliance.org/guide/user-stories.html
• http://www.infoq.com/br/news/2013/03/estimativas-possibilidade
• http://www.knowledge21.com.br/sobreagilidade/user-stories/como-e-user-story/
• http://pt.slideshare.net/manoelp/exemplos-de-user-stories
• http://blog.myscrumhalf.com/2012/04/mitos-do-scrum/
• https://brasil.pmi.org/brazil/CertificationsAndCredentials/PMI-ACP.aspx
• http://www.baguete.com.br/noticias/28/04/2015/gartner-75-da-ti-tera-metodos-ageis-ate-
2018
• http://www.mountaingoatsoftware.com/topics/scrum
• http://www.crisp.se/planningpoker/
• http://www.planningpoker.com/detail.html
• http://www.mountaingoatsoftware.com/books/1
• http://www.trainning.com.br/download/GUIA_DO_SCRUM.pdf

Material Workshop Scrum foundation - Fernando Cunha

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (13)

Ähnlich wie Material Workshop Scrum foundation - Fernando Cunha

Ähnlich wie Material Workshop Scrum foundation - Fernando Cunha (20)

Mehr von Wise Systems

Mehr von Wise Systems (9)

Material Workshop Scrum foundation - Fernando Cunha

Hinweis der Redaktion