This table only deals with the situation where they all work on the same thing.
I recently had a crash project. If it didn't work out, the company would be forced to stop work until the project was completed. We were talking millions of dollars per day here, so the project was a tad urgent.
First, the other information analyst was removed. Then I did the requirements. While they were being completed. a testmanager came in and started writing testcases on the requirements. A programmer came in and did mock-ups. I corrected the mock-ups. A secondary team was set up to build the fallback solution - completely separate but we could use their input. Then another programmer was added to assist the first. They only talked to eachother. The file management solution was handled by someone else: he just gave us a place to store and receive files. No other interface between his project and ours, except the deadline.
Common thread: separation of concerns, public interfaces, minimal reliance of one class (programmers, testers, designer) on any other class. Worked very well - we finished right on time, tested and validated as well, in half the budget and time of the previous project. The previous project had used more people working on the same thing. That never really works out.
In my current project we have way too many people working on the same subject. Now I have to check with my co-workers whenever I want to edit documents. Argh. Every decision has to be a group decision. Arrrrggggghhhh. A very simple project has now turned into a two million euro monstrosity.
Interfaces and information hiding: a really good idea if you want to get stuff done. It works for organisations too: "need to know" and "call my secretary".