Продажа TDD для команды

Question

Я занимаюсь TDD в течение последних 3 лет. Мы были небольшой компанией, и у нас была очень прочная поддержка большинства аспектов гибкого процесса от руководства. В ходе этого процесса была реализована вся команда разработчиков. И, таким образом, авансовые инвестиции, которые обычно требуется для сборки светильников, были приняты, зная, что он будет окупиться по пути. (Код, который запускает HTTP-сервер, код, который заполняет базы данных SQL перед тестированием и т. Д.). Документация, как правило, происходила в тестах, а запросы помощи обычно представлялись в виде теста с ошибкой.

Теперь я переехал в более крупную компанию, и хотя руководство поддерживает Agile-процесс, товарищи по команде представляют собой смешанную сумку, некоторые из них считают ее полезной, некоторые из них делают это из-за управления, а некоторые не видят стоимость. Было сложно убедить людей потратить некоторое время на сборку светильников или убедить члена команды наилучшим образом помочь мне, если он найдет время, чтобы написать неудачный тест.

Как вы думаете, лучший способ продать TDD нерешительному товарищу по команде? Обычно это возражения: «Это ненужная стоимость», «мы всегда можем писать тесты после факта для важных частей», «это звуковое слово, команды выбирают его, а затем он падает в сторону, когда начинается тяжелая шлифовка» 'и т. д.

Answer 1

"лучший способ продать TDD для нерешительного товарища по команде"

Вы не можете. Не тратьте время на «продажу».

Вместо этого инвестируйте время в «доказательство».

Просто сделайте это. Быть успешным. Когда люди спрашивают, в чем секрет вашего успеха, тогда покажите TDD. Не раньше, чем.

Answer 2

простой - ремонтопригодность. TDD дает вам возможность вносить изменения и видеть, где эти изменения влияют на остальную часть кода. Чем больше база кода, тем более важно, чтобы были тесты для проверки любых новых изменений.

правильность. Хотя тесты сами по себе могут быть нарушены, в конечном итоге они достигают точки, в которой они обеспечивают, чтобы компоненты выполняли то, что они должны были делать. Чем лучше разработчик, тем быстрее это происходит.

Другим преимуществом является то, что TDD информирует о конструкции компонентов в системе. Если вы пытаетесь что-то протестировать, а тест слишком сложный, это, вероятно, означает, что вам нужно разбить проблему на более мелкие части ...

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

Answer 3

Я думаю, Joel's post очень хорошо объясняет, почему тестирование - это хорошая вещь.

Я не думаю, что он когда-либо использовал фразу «TDD», но у нее есть отличная информация.

Answer 4

Для нерешительного товарища по команде, будьте терпеливы, дождитесь возможности, затем наброситесь. В разработке программного обеспечения, несомненно, будет проблема, когда TDD предотвратит или смягчит проблему. Будьте в поиске такой возможности. Поработайте с ним, чтобы создать тест (ы), который должен был быть разработан с самого начала. Однако убедитесь, что вы создаете свое сообщение таким образом, чтобы не смущать вашего товарища по команде.

Answer 5

Я согласен с S. Lott, вы не можете «продать» их, вам нужно показать значение.

Один из самых эффективных способов сделать это с помощью парного программирования. Конечно, у вас есть еще одна проблема «продажи», убеждающая людей в том, что сопряжение является эффективным подходом, но через некоторое время вы можете убедить/конвертировать разработчика или тоже.

TDD был для меня непростой концепцией, но теперь я не могу изобразить программирование каким-либо другим способом.

Answer 6

Покажите им этот сайт: WeDoTDD.com - фактические примеры использования команды компании. Те, кто успешно практикуют TDD в реальных компаниях.