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.

rfc

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

Bring Back the RFCs

6 Lessons I learned while implementing technical RFCs as a decision making tool

Scaling Engineering Teams via RFCs: Writing Things Down

Design Docs at Google

A Structured RFC Process