Scrum

Eric Cavalcantiecavalcanti@gmail.com

@ericoc

Scrum

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

Perguntas?

Eric Cavalcantiecavalcanti@gmail.com

@ericoc