Nos últimos tempos ganhou força um novo movimento chamado #noestimates? O que isso significa? Qual a vantagem de adotar esse caminho?
O movimento, se assim podemos chamar, #noestimates tem como fundamento básico a afirmação que “estimativas não geram valor”. Baseado nisso, prega que devamos evitar a todo modo estimar, reduzindo tal atividade ou mesmo a extinguindo. Advoga que devemos bolar métodos alternativos à estimação. Será? Esse caminho serve para a gente?
Vamos começar falando um pouco sobre estimativas. Estimativas são por natureza incertas, i.e., apresentam o valor aproximado de algo que ainda não conhecemos, não dominamos ou não temos como medir. Estimativas são comumente usadas para previsão. E porque precisamos prever algo? Simples: para podermos planejar.
A ideia com o planejamento de uma forma geral é permitir que nos preparemos para o futuro, especialmente no que diz respeito a tomarmos decisões que promovam a eficácia e eficiência do nosso projeto. Nesse artigo Planejando a Sprint: Velocidade e Estimativa, p.ex., falamos do planejamento da Sprint.
Entretanto, adicionalmente, devemos também entender que o processo de estimar envolve a procura de conhecimento sobre o que se deseja estimar. Em projetos de desenvolvimento, seja de software ou de qualquer outro produto ou serviço, isso representa discutir o assunto com o cliente/usuário. Buscar e investigar produtos ou serviços semelhantes ou de concorrentes. Muitas vezes até promover discussões com especialistas. E essa busca por conhecimento traz como efeito colateral um melhor entendimento do que se deseja estimar. Quanto mais sabemos mais acertamos, como discutimos nesse post Histórias bem Descritas, Estimativas mais Precisas.
Assim, chegamos ao primeiro aspecto importante, abordado de certa forma pelo #noestimates. Só devemos estimar se isso for necessário para alguma coisa que nos traga valor. Seja para prever custos, prazos, planejar capacidade, definir escopo de projeto, entender dependências entre requisitos e/ou melhorar o entendimento sobre algo que deveremos fazer.
Por outro lado, sabemos que estimativas são intrinsecamente imprecisas, especialmente se elaboradas pelas pessoas erradas, no momento errado. A literatura relacionada a projetos de software deixa isso bem claro, como apresentado por Robert Glass, aqui sintetizado:
- A maioria das estimativas de software é feita no início do ciclo de vida, quando tem-se pouco entendimento do problema.
- A maioria das estimativas é feita pela gerência ou pelo marketing, não por quem irá efetivamente construir o software.
- Raramente estimativas são refeitas.
Considerando tais observações, podemos também deduzir para que estimativas não devem ser usadas.
- Determinar algo com precisão.
- Estabelecer desafios.
- Basear cobranças.
- Premiar desempenho.
- Curar falta de comprometimento.
- Estabelecer confiança.
Sabemos que estimativas são muitas vezes utilizadas de forma errada e isso precisa sim ser combatido. Porém estimativas são parte indispensável de um processo de planejamento que, como vimos acima, serve pelo menos para organizarmos esforços para o atingimento de algum objetivo.
Como fazer então? Falamos para o cliente que é impossível planejar, porque não podemos ou devemos estimar nada? Planejamos com detalhes tudo que vamos fazer?
Bem, inicialmente devemos entender que o movimento ágil percebeu esse problema nos processos tradicionais de desenvolvimento e estabeleceu algumas diretivas que ajudam a reduzir os efeitos colaterais negativos de estimativas. Destaco a mais relacionada, ao meu ver, a estimativas: “Responder a mudanças mais que seguir um plano”. Isso significa, por exemplo, que ao planejarmos algo entendemos que nosso conhecimento sobre o planejado irá mudar e que precisaremos rever nosso planejamento. Tudo a ver com o que discutimos acima.
De uma forma geral, o movimento #noestimates, ou as recomendações do mesmo, segue o mesmo caminho de muitos outros que tem surgido na agilidade: traz diversos insights interessantes, mas não pode ser aplicado de forma absoluta ou em qualquer caso.
Muitos projetos e organizações com as quais temos contato já, de certa forma, ao utilizar o Scrum, trabalham com #noestimates. Em sua maioria, os times estimam histórias usando pontos de história. Entretanto, a maioria não estima tarefas, limitando-se a estabelecer um timebox para estas. É comum os times quebrarem suas histórias em tarefas procurando limitar o tamanho de suas tarefas para que possam ser realizadas em um dia, no máximo em dois.
Concluindo, #noestimates é muito válido, mas não significa que deva ou possa ser aplicado indiscriminadamente. Se agrega valor, estimar é preciso. O mais importante é lembrar que estimar por estimar só atrapalha o time.
Como tem sido sua experiência em projetos Scrum? Sua equipe estima ou não? Vocês vêem valor em estimar?
-350x264.jpg?x13947)
Olá,
Executamos um projeto de melhorias aqui na empresa e ao invés de estimarmos as tarefas seja por pontos, seja por unidades de tempo, definimos para cada uma um deadline de forma que não bloqueasse as tarefas seguintes e permitisse que entregássemos a Sprint com tudo que tinha sido planejado. Funcionou bem, porém, não tivemos capacidade de realizar uma mensuração mais precisa, como por exemplo, um burndown detalhado. O que conseguimos “reportar” era quantas tarefas definimos para a Sprint e quantas estavam em “To-Do”, “Doing” ou “Done”.
Oi Francilei,
Bem legal o approach de vocês. E a ideia quando se fala de tarefas é exatamente esta, ou seja, ao invés de estimar, fazer com que todas tenham um tamanho padrão a grosso modo, normalmente um ou dois dias. Com relação ao Burndown, normalmente o fazemos baseado nos pontos das histórias, não das tarefas. Mas também há formas de se fazer por tarefa. Só não entendi o que vocês chamam de deadline. Vocês estabelecem datas tarefa a tarefa, para cada história? Tudo durante a reunião de planning?