Rápido e Devagar: Dicas para Estimativas que Quase Dão Certo
Tags: estimativa, estimando, iniciante
Published: 2024-05-09 03:09:04

## 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