Не ища и не будучи достаточно новым здесь, я предполагаю, что было много дискуссий вокруг этого, но позвольте мне все же дать ответ.
Во-первых, я бы спросил, что вы подразумеваете под «большим» проектом? Я видел, как некоторые люди отмечают, что проект занимает несколько месяцев и привлекает 4-5 программистов как «большой проект». Для других «большой проект» означает многолетнюю продолжительность и 30 или 40 разработчиков. Я предполагаю, что это где-то посередине, учитывая, что вы упомянули «нескольких разработчиков». Чтобы быть в безопасности, давайте предположим, что это длится от полугода до года с 5-10 девайсами.
Как уже говорили другие, если вы делаете TDD, вы бы сначала начали с тестов, а не с большой дизайнерской работы. Дизайн эмерджентный. На практике, однако, я считаю, что существует баланс между подходом TDD (который я считаю ценным, но не обязательным) и простым обеспечением хорошего охвата модульных тестов, что, на мой взгляд, важно
Если вы сами кодер и имеете опыт работы с TDD, я бы посоветовал вам практиковать то, что вы будете проповедовать. Вместо того, чтобы пытаться спроектировать всю систему на абстрактном уровне, определить интерфейсы и т. Д., Выберите основную часть системы. Убедитесь, что вы сделали простейшую вещь, возьмите зеленую полосу, проведите рефакторинг, добавьте еще один тест и т. Д.
Самым большим препятствием для использования TDD в проекте с несколькими разработчиками является отсутствие опыта в методологии. Дайте вашим программистам конкретный пример (даже если он немного функциональный), который действительно показывает им, как это сделать правильный путь , взаимодействовать с людьми, когда они приходят в проект, регулярно просматривать отзывы людей тесты, и убедитесь, что это продолжает оставаться темой, которая находится на переднем крае того, что вы делаете, а не просто запоздалая мысль. Если вы делаете Scrum, включите его в определение «готово» для любой задачи / истории.
Я бы также потратил некоторое время на настройку чего-то вроде EMMA или Cobertura (большой поклонник Cobertura), так что у вас есть несколько жестких показателей для оценки тестов людей. эффективны ваши тесты, но они являются точкой данных. Если у вас есть 20% тестового покрытия, вы можете быть уверены, что люди не пишут тесты, которые они должны. И наоборот, только то, что у вас есть 90% тестового покрытия, не гарантирует, что тесты хороши, что является причиной таких вещей, как сопряжение и отзывы.
Итак, простой ответ: приведите своим ребятам пример, сфокусируйтесь на сопряжении / обзорах и добавьте некоторые вещи, такие как инструмент покрытия кода, чтобы помочь команде оставаться честной.