Como é o dia a dia de um dev?
Tags: beginners
Published: 2020-02-19 19:13:12

Você quer se tornar um programador e tem curiosidade de como é nossa rotina? Então esse post é para você! 😉

Nesta postagem eu irei contar com detalhes o meu dia a dia como desenvolvedora frontend numa equipe ágil.

## Afinal, o que é uma equipe ágil?

Uma equipe ágil é uma equipe que segue uma **metodologia ágil**, como o [Scrum](https://www.desenvolvimentoagil.com.br/scrum/). Dentro do Scrum, nós temos um ciclo de tempo chamado **Sprint**.

Se você não conhece nada disso, não tem problema. Basta entender que tudo gira em torno dessa Sprint. No projeto que participo, uma Sprint dura 2 semanas, mas isso pode variar de acordo com o projeto. 

Ao longo de uma Sprint, acontecem reuniões que chamamos de **cerimônias**. Vou explicar um pouquinho de cada cerimônia que eu participo.

### Início da Sprint

➡️ **Planning**: nessa cerimônia, lemos todas as tarefas que vamos desenvolver durante a Sprint. Chamamos as tarefas de **histórias**. Depois de ler as histórias, criamos as **subtarefas** para cada história. Ao criar as subtarefas, podemos dividir a história em pequenos pedaços, para que a estimativa seja mais fácil.  

➡️ **Estimativas**: como o próprio nome diz, nós iremos estimar as subtarefas que criamos na Planning. Existem várias maneiras de estimar essas subtarefas, mas aqui onde trabalho estimamos em horas.

*Por exemplo*: na subtarefa 1 eu irei levar 4h e na subtarefa 2 eu irei levar 8h. No total, essa história foi estimada em 12h para ficar pronta. Viu porque é importante dividir as histórias em pequenos pedaços? Fica bem mais fácil estimar. 🙂

🕒 A duração das duas (no caso do meu projeto) é de 1 dia inteiro.

### Durante a Sprint

➡️ **Daily**: é uma cerimônia que acontece diaramente para saber o que fizemos ontem, o que vamos fazer hoje e se estamos com algum impedimento. 

🕒 Dura em média 15 minutos.

### Fim da Sprint

➡️ **Demonstração**: na demo, nós apresentamos para o cliente as histórias que desenvolvemos durante o projeto. Aqui no projeto, quem apresenta são os desenvolvedores.

➡️ **Retrospectiva**: na retro, escrevemos num post-it anônimo pontos negativos e positivos da Sprint. Depois, lemos um por um e discutimos o que pode ser feito para melhorar os pontos negativos.

🕒 A duração das duas (no caso do meu projeto) é de 1 dia inteiro.

## Com quem o dev convive?

Acho importante também falar um pouco das pessoas que trabalhamos no nosso dia. Cada um tem um papel importante na equipe ágil; nós trabalhamos em conjunto para chegar ao produto ideal. 

👤 **Cliente**: geralmente nós devs não convivemos com o cliente todos os dias, mas através do nosso PO e do nosso Gerente de Produto recebemos a ideia do que eles precisam no produto final.

👤 **Product Owner (PO)**: está muito ligado e alinhado as necessidades do cliente, é ele que traduz tudo que o cliente precisa no projeto. Ele sabe quais tarefas devem ser priorizadas de acordo com a necessidade.

👤 **Gerente de Produto**: é quem tem o papel de liderar a equipe do produto e ao mesmo tempo manter a cabeça na área de negócios. Ele analisa os dados para acompanhar o desempenho do produto.

👤 **QAs**: o pessoal de qualidade testam as telas, integrações e fluxos antes do usuário. Eles ficam responsáveis por abrir bugs (erros que precisam ser arrumados) e alguns também fazem [testes automatizados](https://blog.geekhunter.com.br/as-maiores-vantagens-de-testes-automatizados/).

👤 **Designers**: o pessoal de UX/UI vai desenhar e pensar na melhor forma de experiência para o usuário nas telas que o frontend vai programar. Eles precisam entender bem os usuários do sistema e seus objetivos.

👤 **Devs**: no seu projeto podem ter diversos tipos de devs, como frontend, backend, mobile, analista de banco de dados, etc. Estamos sempre conversando via chat e se ajudando.

## E quando eu começo a programar?

Depois de **MUITA** conversa, leitura das histórias, divisão das tarefas e planejamento, iniciamos o desenvolvimento das tarefas.

Quando inicio uma nova tarefa, eu recebo o protótipo do designer e entro em contato com o backend para pegar o *contrato*. Como sou frontend, eu preciso consumir a API que o backend vai criar, por isso ambos precisamos de um contrato para que nossos códigos conversem entre si.

O pessoal do banco de dados também tem uma comunicação parecida com o backend: eles fazem a modelagem do banco e precisam passar para o backend desenvolver suas tarefas.

Entendeu que temos muita comunicação entre si, né? 😂 E agora, já podemos sair desenvolvendo nosso código por aí? Eu diria que mais ou menos. Primeiro, precisamos pensar na **lógica** que iremos utilizar na tarefa. Iniciar a programar sem ter noção disso é um caminho perigoso e você pode dar muitas voltas sem necessidade.

Depois de tudo que foi discutido acima, já podemos botar a mão no código. O fluxo é o seguinte:
* Escrevo o código;
* Testo tudo que fiz (tem projetos que [testam antes de escrever o código](https://becode.com.br/tdd-para-newbies-o-que-e-e-como-aproveitar-a-tecnica/));
* Abro um pull request (PR), que é uma solicitação para que as pessoas possam **avaliar** e **aprovar** todo código que fiz;
* Depois que o código é aprovado por pelo menos 2 pessoas, o próximo passo é o QA analisar a história;
* Se o QA analisar e abrir um bug, preciso realizar todo processo acima para ajustar o erro e enviar para o QA reavaliar a história.

## Quais são as dificuldades no dia de um dev?

Como sabemos, todas as áreas tem suas dificuldades. Na área de programação não seria diferente. Abaixo, alguns dos problemas que eu enfrentava bastante no começo da carreira:

🔻 **Vergonha de perguntar**: quando você começa, perguntar muitas coisas é normal. Todos na equipe sabem que você começou agora e precisa de ajuda. É melhor perguntar e fazer certo, do que não perguntar e perder tempo fazendo errado.

🔻 **Ficar muito tempo preso num erro**: as vezes nós ficarmos muito tempo presos num problema, então, para evitar isso tenho uma técnica. Se eu ficar presa mais de 30 minutos no mesmo erro, peço ajuda para um colega meu. Tenham em mente que esse obstáculo não é só seu, mas sim da equipe inteira.

🔻 **Não parar para descansar**: é bem comum isso acontecer porque nosso trabalho exige muita concentração, mas ficar muitos dias fazendo hora extra vai acabar com sua qualidade de vida. Você trabalha para viver melhor e não vive para trabalhar, certo?

---

E esse é meu dia a dia. 🙂 Costumo dizer que minha profissão é de altos e baixos, mas no final do dia é isso que amo fazer. 

Desejo bons estudos a todos que querem ser programadores e agradeço por lerem até aqui. ❤️ Deixem um comentário para falar se gostaram da rotina e também deixar sugestões se quiserem!

> Agradeço a ajuda especial da Joana ([@jojofrancener](https://twitter.com/jojofrancener)) e da Bruna ([@bruveloper](https://twitter.com/bruveloper)).