Fazendo estimativas precisas de projetos de software

estimativa de projeto de software

Pixabay

Introdução

Estimar é difícil. Infelizmente, também é muito necessário. As empresas usam estimativas para projetar cronogramas de lançamento, fazer compromissos com seus clientes, decidir se vale a pena implementar um recurso proposto, rastrear a velocidade das equipes e priorizar o trabalho com eficácia. Os executivos geralmente desejam saber quando um recurso ou entrega estará pronto para produção. Afinal, o desenvolvimento de software não é um investimento trivial. Sem estimativas, como o gerente de projeto faria uma avaliação? Se os humanos pudessem prever o futuro com precisão, as pessoas não ganhariam nas corridas de cavalos 2% das vezes. A estimativa é o grande enigma. É essencial e necessário que as empresas peçam a seu pessoal o impossível: prever o futuro.

Primeiro, vamos revisar alguns métodos de estimativa populares (caso você tenha perdido parte da empolgação). Então, podemos ver o que isso significa para nós e nossos projetos.

O modelo do Fortune Teller

Este modelo quase não requer esforço para produzir uma estimativa. Os estimadores pensam um pouco sobre o que precisa ser feito para implementar e testar um recurso, depois descartam um número. Parece muito com “… (longa pausa)… Ummmmm… 6 semanas.” Então todos acenam com a cabeça e seguimos em frente. Eles poderiam passar um bom tempo falando sobre o que sabem sobre os requisitos (o que provavelmente não é o quadro completo). Essa análise cuidadosa torna sua estimativa mais confiável. No final do projeto, sempre há uma justificativa aceita para explicar por que a estimativa estava tão distante da realidade. Sempre há circunstâncias imprevistas que podem servir de bode expiatório. Freqüentemente, não ocorre a ninguém que o modelo tem graves falhas.

Então, como podemos tornar esse processo melhor? Eu sei! Podemos usar a técnica de decomposição (ou seja, dividir e conquistar). Essa abordagem pressupõe que você conhece o escopo completo do recurso ou projeto no front end. Cada recurso é dividido em pedaços pequenos. Cada pedaço é estimado (estilo cartomante), então nós os somamos para obter uma estimativa geral do recurso / projeto. Esta é certamente uma abordagem mais complicada, mas parece melhor por dois motivos:

• Pedaços de trabalho menores tendem a ser mais fáceis de estimar com segurança.
• Embora ainda haja a oportunidade de erro (+/- algum valor), há uma suposição de que os erros se cancelarão quando você adicionar tudo e obter uma estimativa geral mais confiável.

A falha fundamental dessa abordagem é que os colaboradores individuais (as pessoas que realmente fazem o trabalho) universalmente subestimam. Eles ainda são significativamente melhores do que aqueles acima e ao redor deles, mas isso não é uma barreira alta. Isso não parece ser o caso, porque todos nós vimos casos em que os desenvolvedores se surpreenderam ao realizar algo antes do planejado. Mas este é um único ponto de dados, não uma tendência. As pessoas realmente ganham ocasionalmente no cassino; gaste dinheiro em um cassino todos os dias durante um ano e você terá menos dinheiro do que você começou. Se você acompanhar as estimativas e os reais por um ou dois anos, descobrirá que as estimativas estão aquém da realidade. Enquanto muitos empresários estão absolutamente certos de que os desenvolvedores estão preguiçosamente preenchendo suas estimativas e usando o tempo extra para "garimpar" ou verificar seus estoquesos dados mostram o contrário. A estratégia de “cancelamento” não funciona.

Então, e agora? Vamos abandonar o modelo do cartomante e mudar para uma abordagem baseada no tamanho. Acontece que, embora os humanos sejam péssimos em estimar o tempo de conclusão, somos muito bons em dizer o quão grande algo é. Somos especialmente bons em dimensionamento comparativo (“é maior do que isso, mas menor do que ali”). Se pensarmos em termos de tamanho ou complexidade, em vez de tempo, nosso cérebro o processa de maneira mais confiável. Então podemos pegar os valores do tamanho e calcular o número real de horas do projeto com base em uma fórmula mágica bacana! E é aí que o popular modelo de pontos de função entra em cena (palco à esquerda).

Análise de Pontos de Função (FPA)

Para análise de ponto de função, precisamos identificar cinco tipos de coisas em nosso aplicativo: entradas externas, saídas externas, consultas externas, arquivos de interface externa e arquivos lógicos internos (não se preocupe muito com as definições; você pode pesquisá-los mais tarde). Cada exemplo dessas (uma função) tem uma complexidade associada a ela (baixa, média ou alta). Usamos a tabela abaixo para descobrir quantos pontos cada função recebe.

Agora, se somarmos os pontos de todas as nossas funções, podemos obter um número como 457 pontos de função para o nosso projeto. Então, precisamos apenas de uma fórmula para calcular o número de horas… Com base em nosso último projeto, nossa “taxa de entrega” foi de 15 pontos de função por pessoa por mês. São cerca de 30 pessoas / mês de trabalho, o que deve levar um pouco mais de dois meses e meio para minha equipe de 12 pessoas.

Isso certamente é mais complexo do que nosso modelo anterior. Na verdade, existem quatro áreas principais de complexidade a serem reconhecidas.

1. Os cinco tipos de componentes não são necessariamente intuitivos e é fácil esquecer de colocar algo na lista ou atribuí-lo ao bloco errado.
2. A tabela usada para realmente gerar os pontos de função contém números mágicos que exigiriam muito esforço para validar. Esses números estão calibrados corretamente para gerar estimativas confiáveis ​​para minhas equipes?
3. A taxa de entrega (uma peça crítica do quebra-cabeça) é calculada com base na produtividade de sua equipe. Com que frequência precisamos calcular um novo número? Na verdade, há muito pouca orientação sobre isso.
4. O que constitui baixa, média ou alta complexidade? Como definimos isso para que todos entendam? Não é fundamental para a precisão de nossos cálculos acertar?

Existem várias partes móveis neste exemplo muito simples, e ainda não discutimos modelos de complexidade mais complicados e os outros dados que podem entrar em jogo (taxa de custo ex, taxa de suporte, densidade de defeito, etc.). Mais peças móveis significam mais oportunidades para a ocorrência de erros. Estamos tornando as estimativas muito complicadas agora? Não estamos pagando aos desenvolvedores para dedicar muito tempo à estimativa. Não posso vender um orçamento para meus clientes. Eu preciso de um software funcionando. Existe mais alguma coisa lá fora?

Agilidade

Agora, vamos dar uma olhada rápida no ágil scrum (apenas o suficiente para fazer uma comparação). Como afirmado anteriormente, os humanos são terríveis em estimar o tempo e são muito bons em tamanhos comparativos. Aqui estão alguns termos para entender:

• Um sprint - um período de tempo definido (geralmente duas semanas).

• História do usuário - um trabalho discreto, de preferência pequeno o suficiente para ser executado por uma pessoa em um sprint. Isso é o que estamos estimando.

A estratégia mais popular é usar uma sequência de fibonacci (0, 1, 2, 3, 5, 8, 13) para estimativas. Não é linear - conforme você sobe na escala, o tamanho das lacunas aumenta. A chave é que as lacunas devem ser grandes o suficiente para que não haja razão para discutir diferenças insignificantes. Depois de passar de 3, a diferença entre 4 e 5 ou 7 e 8 é tão insignificante que não faz sentido perder tempo descobrindo qual é. Uma sequência de base 2 também funcionaria (0, 1, 2, 4, 8, 16, etc.).

“Mas espere, este é apenas um número. O que isto significa? Quantas horas é um ponto? ” Os pontos não devem se correlacionar diretamente com as horas, porque, se o fizessem, as equipes ficariam tentadas a voltar a estimar em horas e, em seguida, converter isso em pontos de alguma forma. Conforme discutido anteriormente, a precisão de nossas estimativas vem do tamanho comparativo e não da estimativa do número de horas que algo levará. Se você der à equipe a capacidade de pensar em termos de horas, estará comprometendo sua capacidade de estimar com precisão.

Digamos que você começou com um exercício de calibração. Puxe sua equipe para uma sala e mostre uma lista de 10 a 12 histórias de usuários. Escolha um que seja pequeno, mas não o menor, e faça aquele primeiro. Reveja e anuncie que esta história é um “3”. Você não está perguntando. Você está contando. Em seguida, passe para a próxima história. “Se fosse um 3, qual é este?” Agora a equipe está avaliando as histórias em relação a outras histórias. Eventualmente, eles terão uma boa ideia do que constitui um “1”, um “2”, etc. Eles não estão estimando. O tempo não importa. Eles estão dimensionando histórias em relação a outras histórias que já têm um número. Você pode então colocar histórias de exemplo para cada número na sequência em um documento denominado régua. Eles podem usar isso como referência se não tiverem certeza do que é um “5”.

Agora, aqui está a chave. O molho mágico que faz esse trabalho funcionar é a “velocidade” (o número de pontos que uma equipe pode completar em uma corrida em média 3-4 sprints). Digamos que seu sprint seja de duas semanas e sua equipe de 8 pessoas tenha uma velocidade média de 35 pontos. Você está obtendo 35 pontos em 640 horas de trabalho (8 x 80 horas). Se descobrirmos que um recurso vai levar cerca de 100 pontos de trabalho do início ao fim, então sei que são cerca de 6 semanas de trabalho e ~ 1900 horas. A equipe se torna muito boa em dimensionar histórias de maneira consistente, e você aproveita isso para fazer o planejamento do projeto. Este cálculo funciona porque a duração é consistente de sprint a sprint.

Para fazer um planejamento de alto nível de longo prazo, você pode pedir a seus leads para dividir os recursos de alto nível em histórias de uma linha provisória e colocar valores pontuais nelas. Haverá um certo grau de perda de precisão, mas você está aproveitando o modelo que eles já entendem. Um caminho mais preciso seria o dimensionamento relativo no nível do recurso. “Este recurso é maior do que aquele de 40 pontos, menor do que aquele de 120 pontos ali e um pouco maior do que o recurso de 65 pontos que acabamos de fazer”. As histórias são agrupadas em “épicos”. Se cada recurso for um épico, no final você saberá quantos pontos foram necessários para concluir esse recurso. Mantenha um histórico disso e você pode usá-lo para seu planejamento de lançamento.

Conclusão

Existem muitas metodologias em uso hoje. Cada um tem prós e contras. De alguma forma, precisamos descobrir como maximizar a precisão de nossas estimativas para que possamos tomar boas decisões. Isso não significa que nossas estimativas devem ser precisas. Eles só precisam ser precisos o suficiente para serem úteis. Se você não entende as estimativas, pode supor que as estimativas não eram precisas porque a equipe não fez um bom trabalho. Eles não estimaram corretamente ou não executaram o projeto corretamente. Os espancamentos continuarão até que as estimativas melhorem. Mas as estimativas nunca devem ser usadas como um compromisso. É a melhor estimativa com base nas informações limitadas que temos hoje. Quando novas informações aparecem, temos que permitir que as estimativas sejam revisadas. Qualquer outra coisa é esperar o impossível, o que é um problema de liderança (não de equipe).

A abordagem do Scrum é muito mais simples do que vemos na análise de pontos de função. E eu diria que é muito mais confiável do que tabelas mágicas com números mágicos. Ele obtém o melhor retorno para o investimento (esforço mínimo com um grau razoavelmente alto de precisão). De uma perspectiva de esforço, não cria um processo pesado para as equipes entenderem e usarem. A parte de estimativa do ágil pode realmente acontecer muito rapidamente, uma vez que todos entendam os detalhes do trabalho que está sendo estimado. Certamente é melhor do que extrair números do nada. Alavancar a velocidade faz algo muito importante: traz dados históricos para o cálculo. A cada sprint, você recalcula sua velocidade. Isso é crítico, porque ao longo do tempo o rendimento muda. As equipes que usam FPA podem derivar sua taxa de entrega de seu projeto anterior,que em alguns casos foi há vários meses. Muito provavelmente mudou desde então. Minha sugestão é que você explore o Agile e realmente se esforce para entender os pontos da história e a velocidade. Não recue na estimativa de horas só porque é isso que você entende. Eu acredito que você vai se agradecer mais tarde.

Enquete Rápida