Embed Size (px)
DESCRIPTION
Slides utilizado no treinamento de Scrum
Citation preview
O Problema
2004
2006
200932%
35%
29%
44%
46%
53%
24%
19%
18%
Chaos Report
FracassadosComprometidosBem sucedidos
!"#$%&'(")&*%+,-."/0$12""
Principais fatores de insucesso
requisitos incompletos
falta de envolvimento
de usuários
mudanças de
requisitos e especificações
falta de apoio de negócios
falta de recursos
Como resolver?
Abordagem Tradicional
BDUF Big Design Up Front
Analista de Requisitos, Analista de Negócios, Engenheiro de Requisitos, Engenheiro de Qualidade,
Gerente de Configuração, Líder de Projeto...
Programadores
Processo!!
Ainda assim...
Ainda mais...
Código Complexo.Manutenção difícil.Baixa produtividade.Cronograma sempre atrasado.Insatisfação de todos.Design degradado.Documentação defasada, excessiva e ilegível.Fracasso em grande parte dos projetos.
Por quê?
Previsibilidade
O desenvolvimento de software depende muito mais das pessoas e da comunicação
Larman
“Ao contrário do cenário numa linha de produção em massa, o software não é algo previsível ou imune a mudanças”
“Desenvolver software é como desenvolver novos produtos”
Larman
“Desenvolver é como criar uma receita, enquanto produzir é seguir a receita”Poppendieck
“O desenvolvimento é um processo de aprendizado, que envolve tentativa e erros”
Larman
“Como a manufatura previsível, não pode ser comparada ao software, dificilmente as práticas e valores enraizados nesse paradigma trazem algum benefício” Larman
64% das funcionalidades desenvolvidas nos softwares não são utilizadas
Standish Group
A Lei de Pareto, também
conhecido como princípio 80/20
20% do esforço do desenvolvimento80% dos benefícios
20% dos custos80% dos problemas
Muitas vezes, pelo fato do cliente só poder pedir uma vez, ele acaba pedindo coisas que não
tem certeza que precisa
Essas funcionalidades fazem parte dos 64% que ele nem repara que estão lá, quando o software é entregue
Microsoft
70% dos usuários utilizam as
funcionalidades básicas de um software.
20% utilizam as funcionalidades
intermediárias.
10% utilizam as funcionalidades avançadas.
Cone da Incerteza
É natural que os usuários tenham novas
idéias e suas opiniões mudem quando vêem as primeiras versões
do software
Os softwares mais famosos e utilizados no mundo são os mais simples
“Menos é Mais”A cabeça de Steve Jobs (Inside Steve’s Brain) - Agir 2008
Abordagem Ágil
Final da década de 90
eXtreme Programming
Feature Driven Development
Scrum
Crystal Clear
Adaptive Development
Dynamic Systems Development Method
Mas o que é ser ágil?
Manifesto Ágil
Kent Beck
Mike Beedle
Arie van
Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
Indivíduos e interação entre eles 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
Princípios por trás do manifesto ágil
Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor
Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento
Processos ágeis se adequam a mudanças, para que o cliente
possa tirar vantagens competitivas
Entregar software funcionando com
frequencia, na escala de semanas até meses, com
preferência aos períodos mais curtos
Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto
Construir projetos ao redor de indivíduos motivados. Dando a eles o
ambiente e suporte necessário, e confiar que farão seu trabalho.
O método mais eficiente e eficaz de transmitir informações é através de uma conversa cara a cara.
Software funcional é a medida primária de progresso.
Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito
As melhores arquiteturas, requisitos e designs emergem
de times auto-organizáveis
Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam
seu comportamento de acordo
Por que adotar abordagens ágeis?
STATE OFAGILE SURVEY2010
VersionOne
4.770 participantes
91 países
90%trabalham em
organizações que usam práticas de
desenvolvimento ágil em um certo grau
STATE OFAGILE SURVEY2010
VersionOne
68% conhecem moderadamente ou extremamente
40% utilizam abordagem ágil a mais de 2 anos
STATE OFAGILE SURVEY2010
VersionOne
STATE OFAGILE SURVEY2010
VersionOne
Scrum e variantes de Scrum são de longe os mais utilizados
STATE OFAGILE SURVEY2010
VersionOne
As razões mais comuns para a adoção ágil gira em torno de
aumento produtividade e tempo de aceleração para o mercado
STATE OFAGILE SURVEY2010
VersionOne
83% consideram que projetos ágeis foram mais rápidos
ou a mesma coisa que projetos não ágeis
STATE OFAGILE SURVEY2010
VersionOne
87% melhoria significante no gerenciamento de prioridades
O Scrum
A origem
1986
1995Jeff SutherlandKen Schwaber
“O Scrum não vai dizer exatamente o que fazer, não irá resolver todos os seus problemas, mas com certeza os problemas serão mais facilmente identificados”
Ken Schwaber
Se destaca dos demais métodos ágeis pela ênfase dada ao gerenciamento do projeto
Práticas de Engenharia
Not included
Papéis do Scrum
Product Owner
Determina a visão do produto
Define as funcionalidades
Escolhe as datas de release
Dá o feedback
Gerencia os stakeholders
Aceita ou rejeita os resultados
Prioriza de acordo com o ROI
Product Owner
O Time
Pequenos (5 a 9 pessoas)
Desenvolve as funcionalidades
Auto-organizável
Auto-gerenciável
Multifuncional
Estima o esforço
Defina as tarefas
Responsável pela qualidade
Scrum Master
Líder Servidor
Protege o time
Remove impedimentos
Guia do Scrum
Porcos e GalinhasProduct OwnerScrum Master
Time
UsuáriosGerentesMarketing
Como funciona?
Visão do ProdutoUma visão é uma imagem clara que evoca uma atração emocional
O Product Owner cria a visão do produtoEle compartilha a visão com o time
Ele refina a visão com o time
Product Box
http://innovationgames.com/product-box/
Elevator Statement
Para (público alvo)Que estão insa6sfeito com (as atuais alterna6vas de mercado)Nosso produto é um (nova categoria do produto)Que (problema chave que ele resolve)Diferente (o produto alterna6vo)Nós fornecemos (funcionalidades chaves)
Vamos criar a visão!
Product Backlog
Contém valorRetardar decisões
Product Backlog
Uma lista de coisas que queremos que sejam
entregues
As funcionalidades são geralmente escritas em estórias de usuários.
Como um <perfil>, quero <funcionalidade>, para <valor de negócio>
Como um agente de viagens, quero reservar lugar, para facilitar o atendimento dos clientes
corporativos
Vamos contar estórias!!
O time estima o trabalho associado a cada estória.
Problemas com estimativas
Pessoal, qual a estimativa para essa
estória?
Opinião de Especialistas
Analogia
Desagregação
Baseado em Fibonacci
1, 2, 3, 5, 8, 13, 20, 40, 100
Planning Poker
Estimando com Planning Poker
Pessoal, qual a estimativa para essa
estória?
Vamos jogar poker!
As estórias são rankeadas em ordem de importância pelo product owner.
Novos negócios
Venda
Retenção
Eficiência Operacional
Business Value Game
100, 200, 300, 500, 800, 1200, 2000, 3000
O product owner é o dono do backlog do produto.
Roadmap do Produto
Mês 1 Mês 2 Mês 3
Release 1 Release 2
Plano de Releases
Release 1 Release 2 Release 3
Planejando uma release
Priorização
Business Value / Story Points
BV SP BV/SP
US3 400 5 80
US1 200 5 40
US2 200 20 10
Product Backlog
Sprint Planningcapacidade do time, backlog do produto,produto atual, condições de negócio, tecnologia
Objetivo da Sprint
+
=Planning 1priorizar/selecionar os itens de backlog, discutir os critérios de aceitação, verificar o entendimento
Planning 2quebrar os items de backlog em tarefas, opcionalmente estimar as tarefas
+
Backlog da Sprint =
Vamos produzir aviões
Team Velocity
BV SP BV/SPUS3 400 5 80
US1 200 5 40
US2 200 20 10
Calculando o velocity em uma Sprint
BV SP BV/SPUS3 400 5 80
US1 200 5 40
US2 200 20 10
Team Velocity = 10
Calculando o velocity em uma Sprint
Team Velocity
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7
7070
80
70
60
90
40
Sprint 1
Sprint 2
Sprint N
Itens de risco
Aplicando o velocity no backlog
Criar as tarefas
Como cliente, gostaria de poder mudar a data da minha reserva
Quebrando os itens de backlog em tarefas
Sprint Backlog
Executando a Sprint
Análise Código Testa
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Análise Código Testa
Análise Código Testa
Análise
Código
Testa
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Análise
Código
Testa
Análise
Código
Testa
Daily Scrum Meeting
• O que você fez ontem?
• O que você fará de hoje
para amanhã?
• Há algum impedimento
em seu caminho?
15 minutos
Taskboard
Acompanhamento
Sprint Burndown
Product Burndown
1 2 3 4
80
100
120
160
Stor
y Po
ints
Sprint
Sprint Review
Scrum Retrospective
Revisando...
Scrum of Scrums
