Ну вообще в разных компаниях видел разную организацию, общие моменты обычно такие:
1. Программиста не стоит заставлять пользоваться конкретным инструментом, если ему это не удобно и он может пользоваться другими, не усложняя командную работу и с такой же эффективностью.
2. Тут от проектов будет зависеть, обычно либо локальные виртуальные машины используются, либо общий сервер разработки (несколько серверов), где есть у каждого своя копия проекта(ов). На сервере также можно использовать для удобства виртуализацию. Тяжеловесные сервисы обычно тоже имеют тестовый сервер, как правило, куда можно подключиться, либо же вообще использовать mocking стоит. Сервера разработки обычно локально, поэтому с синхронизацией особых проблем нет: общие папки, sftp, nfs, что душе угодно.
3. Процесс работы с VCS часто от продукта зависит, но обычно можно использовать общепринятые стандарты и соглашения, вот читайте
habrahabr.ru/post/106912
4. Для тестирования часто выделают отдельный сервер со сборкой проекта в тестовом окружении, где можно запускать unit-тесты, функциональные, и ручное тестирование. В серьезных компаниях обычно есть тестировщики, селениум применяется, там где действительно есть выгода от него (иногда тестировщикам реально проще вручную протыкать нужные вещи).
5. Тут тоже полно инструментов, выбирают основываясь на списке функций, которые нужны для работы. Мне чаще всего приходилось работать с redmine, phabricator.
6. Тут тоже зависит от команды, какие разработчики в ней есть, кто что умеет делать лучше - это уже работа тимлида, добиваться максимальной эффективности от команды. Я не сторонник разделять по такому принципу задачи, лучше делить по области, которую задача затрагивает (по модулям в проекте, фронтенд или бекенд и т.п.)
Ну и, конечно, нужно учитывать специфику проектов и команды, если что-то из этого только мешает, может и стоит отказаться от него. И зачастую что-то свое приходится внедрять, чтобы повысить эффективность работы команды, допиливать стандартные инструменты разработки и контроля задач, разные хуки на git навешивать и т.п.
