Мотивация

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

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

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

Обычные способы

Обычно при приходе в новую компанию люди получают массу документации и встреч, описывающих желаемые процессы и способы работы.

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

Проблемы с обычными способами

Когда документация раздается, она часто устаревает, не читается полностью или процессы проживаются не так, как описано.

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

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

Отзывы — отличный способ узнать что-то от других сотрудников компании. Проблема с обзорами заключается в том, что разработчик получает отзыв только после того, как определенная функция завершена.
На этом этапе изменения дизайна уже применяются, и в большинстве случаев потребуется много времени, чтобы повторить их, если они не подходят. Из-за этой двойной работы код часто сохраняется как есть во время проверки кода (см. ошибка необратимых затрат) и оставляются только комментарии на будущее, наименования символов в коде или советы по синтаксическому сахару, если код работает.

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

Решение проблемы

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

Подходы совместного создания используются не только в разработке программного обеспечения. Их также можно применять в других областях, таких как UI/UX дизайн.

Почему этот подход так выгоден? — Подходы совместного творчества не только двунаправленно передают знания. Они также являются социальным упражнением для повышения командного духа и (особенно для новичков) подтверждения того, что персонаж абсолютно подходит для команды.

Разве это не требует вдвое больше времени, чем позволить людям работать в одиночку? - НЕТ! Согласно этому исследованию Университета Юты, подход парного программирования занимает примерно на 15 % больше времени, но также приводит к видимому повышению качества результата.
Такое повышение качества (в программном обеспечении) инженерии) поддерживают теорию быстрого продвижения за счет хороших результатов и приводят к более стабильной скорости разработки в долгосрочной перспективе.

Практический пример

Возвращаясь к первоначальной постановке задачи обеспечения наилучшей передачи знаний новичкам в команде (и/или компании):

Новичок может получить фиксированного «наставника» на определенный период (в зависимости от его стажа).
Этот наставник должен быть доступным для новичка и посвящать большую часть своего времени поддержке передачи общих знаний и руководству совместной работой. - творческий процесс.

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

После первой фазы входа, когда наставник чувствует, что новичок «прибыл» в команду, интенсивное наставничество должно быть уменьшено, чтобы оставить место для дыхания.

Прагматичный подход

Мы не стремимся к 100%-ному парному программированию, когда кто-то интегрирован в команду.
Наставник, технический руководитель или даже вся команда (например, на совещании по планированию) должны решить, какие задачи должны быть парными, а какие - сольной работой.

Я рекомендую всегда объединяться для новых функций, концептуальной работы или рефакторинга. — Для всех людей, а не только для новичков в команде.
Так можно обсуждать идеи при создании, быстро интегрировать изменения (в этих случаях не потребуется код-ревью) и исключить дублирование работы .

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

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

Достижения

С помощью этого подхода мы достигаем нескольких целей (также для разных вовлеченных лиц):

  1. Новичок максимально тесно взаимодействует с командой, накапливает знания, знакомится со здравым смыслом (а может быть, и с некоторыми подводными камнями), знакомится с командой и системой, с которой работает команда
  2. На начальном этапе наставничества новичок должен получить навыки, чтобы также стать наставником и направлять следующего человека, присоединяющегося к команде.
  3. Наставник проверяет документацию по установке и совершенствует наставничество других
  4. Команда может проверить альтернативные подходы, возникающие в ходе обсуждений с новичком, и при необходимости изучить/улучшить

Также важно: процесс сотворчества — это дополнительная методология. Он не заменяет существующие соглашения, такие как документирование системы.
Это может улучшить эти вещи, потому что несколько человек могут просматривать его одновременно.

Заключение

Совместная творческая работа, такая как парное программирование, — чрезвычайно мощная методология для обеспечения эффективной и интерактивной адаптации людей (особенно разработчиков в этом примере) любого уровня квалификации.

Преимущества парного программирования выходят далеко за рамки этого. К ним относятся обучение, инновации, меньшее количество ошибок, качественный код, продуктивность, устойчивость бизнеса и хорошие отношения в команде (при условии, что все сделано хорошо).

— Дэйв Фарли

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

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

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