Не успел детально изучить предложения этих сервисов, но пока не нашел у них упоминания про поддержку mutual ssl.

В loader.io точно нет. Про остальные — не в курсе.

Согласно FAQ loader.io, это не совсем так.

Значит не обновили FAQ. Мультирегионы и провайдеры уже давно крутятся на продакшене (хотя за эту фичу придется платить).

Зависит от аргументации. Нужно понять почему он не согласен, в то время как остальные согласны (это его участок кода? он знает то, о чем остальные не в курсе? а может эти 4 человека знаю то, что 5 не в курсе, и риски намного меньше, чем он себе представляет?)

По моему опыту, технические проблемы решаются в команде достаточно просто. Некоторые идут на уступки в одном (например в выборе платформы разработки), но не дают уступок в другом (покрытие тестов не менее 95%).

Больше проблем начинается, когда продакт овнер хочет отойти от процесса разработки продукта («нужно релизит к этому числу», «не нужно писать тесты»). Тут ужа начинается проблема конфликта продакт офнера с командой. В этом случае (конфликт с продакт овнером) берется еще человек, у нас их называют «Leaison» (вроде скрам мастера, но на время конфликтов). Что самое интересное — этот человек может быть просто другим девелопером с другого проекта. Его задача — взглянуть на ситуацию под другим углом и помочь выбрать правильное решение. Далее — идет обсуждение проблемы (команда, leaison и продакт овнер). Иногда команда идет на уступок (например, зарелизить в нужный срок без полного покрытия), но потом клиент идет на подобный уступок в ответ — команда дополнительно тратит время покрыть созданый тех. долг (данное потраченное время не несен никакого «бенефита» продакт офнеру с его стороны).

Еще часто такое возникает, когда над продуктом работают разные команды (с разных контор), и у каждой команды свои методики. Тут уже командам придется активно договариваться как вести процесс вместе.

Я обожаю тим-ревью, но даже с таким подходом, на одном из проектов пролетела бага, которая убила регистрацию(!)

А тесты на регистрацию не?

Да не наказываю я. Я нахожусь с другой барикады. Данный подход пока не позволил допускать такие проблемы.

ЗЫ даже если проект большой — команды дробятся на 4-5 человек, так что будут отвечать 4-5, а не 100 (точнее 4-5 + пару кто ревьюил)

Он знает возможные проблемы и их решения, что и для чего можно использовать

Тести показывают проблемы и как они решаются через код. Как это будет работать и реализовано решает команда, а не один человек (планирование «скоупа» работ и реализация). Ответственность несут тоже все. Написание контролируется тоже командой (code review, switch pairs and context). Нет hero-mode, он просто не нужен.

14. Четко разделяйте ответственность — за каждый участок кода должен отвечать один разработчик

Не работает. Человек может заболеть/уйти в отпуск/уволится. Тогда он становится узким местом в разработке (пример: один знает работу билинга — на него все молятся, ведь только он может его чинить). Команда вся должна быть в курсе всех частей проекта. Для решения подобных проблем используется система «review» кода перед принятием в основную ветку другим(и) разработчиком(ами). Также используется работа в паре и переключение с контекстных задач людей.