Nesta análise, estaremos usando os dados da empresa Software in Partnership (SiP), conjunto de dados relacionado à área de Engenharia de Software, que trata mais especificamente sobre a estimativa e o custo em tempo nas atividades dessa empresa. Além dos dados, já existe uma análise inicial, que pode auxiliar nosso trabalho.
Antes de iniciar a análise, é sempre interessante termos uma visão inicial dos dados:
## Rows: 12,299
## Columns: 17
## $ task_number <chr> "1735", "1742", "1971", "2134", "2251", "2283",~
## $ summary <chr> "Flag RI on SCM Message Summary screen using me~
## $ priority <dbl> 1, 1, 2, 5, 10, 1, 5, 5, 6, 5, 2, 1, 3, 1, 1, 8~
## $ raised_by_id <chr> "58", "58", "7", "50", "46", "13", "13", "13", ~
## $ assigned_to_id <chr> "58", "42", "58", "42", "13", "13", "13", "58",~
## $ authorised_by_id <chr> "6", "6", "6", "6", "6", "58", "6", "6", "6", "~
## $ status_code <chr> "FINISHED", "FINISHED", "FINISHED", "FINISHED",~
## $ project_code <chr> "PC2", "PC2", "PC2", "PC2", "PC2", "PC9", "PC2"~
## $ project_breakdown_code <chr> "PBC42", "PBC21", "PBC75", "PBC42", "PBC21", "P~
## $ category <chr> "Development", "Development", "Operational", "D~
## $ sub_category <chr> "Enhancement", "Enhancement", "In House Support~
## $ hours_estimate <dbl> 14.00, 7.00, 0.70, 0.70, 3.50, 7.00, 7.00, 7.00~
## $ hours_actual <dbl> 1.75, 7.00, 0.70, 0.70, 3.50, 7.00, 7.00, 7.00,~
## $ developer_id <chr> "58", "42", "58", "42", "13", "13", "43", "58",~
## $ developer_hours_actual <dbl> 1.75, 7.00, 0.70, 0.70, 3.50, 7.00, 7.00, 7.00,~
## $ task_performance <dbl> 12.25, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00~
## $ developer_performance <dbl> 12.25, 0.00, 0.00, 0.00, 0.00, 0.00, NA, 0.00, ~
Para entender melhor os dados, além da visão inicial que tivemos, é sempre interessante gerar algumas perguntas e hipóteses, para que sejam respondidas ao longo da análise: * Qual a distribuição das estimativas? Dos tempos de tarefa? * Quais os tamanhos de time? * Quantos projetos temos? * Quantas categorias temos?
Pela distribuição que conseguimos ver acima, é difícil concluir algo muito concreto. Mas, conseguimos entender que existem atividades estimadas em mais de 750 horas, e existem atividades que custaram mais de 2 mil horas. Entretanto, tanto nas estimativas quanto nos custos reais, o tempo costuma ser bem menor às 250 horas. Vejamos então como se distribuem as atividades usando dois limites: 100 e 250 horas.
Após limitar o eixo x, conseguimos entender melhor como é a distribuição dos dados: agora fica claro que tanto as horas estimadas quanto as horas gastas se concentram em 10 ou menos horas. Além disso, podemos ver uma leve diferença entre a distribuição no tempo estimado e no tempo real: enquanto a distribuição do tempo estimado parece mais “discretizada”, a do tempo gasto exibe mais claramente uma cauda longa, mais contínua.
À exceção do que vimos nos dois primeiros gráficos em que as tarefas mais longas foram estimadas em torno de 800 horas, enquanto as mais longas custaram mais de 2 mil horas, quando focamos nas atividades que gastaram menos horas, o tempo estimado é bem mais próximo do tempo gasto. Talvez isso se deva a serem atividades menos complexas de serem estimadas, indicando que a granularidade da tarefa impacta diretamente na diferença entre o tempo estimado e o tempo gasto.
Além de entender os tempos, temos que entender também como funcionam os times, principalmente seus tamanhos. Vejamos então quais são os tamanhos dos times por projeto:
Com os dois gráficos acima, podemos entender melhor algumas coisas, de forma complementar: * O primeiro deles, de forma absoluta, estamos contando a quantidade de membros de cada equipe, e podemos ver com clareza que equipes de 8 e 11 membros são as mais frequentes, que não existem equipes de 7 ou 9 membros, e entender a quantidade de equipes com cada quantidade de membros; * O segundo nos dá uma visão mais geral acerca da distribuição das equipes, e embora não consigamos ver o número de equipes, conseguimos ver mais claramente que é mais comum que as equipes possuam de 4 a 10 membros, mas que é mais comum que tenham menos que 4 membros do que mais que 10.
Para responder essa pergunta, precisamos sumarizar a informação, contando quantas tarefas cada projeto possui:
Através do gráfico, podemos ver que os projetos PC2, PC18 e PC9 possuem uma quantidade bem maior de tarefas que os outros projetos. Além disso, conseguimos visualizar que possuimos os dados de 20 projetos - de PC1 a PC20.
Agora com outro objetivo, de entender as categorias, podemos repetir o mesmo processo feito na visualização anterior. Vejamos:
É fácil de entender que a grande maioria das atividades são de desenvolvimento, enquanto a quantidade de tarefas operacionais e de gerência são bem próximas. Entretanto, cada projeto tem sub categorias. Como a maior parte das tarefas é de desenvolvimento, é também interessante analisar suas subcategorias:
Agora conseguimos entender com mais clareza em que o tempo de desenvolvimento é dedicado, e da mesma forma que anteriormente, o predomínio é nas atividades de Suporte, Solução de Bugs, e Desenvolvimento de melhorias. Entretanto, observando essas categorias, é possível gerar alguns questionamentos, por exemplo: “Se houvessem mais atividades focadas em testagem, diminuiria o número de tarefas de solução de bugs?”. Esse tipo de questionamento poderia ter ajudado nas atividades de gerenciamento da empresa.
Consideremos que o erro em uma estimativa é a diferença entre a estimativa e o tempo que a tarefa de fato tomou. O erro absoluto é o módulo do erro. Então, além das perguntas anteriores, vamos responder mais algumas: * Como é a distribuição do erro nas estimativas de diferentes subcategorias de tarefas? Se quiser, use também as categorias nos dados. * Como se comparam as distribuições de tempo (real) das tarefas entre os diferentes times? Há times com tarefas consideravelmente maiores?
Vendo o eixo X, existem erros de estimativa de mais de 2 mil horas. Entretanto, a grande maioria está concentrada abaixo de 250 horas de erro. Vejamos novamente, limitando o eixo:
O erro de estimativa parece ser bem pequeno, a grande maioria com menos de 10 horas de erro por tarefa. Para melhorar o entendimento, podemos ver essa informação dividida pelas subcategorias. Para isso, precisaremos sumarizar a informação e veremos essa distribuição agrupada nas subcategorias, usando um boxplot:
Pela visualização acima, conseguimos entender que a subcategoria de teste é a que teve o maior erro de estimativa, mas além desse outlier, não existem discrepâncias tão absurdas. Entretanto, o erro costuma ser bem pequeno em todas as subcategorias, e isso pode ser entendido percebendo que a maioria das caixas do boxplot são pouco visíveis, enquanto na maioria do gráfico, se concentram os outliers. Vejamos o erro padrão, desconsiderando os outliers:
Nessa visão mais próxima, conseguimos entender que as tarefas de pesquisa e conversão são as estimadas mais equivocadamente, enquanto a de solução de bugs e de suporte tem uma estimativa bem condizente com a realidade.
Como uma das perguntas iniciais, sabemos que os projetos PC2, PC18 e PC9 são os que possuem mais tarefas. Assim, esperamos que esses sejam os projetos que mais tenham horas dedicadas. Vejamos se essa expectativa se concretiza:
Diferente do esperado, o projeto que possui uma distribuição maior de horas é o PC20. Entretanto, o PC20 é o segundo projeto que tem menos tarefas, então entende-se o motivo de estar com a distribuição acima das demais. Observando a quantidade de outliers, vemos que os projetos PC9, PC2 e PC18 são os que possuem mais outliers, não necessariamente nessa ordem, mas que condiz com a expectativa que havíamos criado anteriormente.
Podemos também visualizar novamente essa mesma informação, restringindo até 500 horas dedicadas - já que os dados que passam desse limite ficam bem visíveis na visualização anterior:
Agora, é mais claro o número de horas dedicadas que fogem da normalidade em cada projeto. Novamente, fica claro que os projetos PC9, PC2 e PC18 são os que mais possuem atividades com dedicação acima do comum.