Planejando uma sprint assertiva sem estimativas!

Provavelmente você está aqui em busca de respostas, certo? As perguntas costumam ser muitas. Iniciar uma nova sprint tendo a certeza de que tudo dará certo e a sprint será concluída é uma tarefa bem complicada!

Por muitos anos, na empresa onde eu trabalho (MOVERE Software), planejávamos a sprint com base em estimativas. No início, estimávamos as tarefas estipulando o tempo necessário (em horas) para realizar tal tarefa. Posteriormente, passamos a estimar as tarefas em Story Points, nos baseando no Pointing Poker ou até mesmo no achismo, onde cada um “chutava” quantos Story Points eram necessários para concluir uma determinada tarefa.

Independente do formato, se você planeja sua sprint com base em estimativas, no final das contas você está planejando com base no achismo das pessoas, com um nível muito baixo de certeza. Talvez seja por isso que seu time costuma atrasar a maioria das sprints, ou então, estão pegando cada vez menos tarefas para trabalhar com mais folga, tornando a previsibilidade do backlog algo pouco tangível.

E qual é o melhor formato?

O melhor formato que encontramos para ter uma assertividade maior no planejamento da sprint foi: Planejar as tarefas! Isso mesmo, planejar cada tarefa! Isso consiste em conhecer muito bem o assunto em questão, não pode haver “entre linhas”, tudo precisa estar exposto, cada detalhe!

Basicamente estamos falando de “No Stimates, e é literalmente isso! Não existe mais “eu acho que leva tanto tempo”, ou então: “acho que amanhã estará pronto”, não não! O que fazemos é pegar um assunto (PBI), entender o contexto dele, entender o critério de aceitação, e com base nisso, começar a discutir em como implementar esse PBI no sistema. E isso é feito nos menores detalhes possíveis, chegando a ter tasks do tipo “Criar a classe XTPO“, “Criar o método que carrega os detalhes do cliente“, “Criar a procedure que retornará os detalhes do pedido“, “Criar teste unitário para o cenário X“, e assim por diante.

Entendendo a diferença entre estimativa e planejamento

Vamos tomar como exemplo um PBI (Product Backlog Item) que nos solicita que seja criado um CRUD para que possamos guardar no sistema o cadastro de produtos. Dado esse cenário, sabemos que temos envolvido nessa solução tanto banco de dados quanto o sistema (aplicação). Vamos aos planejamentos e estimativas conforme os dois modelos:

Primeiro, vamos ao formato de estimativa em Story Points (chute com base no achismo do desenvolvedor). Nesse formato, estou tomando como modelo tarefas de mais alto nível, sem detalhamento, veja:

TarefaEstimativa
Criar estrutura de banco de dados3
Criar nova rotina (tela) no sistema (CRUD)5
Implementar CRUD3
Homologar, testar e documentar2
Total13

Isso quando o formato utilizado não seja estimar diretamente o PBI, chutando um número de 13 ou 21 Story Points sem saber nos detalhes o passo a passo a ser executado para levar a tarefa para “done”.

Agora, vamos ao modelo que utilizamos (há alguns anos) atualmente na empresa onde eu trabalho. Este modelo tem se mostrado muito promissor, principalmente quando novos membros do time precisam lidar com tarefas já planejadas anteriormente.

Antes de expor o modelo sugerido, vale notar que o planejamento é feito a nível de “task” e o tamanho dela é sempre 1. Nesse caso, a tarefa só tem duas situações: Ou está pronta, ou não está! Vamos ao exemplo:

Nota: Planejamento com base em um sistema WebForms sem Migrations ou Entity Framework.

TarefaPeso
Criar a tabela no banco de dados1
Criar o model da tabela no sistema para posterior utilização1
Criar o script para geração da tabela nos bancos de dados de produção1
Cadastrar a nova rotina no sistema1
Criar os arquivos base para a rotina1
Criar os controles necessários para o usuário inserir os dados1
Padronizar os controles conforme os padrões utilizados1
Criar a classe necessária para persistência e carregamento de dados1
Criar estrutura necessária para persistência1
Criar o método para cadastrar um novo registro1
Criar o método para carregar um registro já persistido1
Criar o método para atualizar um registro já persistido1
Criar o método para excluir um registro já persistido1
Implementar uso da classe de persistência na rotina criada1
Na rotina, implementar preenchimento dos controles para Alteração de registros1
Criar os botões de ações (salvar, voltar)1
Implementar uso da classe de persistência e leitura de dados para gravação dos registros (novo, alterar e excluír)1
Validar o funcionamento da rotina como um todo1
Criar a documentação necessária1
Homologar solução1
Total20

É importante ressaltar que a “quantidade final” não é comparável entre os modelos, visto que, são medidas diferentes. O que eu quero destacar aqui é o nível de certeza que o modelo planejado nos trás. No primeiro exemplo, onde estimamos com base no que conhecemos e no achismo, o nível de certeza é menor, principalmente se algum detalhe escapar. Já no segundo modelo, você pode notar que não há como fugir muito do que foi planejado, visto que, já colocamos o passo a passo necessário para concluir a tarefa.

Outro ponto interessante é o “estado da tarefa”. Nesse modelo com planejamento, ou uma tarefa está pronta ou não está! Não existe isso de chegar no final do dia e “estimar o quanto falta para acabar”.

Ganhos perceptíveis

Após muitas e muitas sprints utilizado este modelo de planejamento, atualmente temos uma certeza bem maior do que pode ou não pode ser feito numa sprint (utilizamos sprints de uma semana). Após finalizado o planejamento da sprint, sempre estamos confiantes de que tudo está bem planejado e que ao iniciar a sprint, bastará seguir o planejamento para concluir todas as tarefas.

Outro ganho aparente está na facilidade com que novos membros lidam com as tarefas, visto que, eles não precisam ficar adivinhando os passos a serem seguidos para construir o software solicitado pela tarefa, visto que, a própria tarefa serve como guia, expondo passo a passo o caminho a ser seguido.

Existem desvantagens?

Eu diria que não! Provavelmente surjam dúvidas e questionamentos se forem implementar tal método de planejamento, tipo: “A sprint planing vai levar o dobro do tempo”. Sim, a sprint planing vai levar mais tempo utilizando esse modelo, porém, isso é compensado com a assertividade das tarefas, evitando surpresas do tipo: “Não deu para fazer tudo”, “A tarefa estava mal estimadas”, “Esquecemos de considerar o módulo X”, e assim por diante.

Considerações finais

Eu como desenvolvedor me habituei a planejar as sprints da qual eu participo dessa forma. Lembro que fui o pioneiro a usar esse modelo de estimativas no time que eu estava na época, e logo, todos os times passaram a adotar esse modelo.

Tenho para mim que é o melhor modelo de planejamento, principalmente quando você tem profissionais seniores e juniores no mesmo time, onde pode acabar acontecendo de todos estimarem juntos e acabar com que um júnior execute a tarefa. E convenhamos, a estimativa que um júnior dá a uma tarefa é bem maior (em horas ou strory points) do que um sênior, certo? No modelo de planejamento não existe essa distinção, a tarefa tem um tamanho que serve para ambos os cargos.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.