The disclaimer is that i have never worked with automotive CAN directly. I was a mechanic for a long time and then got into other things. I have worked with embedded CAN applications.
First you need a tool to connect to the CAN bus. The more flexible the tool is the better. There are two problems with reverse engineering CAN. One is that CAN is message based. This means that no two module ever directly speak to each other. Every module broadcasts its data to the whole bus and that data is coded with a message ID. That message ID identifies what that data is to everyone and whoever is interested in the data reads it in. The simplest implementation of CAN has 2000 IDs. The more advanced systems have hundreds of thousands. The second problem is that everyone is talking on the bus at the same time. The difficulty is to filter out what is data you want and what is irrelevant.
Once your connected to the bus start listening. Capturing the data and then analyzing it in a spread sheet would probably be best. Engine RPM would probably be the easiest to identify. Once you've identified a particular message ID and what it means the flexibility of your tool comes in to play. Tell the tool to filter out the message IDs that you already know.
Once you passively identify most of the data on the bus comes a choice. There is a hard way and an easy way from here. CAN supports data requests. The hard way involves transmitting data requests to the car and listening to the reply and then trying to analyze what the returned data means. The easy way involves borrowing a scan tool and listening to the bus while the tool is requesting data from the car. Then analyzing it to identify what request messages get what data and the message IDs.