Здравствуйте, blp, Вы писали:

L>>Здесь придется сначала разделять задачи и ответственность. Нельзя объять необъятное. Бригаду обезьян перевоспитать с наскока не получится, их надо медленно варить.
blp>Собственно, мой основной вопрос был как раз про детали этого медленного варения. Судя по ответам, ваш случай относится к маленькой команде в 5-7 человек, которая не распределена географически. Моя ситуация про команду раз в 10 большую, распределенную примерно в 3 таймзонах.

Ну не бывает команд в 10 раз больших. Бывают 10-20 условно проектов, на которых попеременно работают в общей сложности столько народу.
Впрочем, это неважно — такую толпу разом не объять.

>>Маньяка с командой лучше сначала изолировать на небольшом модуле, откуда тесты вскоре начнут расползаться по другим модулям.
blp>Неосуществимо.

Только так, никак иначе не выйдет.

L>>Размер команды не имеет такого большого значения.
blp>Не согласен.

>>Конечно, в небольшой локализованной команде до 5-7 (кстати, размер команды из поста) разработчиков внедрять новые подходы намного легче, нежели в распределенной команде о 50 человеках. Нужно начинать снизу, с небольших команд.
blp>"Снизу" не начинается, потому что команды шарят достаточно большой проект и имеют зависимости друг на друга.

Ну и что? Написал новый юнит-написал к нему, и только к нему, без попыток замокать всю вселенную, комплект юнит-тестов.

L>>Тут нужно еще понимать, какой будет выхлоп.
blp>Да выхлоп как раз понятен — ускорение релизов, уменьшение числа регрессий, снижение он-колла. У нас не коробочный продукт, а сервис с довольно частыми релизами (~раз в неделю) и он-коллом.

У меня сейчас такая же ситуация. Внедряю методом медленной варки. Идет с сильным скрипом, если честно, но необходимо.