The mechanics of shift-reduce parsing is pretty simple -- the hard part is understanding why it works or how to construct the tables. But since you already have the table, that is not relevent.
To do shift/reduce parsing, you need an action table and a goto table (which you have) and a stack of states. You start with just state 0 on the stack. At each step you look up in the action table with the top state on the stack and the next token of input and perform the corrsponding action.
for a SHIFT action you consume the token of input and push the state on the stack
for a REDUCE action, you find the SIZE of the right-hand-side of the rule to be reduced (number of symbols -- ε is zero size) and the SYMBOL on the left-hand-size. You pop SIZE states from the stack and then use the state now on top of the stack and the SYMBOL to lookup in the GOTO table and push the corresponding state.
That's it. You repeat the above until you either reach an ACCEPT action (the string matches) or a REJECT action (any blank in the action table -- the string is not matched). The reduce action is a bit complicated as it chains immediately to a goto action, so you can think of the reduce+goto as a single action or as two distinct actions as you prefer.
If you want your parser to construct the parse tree while you're at it, its a bit more complicated. You need to have your stack hold state × subtree pairs -- when you shift a token you include that token (as a single node subtree) along with the state, and when you reduce, you create a new subtree from the subtrees popped (as children to the LHS symbol) which you push along with the GOTO state. When you get to the ACCEPT state you do a 'reduce 1' action to build the complete parse tree.