- PVSM.RU - https://www.pvsm.ru -
Я столкнулся с командами в нашей организации, которые пытаются внедрить Test Driven Development (TDD).Иногда одному или двум разработчикам удается применить его без посторонней помощи, но у большинства этого не выходит. Чтобы лучше понять проблему я провел опрос среди членов команды и обнаружили, что даже после обучения еще многое предстоит сделать. Эта стратегия была разработана, чтобы помочь любому внедрить TDD в организации, хотя некоторые из идей применимы лишь для средних и крупных компаний.
Мое исследование членов команды (все они прошли обучение) показало следующие проблемы:
Исходя их этих симптомов, что же является основными проблемами?
Test Driven Development трудно изучать. Фазы обучения (время, в течение которого он становится глубоко укоренившейся привычкой) обычно длится от двух до четырех месяцев, в течение которых производительность снижается. В конечном счете, преимущества [1] будут очевидны и TDD будет использоваться само по себе, но вопрос в том, как сделать так, чтобы это время появилось? Многие разработчики сдаются уже через несколько дней.
Большинство стратегий внедрения, которые я видел, делают акцент на аудиторные занятия (или электронного обучения) и наставничество один-на-один. Хорошо проведенные, они конечно достигают своей цели, но я думаю, что требуется гораздо больше.
Обучение в классах страдает от двух ключевых проблем: примеры слишком просты и не связаны с реальными проблемами, и почти нет шансов попробовать это на практике.
Интерактивное обучение имеет преимущество, позволяя погрузиться в тему глубоко.Однако все еще не достаточно шансов попробовать все это на практике. Кроме того, эти курсы, как правило, проходят без взаимодействия с другими студентами. Услышав вопросы от своих одноклассников и коллег, вы часто можете сами достигнуть понимания.
Наставничество один-на-один не масштабируется, за исключением работы с несколькими членов одной команды одноврменно. Это особенно трудно в большой корпоративной среде, где есть только несколько экспертов и сотни или тысячи людей, нуждающихся в помощи.
Книги являются отличным вариантом, но немногие разработчики любят читать книги об инженерных практиках, и даже те, кто учатся TDD таким образом, сталкиваются с большими проблемами. Как и онлайн-курсы, проблема обучения лежит на их собственных плечах.
И наконец: унаследованный код делает и без того трудную задачу сложнее в сотни раз. Разработчики справедливо задают вопрос: «Как я могу протестировать эти тесно связанные объектов? Этот код сложный, как я могу проверить этот алгоритм? „
Что же может сработать? Предыдущие подходов страдают от двух ключевых проблем: отсутствием глубины и общения. Полная стратегия содержит в себе комбинацию подходов.
В основе этого плана лежит: создание постоянного обзения и расширения сотрудничества вокруг TDD. Три из этих стратегий сосредоточены в этой области: парное программирование, Coding Dojo [6] и чтения семинаров.
Coding Dojo (с помощью формата Рандори) является мероприятием, где небольшая группа людей (не более 15), решает задачи с использованием TDD (адаптировано из Danilo Sato [7]):
Из опыта я рекомендую вам выбрать для начала очень небольшие задачи.
Для чтения семинаров существует целый ряд книг:
Обычно команды обрабатывают 1-2 главы за сессию. Темп достаточно медленный для того, чтобы люди могли читать вне работы. Кроме того, он дает достаточно времени для углубленного обсуждения нескольких пунктов из этой главы.
На семинарах должна быть пицца (или любая другая еда) — так как вы просите людей тратить свое личное время для того, чтобы делать что-то похожее на работу, то им нужен стимул. Два семинара могут чередоваться, так что люди не чувствуют, что они застрял в чем-то одном. И не следует ожидать, что группа будет постоянной от встречи к встрече.
Семинары и сообщества гораздо более полезны по сравнению с самостоятельным обучением, потому что члены группы общаются и приносят пользу друг другу. В результате мы узнаем о вещах, до которых сами ни за что бы не дошли.
В общем, вот ключи которые. как мне кажется, помогают создать успешную стратегию внедрения:
Автор: mythmaker
Источник [12]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/testirovanie/19386
Ссылки в тексте:
[1] преимущества: http://www.notesfromatooluser.com/2008/10/advantages-of-tdd.html
[2] Emma: http://emma.sourceforge.net/
[3] Cobetura: http://cobertura.sourceforge.net/
[4] NCover: http://ncover.sourceforge.net/
[5] “Чистый код»: http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
[6] Coding Dojo: http://www.notesfromatooluser.com/2008/10/tdd-randori-session.html
[7] Danilo Sato: http://www.dtsato.com/blog/2008/08/12/coding-dojo-agile-2008/
[8] Test Driven: TDD and Acceptance TDD for Java Developers: http://www.amazon.com/gp/product/1932394850/ref=cm_arms_pdp_dp
[9] Kent Beck's Test Driven Development: By Example: http://www.amazon.com/Test-Driven-Development-Addison-Wesley-Signature/dp/0321146530/ref=pd_sim_b_32
[10] xUnit Test Patterns: Refactoring Test Code: http://www.amazon.com/xUnit-Test-Patterns-Refactoring-Addison-Wesley/dp/0131495054/ref=pd_sim_b_5
[11] Working Effectively with Legacy Code: http://www.amazon.com/Working-Effectively-Legacy-Robert-Martin/dp/0131177052/ref=pd_sim_b_12
[12] Источник: http://habrahabr.ru/post/157729/
Нажмите здесь для печати.