Tomando decisões técnicas usando RFCs
No processo de desenvolvimento de software as equipes precisam tomar várias decisões importantes, desde linguagens de programação, arquiteturas, processos, ferramentas, etc. Conforme o projeto vai tornando-se maior, com o crescimento da equipe a tomada destas decisões começa a ficar cada vez mais complexa e importante. Além disso, como garantir que as decisões tomadas no começo do projeto fiquem documentadas para que as novas pessoas na equipe entendam os motivos e contextos que levaram o time a determinada conclusão?
Existem diferentes formas de se fazer esse processo de tomada e documentação de decisões em equipes, e neste post vou falar sobre uma delas: as RFCs (Request for Comments).
O que é um RFC?
[…] são documentos relativamente informais que a autora ou autor principais de um sistema de software ou aplicativo criam antes de embarcar no projeto de codificação. […] documenta a estratégia de implementação de alto nível e as principais decisões de design com ênfase nos trade-offs que foram consideradas durante essas decisões.
Por que usar?
- permitem que contribuidores individuais participem das decisões para sistemas pelos quais são responsáveis
- permitem que especialistas do domínio contribuam com as decisões mesmo quando não estão diretamente envolvidos na construção de um sistema específico
- melhoram o gerenciamento do risco das decisões tomadas
- incluem as equipes nas decisões, evitando o processo de design by committee
- permite um retrato do contexto para o futuro
- permite que as decisões sejam assíncronas.
Como usar?
Estamos usando este processo na Trybe há mais de 8 meses e estamos organizando da seguinte forma:
- criamos um repositório no Github para armazenar os documentos
- qualquer pessoa da equipe pode criar uma branch, copiar o template que criamos, escrever um novo RFC no formato Markdown e abrir um Pull Request
- as pessoas das equipes são convidadas a fazer comentários e sugestões no Pull Request e caso o RFC seja aceito é feito o merge. Caso o RFC não seja aceito apenas fechamos o Pull Request sem realizar o merge.
Com isso temos um histórico de todas as discussões que foram realizadas para a tomada de determinada decisão, nos pull requests. E na branch main do repositório temos a lista de RFCs aprovados. Na imagem a seguir é possível ver algumas das decisões importantes que tomamos usando este processo, bem como a quantidade de discussões que fizemos em cada uma delas.
Este processo tem sido bem importante para podermos evoluir o projeto como uma equipe, bem como dar contexto para as novas pessoas entenderem os motivos que nos levaram a tomar determinada decisão.
Como eu comentei acima, existem outras formas de se fazer este processo. Você usa outro formato na sua equipe? Está usando RFCs e tem outra experiência? Compartilhe nos comentários.
E se quiser trabalhar na Trybe para fazer poder participar desta e de outras experiências incríveis que estamos criando, estamos com vagas abertas ;)
Referências
6 Lessons I learned while implementing technical RFCs as a decision making tool