UncategorizedгаджетыНовостиразработчиктехнология

Как распространять технические практики, такие как TDD, в организации

Ключевые выводы

  • Технический коучинг означает помощь разработчикам в изменении их повседневных привычек и методов работы для поддержки Agile и DevOps.
  • Немногие организации успешно внедряют TDD. Разработчикам обычно требуется поддержка, чтобы перейти от практических занятий TDD к полноценной производственной кодовой базе.
  • Работа в ансамбле с опытным практиком эффективна для изучения TDD, особенно в сочетании с регулярными практическими занятиями.
  • «Самман» – это подход к техническому обучению. Он состоит из двух основных частей – ансамблевой работы и учебных часов.
  • Слишком мало технических тренеров; конкретный метод, такой как Samman, может помочь разработчикам начать обучение.

Одним из факторов успеха Agile и DevOps является то, что разработчики меняют методы своей работы и применяют такие методы, как разработка через тестирование (TDD). Это не то, что происходит само по себе, и многие из «обычных» способов внесения изменений в TDD не работают. В этой статье я опишу некоторые из тех вещей, которые я пробовал, и которые действительно работают. Я объясню «Самман» – метод коучинга, который я использую с разработчиками.

Почему TDD имеет значение

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

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

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

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

Что организации уже делают

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

Недавно я опросил около 300 участников конференции ACCU 2021 о том, какие учебные мероприятия они уже проводят. (Очевидно, это участники конференции, так что это одно из занятий, которое я не перечислил!) Наиболее популярными вариантами в порядке убывания были:

  • Проверки кода
  • Обучающие видео онлайн по запросу
  • Курсы обучения под руководством инструктора продолжительностью 2-5 дней единовременно
  • Частое парное программирование
  • Хакатоны
  • Сообщество практикующих

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

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

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

Мой собственный опыт

В 2005 году я открыл для себя Coding Dojo как форум для преподавания и изучения TDD и начал замечать некоторый прогресс в том, чтобы помочь своим коллегам освоить его. Я написал свою первую книгу «The Coding Dojo Handbook» в 2011 году. Кодирование Dojo – отличный способ научить людей основам TDD и начать менять культуру разработки. Однако через несколько лет мне стало ясно, что это не так уж и хорошо для внесения устойчивых изменений, особенно в организациях, где качество кода низкое, а TDD затруднен. Слишком большой разрыв между теми упражнениями ката, которые люди успешно выполняют в Coding Dojo, и реальностью, которая поражает их, когда они возвращаются к своим столам.

Что я пробовал дальше – метод Саммана

В 2018 году я получил фантастическое приглашение от Ллевеллина Фалько стать с ним парным тренером. Я провел две недели в США в качестве его клиента и увидел, что то, что он делает, действительно работает. Он использовал тот же вид сеансов Ката с групповым кодом, с которыми я был знаком по кодированию додзё вместе с практическими занятиями всей командой в производственном коде. Комбинация казалась ключом к тому, чтобы она прижилась.

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

Я решил, что этому стилю коучинга нужно название, чтобы отличать его от других подходов и помогать людям его открыть. «Самман» – шведское слово, означающее «вместе». Это казалось подходящим для метода, предполагающего много работы в «ансамбле» – французское слово, которое также означает «вместе». Моя новая книга «Технический Agile Coaching с методом Саммана» вышла в январе 2021 года.

Что такое метод Саммана?

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

  • Учебный час
  • Ансамблевая работа

В учебный час тренер использует упражнения и методы активного обучения, чтобы преподавать теорию и практику таких навыков, как TDD. На сессиях Ensemble вся команда вместе с тренером применяет методы гибкой разработки в своей обычной производственной кодовой базе. (Некоторые люди могут знать ансамблевую работу под другим названием: групповое программирование.)

Учебный час – как короткое, частое додзё кодирования

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

Меня очень вдохновляют методы обучения, используемые Шэрон Боуман. Ее бестселлер «Обучение из глубины комнаты» описывает модель обучения «4С». Каждый учебный час состоит из следующих четырех частей:

  • Соединять
  • Концепция
  • Бетонная практика
  • Выводы

Примерно один абзац назад я просил вас вспомнить, как вы изучали новый навык. Это своего рода «общение». Чтобы узнать что-то новое, вам нужно интегрировать это с тем, что вы уже знаете. Это помогает учащимся вспомнить свои предыдущие знания и сосредоточиться на них, прежде чем переходить к следующей части, «концепции».

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

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

«Конкретная практика» обычно означает написание некоторого кода и выполнение ката кода практики. Часто это самая продолжительная часть учебного часа – около 30-45 минут, работая либо в ансамбле, либо в небольших группах по два-три человека. Вы не можете написать много кода за это время, поэтому вам нужно подготовить отправную точку и четкие инструкции, чтобы люди могли сразу же начать применять то, что они узнали о «концепции».

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

Перед окончанием учебного часа мы всегда уделяем несколько минут тому, чтобы выработать «выводы» из занятия. Это помогает людям что-то вспомнить, если они записывают это своими словами или объясняют другому человеку то, что они узнали. Наконец, я призываю людей позже самостоятельно выполнить упражнение. Свободное владение приходит от практики, и на каком-то уровне вам просто нужно потратить время.

Ансамбль работает над типовой задачей

Все блестящие умы работают вместе над одним и тем же, в одно и то же время, в одном пространстве и за одним компьютером – мы называем это «программированием мобов».

– Вуди Зуилл

Это цитата из «Программирование мафии – подход всей команды» Вуди Зуилла и Кевина Медоуза. Изначально я изучил эту технику у Зуилла и других близких ему людей. За прошедшие с тех пор годы я предпочел описывать это другими словами. Я обычно говорю «ансамбль». Мне нравится, как этот термин подразумевает сотрудничество дружелюбных людей, например, группы музыкантов. Но суть техники та же.

Подобно тому, как музыкантам необходимо практиковаться вместе, прежде чем они смогут создать действительно хороший звук, программисты должны научиться плавно взаимодействовать в ансамбле. В группе вы можете играть разные роли, которые требуют разных навыков. Одна из первых проблем, связанных с выполнением роли «навигатора», – это устное высказывание о коде и дизайне. Вам нужно сказать «объявить новую переменную» или «встроить этот оператор возврата», если раньше вы только когда-либо набирали эту переменную и не задумывались о том, как она вызывается. Однако когда у вас появляется новый словарный запас, это позволяет вам мыслить на более высоком уровне абстракции и открываться для обсуждения дизайна. В конечном итоге вся команда может участвовать в разработке, объединении своих знаний и создании кода, которым все гордятся.

В ансамбле я много раз наблюдал следующее: один человек в команде знает, как что-то делать. Ансамблю нужно это делать. Очень скоро все в ансамбле знают, как это делать. Это происходит постоянно – люди учатся друг у друга, знания и навыки быстро распространяются. Это было ключевым моментом для меня как для технического тренера. Быть частью ансамбля дает мне сверхспособности! Если я присоединяюсь к коллективу, я могу распространять то, что я знаю, очень естественным образом, когда в этом возникает необходимость, со всей командой одновременно.

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

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

На групповых занятиях команда выбирает задачу, типичную для того, над чем они обычно работают. С помощью тренера команда учится применять соответствующие методы гибкой разработки. Это важнейшая часть, которой не хватает, если вы выполняете только практические упражнения и кодируете додзё. Здесь мы начинаем видеть, как выглядят гибкие методы в этом производственном коде, над которым работает моя команда.

Когда люди впервые учатся работать в ансамбле, двух часов в день достаточно. Вот почему метод Саммана позволяет тренеру при желании работать сразу с несколькими командами. Вы можете тренировать одну команду утром (два часа в ансамбле, один час обучения), а другую – днем. Если вы амбициозны, вы можете тренировать групповые занятия трех команд и проводить совместный учебный час каждый день. Я должен сказать, что это немного напрягает.

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

Я считаю, что после десяти полудневных тренировок и команда, и тренер получают пользу от перерыва; за несколько дней или недель до другого аналогичного 10-дневного блока коучинга. У команды есть время, чтобы продолжить новые способы работы без тренера, и они вынуждены выяснить, что они действительно знают и с чем им нужна дополнительная помощь, когда тренер вернется. Тренер получает возможность спланировать новые часы обучения и, возможно, работать в паре с другими. Они могут привлечь новые команды для будущих тренерских блоков.

Наблюдаемые результаты

После одного тренировочного блока продолжительностью 10 полудневных дней я заметил, что большинство команд научились работать в ансамбле до такой степени, что они могут делать это без тренера. Это само по себе является отличным навыком для команды – продвигаясь вперед, они могут решить, когда будет полезно использовать эту технику сотрудничества. Я слышал о командах, которые впоследствии решили объединиться при больших изменениях дизайна и при приеме на работу новых членов команды. Некоторые даже принимают это как регулярную часть своей повседневной работы.

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

  • С большей вероятностью напишет модульные тесты
  • Больше шансов улучшить дизайн и безопасно провести рефакторинг
  • С большей вероятностью разработает удобочитаемые и удобные в обслуживании тестовые примеры
  • С большей вероятностью будет работать небольшими приращениями, чаще фиксируя код
  • Улучшенная командная работа, лучшее сотрудничество

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

Сэмман тренирует вас?

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

об авторе

Эмили Бач имеет более чем 20-летний опыт работы в качестве разработчика программного обеспечения и технического тренера, работая в различных организациях, от небольших стартапов до крупных предприятий. Она известный автор и докладчик по темам, связанным с автоматическим тестированием и техническим коучингом. У нее есть веб-сайт с материалами для технических тренеров.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button