Yakov Akulov

Ну вообще в разных компаниях видел разную организацию, общие моменты обычно такие:

1. Программиста не стоит заставлять пользоваться конкретным инструментом, если ему это не удобно и он может пользоваться другими, не усложняя командную работу и с такой же эффективностью.

2. Тут от проектов будет зависеть, обычно либо локальные виртуальные машины используются, либо общий сервер разработки (несколько серверов), где есть у каждого своя копия проекта(ов). На сервере также можно использовать для удобства виртуализацию. Тяжеловесные сервисы обычно тоже имеют тестовый сервер, как правило, куда можно подключиться, либо же вообще использовать mocking стоит. Сервера разработки обычно локально, поэтому с синхронизацией особых проблем нет: общие папки, sftp, nfs, что душе угодно.

3. Процесс работы с VCS часто от продукта зависит, но обычно можно использовать общепринятые стандарты и соглашения, вот читайте habrahabr.ru/post/106912

4. Для тестирования часто выделают отдельный сервер со сборкой проекта в тестовом окружении, где можно запускать unit-тесты, функциональные, и ручное тестирование. В серьезных компаниях обычно есть тестировщики, селениум применяется, там где действительно есть выгода от него (иногда тестировщикам реально проще вручную протыкать нужные вещи).

5. Тут тоже полно инструментов, выбирают основываясь на списке функций, которые нужны для работы. Мне чаще всего приходилось работать с redmine, phabricator.

6. Тут тоже зависит от команды, какие разработчики в ней есть, кто что умеет делать лучше - это уже работа тимлида, добиваться максимальной эффективности от команды. Я не сторонник разделять по такому принципу задачи, лучше делить по области, которую задача затрагивает (по модулям в проекте, фронтенд или бекенд и т.п.)

Ну и, конечно, нужно учитывать специфику проектов и команды, если что-то из этого только мешает, может и стоит отказаться от него. И зачастую что-то свое приходится внедрять, чтобы повысить эффективность работы команды, допиливать стандартные инструменты разработки и контроля задач, разные хуки на git навешивать и т.п.

Я считаю нормальным такой подход к обучению, но нужно писать применительно к конкретным проектам рабочим. Если советовать на что-то взглянуть, то скорее всего в "правильной" CMS будет трудно разобраться, не создав на ней несколько проектов, также как и с фреймворком.
Я бы тоже советовал начать с написания фреймворка на котором будет делаться CMS (сейчас все популярные движки идут по этому пути). А CMS лучше делать под конкретные проекты, так как нельзя создать рабочую систему в вакууме.
Я вот недавно дабы разобраться со всякими "правильными" паттернами в PHP написал свой фреймворк: https://github.com/jakulov/bun/ с использованием своих реализаций DI, ORM, MVC и т.п.
Сейчас рефакторю код и попутно описывают процесс разработки в блоге jakulov.ru

Попросите банк отправить с их стороны простой запрос curl POST на ваш url, а у себя запишите полученный запрос в логи.
что типа
curl --data "test=ok" example.com/url.php

если запрос придет, значит скорее всего у вас все ок, и проблема в ПО банка

ну первое, что приходит в голову A/B тестинг - сделали изменение - потестировали. Если стало лучше, оставляем.
Со временем у вас накопится опыт определенный, сможете заранее некоторые вещи уже предугадывать.
Все это, конечно, при условие что есть чем измерить "успешность" изменений.
Тема вообще очень обширная.