Workshop Scrum - 8 horas

Soluções inteligentes para um mundo em transformação

Olá sou Fernando Cunha profissional com aproximadamente 14
anos de experiência com tecnologia da informação.
Atuei em empresas de médio e grande porte, privadas e
consultorias dos ramos financeiro, bancário, telecom e produtos.
Tenho forte experiência em gerenciamento de projetos de software e infraestrutura, utilizando
metodologias tradicionais e ágil e com esse know how é que irei auxiliar a sua empresa a conquistar os
desafios impostos pelo mercado e clientes
Experiências:
Gerenciamento de Projetos ágeis e tradicionais
Desenvolvimento web (JAVA, PHP, .NET, Angular, Javascript, HTML)
Engenharia de Software, UML e RUP
Quem sou

Agenda- Parte I
• INTRODUÇÃO
• HISTÓRIA
• VALORES DO SCRUM
• POR QUE SCRUM?
• 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;

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;

Visão do instrutor -O Manifesto Ágil
● Indivíduos e interações mais que processos e ferramentas
• Software 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
A documentação, na realidade, facilita a interação, funcionando como seu
subproduto na forma de documentos, rascunhos, desenhos, anotações etc.,
que podem (ou não) ser utilizados como um registro permanente (Highsmith,
2004).

Por que Scrum?
• Entregas frequentes de retorno ao investimento dos clientes:
○ Scrum possibilita que se entreguem, desde cedo no projeto e
frequentemente, partes do produto funcionando
• Redução dos riscos do projeto:
○ Scrum visa à redução dos riscos de negócios do projeto pela
colaboração com os clientes e demais partes interessadas
durante todo o seu decorrer.
• Maior qualidade no produto gerado:
○ A parte do produto gerada em cada ciclo de desenvolvimento
deve possuir a qualidade necessária para poder ser entregue
para os clientes do projeto

Por que Scrum?
• Mudanças utilizadas como vantagem competitiva:
○ Em um projeto com Scrum, as mudanças são acolhidas como
oportunidades e não como acontecimentos indesejáveis. Elas
são parte do ambiente dinâmico em que os projetos estão
inseridos
• Visibilidade do progresso do projeto:
○ Diversas práticas e artefatos do Scrum ou associados visam
garantir a visibilidade ou transparência do progresso do projeto
para seus participantes e envolvidos
Redução do desperdício
A ideia central é que o time que usa Scrum produza e utilize
apenas o que é necessário e suficiente

Scrum
Scrum é um framework Ágil, simples e leve, utilizado para a gestão do
desenvolvimento de produtos complexos .
Scrum utiliza uma abordagem iterativa e incremental para entregar valor
com frequência e, assim, reduzir os riscos do projeto.
Scrum é um framework para gestão de projetos e não um metodologia ou
conjunto de processos. o Scrum não de!ne práticas especí!cas e detalhadas a
serem seguidas. como por exemplo como deverá ser levantadas as
oportunidades de negócio.
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

Scrum
DEFINIÇÃO DE “ÁGIL” NO CONTEXTO
SCRUM:
que se movimenta com facilidade;
ligeiro, leve
a origem do nome Scrum: reinício de
jogada no rugby, onde os jogadores dos dois times
se juntam com a cabeça abaixada e se empurram
com o objetivo de ganhar a posse de bola, o termo
deriva da palavra inglesa scrimmage que significa
escaramuça.

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;

Valores do Scrum
Foco - os times mais produtivos trabalham em apenas um projeto de
cada vez, evitando a multitarefa
Coragem: as pessoas que trabalham no projeto têm coragem para aceitar
a mudança como parte natural do processo de desenvolvimento do produto
Franqueza: a franqueza ou transparência é necessária para que se possa
realizar a inspeção e adaptação.
Compromisso: o time determina como seu trabalho será realizado, monitora
seu progresso e realiza as correções de rumo que achar necessárias.
Respeito: os membros do time trabalham juntos, compartilhando
responsabilidades, e assim ajudam-se uns aos outros em seu trabalho.

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...”

Developer Team
• 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

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
Eventos - Sprint

Eventos - 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.

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).

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.

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
Eventos - Daily Scrum

Funcionamento:
Cada membro da equipe responde para os outros membros:
Após a última atualização do – Guia do Scrum™ 2013
• O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a
meta da Sprint?
• O que eu farei hoje para ajudar o Time de Desenvolvimento atender a
meta da Sprint?
• Eu vejo algum obstáculo que impeça a mim ou o Time de
Desenvolvimento no atendimento da meta da Sprint?

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
Eventos- Sprint Review

Eventos - Sprint Review
Funcionamento:
• O Time comenta os 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

Eventos -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.

Eventos - Estimativas
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

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;
• Discute-se pontos de atenção.
• 4 horas para Sprint de 01 mês
Eventos - Planning 01

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
Eventos - Planning 2

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.

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;
Eventos - Sprint Review

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!
Eventos - Retrospective

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
Eventos - Tempos e Reuniões

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

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.
Product Backlog

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
Product
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 do
produto.
Sprint
São os itens que
serão
implementados no
intervalo
estabelecidos do
Sprint, e farão
parte portando do
ciclo de
desenvolvimento.
Quantos Backlogs!

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

a
Scrum - Visão Geral do Ciclo de Vida

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
desenvolvi
das no
Sprint
São as
tarefas
pertencent
es as
estórias
que estão
aptas a
serem
realizadas
São as
tarefas
pertencent
es as
estórias
que estão
em
desenvolvi
mento 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
desenvolvi
das no
Sprint
São as
tarefas
pertencent
es as
estórias
que estão
aptas a
serem
realizadas
São as
tarefas
pertencent
es as
estórias
que estão
em
desenvolvi
mento 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
Objetivos dos quadros

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
KANBAN

• 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

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.
História

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.
Estrutura de uma História de Usuário

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

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.
Os 3Cs segundo Ron Jeffries

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?
História Técnica versus História de 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 história 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
comprarTECHNICAL 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!

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
• 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
Mapeamento de Épico X História X Tarefa

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

Estimativa de software compõe uma das disciplinas de
Engenharia Software
e tem como objetivo elaborar:
o esforço, prazo e o custo de uma determinada
funcionalidade.
Estimativa de Software

Estimativas de Software
“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.

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;
Planning Poker

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
Velocidade do Time

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.
Burndown

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.
CFD - Cumulative Flow Diagram

• 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

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.
Mito ou Verdade

Scrum não precisa de documentação?
Mito!
• O Scrum prega que a documentação que o
time julgue necessário deverá ser construída
Mito ou Verdade

a
-> Os criadores do Scrum se inspiraram em um artigo dos autores Hirotaka Takeuchi e
Ikujiro Nonaka, intitulado “!e New New Product Development Game” (ou “O Novo
Jogo no Desenvolvimento de Novos Produtos”). Esse artigo foi publicado em 1986 na
renomada revista Harvard Business Review (Takeuchi & Nonaka, 1986).
->Os propósitos da Agilidade e do Sistema Toyota de Produção são diferentes, a
princípio. Enquanto STP foi originalmente concebido para manufaturas, a Agilidade foi
criada no contexto do desenvolvimento de so"ware. No entanto, Scrum, assim como
todo o movimento Ágil, possui várias de suas ideias enraizadas no STP.
Curiosidades

a
• https://trello.com/
• http://myscrumhalf.com/?lang=en
• https://kanbanflow.com/
• https://www.ibm.com/developerworks/community/blogs/rationalbras
il/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
• https://www.atlassian.com/software/jira - Jira Atlanssian
Ferramentas

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
Conclusões

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

a
• 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.
• Scrum Gestao Agil para Projetos de Sucesso; - Casa Do Código-Sabbagh Rafael
• 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
Referências

a
• 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
Referências

Obrigado!
96
INSTRUTOR: FERNANDO CUNHA
Email: bluenoteticompany@gmail.com
https://www.linkedin.com/in/fernandocunha2

Workshop Scrum - 8 horas

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Workshop Scrum - 8 horas

Ähnlich wie Workshop Scrum - 8 horas (20)

Mehr von Wise Systems

Mehr von Wise Systems (9)

Workshop Scrum - 8 horas