Clavius Tales

Advertência: prefiro trabalhar com horas, turnos ou dias ideais (daqui pra frente, só chamarei de “dias-ideais”). Muitas pessoas se referem a dias-ideais como pontos. De fato, até aqui na Fortes chamamos os dias-ideais de pontos. Mas os pontos a que me refiro no título do post se referem àqueles em que as equipes atribuem um ponto para a história mais simples e estimam as demais histórias em relação a essa mais simples. É dessa abordagem que não gosto. Daqui pra frente neste post, quando falar em pontos, é dessa abordagem que estou falando, e não da de dias-ideais.

Não acho nada natural estimar uma história em relação a outra. Imaginemos que num sistema de controle de issues a história mais simples seja “registrar issue”. Imaginemos ainda que haja a história “tela de acompanhamento de issues”. Simplesmente não consigo – pode ser uma limitação minha – fazer qualquer relação direta de tamanho entre essas duas histórias. A única forma que conseguiria de fazer essa relação seria estimar ambas em dias-ideais e ver quantas vezes uma é maior que a outra.

Quando o Alexandre Magno esteve aqui na Fortes ministrando um treinamento, ele fez uma dinâmica para tentar explicar por que seria interessante trabalhar com pontos. Ele nos trouxe uma série de “livros”, de bem simples como um de histórias em quadrinhos, a bem complexos como um do Dostoiévski. Pediu para escolhermos o mais simples e para estimarmos a complexidade dos demais em relação a ele. Adivinha o que aconteceu na minha cabecinha? Para cada livro estimei quanto tempo levaria para lê-lo e fiz a relação entre eles a partir dessa estimativa. Foi a forma mais simples e natural que achei de fazer o que havia sido pedido.

Desde que o mundo é mundo, estimar atividades em tempo é a regra, é a forma mais natural.

Uma crítica comum que se faz ao modelo de dias-ideais é a seguinte: “Esforço não é mesma coisa que tamanho. Dias-ideais se referem a esforço, mas o que queremos saber é qual o tamanho das histórias.” Concordo que esforço não é igual a tamanho. Mas discordo quando dizem que dias-ideais se referem diretamente a esforço. Se eu estimar uma história em cinco dias-ideais, pode ser que a faça em dez. Quede a relação entre dias-ideais e esforço? Perguntariam: como faço então para resolver esse problema de erro de estimativa? Resposta: além do próprio aprendizado empírico, aplicando o conceito de “velocidade”.

Dias-ideais também não se referem diretamente a tamanho, pelo menos não em seu conceito canônico. Em tese, o tamanho deve ser o mesmo para o mesmo projeto independente da equipe que o meça. E isso realmente não dá para conseguir com dias-ideais. Duas equipes podem chegar – e normalmente chegam – a tamanhos diferentes quando medem um mesmo projeto em dias-ideais. Esse problema é em tese resolvido com o modelo de pontos. Mas ainda assim esse modelo não consegue resolver outro conceito – o mais importante – por trás do tamanho: a existência de uma unidade de medida universal para tamanho de projetos.

Iniciando um aparte.

Atualmente considero a técnica de Pontos-de-Função (PFs) o melhor – de fato, menos pior – modelo de tamanho, a melhor unidade de medida universal. Como disse, é o menos pior. A técnica de PFs apresenta ainda uma série de problemas: há alguma subjetividade, a faixa de tamanhos das funções em P, M e G é muito simplista, não pode ser aplicado a todo tipo de projeto de software e alguns dos fatores de ajuste deveriam ser aplicados por função. Ou seja, ainda estamos longe de conseguir uma boa unidade de medida universal para projetos de software (de fato, acho que nunca vamos conseguir; se até hoje nenhuma das chamadas indústrias criativas conseguiu isso, não vai ser a de software que vai conseguir). A questão é: que vantagem teríamos se houvesse essa unidade de medida universal? Várias: poderíamos por exemplo saber se uma equipe está ficando mais produtiva ao longo do tempo; poderíamos também saber se uma equipe é mais produtiva que outra. Essa última vantagem seria especialmente interessante para a contratação de projetos de software por órgão públicos, mas isso é assunto para outro post.

Voltando do aparte.

Um outro problema do modelo de pontos que vejo é o seguinte: não dá para aproveitar a velocidade obtida num projeto para estimar o tempo de desenvolvimento de outro projeto. A história mais simples de um projeto pode não ser do mesmo tamanho que a história mais simples de outro projeto. Responderiam: é só fazer a relação entre as histórias mais simples dos dois projetos, quantas vezes uma é maior que a outra. Tostines: se já acho difícil fazer a relação entre histórias do mesmo projeto, avalie entre histórias de projetos diferentes. Voltamos ao ponto inicial.

Atualização
O tema foi bastante aprofundado e estendido nos comentários.

Venho há um bom tempo pensando em criar um blogue para divulgar meus pensamentos a respeito de desenvolvimento de software, metodologias ágeis e XP. Nunca tive coragem de começar por achar que iria acabar não tendo tempo de dar continuidade. Refletindo melhor, vi que se  isso acontecer, de não dar continuidade, não causaria problema a ninguém. Resolvi então começar.

Queria antes agradecer ao meu amigo e guru Vinícius Teles, que foi quem me iniciou de forma efetiva nesse mundo do desenvolvimento ágil de software e é para mim a mente mais brilhante no assunto no Brasil. Queria também agradecer aos meus colegas de trabalho, que, a despeito de todos os erros que cometi nessa jornada, abraçaram minha ideia de implantar XP aqui na Fortes. Queria agradecer ainda a todos aqueles que de alguma forma me ajudaram nesse trabalho, seja publicando conteúdo valioso na internet, participando de listas de discussão ou ministrando treinamentos aqui na Fortes.