Estimativas vs. Lead Time: fazendo previsões

Sempre que navego nas redes sociais, principalmente no Linkedin vejo alguns posts e até mesmo artigos que abordam a estimativa por meio da sequência de Fibonacci tendo uma baixa, ou baixíssima correlação com o lead time das atividades.

Realmente essa correlação é baixa, o que demostra nossa baixa capacidade de tentar mensurar o trabalho criativo. Tarefas que são estimadas em 8 pontos são finalizadas em 3 dias, enquanto tarefas que estimamos em 3, levam 12, 15 dias. Você pode ser perguntar por que isso acontece, porque erramos tanto nessa tentativa ineficaz de tentar prever algo.

Eu escrevi dois artigos sobre isso que vocês podem encontrar nestes links:

Correlação pontos de história e lead time!

Lidando com outliers nas medições de lead time

Eu ainda estou tentando descobrir uma maneira de prever com mais acurácia quanto tempo de fato vai levar uma tarefa estimada em 8 pontos, ou estimada em 5 talvez. Como resultado temporário e busca constante por respostas apresento mais um resultado que obtive com o estudo dos dados de um time Scrum que tem pouco mais de 6 meses trabalhando juntos e que fazem as estimativas das histórias de usuário por meio da Sequência de Fibonacci.

Além de coletar as estimativas, também coletei o tipo de demanda (bug, melhoria, nova feature) e se esses itens tinham ou não dependências conhecidas. O resultado está aí!

Introdução

Em 2011 o professor de Oxford Bent Flyvbjerg e o consultor da Mckinsey Alexander Budzier escreveram parta a Harvard Business Review um artigo intitulado “Why Your IT Project May Be Riskier Than You Think” que em tradução livre seria “Por que seu projeto de TI pode ser mais arriscado do que você pensa”. No artigo os autores explicam que os projetos de TI agora são tão grandes e afetam tantos aspectos de uma organização que representam um novo risco singular (FLYVBJERG e BUDZIER, 2011).

Sistemas de Tecnologia se tornaram um importante elemento competitivo em muitas indústrias (BLUMBERG e LAARTZ, 2012). A Universidade de Oxford, sugere que metade de todos os grandes projetos de TI — definidos como aqueles com preços iniciais superiores a US$ 15 milhões — estouraram enormemente seus orçamentos. Em média, grandes projetos de TI são executados 45% acima do orçamento e 7% acima do tempo, enquanto entregam 56% menos valor do que o previsto (BLUMBERG e LAARTZ, 2012).

São muitos riscos associados aos nossos projetos. Riscos muitas vezes desconhecidos que podem minar o nosso desempenho. Um aspecto importante do gerenciamento de riscos é a capacidade de prever, em qualquer etapa de um projeto, quais tarefas estão em risco de sofrer atrasos. Prever esses riscos permite que os gerentes de projeto tomem medidas prudentes para avaliar e gerenciar os riscos e, consequentemente, reduzir a chance de seu projeto ser atrasado.

Cumpre ressaltar que quanto mais tempo um projeto leva para ser concluído, mais valor ele perde. O sucesso geral percebido de um projeto de software depende fortemente da pontualidade de sua entrega (CHOW e CAO, 2008). Portanto, prever um risco deve ser uma habilidade dos times e em se tratando de projetos tradicionais, dos gerentes.

Ambientes modernos de desenvolvimento ágil exigem diferentes abordagens para o planejamento devido à sua natureza iterativa e voltada para equipes (KULA, VAN DEURSEN e GOUSIOS, 2021). Prever quando uma atividade vai acabar pode ser útil para planejamento futuros, aumento da confiança da equipe e diminuição do risco.

Existem algumas maneiras de evitar falhas em projetos de TI. Uma abordagem é criar equipes integradas de negócios e TI que trabalhem em conjunto desde o início do projeto até a conclusão, definindo requisitos e testando o produto final. Isso ajuda a evitar mal-entendidos durante as transições de estágio e garante clareza na responsabilidade e propriedade do projeto. Além disso, é importante analisar os riscos antes de iniciar um grande projeto de TI, especialmente os riscos imprevisíveis (black-swan risk). Outras práticas recomendadas incluem definir metas claras, estabelecer um plano realista e gerenciar cuidadosamente o escopo do projeto para evitar mudanças excessivas.

Explicando os dados

As pesquisas nessa área ainda são limitadas. Não temos também muitos datasets públicos disponíveis, talvez por se tratar de dados que contenham certo sigilo. Os dados par este estudo foram coletados e autorizados a serem tratados de forma anônima. São dados coletados ao longo de 3 meses, mas que correspondem a 4 semanas de trabalho, pois compreendem desde o planejamento por pontos de histórias até o completo ciclo de desenvolvimento. Um resumo dos dados de ser encontrado na tabela abaixo:

Neste resumo, temos 36 observações, sendo que a tarefa de menor lead time foram 2 dias e a tarefa de maior lead time foram 32 dias. A média de lead time foi de 8,72 dias com desvio padrão de 5,54 dias. Temos ainda neste dataset uma coluna com o tipo de atividade que o time estava realizando distribuídas em três categorias: bug, melhoria e nova feature. Para complementar também foi coletado se a atividade tinha dependência ou não.

Na amostra, temos 6 atividades consideradas pelo time como bug, 12 atividades de melhoria, ou seja, melhorar e aprimorar o que já havia sido feito e entregue e 18 eram novas features para o sistema. 24 atividades não tinham dependências e 12 eram dependentes de alguma outra atividade presente ou não no backlog.

O objetivo do estudo era saber se, com o acréscimo de duas variáveis ao dataset: tipo de atividade e se existe ou não dependência da tarefa, nós conseguiríamos aumentar a capacidade preditiva do nosso modelo em comparação quando coletamos apenas estimativa de pontos de histórias e lead time.

A previsão de quanto tempo uma história de usuário vai levar para ficar pronta pode ser feita com base em outros fatores, mais difíceis de se coletar, tais como a carga de trabalho do desenvolvedor, a experiência da equipe, a estabilidade da equipe e as estimativas de esforço anteriores. Além disso, o treinamento em histórias recentes de usuários pode levar a previsões mais precisas. Como não estamos prevendo as histórias de usuários em dias, não será possível calcular o atraso médio.

Sucesso no desenvolvimento de projetos

Um dos desafios na gestão de projetos de software é fazer previsões confiáveis de atrasos no contexto das mudanças constantes e rápidas inerentes aos projetos de software (CHOETKIERTIKUL, M. et al, 2015). Novas abordagens surgem com certa frequência para diminuir a lacuna entre o que foi previsto e o realizado. Com base nessa diferença, novas medidas deveriam ser tomadas para maximizar a performance do time. Entretanto, estamos mais preocupados em medir, do que trabalhar com o time em busca de melhorias.

De acordo com REEL (1999), As organizações têm tentado melhorar seus processos de desenvolvimento de software de várias maneiras. Ele enfatiza a importância de construir a equipe certa, obtendo pessoas boas e alertando que as empresas geralmente querem colocar as pessoas em vários projetos simultâneos. É importante fazer a gestão do produto, mais do que a gestão das pessoas.

Aprimorar a gestão do produto significa aumentar a satisfação das partes interessadas. Há literatura sugerindo que as partes interessadas podem ter diferentes percepções do que constitui sucesso do projeto, tanto em termos da importância dos critérios quanto do desempenho do projeto em relação aos critérios (DALCHER e DREVIN, 2003; Turner et al., 2009). Não há clareza absoluta na teoria que garante o que é um produto ou projeto de sucesso, mas aumentar a nossa acurácia em relação as previsões não nos trará efeitos negativos.

Outros fatores que podem influenciar no sucesso dos projetos e no desenvolvimento dos nossos produtos, além de uma previsão satisfatória das nossas atividades foram descritas por MCLEOD e MACDONELL (2011), são eles: a qualidade da equipe de desenvolvimento, a comunicação efetiva entre os membros da equipe, o gerenciamento adequado do projeto, a definição clara dos requisitos do projeto e a utilização de metodologias ágeis.

Sucesso ou fracasso de um projeto de desenvolvimento de sistemas de software é um conceito multidimensional e complexo, com dimensões técnicas, econômicas, comportamentais, psicológicas e políticas inter-relacionadas (MCLEOD e MACDONELL, 2011).

Evolução do Modelo

A primeira análise realizada com o nosso dataset foi a correlação entre as estimativas e o lead time. O valor obtido foi de 0.30, sendo uma correlação baixa entre estas duas variáveis. O gráfico abaixo ilustra o resultado.

O coeficiente de determinação, ou R², é uma medida que indica a proporção da variabilidade em y que é explicada pelo modelo de regressão linear. O valor de R² varia entre 0 e 1, sendo que valores próximos a 1 indicam que a maioria da variabilidade em y é explicada pelo modelo. No entanto, é importante lembrar que é possível aumentar artificialmente o valor de R² adicionando mais termos ao modelo, o que não necessariamente significa que o modelo é superior. Além disso, o valor de R² depende da amplitude da variabilidade na variável regressora x.

Obtemos um valor de R² = 0.0913, considerado baixo para explicar a variável lead time pelas estimativas. Valores de R² próximos a 1 implicam que a maioria da variabilidade em y é explicada pelo modelo de regressão (MONTGOMERY; PECK; VINING, 2012). Neste caso, um R² de 0,091 significa que apenas 9,1% da variação no lead time pode ser explicada pelas estimativas. Os restantes 90,9% da variação no lead time são atribuídos a outros fatores não incluídos no modelo. Isso sugere que pode haver outras variáveis ou fatores que influenciam o lead time e que não foram considerados no modelo atual.

O primeiro modelo de regressão linear tem o seguinte resultado:

Conforme resultado do modelo, a variável “estimado” apresenta uma relação pouco significativa, p-valor entre 0,05 e 0,1.

O teste de Shapiro-Francia é um teste estatístico utilizado para verificar a normalidade de uma amostra. Ele é uma variação simplificada do teste de Shapiro-Wilk, considerando apenas a assimetria e curtose da distribuição. As hipóteses para o teste são:

• Hipótese nula (H0): A amostra segue uma distribuição normal. Ou seja, não há evidências suficientes para afirmar que a distribuição da amostra é diferente de uma distribuição normal.

• Hipótese alternativa (H1): A amostra não segue uma distribuição normal. Isso significa que há evidências suficientes para afirmar que a distribuição da amostra é diferente de uma distribuição normal.

O teste de Shapiro-Francia calcula um valor-p, que é comparado com um nível de significância pré-determinado (geralmente 0,05). Se o valor-p for menor que o nível de significância, rejeitamos a hipótese nula e concluímos que a distribuição não é normal. Se o valor-p for maior que o nível de significância, não podemos rejeitar a hipótese nula e concluímos que a distribuição pode ser normal.

Dessa forma concluímos que a distribuição dos resíduos não segue uma distribuição normal. O que irá nos ajudar neste caso é transformar a variável via transformação de Box-Cox.

A transformação de Box-Cox é uma técnica utilizada para transformar dados que não seguem uma distribuição normal em dados que se aproximam de uma distribuição normal (BOX e COX, 1964). A transformação é feita através da aplicação de uma fórmula matemática que envolve um parâmetro lambda (λ). A escolha do valor de lambda é feita através da análise da superfície gerada pela fórmula para diferentes valores de lambda. A transformação pode ser aplicada tanto na variável dependente quanto nas variáveis independentes. A escolha da melhor transformação pode ser feita através de uma combinação de investigação direta da variável dependente e do método de Box e Tidwell aplicado às variáveis independentes. A técnica pode ser aplicada em diferentes áreas, como análise de variância, modelos de efeitos aleatórios, análise multivariada e análise de séries temporais. No entanto, é importante lembrar que a técnica depende de certas suposições e deve ser usada com cautela.

Após a transformação, estimamos um novo modelo:

Note que a variável “estimado” apresenta relação uma relação estatisticamente significativa. Dessa f orma nosso modelo de previsão considerando apenas as variáveis lead time e as estimativas é:

Y = 1.83341 + estimado*0.16653

Fazendo algumas previsões obtemos:

Para uma história de usuário prevista com esforço 5:

Para uma história de usuário prevista com esforço 8:

Eu vou encerrar esse post por aqui para não ficar muito extenso. Nos próximos artigos vamos acrescentar mais duas variáveis ao modelo continuar as previsões. Até lá!

Para escrever este artigo eu utilizei as seguintes referências:

ATKINSON, A. C. Plots, transformations, and regression: an introduction to graphical methods of diagnostic regression analysis. Oxford : New York: Clarendon Press ; Oxford University Press, 1985.

B. FLYVBJERG E A. BUDZIER, “Why Your IT Project May Be Riskier Than You Think,” Harvard Business Review, vol. 89, no. 9, pp. 601– 603, 2011 – https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think

B. MICHAEL, S. BLUMBERG, AND J. LAARTZ, “Delivering large-scale IT projects on time, on budget, and on value,” 2012 – https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value

BOX, G. E. P.; COX, D. R. An Analysis of Transformations. Journal of the Royal Statistical Society: Series B (Methodological), v. 26, n. 2, p. 211–243, jul. 1964.

CHOETKIERTIKUL, M. et al. Predicting Delays in Software Projects Using Networked Classification (T). 2015 30th IEEE/ACM International Conference on Automated Software Engineering (ASE). Anais… Em: 2015 30TH IEEE/ACM INTERNATIONAL CONFERENCE ON AUTOMATED SOFTWARE ENGINEERING (ASE). Lincoln, NE, USA: IEEE, nov. 2015. Disponível em: <http://ieeexplore.ieee.org/document/7372024/>. Acesso em: 8 maio. 2023

CHOW, Tsun; CAO, Dac-Buu. A survey study of critical success factors in agile software projects. Journal Of Systems And Software, [S.L.], v. 81, n. 6, p. 961-971, jun. 2008. Elsevier BV. http://dx.doi.org/10.1016/j.jss.2007.08.020.

DALCHER, D.; DREVIN, L. Learning from Information Systems failures by using narrative and ante-narrative methods. 2003.

KULA, Elvan; VAN DEURSEN, Arie; GOUSIOS, Georgios. Modeling Team Dynamics for the Characterization and Prediction of Delays in User Stories. 2021 36Th Ieee/Acm International Conference On Automated Software Engineering (Ase), [S.L.], p. 991-1002, nov. 2021. IEEE. http://dx.doi.org/10.1109/ase51524.2021.9678939.

OSBORNE, J. Improving your data transformations: Applying the Box-Cox transformation. [s.d.].

MCLEOD, L.; MACDONELL, S. G. Factors that affect software systems development project outcomes: A survey of research. ACM Computing Surveys, v. 43, n. 4, p. 1–56, out. 2011.

MONTGOMERY, D. C.; PECK, E. A.; VINING, G. G. Introduction to linear regression analysis. 5th ed ed. Hoboken, NJ: Wiley, 2012.

REEL, J. S. Critical success factors in software projects. IEEE Software, v. 16, n. 3, p. 18–23, jun. 1999.

SAKIA, R. M. The Box-Cox Transformation Technique: A Review. The Statistician, v. 41, n. 2, p. 169, 1992.

TURNER, J. R. The handbook of project-based management: leading strategic change in organizations. 3rd ed ed. New York: McGraw-Hill, 2009.

Sobre o autor

Rodrigo Zambon

Sólida experiência em Metodologias Ágeis e Engenharia de Software, com mais de 15 anos atuando como professor de Scrum e Kanban. No Governo do Estado do Espírito Santo, gerenciou uma variedade de projetos, tanto na área de TI, como em outros setores. Sou cientista de dados formado pela USP e atualmente estou profundamente envolvido na área de dados, desempenhando o papel de DPO (Data Protection Officer) no Governo.