O nosso código dorme hoje dentro do Github e nos últimos seis meses passamos a nos organizar em volta dele.
Faz todo sentido para a gente, quanto mais próximo a empresa está do nosso código, mais fácil fica a comunicação, identificação de problemas e oportunidades.
——
Repositório de código
Começamos a usar o Github como todos começam, usando para guardar o nosso código.
Além dele, fizemos fork de algumas gemas que tivemos que fazer alguma modificação para atender nosso interesse.
Essas gemas ficam em repositório aberto, enquanto nosso código permanece fechado.
Issues
Todo atendimento de Dev ocorre por meio de issues, as mesmas são divididas em melhorias, bugs ou no code.
Uma ferramenta que o Github tem, na qual nos mudou de patamar, foi a possibilidade de templates de issues. Com isso, quando qualquer pessoa da empresa quer abrir uma issue, ela já sabe os pontos importantes que precisa preencher.
O legal é que depois de um tempo toda a empresa mudou para issues. E quando alguma pessoa nova entra por exemplo, é criada uma issue de onboard.
Assim todo mundo tem visibilidade do que cada time tem de tarefa, aumentando a viabilidade.
Projects
Abandonamos o Trello e migramos todos os nosso boards para o Projects.
As issues deram visibilidade de quais tarefas existiam para cada time. No projects temos a ideia de qual etapa cada issue está no nosso processo de priorização.
Assim, evitamos a necessidade de reuniões para ficar perguntando onde cada coisa está, e podemos usar as reuniões para focar em como podemos ajudar uns aos outros a mover a issue para frente.
Actions
Também movemos todo nosso pipe de CI para dentro do Github.
Assim, o mesmo ficou integrado dentro do nosso processo, sendo executado tanto quando adicionamos uma label específica, quanto por commits.
E também, geramos os nossos relatórios de releases semanais para informar a empresa tudo que entrou no produto na semana.
Qualquer pessoa do time tem acesso, por exemplo, a deploys que funcionaram ou quebraram, testes que não passaram, etc…
Pull Request
O coração aonde o Dev faz suas tarefas. Todo pull request tem que estar vinculado a uma ou mais issues ao qual vai fechar/avançar.
Ao ser marcado como pronto para revisão, o próprio Github atribui ele para algum outro Dev revisar, não necessariamente da mesma squad.
Assim, além de melhorar a qualidade do que está sendo entregue, pois a modificação tem que ser simples para qualquer um entender, garantimos que todo o time tenha algum conhecimento de todas as partes do nosso produto.
Muitas vezes as melhores decisões de código vêm de pessoas que estão mais afastadas do problema, pois essas tendem a questionar mais as decisões tomadas.
Github CLI
Infelizmente o insight do Github é bem ruim. Mas resolvemos isso adicionando labels necessárias nas issues e um pouco de código para pegar essas informações pela api do Github.
Dessa maneira, conseguimos tirar métricas de velocidade do time, quantidade de bugs, etc.
E assim, podemos saber se as mudanças organizacionais que tomamos estão tendo efeitos positivos ou negativos.
Discussion
Essa ferramenta acabou de deixar fase beta do Github.
Ela é um fórum interno do mesmo, e usamos para registrar todas as discussões que temos internamente.
Quando algo começa a se prolongar no Discord, migramos para lá.
Até para ser fácil pessoas novas entenderem o contexto do porquê as coisas hoje são como são.
Também registramos resumo de livros que gostamos, e como resolvemos algum problema mais sério dos nossos clientes.
Wiki
Aqui mora toda a nossa documentação, desde documentação de como usar o produto, responder a certos questionamentos do cliente, até nossa boas práticas de programação.
Também usamos nossa wiki para o nosso processo de onboard. Temos documentado nela (e gosto de acreditar que cada pessoa que entra melhora esse processo) o que se espera que a pessoa saiba a cada semana até conseguir chegar em um ponto que consegue realizar as primeiras atividades sozinha.
Futuro
Quem sabe não adotamos no futuro o editor de código que o Github acabou de lançar?
O que eu posso falar é, cada dia que passa sinto menos necessidade de ter outras ferramentas de gestão de time, produto e código, além do próprio Github.
Top comments (3)
A V360 está com vagas abertas em estágio e júnior na área de Pessoa Desenvolvedora Full-Stack. Acesse em: somosv360.gupy.io/
Excelente artigo! Essa mentalidade de sempre tentar centralizar os processos num lugar só é excelente. Realmente, o insight do Github não atende legal. Aqui utilizamos o Shortcut visando exatamente isso. De resto, o Github é excelente para tudo que foi mencionado.
Não conhecia o Shortcut, vou dar uma olhada.