Rápido e Devagar: Dicas para Estimativas que Quase Dão Certo

O início

---

Estimar em desenvolvimento de software é uma arte cheia de variáveis. "Rápido e Devagar: Dicas para Estimativas que Quase Dão Certo" oferece sugestões práticas para aprimorar suas estimativas, adaptáveis à sua realidade específica.

Mas lembre-se, essas são apenas sugestões e podem precisar de adaptações para se ajustarem à sua realidade.

---

Estimando

---

• Não seja otimista nem conte com a sorte
• A estimativa nunca irá ser precisa
  • Por isso é uma ‘estimativa’
• Analise se você já implementou alguma funcionalidade parecida antes
• Busque saber, se há algo parecido com tal funcionalidade dentro do seu projeto
  • Isso evita a falta de padronização nas soluções
  • Economiza tempo, por não precisar construir nada do zero, apenas adaptar
  • Facilita no entendimento do quê e como precisa ser feito
• Analise os principais pontos de alteração e esforço que envolvem o requisito/atividade
• Realize a gestão de impacto e precedências
  • O requisito atual, depende de funcionalidades existentes?
  • O requisito atual, impacta funcionalidades existentes?
  • Tentar mensurar os impactos em baixo, médio e alto caso existam.
• Caso nunca tenha visto nada parecido, faça uma breve pesquisa, pergunte se alguém do time já resolveu algo parecido para te apoiar
• Leve em consideração o desempenho da sua máquina de trabalho

Pontos para levar em consideração:

• Verificar necessidade de criação de novas entidades e mapeamentos
• Sempre tentar mapear todos os endpoints e comportamentos necessários na tela
• Considerar regras de negócio novas e antigas se souber
• Considerar estrutura do banco de dados, se souber
• Tempo de configuração de ambiente se necessário
  • Banco de dados atualizado
  • Variáveis de ambiente
  • Lentidão da sua máquina de trabalho
• Tempo para abrir o PR
• Tempo para implementação considerando o teste da funcionalidade:
  • Considerar o tamanho do fluxo que será desenvolvido
  • A quantidade de passos que devem ser realizados para criar a massa de dados e validar o fluxo
  • Considere utilizar testes unitários

---

Iniciando uma atividade nova

---

O que fazer, pensar e refletir antes de iniciar a codificação?

• Leitura da documentação, ata ou qualquer artefato que defina o que deve ser feito no requisito
• Analisar e revisar o requisito por completo, antes de dar início a codificação
  • Faça o máximo para não iniciar a codificação sem realmente entender o que precisa ser feito
  • Durante a análise, estabeleça um fluxo lógico de mais alto nível para servir como guia na implementação
  • Isso evita que em um requisito longo, por exemplo, uma regra específica que aparece apenas ao final da especificação, afete todo o código que já foi criado (sem considerar o requisito por completo)
    • Nesse caso, seria necessário uma refatoração do código feito, um retrabalho, que poderia ter sido evitado com uma análise prévia.
• Como essa funcionalidade impacta o cliente (usuário final) ?
• Tem dependência de outras atividades?
  • Analise se a dependência é de regra de negócio, banco de dados, fluxo lógico, documentação, ambiente e etc.
• Tem impacto em outras atividades?
  • Tente mensurar o impacto em baixo, médio ou alto.

• Como isso será implantado?

  • O ambiente possui alguma limitação de recursos?
    • Performance:
      • Entender quando é necessário otimizar:
        • Métricas são obrigatórias para a tomada de decisão de otimizar alguma funcionalidade
        • Sempre comparar o ANTES x DEPOIS
      • Entender o que consome memória/processamento e o motivo disso
  • Afeta a estrutura do banco de dados?
    • Será necessário script para atualização de dados?
    • Será necessário script para migração de dados?

• Como o código irá impactar numa manutenção futura?

  • Sempre escrever o código pensando na manutenção.
  • Sempre pensar na ideia: Irei conseguir ler e entender esse código no futuro?
    • Meu colega de time mais novo, ou mais velho, também irá entender?
  • Alguns pontos que ajudam a escrever um código de fácil manutenção:
    • Legibilidade
      • Utilize nomenclaturas claras
        • Evite abreviações
        • Busque utilizar a mesma ‘linguagem’ que todos usam, cliente e time, para facilitar o entendimento em conversas futuras
    • Coesão
    • Evite o acoplamento
    • Organização lógica do código

---

Iniciando uma correção

---

• Caso a situação relatada no bug não ocorra, certifique-se que está tentando replicar utilizando exatamente o mesmo cenário onde o BUG foi identificado, seja em um ambiente de homologação ou produção.
  • Isso leva em consideração:
    • Os mesmos dados no banco de dados
    • Mesmo usuário e mesmas permissões
    • Mesmo cenário de rede (em casos mais específicos)
• Busque entender se foi feita alguma alteração recente no código, sua ou da equipe, o bug provavelmente virá de lá
• Procure entender e realizar a correção na causa raiz do BUG
  • Busque entender o problema como um todo:
    • De onde veio o dado usado como parâmetro?
    • Qual é o inicio, meio e fim do fluxo?
      • Estabeleça a ordem lógica do fluxo
    • Tenha cuidado ao realizar alterações em arquivos/classes comuns (utilizado em várias partes do projeto)
      • Como classes que são herdadas, arquivos utilitários e etc.
      • Identifique os possíveis impactos em outras funcionalidades na correção, caso seja necessário alterar esse arquivo comum