When a project is up and running, it's usually quite easy to divide tasks, but I find this harder when getting started. Do you do a lot of whiteboard design, and split it into classes/other units of code? How do you make sure these work well together? Or does every project best get started with work by one person, that others can add upon later?
For complex backend projects we usually whiteboard/flowchart as a team first (high level), and use that diagram to pick which parts should be assigned to which person.<p>At that point we start individually writing documentation for our respective pieces, (as if those services already existed). This might take the form of Readme files, wikis, or formal API documentation.<p>Normally the process of writing documentation (and getting feedback on it) flushes out of a lot of issues. When everything is documented and everyone is on the same page about what everybody else is doing, then we write our tests and repeat the same feedback process. Once everyone's tests are on the same page, then we write our code, and do a code-review when that is done.<p>Even with all those checks and balances, mistakes and confusions and miscommunications still happen. But having those regular check-ins to flush out issues before the real code gets written can save a lot of headache. If you get to the code review and find an issue, it's probably not going to be a huge one.
Someone creates the user interface and someone creates each of the backend APIs that powers it.<p>Prototyping the user interface can be done by any number of people any number of times, since the goal is to experiment with different ideas. The backend APIs are usually mandated by what the user interface requires.
To me it's about finding the critical path.<p>You find what things might stop your project going live and work on those things first. If they can be worked on in parallel even better.