Tags:

Estimar ou não estimar, eis a questão!

Sempre que estamos envolvidos com o planejamento de algo, independente de ser um projeto de software, podemos estimar nossas atividades para alcançar o objetivo desejado.

Por exemplo: Aquela viagem tão esperada nas próximas férias, estamos planejando levar X horas da origem para destino, mais Y horas em determinado passeio, Z dias em uma cidade N em outra, assim sucessivamente.

Por meio desse exemplo já podemos perceber que a todo tempo estamos estimando sem perceber, quase um ato involuntário.

Mas será que damos a devida importância para estimativa de horas? Ou ainda, será que sabemos como estimar de forma que o planejado seja mais próximo do realizado? Como estamos estimando? Já parou para pensar nessa questão dentro dos projetos que tem integrado?

Em projetos ágeis como Scrum é sempre polêmico a questão das horas “Estimadas x Realizadas”, principalmente se estamos falando de uma Sprint que falhou.

Outros pontos delicados dessas estimativas em projetos seriam a relação com custo do software e prazo de entrega para o cliente. Alguns dizem que estimativas podem surtir 2 efeitos: como pressão, para conseguir a “qualquer custo” cumprir a hora estimada ou como “folga” por cumprir com atividade antes do prazo mas dar aquela enrolada por saber que está dentro do tempo ainda. Balela!

Mas vamos por partes, pode parecer lógico, mas esclareceremos sua definição:

Estimativa “Cálculo aproximado, avaliação; conjectura” [1]

Veja que o nome já diz, é um cálculo aproximado, é óbvio que o valor nunca será exato, é extremamente difícil estimar que gastará 10 horas em uma atividade e as horas realizadas para ela será exatamente isso. É compreensível que haja uma variação no valor, tanto para mais quanto para menos, o que ainda é gerenciável. Mas não podemos entender como normal sempre que estimarmos as horas usarmos muitas horas a mais do que estimamos. É necessário entender onde está o gargalo para que possamos nos aproximar mais das horas estimadas e assim sermos mais assertivos em nossos projetos, nossas Sprints. Geralmente o entendimento desse gargalo, a análise dos pontos que foram responsáveis pelo estouro são levantados em uma retrospectiva.

Levantei algumas questões acima que geralmente nos perguntamos quando esse assunto é pauta, vamos debater cada um desses pontos e vamos trazer dicas para estimarmos melhor. Vamos lá!

A estimativa das horas em um projeto é muito importante, através dela é que fazemos todo o planejamento de cada atividade e teremos a visão se o que foi previsto para uma Sprint caberá nela ou será necessário haver mais quebras de atividades ou até mesmo mais recursos para que o desejado seja alcançado. Pode acontecer de itens serem retirados do backlog também.

Tempo não passa, tempo voa [5]
Às vezes temos a impressão que o tempo não passa, o tempo voa [5]

Mas nem sempre damos a devida importância para estimativa, principalmente quando estimamos e mesmo assim “fazemos caber” a atividade de uma forma ou de outra.
O que seria isso? Levantar N cenários de teste e priorizar alguns, testes cruzados (executados por desenvolvedores), levantar N validações necessárias e nem todas serem priorizadas, já ouviu aquela história de que aquele cenário é praticamente impossível de acontecer (Esse ai provavelmente não conhece Murphy [4]), entre outros.

Diante disso levo a todos refletirem se esses recursos valem a pena. Não estou dizendo para sermos inflexíveis, é praticamente impossível ser assim nessa realidade dinâmica que vivemos. Porém, é necessário presar pela qualidade sempre. Pode não parecer mais muitas vezes estimativas erradas para serem enquadradas em novos cenários podem comprometer a qualidade do software.

“Estimativas não são um problema de desenvolvimento de software, mas uma ferramenta que a sociedade usa para tomada de decisão, o erro está em acreditar que estimativa é preciso, se fosse preciso não era estimativa, era certeza.”[2]

Gostei bastante da frase acima, realmente estimativa é uma ferramenta para tomada de decisão. E quem disse que estimar é fácil? Não é, é uma tarefa bem difícil, mesmo porque na maioria das vezes estamos lidando com atividades não realizadas antes, uma dica é trabalhar baseado em históricos de funcionalidades já desenvolvidas com grau de dificuldade semelhante. Existe no mercado métricas e técnicas para se fazer isso também, como ponto de função, por exemplo.

Mas e os testes? Como estimá-los?

Por favor, não me venha com aquela história que a estimativa do teste é 30% do desenvolvimento. Não da para acreditar que ainda tem gente que estima assim.

Como comentei acima, estimar não é uma tarefa simples, são vários os fatores que influenciam e pela experiência que pude perceber é que quanto mais trabalhamos e conhecemos do software e temos um histórico com ele que nossa estimativa vai melhorando a cada Sprint.

Algumas dicas para fazer uma boa estimativa são:

  1. Ter compreendido o escopo, tudo que deverá ser desenvolvido e validado.
  2. Tirar todas as dúvidas sobre o escopo antes de fechar a estimativa, pode ser que um detalhe que parece pequeno, uma “bobeirinha”, seja uma validação considerável que pode afetar sua estimativa.
  3. Dividir tudo que deverá ser validado em tópicos, aqui não precisa ter o detalhamento ainda, pode ser alto nível para ter uma visão melhor de tudo que deverá validar\desenvolver.
  4. Verificar possíveis integrações com outros sistemas (que geralmente são potenciais “enroscos” dentro do projeto.
  5. Considerar complexidade da funcionalidade.
  6. Considerar histórico de testes\desenvolvimento da mesma funcionalidade (caso de customização) ou de funcionalidade similar. Nesse caso, é interessante você verificar quanto estimou e quanto gastou e se houveram problemas, quais foram, para pesar nessa nova estimativa.
  7. Verificar se já possui ambiente de teste para essas validações, o que será necessário configurar para adequá-lo para os testes.
  8. Verificar necessidade de massa de dados para o teste.
  9. Para facilitar você pode quebrar a estimativa em escrita de caso de teste \ execução \ retestes (tópico voltado mais para testes mas que pode ser adaptado para desenvolvimento também):
    9.1. Escrita do caso de teste: Lembre-se de considerar conhecimento em tal funcionalidade, se já existe algum template de teste que poderia ser reaproveitado, necessidade de simulação de alguma funcionalidade que tem relação com o teste, tudo deverá ser antecipado nessa etapa para não correr o risco de encontrar surpresas no meio do percurso da Sprint com o que não foi considerado inicialmente.
    9.2. Execução: Considere tudo que precisará validar, os cenários que levantou de acordo com leitura do escopo, explicação na planning, massa de dados para realizar as validações.
    9.3 Reteste: Pode parecer estranho esse item aqui, mas quem testa sabe que sempre haverá algum reteste, quem desenvolve também sabe que sempre é necessário corrigir algo no código. Acharia estranho testar alguma funcionalidade e não econtrar nenhum erro, pois essa é a finalidade dos testes, certo? O momento de encontrar todos os problemas é durante o desenvolvimento. Essa mediação é realizada geralmente de acordo com experiências anteriores, você vai criando um feeling para a coisa. De acordo com o que levantou de tudo que precisa testar faça uma “previsão” de quanto tempo para reteste precisará validar. Pode parecer um pouco abstrato, mas verá que quando aplicado na realidade fará sentido.

Nem sempre medimos isso, mas gastamos muitas, mas muitas horas mesmo em reteste. Dependendo do erro lançado quando retesta aquele defeito pode ser que a correção afete outra ponta que já funcionava, e como você garantirá isso? É meu caro, retestando o erro e a outra ponta afetada. Não estou dizendo que temos que sempre testar tudo de novo a cada defeito que lançamos. Calma, não sejamos 8 nem 80, mas é preciso estar alinhado com quem fez a correção para que os pontos que podem afetar sejam passados para validarmos no reteste.

Essas dicas listadas são voltadas para um cenário em que utilizamos metodologia ágil Scrum.

Examine com calma e veja o que poderá ser absorvido para sua realidade.

E o que me conta sobre suas experiências com estimativas dentro de projetos?
Compartilhe suas dicas com a gente também.

Referências

[1] http://www.dicionarioinformal.com.br/estimativa/

[2] http://sidneylimafilho.com.br/post/estimativas-de-software-quando-fazer-e-quando-nao-fazer/

[3] http://www.bfpug.com.br/Artigos/APF%20-%20Qualitativo%20x%20Quantitativo.pdf

[4] http://www.brasilescola.com/curiosidades/lei-murphy.htm

[5] http://gerenciandoriscosemprojetos.com/os-riscos-das-estimativas-de-cronogramas/

Links

[1] http://www.matera.com/br/2014/11/27/as-outras-fases-do-scrum/

[2] http://www.matera.com/br/2013/03/11/metodologia-agil-framework-scrum-2/

Por ARIANE FERREIRA IZAC

Analista apaixonada por testes, dançarina, corredora e colecionadora de viagens! Filha de peixe (jornalista) peixinho (blogueira) é. Meu grupo no LinkedIn só poderia ser "Diário de uma paixão: Teste de Software"

Postado em: 29 de maio de 2015

Confira outros artigos do nosso blog

REST não é JSON

21 de agosto de 2017

Bruno Sofiato

[Webinar] Profile de aplicações Java com Oracle Mission Control e Flight Recorder

24 de julho de 2017

Danival Calegari

Criando Mocks de serviços REST com SoapUI

27 de junho de 2017

Monise Costa

JavaScript 6: diferença entre var, let e const

09 de maio de 2017

Otávio Felipe do Prado

Deixe seu comentário