21.6 Mais algumas considerações sobre a velocidade

Posted on: seg, 05/13/2019 - 05:17 By: Cesar Brod

 

A equipe Scrum é soberana na estimativa do esforço necessário, tipicamente em pontos (history points), para o desenvolvimento de cada uma das histórias do Product Backlog. O Product Owner, porém, precisa ter uma boa ideia da velocidade da equipe, o número de pontos que ela consegue realizar por Sprint, para poder controlar a ansiedade dos patrocinadores e clientes com relação às entregas que serão feitas.

A Tabela 21.1 é adaptada dos ensinamentos de Henrik Kniberg e outros agilistas e é a que mais tenho usado em minhas equipes para estimar velocidade e, com ela, tempo para as entregas.

Tabela 21.1 – Evolução da velocidade

 Sprint
 1
 2
 3
 4
 5
 6
 7
 8
 Número Mágico
 Velocidade real
 
 
 
 
 
 
 
 
8
 Velocidade estimada
 
 
 
 
 
 
 
 
 
 Dependências
 
 
 
 
 
 
 
 
 
 Versão
 
 
 
 
 
 
 
 
 

 

Cole essa tabela em algum lugar próximo ao Burndown Chart de sua equipe e preencha-o, na medida em que os Sprints progridem, sempre indicando qual é o Sprint corrente. Aqui, iremos destacar, com letras em vermelho, a coluna da tabela que corresponde ao Sprint em questão.

No primeiro Sprint de um projeto, especialmente quando trabalhamos com uma nova equipe, não há como estimar a velocidade. A equipe ainda está calibrando o seu chute. Nesse caso, o Product Owner apenas registrará o número de pontos efetivamente realizados pela equipe: a soma de todos os pontos das histórias que foram aceitas na revisão do Sprint.

A Tabela 21.2 ilustra esse registro ao final do primeiro Sprint.

Tabela 21.2 – Evolução da velocidade, Sprint 1

 Sprint
1
 2
 3
 4
 5
 6
 7
 8
 Número Mágico
 Velocidade real
N/A
 12 - 28
 
 
 
 
 
 
 8
 Velocidade estimada
20
 
 
 
 
 
 
 
 
 Dependências
 
 
 
 
 
 
 
 
 
 Versão
 
 
 
 
 
 
 
 
 

 

O Product Owner anota, na linha Velocidade Estimada, N/A (não se aplica, já que estamos no primeiro Sprint), e constata que a equipe entregou três histórias cujos pontos, somados, resultam em 20. Agora, ele subtrai o número mágico desse total (12) e o soma ao total (28). Sua velocidade estimada para o Sprint 2 é algo entre 12 e 28. Logo mais falaremos sobre o número mágico.

Ao final do segundo Sprint, a equipe realizou 22 pontos. Como esse número está entre 12 e 28, o número mágico é decrescido de dois, passando a ser seis. Assim, a estimativa para o próximo Sprint é que a velocidade seja 22 +/- 6 (entre 16 e 28).

Tabela 21.3 – Evolução da velocidade, Sprint 2

 Sprint
 1
2
 3
 4
 5
 6
 7
 8
 Número Mágico
 Velocidade real
N/A
12 - 28
 16 - 28
 
 
 
 
 
 6
 Velocidade estimada
20
22
 
 
 
 
 
 
 
 Dependências
 
 
 
 
 
 
 
 
 
 Versão
 
 
 
 
 
 
 
 
 

 

Ao final do terceiro Sprint, a equipe realizou 15 pontos. Como esse número não está entre 16 e 28, o número mágico é acrescido de dois, voltando a ser oito. Assim, a estimativa para o próximo Sprint é que a velocidade seja 15 +/- 8 (entre 7 e 23), como mostra a Tabela 21.4.

Tabela 21.4 – Evolução da velocidade, Sprint 3

 Sprint
 1
2
3
 4
 5
 6
 7
 8
 Número Mágico
 Velocidade real
N/A
12 - 28
16 - 28
 
 
 
 
 
 8
 Velocidade estimada
20
22
15
 
 
 
 
 
 
 Dependências
 
 
Faltou um membro da equipe nesse Sprint
 
 
 
 
 
 
 Versão
 
 
 
 
 
 
 
 
 

 

Note que a equipe observou a falta de um membro da equipe no terceiro Sprint. Imprevistos acontecem. É importante observar o que impacta, positiva ou negativamente, o desempenho da equipe. Para o Product Owner, porém, o importante é ir calibrando o chute, aproximando a estimativa da realidade. E é por isso que o número mágico aumenta quando a realidade fica fora da estimativa e diminui quando fica dentro. Não importa se os pontos alcançados ficam fora do limite superior ou inferior da estimativa: se a equipe tivesse realizado 29 pontos em vez dos 15, ainda assim o número mágico voltaria a ser oito.

Mas, afinal, de onde vem esse número mágico? De lugar nenhum! Ele é um chute inicial. Na minha prática acabei por concluir que um número de mágico igual a oito, com o incremento ou decremento de dois, funciona bem. Uso a regra de três para velocidades iniciais reais diferentes (20 está para oito como 40 está para dezesseis e, então, o passo incremental fica em quatro, para mais ou para menos). Se você não gosta do número oito, tente com outros números e incrementos. Para efeito de nosso exemplo, sigamos com o número mágico inicial oito e rodemos mais alguns Sprints.

Tabela 21.5 – Evolução da velocidade, Sprint 4

 Sprint
 1
2
3
 4
 5
 6
 7
 8
 Número Mágico
 Velocidade real
N/A
12 - 28
16 - 28
7-23
 
 
 
 
 6
Velocidade estimada
20
22
15
20
 
 
 
 
 
 Dependências
 
 
Faltou um
membro da equipe
nesse Sprint
 
 
 
 
 
 
 Versão
 
 
 
 
 
 
 
 
 

 

A tabela 21.5 mostra que a equipe voltou a fazer 20 pontos no quarto Sprint, ficando dentro da estimativa, o que faz com que o número mágico volte a ser seis. Assim, a estimativa de velocidade para o quinto Sprint passou a ser entre 12 e 28 pontos. A tabela 21.6 mostra que a equipe se manteve dentro da estimativa no quinto Sprint, quando entregou o MVP completo (o mínimo produto viável – ver o Capítulo 19).

Tabela 21.6 – Evolução da velocidade, Sprint 5

 Sprint
 1
2
3
4
5
 6
7
 8
 Número Mágico
 Velocidade real
N/A
12 - 28
16 - 28
7 - 23
12 - 28
 
 
 
 4
Velocidade estimada
20
22
15
20
23
 
 
 
 
 Dependências
 
 
Faltou um
membro da equipe
nesse Sprint
 
 
 
 
 
 
 Versão
 
 
 
 
MVP
 
 
 
 

 

O produto é, então, lançado para um grupo significativo de clientes e, com o seu feedback imediato, o Product Owner irá refinar as próximas histórias de desenvolvimento, sempre com o apoio da equipe e com as informações dos usuários e, repetindo-se algumas dinâmicas selecionadas e exemplificadas na parte V desse livro, chega-se a uma definição de quais histórias irão compor a versão 1.0 do produto.

Imagine que o total dessas histórias some 160 pontos e a equipe de marketing da empresa deseja saber quanto tempo tem até que o produto possa ser lançado. O Product Owner já sabe que, no melhor cenário, a equipe pode chegar a 27 pontos por Sprint e, no pior cenário, a 19 pontos por Sprint, assim:

Pior cenário = 160/19 ≃ 9 Sprints

Melhor cenário = 160/27 ≃ 6 Sprints

Ou seja, a versão 1.0 será entregue entre seis a nove Sprints. Essa é outra razão pela qual prefiro Sprints curtos, de uma semana. Além de se chegar mais rapidamente a uma estimativa de velocidade que se aproxime da realidade, é mais fácil coordenar ações acessórias ao desenvolvimento (marketing, precificação, etc) em um período mais visível de tempo (semanas ou meses em vez de trimestres, semestres ou anos). É assim, inclusive, que a agilidade irá permear outras áreas da empresa.

Em equipes que adotam plenamente o Scrum, com seus papéis, ritos e artefatos, junto com as práticas de engenharia de software do Extreme Programming (XP, ver Capítulo 3), é comum chegar em um número mágico igual a dois e um incremento igual a um.

 

TODO: Colocar debaixo da estrutura correta quando o capítulo 21 for inserido

Comentar

CAPTCHA Nosso portal usa esse mecanismo para evitar spam.