Evidence Based Scheduling

Eu não acredito em cronogramas, mas que eles existem, existem. Bem, nem todo cronograma é furado… os ferroviários ingleses que o digam.🙂

O Joel Spolsky, que é um cara inteligente e experiente, diz que os desenvolvedores de software em geral não gostam de fazer cronogramas por duas razões. Primeiro, porque é um saco. Segundo, porque ninguém acredita mesmo que o cronograma seja realístico.

Mas, como dono de uma empresa de software, o Joel deve ter seu “lado administrador” sempre procurando encontrar uma forma de “controlar as coisas”. Sabe como é: planejamento, planilhas, cronogramas…

O fato é que ele bolou um novo método de produzir cronogramas baseado no método de Monte Carlo e conseguiu me fazer acreditar que funcione. Ele chamou o método Evidence Based Scheduling, ou EBS, que parece bastante apropriado.

Para os que gostam (e principalmente para os que, como eu, não gostam) de cronogramas, eu sugiro a leitura do artigo em que o Joel explica detalhadamente o método. Para os demais (hã?) aqui vai um resumo:

O início não tem novidade. O grupo de desenvolvedores que vai trabalhar num projeto faz uma WBS detalhada do mesmo, quebrando-o em atividades de, no máximo, 16 horas. Cada atividade é atribuída a um desenvolvedor e é ele quem decide o tempo que vai levar para executá-la.

Todas as estimativas devem ser registradas e associadas ao desenvolvedor que as fez. É importantíssimo que cada desenvolvedor registre também o tempo que ele efetivamente gastou na execução das tarefas. Deste modo, ao longo do tempo, vai-se acumulando informações sobre a capacidade de “estimação” de cada desenvolvedor.

Depois de algum tempo, é possível plotar um gráfico para cada desenvolvedor, correlacionando suas estimativas com suas respectivas execuções. A idéia é que “estimadores” experientes tendem a cometer sempre os mesmos erros. Já estimadores inexperientes tendem a variar bastante nos seus erros.


De posse desse histórico e do conjunto de estimativas da WBS do novo projeto, o sistema gera 100 simulações diferentes usando, cada vez, um valor aleatório do histórico de erros passados de cada desenvolvedor para projetar o tempo de execução efetivo de cada atividade. O resultado dessas 100 simulações é um gráfico mostrando a probabilidade de que o projeto termine em um intervalo de datas dentro do qual caíram todas as 100 simulações.


O que é bacana neste método é que ele não determina uma data mágica, mas sim um intervalo de datas com probabilidades geradas a partir do histórico de sucesso de cada desenvolvedor individualmente.

O artigo original mostra várias outras vantagens do método e sugere algumas técnicas gerais para tornar o exercício mais previsível. Vale realmente a pena lê-lo.

Eu estou convencido de que o método tem mérito, mas isso não quer dizer que ele funcione. É óbvio que ele depende fortemente de que os desenvolvedores registrem suas estimativas e suas execuções o mais fielmente possível e também que produzam muitas estimativas pra aumentar a qualidade do histórico. Mas mais que tudo, o método supõe que a capacidade de estimativa dos desenvolvedores tenda a se estabilizar à medida em que eles ganham experiência. Isso parece fazer sentido, mas não conheço estudos empíricos que validem esta suposição.

Outra coisa importante é que não dá pra fazer as simulações na mão. É preciso usar um sistema que automatize o processo. Mas o Joel cuidou disso também. Ele adicionou um módulo de EBS no FogBugz 6.0, a nova versão da sua ferramenta de gestão de projetos.🙂

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: