yes and no. QoS and bufferbloat should be orthogonal concepts, but if your equipment is doing too much buffering, you aren't going to be able to to get good results from QoS because of the latency that full buffers cause.

You want to have enough buffering to keep the pipe full, but beyond that it just adds latency. There are two changes that have happened in the last few years that help with this.

The first is BQL (Byte Queue Lengths), this is a change to each network card driver (far too many haven't had this change implemented yet), that changes the way the driver manages it's queue lengths from holding X packets to holding X bytes. This helps because the number of 64 byte packets that you want to have in your buffer to keep the wire busy is much higher than the number of 1500 byte packets that you would need in your buffer.

fq_codel as a queuing discipline works to give all streams of traffic low latency, and the result of using fq_codel is that you may find that you no longer need to set QoS on your network. With fq_codel, your VoIP streams will get low latency in leaving your network, which is the result that you are attempting to get by setting QoS

One good way to see the problem is to watch what happens to ping responses while you do a large file transfer. With the traditional tail-drop queues, the ping times skyrocket during your file transfer. With fq_codel they don't change much

Tsiox has it right that you should first address bufferbloat and then look at QoS if you find you still need it.

It is important to note that you can only directly affect the traffic that you are sending, There are indirect ways to affect the traffic you are receiving (google for sqm-scripts that were created for cerowrt and are now standard in openwrt and with minor tweaks can be used on any linux system for an example of how you can manage your inbound traffic to avoid hitting bufferbloat on your ISPs routers)