Acho que todas as respostas "sim" ajudam muito a endossar a ideia. Mas vou jogar fora a ideia de que a decisão é baseada em algumas perguntas:
- Como você deseja se comunicar como uma equipe? Com dois desenvolvedores, agora você é uma equipe. Como você quer se comunicar? Muitas equipes ágeis vivem com discursos em pessoa e esboços em quadros brancos. Mas eles também podem ir tão longe a ponto de anotar as coisas, especialmente se for um bug que não estará no topo da lista de prioridades por um tempo.
- Como você deseja se comunicar com seus clientes? Eu não sei a resposta para isso, mas se você tem algum motivo para publicar bugs (ou bugs corrigidos em um documento de versão), então você ' vai acabar escrevendo-os eventualmente. Poderia também escolher um sistema de gerenciamento de bugs de baixo estresse e acabar com isso.
- Existe valor para preservar o histórico? A resposta pode ser "não agora", mas se você acha que, no futuro, gostaria de ver a tendência dos bugs para ver os lugares que os usuários ter mais problemas, ou lugares onde você poderia passar algum tempo checando e revisando antes de um grande lançamento - então pegue um sistema de rastreamento de bugs. A coisa sobre a história é que o dia em que você quer o registro não é o dia em que você deve começar a manter registros.
IMO, as respostas para essas perguntas são mais sobre onde você vê o produto e como você quer aumentar sua equipe e menos sobre se "2 pessoas = razão para o sistema de rastreamento de bugs". A pergunta maior provavelmente é "um sistema de rastreamento de bugs vale a pena o tempo para configurar & gerenciar e o custo de compra?"