1. Как писать автотесты — зависит от средств разработки. Скрипты на perl, десктоп приложения на Qt, и серверные приложения на Java тестируются, очевидно, по-разному.
2. Как делать описания тестов (для тестировщиков) — для этого нанимается опытный тестировщик, который сам все объяснит.
3. При работе с git — коммитить желательно отдельными логическими изменениями. Желательно перед коммитом проверять компилируемость. Не стоит крупные изменения делать одним коммитом, лучше разделять — вот сделали подсистему, вот мы ее используем в этом модуле, вот — в другом. Если какая-то функциональность развивается долго параллельно другой деятельности — git rebase позволит команде которая занимается этой подсистемой синхронизироваться с остальными, но не отправлять свои изменения пока не закончит работу. А потом отправить сразу группу коммитов.
4. Как настроить среду на кодинг — я не думаю что получится установить это как стандарт. У каждого программиста свои привычки. Идеальной настройки emacs/vim не существует.
5. По поводу DE — я лично фанат xmonad. Многие tiling WM не выносят, и для них он не подходит. Я не понимаю почему — но это факт. При найме программиста мне важно как он пишет код, а не какой window manager использует.
6. Тут вот какая штука — в Linux легко организовать миграцию конфигов. Так что даже при использовании парного программирования элементарно обеспечить чтобы каждый работал с привычной ему средой.
Стандартизировать надо не window manager, а требования к оформлению кода.
Возможно даже используемые в интерфейсах цветовые схемы и шрифты — чтобы при парном программировании люди глаза не ломали. Но и тут я бы поостерегся, а скорее предоставил возможность людям тратить некоторую часть рабочего времени на тюнинг. Тогда они будут интересные идеи по настройке рабочего места утаскивать друг у друга. Результат будет лучше чем любой стандарт.