Drupal development workflows come in a wide range, from a solo developer working on a shared web server, to a large team committing changes via Git to a central staging environment. We land somewhere in the middle.
As a tight-knit and efficiency minded development team, we have arrived at an ideal workflow which combines aspects of on-server development with the power and reliability of separate version controlled environments. Our platform of choice is Pantheon, which makes this setup a breeze.
Our average project sees a two-person team of primary developers working in tandem to produce each new feature. Generally one of us will work front-end, while the other handles on-site configuration and back-end module work. This makes for an extremely efficient workflow as features are created quickly and with multiple sets of eyes. An example of an average afternoon might be one developer creating a new content type, populating some dummy content, and creating a matching view. Meanwhile, the other developer is theming the new markup as it is added. We leave an open Skype line between developers during the construction of each new feature, so that both parties are in constant communication as changes are made. Individual code updates are uploaded to a shared development server, where they are committed in batches to the Git repository. Once a batch of changes have been approved for deployment, they will be pushed via Git to the staging environment and merged with a copy of the live database to test that everything is working as it should. Only once the staging environment has been fully tested and signed off on will the code be pushed once again by Git up to the live server environment.
Ensuring that both the live and test environments are not accessible via FTP helps prevent mishaps in the deployment process. Since the only way code can move from the development environment to the live environment is via Git, all code changes are accounted for and will be recorded in the git commit log by the committing developer. Especially with larger teams or complex features, this adds an important layer of review and accountability which prevents issues from hitting a live site.
In our case there is one additional aspect of on-server development, and that is Dropbox. For minute to minute code changes it is often quite helpful to have multiple eyes on a given line in a module. Working remote, we employ a shared Dropbox sites folder which contains the working code of a given project. We configure our code editors to auto-update files on change, which allows multiple developers to view real-time changes in a module or theme file and help resolve issues or work through bugs. Dropbox has lightning fast response time which can result in something akin to Google Docs collaborative document editing, but in your favorite editor!
The above Drupal development strategy works amazingly well in our use-case, however there are some things to keep in mind: This development workflow only works if all developers are trusted, and follow exacting coding standards. Since we employ the use of a shared development server, each member of the team must be very clear in exactly what tasks they are working on and when. Personally I have a hard time imagining a situation where you would realistically want more than one developer working in the same file at the same time, but if this is a requirement for your project a better solution may be to work in separate localhost Git branches, merge changes together as you build. For more cohesive teams however, this is what we've tested to be the most efficient use of developer resources.