O desafio da previsibilidade
Estimativas representam o esforço legítimo de tentar prever o prazo de entrega e o custo de desenvolvimento de um software. Estas previsões acabam sendo pré-requisitos devido ao modo como planejamos nossa estratégia, que geralmente exige um orçamento prévio e um plano de negócio com um cronograma definido.
Para projetos aos quais conseguimos no seu início ter clareza dos requisitos e uma razoável estabilidade do escopo, como a construção de uma casa ou um prédio, por exemplo, essa abordagem pode fazer sentido de fato. Talvez essa, inclusive, seja a razão pela qual tentamos utilizar o mesmo método em outros cenários.
Todavia, geralmente, em desenvolvimento de software estamos trabalhando na concepção e construção de um produto inédito. Muito sujeito a mudanças decorrente do aprendizado que ocorre durante seu desenvolvimento e quase sempre não há uma visão de tudo que precisa ser feito desde o início.
Portanto, como fazer previsões de algo que nunca foi feito antes, que muda a todo momento e que não sabemos de antemão o que precisa ser feito?
Para tentar responder essa pergunta existe no mercado uma série de métricas e técnicas prometendo ser a sua bola cristal: contagem de pontos de função, story points, homem/hora, planning poker, etc… Todas essas medidas tem como fundamento as percepções dos desenvolvedores sobre quanto tempo leva para programar uma determinada funcionalidade. O que é simplório, pois ignora todas as outras etapas do processo de criação. Também [tweet]é no mínimo frágil tomar decisões importantes do negócio com base na opinião do time operacional, e é isso que fazemos quando trabalhamos com estimativas de software[/tweet].
Previsibilidade exige visão holística do processo
O processo de desenvolvimento de uma solução, além da codificação, por padrão, envolve: Concepção, processos de aprovação, entendimento e detalhamento das demandas, teste, homologação e deploy. Sendo que várias dessas etapas estão sujeitas a paradas por dependência de processos externos. Por exemplo, a aprovação pode exigir o encontro de um comitê; etapas que envolvem times diferentes podem implicar em espera por falta de disponibilidade do outro time; o processo de deploy pode estar atrelado a uma janela de publicação que ocorre uma vez por mês.
O tempo entre uma demanda surgir e entrar em produção é fortemente influenciado pela quantidade de vezes que elas precisam voltar etapas no fluxo, por exemplo, requisitos mal definidos que voltam para análise, software mal implementado que volta para desenvolvimento devido a bugs, reprovação pelo usuário na homologação devido a falta de consenso nas regras de negócio, deploy bloqueado por falta de compliance com políticas de segurança, etc… Além dos itens que voltam, alguns são iniciados, mas no meio do processo há uma mudanças de prioridade e eles ficam parados dias, às vezes semanas.
Considerando que do ponto de vista de negócio, estimativas são traduzidas como time-to-market, qual a relevância se o tempo de codificação é de 1 ou 2 dias se provavelmente os itens ficarão parados na fila aguardando várias semanas? Qual a vantagem em codificar rápido, se isso não se traduzir em uma redução no tempo que precisamos para colocar uma solução no mercado? Na nossa experiência é comum que o tempo em espera dos itens na fila seja significativamente superior ao seu tempo de desenvolvimento. Portanto, em vez de analisar uma etapa isoladamente, temos que considerar todo o fluxo.
Estimativas são inúteis?
Em um mundo ideal todo profissional deveria ter condições de dizer quanto tempo levaria para executar determinada atividade. Portanto, não é que não acreditemos que estimativas não tem valor, pelo contrário, entendemos que boas estimativas facilitariam o processo de tomada de decisão de negócio e simplificaria o planejamento. Todavia, do ponto de vista prático, não vemos isso como um exercício produtivo, pois em geral se gasta muita energia para produzir previsões muito ruins.
Como alternativa, acreditamos no planejamento contínuo, suportado por métricas que medem de maneira constante os avanços do negócio. Com indicadores que levam em consideração o fluxo completo de trabalho, não apenas a codificação. Sobretudo, acreditamos que faz parte do processo de desenvolvimento de software gerenciar e lidar com as incertezas. Esse será o tema dessa série de posts.
