Yes, you initialize it like every other shader type using it's specific CreateComputeShader call with the device handle. And you bind it and it's required resources just like every other shader type being executed.
Now the important thing is to understand the threading model. You need to establish how you want to distribute your computation across threads. And then how many threads you want per a thread group and then finally how many thread groups to dispatch with the device context on the CPU.
The number of threads per a thread group is declared in the shader file. It's also important to note that you logically distribute the thread groups and threads across a three dimensional array. So if I were to dispatch (2, 8, 1) thread groups where the shader declares each thread group as (1, 8, 1) threads. This would execute 128 instances of the kernel.
Some other important things to note, buffers that are going to be written to within the compute shader must be bound as unordered access views to the pipeline while read only buffers can be bound as a resource views. There are also some nifty new buffer features. An important one to note are the Append/Consume buffers. These allow you to pop and push data to and from a buffer with out having to worry about synchronization with other threads.
For general synchronization, compute shaders offer some atomic functions and what are called memory barriers. Memory barriers are essentially synchronization mechanisms for shared memory among thread groups.
Also some peformance tips, minimize context switching of the pipeline from computational use to standard rendering use. Also avoid having to read data from the GPU as much as possible. Locking and reading buffers from the CPU is expensive.
