Первый из серии вопросов и ответов с идейным вдохновителем непрерывной доставки Дэйвом Фарли

В духе одной из наших основных ценностей, #AlwaysBeLearning, MarketInvoice объединился с идейным лидером в области непрерывной доставки Дэйвом Фарли (Dave Farley) в серии технических блогов. Наши инженеры задали Дейву несколько животрепещущих вопросов обо всем, от парного программирования и разработки на основе магистралей до непрерывной доставки и многого другого. На этой неделе вопрос поступил от старшего инженера-программиста Mason L’Amy:

«Показано, что парное программирование повышает качество и сокращает общее время разработки. Тем не менее, некоторым людям нужно время, сосредоточенное на проблеме. Как вы сбалансируете это?»

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

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

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

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

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

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

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

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

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

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

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

Поэтому, когда вы создаете пары, а не печатаете, дайте людям возможность заметить и исправить свои собственные ошибки. Упоминайте об опечатке только тогда, когда машинистка продвинулась дальше и явно пропустила ее. Упоминайте правильное использование языковой конструкции или вызова API только в том случае, если машинистка явно застряла. В противном случае МОЛЧИТЕ!

Классическое описание ролей в парном программировании — «Водитель» (человек, который печатает) и «Навигатор» (человек, который не печатает). Это немного грубо, но близко. Если вы не печатаете, ваше внимание должно быть сосредоточено на направлении дизайна, а не на наборе текста.

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

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

Работа в паре означает, что вы работаете в непосредственной близости от других людей. Думайте о своей паре как о команде, у вас общие цели, и вместе вы добьетесь успеха или потерпите неудачу. Будьте внимательны, общайтесь, будьте добры!

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

Дэйв Фарли – идейный лидер в области непрерывной доставки, devops и разработки программного обеспечения в целом. Он является соавтором отмеченной наградой Jolt книги Непрерывная доставка, а также постоянным докладчиком на конференциях и блоггером. Дэйв, один из первых внедривший методы гибкой разработки, применяет итеративную разработку, непрерывную интеграцию и значительные уровни автоматизированного тестирования в коммерческих проектах с начала 1990-х годов. Сегодня он является основателем и управляющим директором компании Continuous Delivery Ltd, где работает независимым консультантом по программному обеспечению.

Первоначально опубликовано на сайте blog.marketinvoice.com 27 ноября 2018 г.