SlideShare uma empresa Scribd logo
1 de 86
INSTRUTOR: FERNANDO CUNHA
Email: fecunhainfo@gmail.com
https://www.linkedin.com/in/fernandocunha2
Workshop Scrum
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;
PAPÉIS E RESPONSABILIDADES
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
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
Estimativa Planning 1 Planning 2 Daily Review Retrospective
• 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
Estimativa Planning 1 Planning 2 Daily Review Retrospective
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
Estimativa Planning 1 Planning 2 Daily Review Retrospective
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
Estimativa Planning 1 Planning 2 Daily Review Retrospective
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
Estimativa Planning 1 Planning 2 Daily Review Retrospective
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
ARTEFATOS
• 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
Task boards
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
Boards
KANBAN SCRUM
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.
PARTE II
• 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?
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 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!
História Técnica versus História de
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
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
Obrigado!
86

Mais conteúdo relacionado

Mais procurados

Kanban Avançado - Além de Visualizações e Limites
Kanban Avançado - Além de Visualizações e LimitesKanban Avançado - Além de Visualizações e Limites
Kanban Avançado - Além de Visualizações e LimitesRodrigo Yoshima
 
Unplanned Work: Options for managing the inevitable
Unplanned Work: Options for managing the inevitableUnplanned Work: Options for managing the inevitable
Unplanned Work: Options for managing the inevitableDavid Hanson
 
Agile Principles, Agile People
Agile Principles, Agile PeopleAgile Principles, Agile People
Agile Principles, Agile PeopleGaetano Mazzanti
 
Kanban - Métricas de Fluxo Sem Exoterismo
Kanban - Métricas de Fluxo Sem ExoterismoKanban - Métricas de Fluxo Sem Exoterismo
Kanban - Métricas de Fluxo Sem ExoterismoMarcelo Lora de Oliveira
 
MTM - Uma Ferramenta para a Melhoria Contínua
MTM - Uma Ferramenta para a Melhoria ContínuaMTM - Uma Ferramenta para a Melhoria Contínua
MTM - Uma Ferramenta para a Melhoria ContínuaAssociação MTM Portugal
 
Apresentação de Design Thinking
Apresentação de Design ThinkingApresentação de Design Thinking
Apresentação de Design Thinkingbaufaker
 
Official announcement of the next edition of the event.
Official announcement of the next edition of the event.Official announcement of the next edition of the event.
Official announcement of the next edition of the event.BMRS Meeting
 
Introdução ao Lean manufacturing
Introdução ao Lean manufacturingIntrodução ao Lean manufacturing
Introdução ao Lean manufacturingEdomar Hornburg
 
Innovación Corporativa y Transformación Digital: Portafolio de Innovación - B...
Innovación Corporativa y Transformación Digital: Portafolio de Innovación - B...Innovación Corporativa y Transformación Digital: Portafolio de Innovación - B...
Innovación Corporativa y Transformación Digital: Portafolio de Innovación - B...Johnny Ordóñez
 
Neurodiversidade e liderança ágil
Neurodiversidade e liderança ágilNeurodiversidade e liderança ágil
Neurodiversidade e liderança ágilNatalia Manha
 
Tudo que sei sobre lean aprendi no 1º ano da escola, Martichenko, R.
Tudo que sei sobre lean aprendi no 1º ano da escola, Martichenko, R.Tudo que sei sobre lean aprendi no 1º ano da escola, Martichenko, R.
Tudo que sei sobre lean aprendi no 1º ano da escola, Martichenko, R.Lucila Imoto Freitas
 
LAST Conference 2016 Agile Landscape Presentation v1
LAST Conference 2016 Agile Landscape Presentation v1LAST Conference 2016 Agile Landscape Presentation v1
LAST Conference 2016 Agile Landscape Presentation v1Chris Webb
 

Mais procurados (20)

Kanban Avançado - Além de Visualizações e Limites
Kanban Avançado - Além de Visualizações e LimitesKanban Avançado - Além de Visualizações e Limites
Kanban Avançado - Além de Visualizações e Limites
 
Kanban Brazil 2022
Kanban Brazil 2022Kanban Brazil 2022
Kanban Brazil 2022
 
Unplanned Work: Options for managing the inevitable
Unplanned Work: Options for managing the inevitableUnplanned Work: Options for managing the inevitable
Unplanned Work: Options for managing the inevitable
 
Agile Principles, Agile People
Agile Principles, Agile PeopleAgile Principles, Agile People
Agile Principles, Agile People
 
Desenvolvimento de liderança amcham
Desenvolvimento de liderança   amchamDesenvolvimento de liderança   amcham
Desenvolvimento de liderança amcham
 
Objetivos y Resultados Claves (OKR)
Objetivos y Resultados Claves (OKR)Objetivos y Resultados Claves (OKR)
Objetivos y Resultados Claves (OKR)
 
Kanban - Métricas de Fluxo Sem Exoterismo
Kanban - Métricas de Fluxo Sem ExoterismoKanban - Métricas de Fluxo Sem Exoterismo
Kanban - Métricas de Fluxo Sem Exoterismo
 
MTM - Uma Ferramenta para a Melhoria Contínua
MTM - Uma Ferramenta para a Melhoria ContínuaMTM - Uma Ferramenta para a Melhoria Contínua
MTM - Uma Ferramenta para a Melhoria Contínua
 
Apresentação de Design Thinking
Apresentação de Design ThinkingApresentação de Design Thinking
Apresentação de Design Thinking
 
Aula Lean
Aula LeanAula Lean
Aula Lean
 
Scrum
ScrumScrum
Scrum
 
Official announcement of the next edition of the event.
Official announcement of the next edition of the event.Official announcement of the next edition of the event.
Official announcement of the next edition of the event.
 
Lean Manufacturing Nova Visão
Lean Manufacturing Nova VisãoLean Manufacturing Nova Visão
Lean Manufacturing Nova Visão
 
Introdução ao Lean manufacturing
Introdução ao Lean manufacturingIntrodução ao Lean manufacturing
Introdução ao Lean manufacturing
 
Innovación Corporativa y Transformación Digital: Portafolio de Innovación - B...
Innovación Corporativa y Transformación Digital: Portafolio de Innovación - B...Innovación Corporativa y Transformación Digital: Portafolio de Innovación - B...
Innovación Corporativa y Transformación Digital: Portafolio de Innovación - B...
 
Introducción a lean para managers
Introducción a lean para managersIntroducción a lean para managers
Introducción a lean para managers
 
Neurodiversidade e liderança ágil
Neurodiversidade e liderança ágilNeurodiversidade e liderança ágil
Neurodiversidade e liderança ágil
 
Webinar - RH Agil
Webinar - RH AgilWebinar - RH Agil
Webinar - RH Agil
 
Tudo que sei sobre lean aprendi no 1º ano da escola, Martichenko, R.
Tudo que sei sobre lean aprendi no 1º ano da escola, Martichenko, R.Tudo que sei sobre lean aprendi no 1º ano da escola, Martichenko, R.
Tudo que sei sobre lean aprendi no 1º ano da escola, Martichenko, R.
 
LAST Conference 2016 Agile Landscape Presentation v1
LAST Conference 2016 Agile Landscape Presentation v1LAST Conference 2016 Agile Landscape Presentation v1
LAST Conference 2016 Agile Landscape Presentation v1
 

Destaque

Agile Certified Practitioner Workshop
Agile Certified Practitioner WorkshopAgile Certified Practitioner Workshop
Agile Certified Practitioner WorkshopPinkesh Shah
 
Designing with Agile Workshop (Half Day)
Designing with Agile Workshop (Half Day)Designing with Agile Workshop (Half Day)
Designing with Agile Workshop (Half Day)Anders Ramsay
 
Agile Marketing Workshop
Agile Marketing Workshop Agile Marketing Workshop
Agile Marketing Workshop Eric Sangerma
 
Introduction To Scrum
Introduction To ScrumIntroduction To Scrum
Introduction To Scrumvineet
 
How to make SAFe really SAFE Scaling Agile using Pull/Invite rather than Push...
How to make SAFe really SAFE Scaling Agile using Pull/Invite rather than Push...How to make SAFe really SAFE Scaling Agile using Pull/Invite rather than Push...
How to make SAFe really SAFE Scaling Agile using Pull/Invite rather than Push...Yuval Yeret
 
Essential SAFe and Launching your first Agile Release Train
Essential SAFe and Launching your first Agile Release TrainEssential SAFe and Launching your first Agile Release Train
Essential SAFe and Launching your first Agile Release TrainCprime
 
Scrum Training (One Day)
Scrum Training (One Day)Scrum Training (One Day)
Scrum Training (One Day)beLithe
 
Scrum as a foundational piece of SAFe(tm) - Give Thanks to Scrum 2016
Scrum as a foundational piece of SAFe(tm) - Give Thanks to Scrum 2016Scrum as a foundational piece of SAFe(tm) - Give Thanks to Scrum 2016
Scrum as a foundational piece of SAFe(tm) - Give Thanks to Scrum 2016Yuval Yeret
 
Timebox Planning Tool V2 with SAFe Support
Timebox Planning Tool V2 with SAFe SupportTimebox Planning Tool V2 with SAFe Support
Timebox Planning Tool V2 with SAFe SupportMarkus Giacomuzzi
 
An Introduction to Scaled Agile Framework (SAFe)
An Introduction to Scaled Agile Framework (SAFe)An Introduction to Scaled Agile Framework (SAFe)
An Introduction to Scaled Agile Framework (SAFe)CA Technologies
 

Destaque (13)

Agile Certified Practitioner Workshop
Agile Certified Practitioner WorkshopAgile Certified Practitioner Workshop
Agile Certified Practitioner Workshop
 
Designing with Agile Workshop (Half Day)
Designing with Agile Workshop (Half Day)Designing with Agile Workshop (Half Day)
Designing with Agile Workshop (Half Day)
 
Agile Project Management (Workshop)
Agile Project Management (Workshop)Agile Project Management (Workshop)
Agile Project Management (Workshop)
 
Agile Marketing Workshop
Agile Marketing Workshop Agile Marketing Workshop
Agile Marketing Workshop
 
Introduction To Scrum
Introduction To ScrumIntroduction To Scrum
Introduction To Scrum
 
How to make SAFe really SAFE Scaling Agile using Pull/Invite rather than Push...
How to make SAFe really SAFE Scaling Agile using Pull/Invite rather than Push...How to make SAFe really SAFE Scaling Agile using Pull/Invite rather than Push...
How to make SAFe really SAFE Scaling Agile using Pull/Invite rather than Push...
 
Essential SAFe and Launching your first Agile Release Train
Essential SAFe and Launching your first Agile Release TrainEssential SAFe and Launching your first Agile Release Train
Essential SAFe and Launching your first Agile Release Train
 
Scaling Agile
Scaling Agile Scaling Agile
Scaling Agile
 
Scrum Training (One Day)
Scrum Training (One Day)Scrum Training (One Day)
Scrum Training (One Day)
 
Scrum as a foundational piece of SAFe(tm) - Give Thanks to Scrum 2016
Scrum as a foundational piece of SAFe(tm) - Give Thanks to Scrum 2016Scrum as a foundational piece of SAFe(tm) - Give Thanks to Scrum 2016
Scrum as a foundational piece of SAFe(tm) - Give Thanks to Scrum 2016
 
Professional Scrum Master I (PSM-I)
Professional Scrum Master I (PSM-I)Professional Scrum Master I (PSM-I)
Professional Scrum Master I (PSM-I)
 
Timebox Planning Tool V2 with SAFe Support
Timebox Planning Tool V2 with SAFe SupportTimebox Planning Tool V2 with SAFe Support
Timebox Planning Tool V2 with SAFe Support
 
An Introduction to Scaled Agile Framework (SAFe)
An Introduction to Scaled Agile Framework (SAFe)An Introduction to Scaled Agile Framework (SAFe)
An Introduction to Scaled Agile Framework (SAFe)
 

Semelhante a Material Workshop Scrum foundation - Fernando Cunha

Semelhante a Material Workshop Scrum foundation - Fernando Cunha (20)

ENGSW_Aula_Scrum.pdf
ENGSW_Aula_Scrum.pdfENGSW_Aula_Scrum.pdf
ENGSW_Aula_Scrum.pdf
 
Guia do scrum
Guia do scrumGuia do scrum
Guia do scrum
 
Guia do scrum
Guia do scrumGuia do scrum
Guia do scrum
 
Scrum
ScrumScrum
Scrum
 
Trabalho scrum
Trabalho scrumTrabalho scrum
Trabalho scrum
 
Scrum
ScrumScrum
Scrum
 
Workshop Scrum - 8 horas
Workshop Scrum - 8 horasWorkshop Scrum - 8 horas
Workshop Scrum - 8 horas
 
Desenvolvimento ágil com scrum
Desenvolvimento ágil com scrumDesenvolvimento ágil com scrum
Desenvolvimento ágil com scrum
 
Agilidade Com Scrum
Agilidade Com ScrumAgilidade Com Scrum
Agilidade Com Scrum
 
Sobre o Scrum
Sobre o ScrumSobre o Scrum
Sobre o Scrum
 
Resumo Scrum Guide
Resumo Scrum GuideResumo Scrum Guide
Resumo Scrum Guide
 
Gerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUMGerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUM
 
Scrum - Visão Geral
Scrum - Visão GeralScrum - Visão Geral
Scrum - Visão Geral
 
Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de Projetos
 
Metodologia SCRUM
Metodologia SCRUMMetodologia SCRUM
Metodologia SCRUM
 
Scrum - As Regras do Jogo segundo o Guia do Scrum
Scrum - As Regras do Jogo segundo o Guia do ScrumScrum - As Regras do Jogo segundo o Guia do Scrum
Scrum - As Regras do Jogo segundo o Guia do Scrum
 
Scrum agil
Scrum agilScrum agil
Scrum agil
 
Gerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrumGerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrum
 
Agile SCRUM
Agile SCRUMAgile SCRUM
Agile SCRUM
 
A Teoria do Scrum
A Teoria do ScrumA Teoria do Scrum
A Teoria do Scrum
 

Mais de Wise Systems

PERT/CPM- Estimativa de projetos
PERT/CPM-  Estimativa de projetosPERT/CPM-  Estimativa de projetos
PERT/CPM- Estimativa de projetosWise Systems
 
ITIL na prática - Gerenciamento de Incidentes, Problemas e Mudanças
ITIL na prática - Gerenciamento de Incidentes, Problemas e MudançasITIL na prática - Gerenciamento de Incidentes, Problemas e Mudanças
ITIL na prática - Gerenciamento de Incidentes, Problemas e MudançasWise Systems
 
Workshop Rational Team Concert - RTC - Planejamento - aula 02
Workshop  Rational Team Concert - RTC - Planejamento - aula 02Workshop  Rational Team Concert - RTC - Planejamento - aula 02
Workshop Rational Team Concert - RTC - Planejamento - aula 02Wise Systems
 
Workshop Rational Team Concert - RTC - Planejamento - aula 01
Workshop  Rational Team Concert - RTC - Planejamento - aula 01Workshop  Rational Team Concert - RTC - Planejamento - aula 01
Workshop Rational Team Concert - RTC - Planejamento - aula 01Wise Systems
 
RTC - RATIONAL TEAM CONCERT - DEVELOPER - SCM RTC SHELL - aula 03
RTC - RATIONAL TEAM CONCERT - DEVELOPER - SCM RTC SHELL - aula 03RTC - RATIONAL TEAM CONCERT - DEVELOPER - SCM RTC SHELL - aula 03
RTC - RATIONAL TEAM CONCERT - DEVELOPER - SCM RTC SHELL - aula 03Wise Systems
 
RTC - RATIONAL TEAM CONCERT - DEVELOPER - SCM ECLIPSE - aula 02
RTC - RATIONAL TEAM CONCERT - DEVELOPER - SCM ECLIPSE - aula 02RTC - RATIONAL TEAM CONCERT - DEVELOPER - SCM ECLIPSE - aula 02
RTC - RATIONAL TEAM CONCERT - DEVELOPER - SCM ECLIPSE - aula 02Wise Systems
 
Rtc work shop - developer - introdução - aula 01
Rtc   work shop  - developer - introdução - aula 01Rtc   work shop  - developer - introdução - aula 01
Rtc work shop - developer - introdução - aula 01Wise Systems
 
NOSQL uma breve introdução
NOSQL uma breve introduçãoNOSQL uma breve introdução
NOSQL uma breve introduçãoWise Systems
 

Mais de Wise Systems (9)

PERT/CPM- Estimativa de projetos
PERT/CPM-  Estimativa de projetosPERT/CPM-  Estimativa de projetos
PERT/CPM- Estimativa de projetos
 
ITIL na prática - Gerenciamento de Incidentes, Problemas e Mudanças
ITIL na prática - Gerenciamento de Incidentes, Problemas e MudançasITIL na prática - Gerenciamento de Incidentes, Problemas e Mudanças
ITIL na prática - Gerenciamento de Incidentes, Problemas e Mudanças
 
Cases big data
Cases big dataCases big data
Cases big data
 
Workshop Rational Team Concert - RTC - Planejamento - aula 02
Workshop  Rational Team Concert - RTC - Planejamento - aula 02Workshop  Rational Team Concert - RTC - Planejamento - aula 02
Workshop Rational Team Concert - RTC - Planejamento - aula 02
 
Workshop Rational Team Concert - RTC - Planejamento - aula 01
Workshop  Rational Team Concert - RTC - Planejamento - aula 01Workshop  Rational Team Concert - RTC - Planejamento - aula 01
Workshop Rational Team Concert - RTC - Planejamento - aula 01
 
RTC - RATIONAL TEAM CONCERT - DEVELOPER - SCM RTC SHELL - aula 03
RTC - RATIONAL TEAM CONCERT - DEVELOPER - SCM RTC SHELL - aula 03RTC - RATIONAL TEAM CONCERT - DEVELOPER - SCM RTC SHELL - aula 03
RTC - RATIONAL TEAM CONCERT - DEVELOPER - SCM RTC SHELL - aula 03
 
RTC - RATIONAL TEAM CONCERT - DEVELOPER - SCM ECLIPSE - aula 02
RTC - RATIONAL TEAM CONCERT - DEVELOPER - SCM ECLIPSE - aula 02RTC - RATIONAL TEAM CONCERT - DEVELOPER - SCM ECLIPSE - aula 02
RTC - RATIONAL TEAM CONCERT - DEVELOPER - SCM ECLIPSE - aula 02
 
Rtc work shop - developer - introdução - aula 01
Rtc   work shop  - developer - introdução - aula 01Rtc   work shop  - developer - introdução - aula 01
Rtc work shop - developer - introdução - aula 01
 
NOSQL uma breve introdução
NOSQL uma breve introduçãoNOSQL uma breve introdução
NOSQL uma breve introdução
 

Material Workshop Scrum foundation - Fernando Cunha

  • 1. INSTRUTOR: FERNANDO CUNHA Email: fecunhainfo@gmail.com https://www.linkedin.com/in/fernandocunha2
  • 3. Agenda- Parte I • INTRODUÇÃO • HISTÓRIA • SCRUM • VALORES DO SCRUM • PILARES • PAPÉIS E RESPONSABILIDADES • EVENTOS E ARTEFATOS
  • 4. Agenda – Parte || • HISTÓRIAS • ESTIMATIVAS • BURNDOWN CHARTS • MITO OU VERDADE • FERRAMENTAS • CONCLUSÃO • AVALIAÇÃO
  • 5. 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.
  • 6. 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);
  • 7. 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;
  • 8. 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;
  • 9. 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
  • 10. 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;
  • 12. 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
  • 13. 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
  • 14. 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.
  • 15. 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.
  • 16. 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.
  • 17. • Histórias / Tarefas • Product backlog • Sprint backlog • Burndown charts Artefatos • Sprint planning • Sprint review • Sprint retrospective • Daily scrum meeting Eventos
  • 19. 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
  • 20. 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.
  • 21. 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).
  • 22. 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.
  • 23. 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
  • 24. 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?
  • 25. 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?
  • 26. 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
  • 27. 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
  • 28. 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.
  • 29. 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
  • 30. Ciclo de Reuniões Completo a Estimativa Planning 1 Planning 2 Daily Review Retrospective • 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
  • 31. Planejamento do Sprint (Planning 2) a Estimativa Planning 1 Planning 2 Daily Review Retrospective 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
  • 32. Scrum meeting a Estimativa Planning 1 Planning 2 Daily Review Retrospective 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.
  • 33. Sprint Review a Estimativa Planning 1 Planning 2 Daily Review Retrospective 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;
  • 34. Retrospectiva do Sprint a Estimativa Planning 1 Planning 2 Daily Review Retrospective 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!
  • 35. 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
  • 36. 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
  • 38. • Product Backlog • Sprint Backlog • Definition of Done – Regras • Product Increment – Entrega • Task Boards
  • 39. 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
  • 40. 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.
  • 41. 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
  • 42. 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.
  • 43. 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
  • 44. 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
  • 45. Scrum – Visão Geral do Ciclo de Vida a
  • 47. 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
  • 48. 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
  • 49. 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
  • 51. 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.
  • 53. • HISTÓRIAS • ESTIMATIVAS • REPORTS • MITO OU VERDADE • FERRAMENTAS • CONCLUSÃO • AVALIAÇÃO
  • 54. •História de Usuário • História Técnica •Estrutura da História •Técnicas para escrever histórias Histórias
  • 55. 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.
  • 56. 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.
  • 57. Técnica de Validação de Histórias I NDEPENDENTE N EGOCIÁVEL V ALIOSA E STIMÁVEL P EQUENA T ESTÁVEL
  • 58. 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.
  • 59. 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?
  • 60. 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 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).
  • 61. “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! História Técnica versus História de Usuário
  • 62. 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
  • 63. 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
  • 64. 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)
  • 65. •Planning Poker • Sequência Fibonacci •Velocidade da equipe Estimativas
  • 66. 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..”
  • 67. 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.
  • 68. 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;
  • 69. 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
  • 70. 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)
  • 71. 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
  • 73. 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.
  • 74. 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.
  • 75. 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.
  • 76. 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.
  • 77. 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)
  • 78. 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.
  • 79. 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.
  • 80. 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.
  • 81. 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
  • 82. 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
  • 83. 10 questões objetivas. Tempo: 30 minutos Avaliação
  • 84. 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
  • 85. 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

Notas do Editor

  1. Exemplo de INDEPENDENTE: PAGAMENTO COM CARTAO CREDITO VISA – PAGAMENTO COM CARTAO CREDITO MASTER NEGOCIAVEL: PAGAMENTO COM CARTAO DE CREDITO VISA. NOTA: A CONFIRMAÇÃO DE COMPRA DEVERÁ SER APRESENTADA NO SITE A CONFIRMAÇÃO DA COMPRA DEVERÁ SER ENVIADA POR EMAIL DO CLIENTE A TELA DE PAGAMENTO DEVERÁ TER A IDENTIDADE DA EMPRESA VALIOSA: AS HISTORIAS DEVEM GERAR VALOR AO CLIENTE ESTIMÁVEL: DEVE PROVER INFORMACAO SUFICIENTE PARA SER ESTIMADAS PEQUENA: HISTORIAS DEVERAO TER UM NÍVEL DE GRANULARIDADE BOM, EX: MUITO PEQUENA, VALIDAR O NUMERO DE CARTAO DE CREDITO TESTÁVEL: DEVE SER CLARA O SUFIENTE PARA SEREM TESTADAS
  2. 3CS SEGUNDO RON JEFFRIES is one of the 3 founders of the Extreme Programming (XP) software development methodology
  3. 3CS SEGUNDO RON JEFFRIES is one of the 3 founders of the Extreme Programming (XP) software development methodology
  4. 3CS SEGUNDO RON JEFFRIES is one of the 3 founders of the Extreme Programming (XP) software development methodology
  5. 3CS SEGUNDO RON JEFFRIES is one of the 3 founders of the Extreme Programming (XP) software development methodology
  6. 3CS SEGUNDO RON JEFFRIES is one of the 3 founders of the Extreme Programming (XP) software development methodology
  7. 3CS SEGUNDO RON JEFFRIES is one of the 3 founders of the Extreme Programming (XP) software development methodology
  8. 3CS SEGUNDO RON JEFFRIES is one of the 3 founders of the Extreme Programming (XP) software development methodology
  9. 3CS SEGUNDO RON JEFFRIES is one of the 3 founders of the Extreme Programming (XP) software development methodology