Для меня парное программирование - одно из самых увлекательных занятий программиста. Кроме того, это не просто развлечение, это отличный инструмент для обмена знаниями и создания команды. И на самом деле это действительно повышает продуктивность, в отличие от того, во что многие ошибочно полагают. Но, к сожалению, так много людей ненавидят это, а также так много компаний даже активно препятствуют этому или чувствуют себя некомфортно из-за этого.
Есть много моментов, которые люди часто используют для нападок на практиков парного программирования. Я просто упомяну два из них, прежде чем мы перейдем к антипаттернам.
1) Даже если доказано, что парное программирование позволяет значительно снизить затраты; лицензии на программное обеспечение, оборудование, обучение и создание команды среди прочего. Тем не менее, многие компании считают это «пустой тратой человеческих ресурсов». Я медитировал и думал об этом несколько раз в течение своей карьеры, и я пришел к выводу, что основная мотивация, когда эта причина приводится, часто происходит из-за огромного страха перед сбоями и изменениями.
2) Еще одна вещь, которую часто можно услышать, - это аргумент «это не для всех». Они говорят, что некоторые люди более замкнуты, чем другие, или иногда требуется время, чтобы думать с большей ясностью и решить проблему.
Мое мнение по этому поводу состоит в том, что в отрасли существует огромное количество людей, обладающих техническими навыками, но неспособных эффективно общаться и высказывать свои соображения или ход мыслей. Люди, которым не хватает социальных навыков и страха или которые чувствуют себя крайне некомфортно при социальном взаимодействии.
Так что да, команды по персоналу и найму (особенно агентства) во многих случаях просто стремятся к «лучшим» технически квалифицированным специалистам, но полностью игнорируют аспекты коммуникации и социальных навыков, которые требуются для работы в команде. К сожалению, это называется парным программированием, но если бы это называлось Парным решением проблем, это указывало бы на то, что это не только технические навыки, которые необходимы.
Это не единственные аргументы, которые вы услышите против парного программирования, существует множество других. Я бы с радостью обсудил их все, но я хочу перейти к антипаттернам, потому что понимание их и размышление над ними, я думаю, может помочь понять, что это за блокаторы для успешной реализации парного программирования.
Это не сложная техника для применения на практике, но чтобы извлечь из нее максимальную пользу, мы должны быть осторожны, как мы подходим к ней, как выглядит наша установка и как другие вокруг нас поддерживают усилия по переходу к ней. Нередко бывает, что команда иногда пробует парное программирование впервые, но они подходят к нему с неправильной точки зрения и, к сожалению, в конечном итоге ненавидят его или, по крайней мере, формируют неправильное впечатление о нем.
Надеюсь, понимание некоторых из этих антипаттеров может помочь команде избежать травмирующего опыта при попытке перейти к парному программированию и, вероятно, избежать формирования неправильных мнений, таких как те, которые я упоминал ранее.
Факторы, которые могут влиять на парное программирование
Эффективное парное программирование зависит от многих факторов. В зависимости от этих факторов, некоторые из них:
- технический (он же практический): это вещи на низком уровне при соединении. Вещи, которые касаются вас и вашей пары. То, как вы взаимодействуете друг с другом и как вы приспосабливаетесь друг к другу.
- окружающая среда: факторы, связанные с вашим непосредственным окружением, которые могут помешать вашему объединению.
- организационные: факторы, имеющие отношение к вашей компании, и ее взгляды на Agile или определенные аспекты создания пары, которые сознательно или неосознанно создают трудности для реализации пары.
- Психологические: набор факторов, а также обычно мысли или состояния ума, которые действуют как силы, которые могут повлиять на качество опыта пары.
Так что, не колеблясь, давайте взглянем на антипаттерны.
Мыслители-одиночки.
Если кто-то из членов пары говорит «Дайте мне время подумать, и я вернусь к вам», мы уже не в пара. Коллективно мы проблему не решаем.
Это просто означает, что пара не знакома с навыками и методами коллективного решения проблем. Да, они распадутся, и каждый из них «индивидуально» предложит какое-нибудь жизнеспособное решение, которое затем будет обсуждаться и т. Д. Но это не командная работа. Проблема не была решена коллективно.
Решение:
Практикуйте навыки парного / коллективного анализа и / или парного / коллективного решения проблем, чтобы помочь паре преодолеть препятствия как паре и улучшить парное / коллективное обучение.
Ностальгия по столу
У настоящих парных программистов нет «своего стола», они оба сидят за одним столом. Будет две мыши, две клавиатуры и, возможно, два экрана, но один процессор.
Если есть два процессора, то это больше не парное программирование, и риск разрыва пары выше. Конечно, у удаленных парных программистов будет свой ЦП, и они будут использовать технологию совместного использования экрана для управления автомобилем и навигации, но это потребует от них дисциплины, чтобы избежать отклонений и отклонений.
Решение.
Прекратите покупать столько оборудования, программного обеспечения и рабочих столов. Если команда распределена, приобретите хорошее программное обеспечение для совместного использования экрана, которое позволяет двум программистам рисовать, выделять и т. Д.
Бестолковый навигатор
Навигатор находится в позиции наблюдателя, а водитель печатает. Он / она просматривает код на ходу, дает указания и делится мыслями.
Навигатор также отслеживает более серьезные проблемы, ошибки и отмечает возможные следующие шаги или препятствия.
Идея этого разделения ролей состоит в том, чтобы иметь два разных взгляда на код. Мышление водителя должно быть более тактическим, он должен думать о деталях, строках кода. В своей роли наблюдателя штурман может мыслить более стратегически и иметь в виду общую картину. Навигатор также проверяет код на ходу, чтобы убедиться, что он соответствует договоренностям команды, дает указания, делает заметки, предупреждает о потенциальных проблемах и делится мыслями.
Итак, как вы видите, навигатор должен быть опытным и знаком с системой и поэтому в парном программировании рекомендуется, чтобы, когда кто-то новичок в команде, этот человек занимал место водителя, а не штурмана.
«Бестолковые навигаторы» могут легко возникнуть, когда новый участник сажается на место штурмана или когда два новых участника сидят вместе. Штурман не сможет направить водителя к важным местам из-за отсутствия опыта. Если за рулем ездит опытный участник, то неопытный навигатор просто сидит и говорит «ага», «хм», «хорошо». И если эти двое были неопытными новичками, вероятно, это закончится каким-то неудавшимся совместным исследованием с вероятным частым прерыванием других членов команды.
К сожалению, во многих компаниях «лучшие старшие» разработчики часто
заняты, и у них нет времени заниматься такими вещами, как парное программирование, до тех пор, пока не пройдет «период занятости» (но этого никогда не происходит), поэтому они просто собирают новых неопытных сотрудников, чтобы прикинуть. дела обстоят не так, но на самом деле это приводит к увеличению количества перебоев в работе из-за частых перебоев.
Решение:
Убедитесь, что в парном программировании принимают участие наиболее опытные люди, и не позволяйте менее опытным членам команды быть навигаторами, пока они не почувствуют себя достаточно уверенно. Это зависит от разных факторов, но часто
новый участник должен быть готов попробовать первую попытку навигации после внедрения трех или четырех историй.
Нарциссический процесс
Иногда, когда некоторые люди, только начинающие заниматься парным программированием, испытывают чувство, что их осуждают. Когда навигатор указывает на нового водителя то здесь, то там, он начинает говорить что-то вроде: «Я знаю это», «Я этого не писал», «Это уже было так», «Кто-то другой сделал это» и т. Д. Чувство осуждения не является чем-то необычным для начинающих парных программистов. Это то, что со временем просто исчезает, поскольку команда становится все больше и больше, и у всех развивается коллективное чувство ответственности и сопричастности. Но иногда некоторые используемые процессы и инструменты способствуют развитию эгоистичного / эгоистичного отношения к развитию, что затрудняет реализацию парного программирования. Это мелкие детали, которые часто остаются незамеченными. Например, язык, используемый во время фуршетных встреч, не должен намекать или вызывать ощущение, что что-то произошло по чьей-то вине, или позицию «бросать через стену». Эти мелочи противоречат гибким принципам совместной собственности и совместной ответственности. Хотя можно критиковать чью-то работу, которую нужно выполнять лучше, подчеркивание того, что что-то является чьей-то ошибкой, а не ошибкой команды, может быть вредным, когда мы пытаемся внедрить парное программирование, поскольку постоянно новые члены команды будут заполняться либо осужденными, либо нерешительными.
Также некоторые из инструментов, которые мы используем, такие как JIRA, иногда ограничивают нас, потому что, если не включены определенные функции, совместное владение задачами невозможно. В большинстве компаний против каждой задачи, отображаемой на доске, всегда сталкивается один человек. Деловые люди любят спрашивать, «кому это принадлежит»? И они ожидают, что ответом будет чье-то имя, а не команда.
Как вы видите, парное программирование - это коллективное усилие, но если пока мы пытаемся создать это коллективное усилие, окружающая среда и инструменты не должны побуждать нас быть индивидуалистами. Подводя итог, можно сказать, что антипаттерн нарциссического процесса так или иначе охватывает в программном процессе все, что противоречит принципам совместного владения и совместной ответственности.
Решение
Используйте ретроспективы, чтобы обсудить концепции Agile и, в частности, значение долевого владения и совместной ответственности на каждом этапе от идеи до продукта, который находится в руках пользователя.
Потение
В офисах с большими открытыми пространствами часто возникают разговоры о кондиционерах и / или системах отопления. Люди продолжают жаловаться на это: «слишком жарко», «слишком холодно» и т. Д.
Но если вы работаете в паре и у вас нет проблем с нагревом, и вы часто потеете, то, вероятно, вы сидите слишком близко друг к другу или даже касаетесь стульев. Может быть, ваша пара время от времени будет говорить вам: «Пожалуйста, не могли бы вы немного подойти».
Решение
Скажите своему менеджеру или руководителю группы, чтобы он купил вторую клавиатуру, мышь и монитор, чтобы вам не приходилось сидеть так близко к своей паре, чтобы вы касались стульев. Если проблема не исчезнет, обратитесь к врачу.
Домино для отвлечения внимания
Одним из преимуществ парного программирования является то, что работа над одной конкретной задачей никогда не прекращается. Пара, которая по какой-то причине прервана, скажем, кто-то приходит спросить что-то, или личный телефонный звонок и т. Д., Не нуждается в остановке, достаточно, если один из членов команды урегулирует временную ситуацию. Домино с отвлечением - это ситуация, в которой внимание обоих участников пары привлекается внешним фактором.
Решение
Если вы навигатор, и кто-то приходит и может прервать его, защитите водителя, ответив на вопрос. Если звонит телефон водителя и звонок действительно важен, навигатор должен временно взять на себя управление, пока водитель отвечает на звонок.
Нет командного диджея
Еще одна причина, по которой многие люди ненавидят парное программирование, заключается в том, что они не могут слушать музыку, пока пишут код. Если команда хочет слушать музыку, она должна уметь это делать. Парное программирование разрешает музыку, но не позволяет использовать наушники. Конечно, команде нужно составить подходящий игровой список, с которым все согласятся во время ретроспективы. Если команда находится на большом открытом пространстве, помните об окрестностях и близлежащих командах, всегда спрашивайте команду / группы поблизости. Но лучше всего, когда у команды есть вся комната для себя, или пространство достаточно велико, чтобы музыка на низкой громкости не мешала соседним командам.
Решение
Во время встречи в стиле ретро или команды договоритесь о жанре музыки, которую команда тоже хотела бы послушать. Также договоритесь о музыкальном времени, которым все довольны. Также переместите рабочие столы подальше, если считаете, что это необходимо и возможно.
Поговорите с находящимися поблизости командами о включении музыки и проверьте громкость, спросив, беспокоит ли их это.
Боязнь вождения
Это очень распространено среди новых практикующих. Оказавшись на водительском месте, некоторые смущаются и боятся, что им делать, что сказать. Это все совершенно нормально, важно то, что обмениваются вопросами и мыслями, а не сидят молча и ждут инструкций. Избавьтесь от страха перед поездкой, купите связь с навигатором. Научитесь понимать его манеру речи и темп. Продолжайте задавать вопросы и не торопитесь, чтобы выполнять действия и оценивать обратную связь.
Иногда страх за рулем может привести к тому, что «сделай это, пожалуйста», и хотя это нормально, может быть, вначале, этого не следует поощрять. Навигатор должен уметь выполнять свою роль, не касаясь клавиатуры, а, нажимая клавиши, водитель должен постепенно усваивать знания. Если вы боитесь за рулем, постарайтесь избегать «сделай это, пожалуйста», вместо этого просто подумайте, подумайте, остановитесь, если вам нужно, подумайте над сформулированным вопросом и при необходимости переформулируйте его. Штурман должен быть терпеливым и понимающим.
Парное программирование - очень мощный инструмент обучения, но чтобы использовать его в максимальной степени, необходимо правильное отношение как водителя, так и навигатора. Также важно отношение компании. Как я уже упоминал, многие компании считают, что время на обучение - пустая трата времени. Да, это правда, что доставка важна, но создание сильной и способной команды, вероятно, еще важнее. Эти компании не понимают, что, если их «лучшие» «попадут под автобус», у их бизнеса могут возникнуть серьезные проблемы. Парное программирование может легко снизить этот риск.
Решение
Это просто требует времени, но помните, что лучший рецепт избавления от страха - это общение. Разговаривайте с навигатором, общайтесь, задавайте вопросы и вместе узнавайте, какой темп подходит вам. Также помните, что водитель не должен поддаваться соблазну сказать: «Вы можете сделать это, пожалуйста?».
Бросившие дорогу
Рано или поздно пара попадет на какой-нибудь блокпост или их колеса застрянут в грязи. Когда это происходит, важно помнить о нескольких вещах, которые могут помочь разрешить ситуацию в паре.
Сначала замедлите темп или даже остановитесь и спросите себя, не чувствуем ли мы себя застрявшим?
Если ответ положительный, то просмотрите, какие были последние несколько шагов и почему. Сформулируйте вопросы и поделитесь мыслями о происходящем.
Иногда блокировщики очень технические, например, трассировка стека, которая на первый взгляд не имеет смысла, или, возможно, неожиданный ответ от зависимой системы и т. Д. В этой ситуации важно, чтобы пара продолжала общаться. На вопрос, возможно, не будет ответа, но он может привести к гипотезе, и ее проверка с помощью экспериментов может дать ответ. Следует не поощрять уход в смысле разделения, чтобы подумать, а затем вернуться. Пара должна добраться до точки, в которой не будет чувствовать дискомфорт из-за присутствия «другого». Постепенно и со временем поймете, что «незнание» чего-то совершенно нормально.
При столкновении с препятствием, на мой взгляд, возникают такие мысли, как «что другие подумают обо мне?» или «достаточно ли я хорош?» в большинстве случаев приведет к следующему шагу или мысли (инстинктивно), а именно: «Я не чувствую себя комфортно, я хочу бросить!».
Сдержанный образ мышления - это огромный антипаттерн, который много повторяется и в конечном итоге разрушает опыт и практику пары.
Новой паре или команде, пытающейся впервые заняться парным программированием, достаточно столкнуться с этой ситуацией один или два раза, чтобы начать сомневаться в таких вещах, как : «Собираюсь ли я отделиться от своей пары, чтобы все равно решить проблему. , тогда почему я вообще спариваюсь ?. Я мог бы сделать это сам ».
Почему мы объединяемся в пары, если нам придется разделиться? Это огромная ошибка, которую мы слышим снова и снова в компаниях, на интервью, встречах и т. Д. «Если нам нужно подумать, мы отступаем, а затем возвращаемся».
Неправильный!!!
Решение
Не бросайте и не бросайте свою пару. Оставайтесь со своей парой, несмотря ни на что. Если что-то в нем / ней вас раздражает или доставляет дискомфорт, любезно спросите. Например, если человек говорит слишком быстро, а вы теряетесь в том, что он говорит, попросите его говорить медленнее. Спаривание служит упражнением для построения команды. Так что расщепление из-за того, что некоторые люди не чувствуют себя комфортно или по собственной воле приведет к лучшему решению, нехорошо. Это просто показывает, что у команды есть какой-то шов. Чтобы залатать эти швы, мы используем общение и сотрудничество. Парное программирование - инструмент, который нам в этом поможет.
Еще одна интересная вещь, которую некоторые команды делают, чтобы улучшить внедрение парного программирования, - это после сеанса или пары сеансов они проводят опрос, задавая вопросы о своих чувствах, а затем делятся друг с другом. Это отличный способ узнать о другом человеке и, вероятно, лучше провести сеанс в следующий раз.
Я создаю пару, но я все еще глуп
« Разве парное программирование не могло помочь нам в обмене знаниями? Но послушайте, Питер по-прежнему ничего не знает о микросервисе XYZ, и он здесь уже 6 месяцев ».
К сожалению, большинство компаний заинтересованы или сосредотачиваются на работе отдельного человека, а не на работе команды. Во многих компаниях ведется постоянный поиск ответственного лица. Все тяготеет к личности.
В то время как бедный Питер сделал все, что в его силах, его в конечном итоге судят и оценивают производительность на основе небольшого спора, который у него в последние пару недель возник по поводу какого-то принципа кодирования, или из-за того, что он не знает, как решить какой-то крайний случай в каком-то непонятном микросервисе, который был просто коснитесь один или два раза за последние 3 года.
Дело в том, что парное программирование поможет получить знания быстрее, но знания - это распределенные знания. Некоторые из этих знаний живут в моей голове, другие - в вашей. Со временем они постепенно передаются, но даже если не все знания полностью передаются на 100% каждому члену команды, это не имеет большого значения, потому что непрерывное объединение в пары передаст достаточно знаний достаточному количеству руководителей, так что команда и пары в команде будет иметь достаточно распределенных знаний для решения проблемы или выполнения задачи.
Решение
Прекратите выносить суждения. Всегда думайте, что все мы работаем изо всех сил, и не критикуем других за то, что они знают или не знают. Думайте как команда и замените «я есть» на «мы».
Поймите, что знания всегда будут в большей или меньшей степени распространяться. Продолжайте делать ретроспективы и чередовать пары и типы задач, которые они выполняют. Иногда ошибка, иногда всплеск, иногда история и т. Д.
Каждые несколько месяцев 3 или 6 собираются для оценки ситуации в команде в отношении передачи знаний. Но не сосредотачивайтесь только на том, что мы знаем о XYZ или ABC, задавайте себе вопрос, насколько устойчива команда? Что произойдет, если один человек исчезнет? Как будет выглядеть соединение? Сможем ли мы побеждать блокирующих и т. Д. Пары идут хорошо, и постепенно команда должна чувствовать себя все более уверенно, когда дело касается знаний.
Каннибализация
Трудно создать команду, если время от времени приходят каннибалы и забирают некоторых из ваших коллег и переводят их в другие команды. Это огромная управленческая ошибка, которая наносит большой урон командам и компаниям. Этот антипаттерн встречается в таком количестве вкусов, что его практически невозможно обнаружить.
Некоторые примеры каннибалов:
- Какой-то менеджер, руководитель группы или кто-то другой говорит что-то вроде: «наша команда работает отлично, технический директор поздравил нас и сказал, что для распространения некоторых из наших передовых практик мы переведем человека xxx в другую команду, которая нуждается в помощь ».
- Один очень важный человек в компании говорит: «Совершенно новый продукт должен появиться на рынке до Рождества. Нам нужно собрать команду, но HR потребуется больше времени, чем у нас сейчас. Итак, мы уже ведем переговоры (конечно, секретно) с некоторыми из вас, кто присоединится к этой команде ».
- Другой продукт-владелец приходит и говорит нам: «Мы хотели бы временно одолжить одного из вас».
Понимаете? Вышеуказанные - лишь некоторые из многих ингредиентов, которые можно использовать в рецептах стихийных бедствий.
Хорошие команды, использующие парное программирование, обладают определенной степенью устойчивости и терпимости к тому факту, что один член команды в какой-то момент уйдет, что внезапно неожиданно присоединится группа новых людей или что может произойти что-то неожиданное. Парное программирование, конечно, поможет смягчить и свести к минимуму множество нарушений, которые могут вызвать такие события. Но парное программирование - не серебряная пуля: если у вас неправильная управленческая культура компании, и эти события не происходят в управляемом, спланированном и заранее согласованном темпе, который может выдержать команда, наверняка будут негативные последствия.
Решение
Защищайте команду независимо от того, кто такой каннибал. Скажите им : «Нет, мы сожалеем, что нам потребовался долгий путь, чтобы добраться туда, где мы находимся». Если они будут настаивать, скажите им, что их действия нанесут вред компании. Если им все равно, и они это делают, повысьте осведомленность и сообщите другим командам о том, как каннибализация нанесла ущерб хорошо работающей команде.
К сожалению, в крупных компаниях нередки случаи каннибализации команд. Остановить и предотвратить это бывает очень сложно. То, что начинается незаметно как практика, в конечном итоге становится плохой управленческой привычкой, которая серьезно вредит компании.
Сделайте все возможное, чтобы дать отпор любыми средствами, которые у вас есть.
Быстрое вождение
В парном программировании нет ограничения скорости, вы можете печатать как можно быстрее. Вы можете открывать и закрывать окна и терминалы браузера и перетаскивать вещи туда и сюда со скоростью света. Все это прекрасно. Пока ваша пара может следовать за вами. И водитель, и навигатор должны понимать, что происходит. Если кто-то просто пошел слишком быстро, а другой ничего не понял, нужно притормозить.
Решение
Навигатор должен сказать водителю, чтобы он снизил скорость, если он не может следовать за ним из-за очень быстрой езды.
Глухой водитель
Если навигатор что-то говорит, а водитель полностью игнорирует это и идет по касательной, навигатор должен остановить водителя и спросить его, что он делает. О том, что делается, нужно постоянно сообщать и рационализировать. Водитель, не желающий слушать навигатора, демонстрирует отсутствие дисциплины.
Решение
Водитель и навигатор должны эффективно общаться и договариваться о том, что будет дальше. Если водитель хочет притвориться глухим и все время повторяет: «Секундочку», «Минутку, дай мне что-нибудь проверить» и т. Д.…
Такая ситуация довольно часто встречается у людей, которые плохо знакомы с парным программированием. Если навигатор чувствует, что его не слышат, он должен озвучить это, иначе соединение со временем, если такая ситуация происходит слишком часто, станет неэффективным.
Слишком много теней
Техника затенения - это техника, при которой одна из пар одновременно движется и перемещается (делает все), а другая наблюдает. Хотя более опытный член команды может объяснять что-то новому участнику, используя технику затенения, если это делать все время, это будет иметь отрицательный обратный эффект.
Обучение происходит на практике, и важно, чтобы объем затенения сводился к минимуму только в случае крайней необходимости. Если кто-то новый или менее опытный просто сидит и смотрит на экран, это не научит его / ее так, как если бы он / она сидели на сиденье водителя.
Это также очень частая неправильная практика и часто происходит из-за того, что разработчик с большим опытом торопится, потому что хочет выполнить цели спринта или у него нет времени.
Решение
Водитель должен вести машину, а навигатор - ориентироваться. Сведите к минимуму затенение или даже постарайтесь его избежать. Если вы обнаружите, что слишком полагаетесь на слежку, спросите себя, почему это так. Если необходимо, сделайте ставку в ретроспективе, что, по вашему мнению, объединение в пары неэффективно, поскольку мы всегда в спешке, и вам не нужно много водить.
Бесшумный водитель
Иногда в начале сопряжения некоторые думают, что разговаривать нужно только навигатору. Это не так. Водитель тоже должен говорить, а не молчать, ожидая каких-то инструкций. Водитель, скорее всего, будет меньше говорить, но не должен молчать. Важно передать мыслительный процесс и текущее действие, происходящее на экране. Драйвер должен сказать что-то вроде «хорошо, теперь я собираюсь проверить базу данных», «это значение, которое я вижу в отладчике» и т. Д. Если вы видите, что навигатор очень часто говорит «а что вы делаете? сейчас? », это может означать, что водитель слишком молчит.
Решение
Попросите водителя рассказать и изложить свои действия и мысли, даже если это просто повторение того, что только что сказал навигатор. Даже если в этом нет необходимости, формулировка мыслей и действий является хорошей обратной связью для навигатора, говорящего о том, что он идет правильным курсом, делая то, что согласовано.
Представьте себе операционную в больнице. Опытный старый врач дает инструкции молодому хирургу, как сделать обходное сердце. Общение обеих сторон чрезвычайно важно, даже если это повторение.
Блиц-навигация
Говорят, если вы пьете, не садитесь за руль, но и не нужно ориентироваться. Если навигатор по какой-либо причине не может общаться со скоростью, которую водитель может понять и рассуждать, то соединение не будет эффективным. Если водитель думает, что навигатор быстро объясняет что-то или слишком быстро перескакивает с одной темы на другую, необходимо сказать навигатору такие вещи, как: «пожалуйста, вы можете повторить это?», «Я не понимаю, что вы имеете в виду. ты можешь мне еще раз объяснить? ». Нередко можно увидеть, как навигаторы разочаровываются из-за того, что водители не действуют так быстро, как ожидают. Это опасно, потому что может привести к появлению вредных привычек, например, к частому переходу навигатора. Если навигатор едет слишком быстро, разочаровывается, а затем берет на себя управление, это случай Blitz-навигации. Иногда это происходит намеренно, и это отличный способ испортить опыт совместной работы. Заставляет водителя чувствовать себя бесполезным из-за того, что он не может делать что-то быстро и не учится, так как теперь водитель просто сидит сзади и находится в тени.
Решение
Опять же, этого можно избежать с помощью эффективного общения, но также и терпеливого отношения. Темп или скорость должны быть удобными для обоих. Возможно, водитель чего-то не понимает и имеет пробелы в знаниях, а может, просто не спал достаточно часов. Штурману следует запастись терпением.
Не будь ботаником
Хотя иногда интересно и полезно цитировать некоторые вещи из какой-то книги или что-то, что однажды сказал какой-то герой Java. Чрезвычайно важно сдерживать эго. Не нужно выпендриваться или вести себя как ботаник. Если то, что вы говорите, по вашему мнению, положительно повлияет на сеанс спаривания, скажите это, но если вы просто делаете это для собственного эго, тогда избегайте этого. Сессия спаривания включает в себя много разговоров, но не является теоретической лекцией по философии программного обеспечения. Не поймите меня неправильно, можно говорить о теориях, принципах, передовом опыте, статьях и т. Д. Но постарайтесь осознавать себя, если вы слишком сильно отклоняетесь от текущей цели. Также прислушивайтесь к отзывам во время разговора и спрашивайте, можно ли отвлечься на определенную тему, потому что вы считаете это необходимым.
Решение
Осознавайте, что вы говорите, и если это по теме, или вы отвлекаетесь на что-то не относящееся к делу. Иногда можно отвлечься, но спросите своего коллегу, принесет ли этот разговор пользу во время сеанса спаривания. Также держите эго в страхе и не упускайте ни слова по теме, которая не имеет отношения к делу или не по теме.
Не проверять зеркало
Первое, что нам нужно сделать перед тем, как начать движение, - это проверить свои зеркала. Когда мы занимаемся парным программированием, нам нужно делать то же самое. В паре, в зависимости от того, какой у нас экран, нам нужно решить, хотим ли мы использовать зеркальный монитор или мы хотим придерживаться разделенного представления. Некоторые люди предпочитают всегда смотреть прямо, это помогает им не только в осанке, но и в мышлении. Очевидно, некоторые из нас не могут думать так же, если повернуть голову набок.
Решение
Попробуйте использовать для сопряжения подход с зеркальным отображением и посмотрите, как вам это понравится. Поговорите со своей парой о том, какой тип дисплея вы предпочитаете, поиграйте с различными вариантами и понаблюдайте, как каждый из них влияет на ваш опыт работы в паре. Выберите то, что вам удобнее.
Шепот
При объединении в пары нет необходимости кричать или слишком громко говорить, но чего не должно происходить, так это то, что ваша пара не должна время от времени говорить вам: «Извините, я могу я тебя не слышу, ты можешь повторить? ». Если это происходит слишком часто, либо у кого-то проблемы со слухом, либо кто-то говорит слишком громко. Также может быть много фонового шума. Решение может отличаться, но важно также определить точную первопричину.
Решение
Если на открытом пространстве много фонового шума, который мешает вам слышать вашу пару. Вы должны обсудить этот вопрос со своим руководителем, и этот вопрос следует решить, например, поставив знак, переставив столы или установив какое-то время тишины, если ни один из предыдущих вариантов невозможен.
Если вы чувствуете, что не слышите, что говорит ваша пара, потому что вам кажется, что она шепчет, посоветуйтесь с третьим членом команды и спросите, чувствуют ли они, что этот человек тоже шепчет. В этом случае попросите человека говорить немного громче, чтобы вы все могли лучше слышать. Но если это не так, рассмотрите возможность наблюдения за этой проблемой и, возможно, попросите врача сделать вам аудиометрический тест, чтобы оценить, нужен ли вам какой-либо слуховой аппарат.
Бормотание
Как и шепот, бормотание также может вызвать некоторые трудности при объединении в пары. Некоторые из нас довольно экстраверты и склонны думать вслух, но когда мысли еще не полностью сформированы, кажется, что мы говорим полпредложения или бормочем. Это заставляет нас выглядеть сомневающимися или сбитыми с толку. Важно поднять этот вопрос или постараться об этом знать.
Решение
Если наша пара говорит нам, что мы бормочем, нам нужно попытаться объяснить им, что мы часто говорим вслух, когда думаем, и что иногда мы склонны немного бормотать, или, может быть, мы может попытаться тренировать нашу осведомленность об этом, чтобы попытаться держать это под контролем. Интересный практический подход - когда когда-либо мы чувствуем искушение сказать что-то, но мыслительный процесс еще не завершен, попробуйте вместо того, чтобы сказать это вслух, записать это. Иногда бормотание является признаком импульсивного характера, но в большинстве случаев при объединении в пары оно исправляется само по себе после нескольких сеансов.
Наушники
Сопряжение с наушниками выглядит глупо, и да, это, вероятно, одна из самых глупых антипаттернов, с которыми вы можете столкнуться. Это немного экстремально, но, не поверите, есть такие случаи. Да, могут быть случаи, когда люди настолько невнимательны и эгоистичны, что даже если кто-то пытается даже не создавать пары, а просто тенью, чтобы увидеть, могут ли они что-то понять, они не снимают наушники. Единственный способ взаимодействовать с ними - это похлопать их по плечу, но даже тогда им это может не понравиться, и они почувствуют, что их личное пространство вторгается.
Но подождите секунду, есть один способ, которым можно использовать наушники для сопряжения. Вы можете догадаться? Точнее, чтобы поговорить друг с другом, если много фонового шума. Важно, чтобы в наушниках была функция шумоподавления и микрофон. На самом деле это довольно круто, если вы используете его рядом с зеркальным экраном, соединение довольно захватывающее.
Конечно, это просто полезный совет, если вы оказались в загруженном офисе, но если вам комфортно подключаться удаленно, не выходя из собственного дома, у вас вообще нет таких проблем.
Решение
Если случилось так, что вы встретите эгоистичного человека, который не может беспокоиться, чтобы объяснять или взаимодействовать с вами, и вы чувствуете, что просто сидите на заднем сиденье, не учась и не участвуя, то скажите ему что вы хотели бы больше общаться и чувствуете, что неуместно носить наушники во время сеанса сопряжения или слежки. Если им все равно, просто уйдите и поговорите об этом со своим менеджером. Для некоторых читателей это, вероятно, очевидно, но, возможно, некоторые из читателей новички в отрасли, и я думаю, им следует знать, что такое поведение неприемлемо.
Если в офисе очень шумно и вы чувствуете, что еда негативно влияет на вашу пару. Подумайте о том, чтобы сделать предложение своей паре, используя наушники и общаясь с помощью голосового вызова, сидя рядом друг с другом. Надеюсь, вы сможете купить пару действительно дорогих гарнитур с лучшими характеристиками за счет своей компании.
Несинхронизированные повестки дня
Представьте, что разработчик работает над функцией, но внезапно его вызывают для решения действительно срочной проблемы. Парное программирование дает команде определенную степень устойчивости, так что работа может быть продолжена, даже если один из участников выйдет из строя.
Но не следует злоупотреблять этой емкостью по не срочным причинам. Допустим, у нас очень напряженная повестка дня, и мы не можем создавать пары, тогда нам не следует этого делать. В идеале спариваться должны только те люди, которые могут синхронизировать свои планы на день или согласованное время. Если вы знаете, что собираетесь начать сеанс сопряжения, но через 20 минут у вас будет 3 встречи подряд, вам не следует создавать пары, их должен создать кто-то другой.
Еще один интересный момент заключается в том, что при занятиях парным программированием команда должна знать, что потребуется выравнивание во время обеда и, возможно, некоторые другие перерывы. Таким образом, ожидается, что пара согласится, в какое время они хотят провести обеденный перерыв.
Выгодно, если пара разделится только тогда, когда это строго необходимо. Обед в разное время не является строго необходимой причиной для разделения пары. Но также не считается крайне плохой практикой. На мой взгляд, этого следует избегать, потому что это потенциально может уменьшить полученные знания, одна из пар может упустить что-то важное. Если во время обеда кто-то из пары продолжает работать, но его вызывают для другого инцидента, когда коллега возвращается, он не знает, куда пошел его коллега, а также может столкнуться с трудностями при возобновлении работы, если код будет оставлен посреди чего-то.
Решение
Перед тем, как приступить к составлению плана на день, узнайте, когда будут проводиться встречи друг с другом, со своей парой и избегайте или откладывайте создание пары, если ожидается много перерывов. Также, если вы можете договориться о времени, когда вы пойдете на обед.
На ходу договоритесь со своей парой о любой паузе или небольшом перерыве, которые могут понадобиться вам обоим, например о перекусе, туалете и т. Д.
Наконец, если один из членов команды устает или ему нужно отдыхать с разной частотой, возможно, использование техники «Помидор» может быть полезным и сделает вас более продуктивным и более сосредоточенным.
Не меняйте места
. Важно чередовать вождение и навигацию. Вы можете согласовать со своей парой, когда поменяться местами. Если мы будем придерживаться одной роли, мы не получим максимальных преимуществ от обучения, которые дает нам объединение в пары. Помните, я уже упоминал, что наименее опытный участник займет место водителя, но будет желательно как можно скорее начать обмен местами.
Решение
Согласитесь со своей парой, когда менять места. День в жизни программиста никогда не бывает одинаковым, каждый день имеет разные задачи, поэтому было бы полезно менять местами хотя бы один раз в каждой сессии пары, чтобы вы оба могли немного поиграть за рулем и немного поэкспериментировать. навигации.
Забыть, как играть в пинг-понг
Некоторым командам нравится заниматься TDD (разработка через тестирование), это очень полезная практика, когда тесты пишутся до реализации. TDD помогает улучшить качество, а также улучшить дизайн нашего кода. Когда пара решила выполнить TDD, использовалась обычная практика, называемая парным программированием для пинг-понга. В этой технике роли водителя и навигатора отведены в сторону, и пара меняет клавиатуру в соответствии с темпом TDD. Это означает, что один участник напишет тест (красный), другой член команды сделает минимум, чтобы пройти тест, а затем напишет еще один неудачный тест для своего коллеги. Пара будет чередовать роли написания теста, реализации и рефакторинга. Это отличное упражнение для совместного решения проблемы, а также для улучшения навыка TDD.
Нередко можно увидеть, как пара, использующая технику драйвер-навигатор, чтобы найти способ обойти код в момент, когда они спотыкаются, назначают короткий фрагмент кода, который им нужно написать, происходят две вещи:
- они не делают этого. не рассматривают использование TDD и
- они используют TDD, они не меняют роли
Решение
Когда вам нужно написать новый фрагмент кода и вам удалось перейти к месту, где должна быть реализация. Предложите своей паре сыграть в пинг-понг. Следуйте методологии TDD и чередуйте роли.
Альфа-ввод
Представьте, что вы ведете машину в обычном темпе, но пара нетерпеливы и говорит вам об этом. «Просто позвольте мне сделать это, мы закончим быстрее». Даже если был крайний срок, навигатор должен продолжать ориентироваться или улучшать свою речь, чтобы водитель мог легко понять, но просто говорить, что это неуместно. Это просто показывает, что обучение и совершенствование не являются приоритетом. По сути, вы просто говорите своей паре сесть на заднее сиденье, пока вы торопитесь с реализацией, потому что вы торопитесь.
Иногда это может быть просто нетерпение, но часто это просто отсутствие общей организации команды, что в конечном итоге вызывает чувство срочности. Когда это происходит, спаривание начинает действовать из-за повторного ввода альфа-клавиатуры.
Решение
Сосредоточьтесь на текущей задаче, а не на часах. Если кто-то спросит, когда это будет готово, просто скажите, что в настоящее время идет работа. Если они станут резкими или слишком любознательными, скажите, что вы работаете над этим, и он будет готов, когда он будет готов. Не беспокойтесь о внешнем давлении, потому что в 99,9% случаев оценки неточны. Сосредоточьтесь на задаче со своей парой и постарайтесь узнать как можно больше.
Беспокойство по поводу производительности
Некоторые люди очень боятся результатов своих проверок, своих менеджеров или даже того, что у них в голове постоянно страх быть уволенным. Это отсутствие контроля над своим страхом может создать ненужную срочность, которая может испортить опыт совместной работы.
Чтобы иметь безопасный и здоровый опыт совместной работы, команда и ее участники должны быть свободны от удовольствия, которое будет вызывать у них позывы.
Также иногда часть беспокойства может быть вызвана отсутствием прозрачности с нетехнической стороной команды в отношении того факта, что они собираются объединиться. Это порой вызывает сильное беспокойство, потому что люди не понимают, как их будут оценивать с точки зрения производительности, многие считают, что не получат повышения по службе, если будут работать в паре, потому что это может быть замечено, поскольку они не знают, как работать самостоятельно.
Решение
Чтобы избавиться от этого страха в команде, сделайте его официальным и сообщите всем, что политика команды всегда заключается в парном программировании. Члены команды должны поддерживать друг друга и всегда давать честную обратную связь друг другу после занятий в паре. Эта обратная связь и признание сильных и слабых сторон поможет людям стать лучше.
Спаривание под прикрытием
Не стыдно попросить кого-нибудь создать пару. Это не признак слабости или лени. Те, кто желает объединиться в пары, но во многих случаях чувствуют, что их команды или компании отвергают эту идею, часто делают это потому, что чувствуют, что в команде что-то не так, и стремятся улучшить динамику командной работы, а также децентрализовать знания, которые часто хранятся в руках нескольких человек.
Иногда они объединяются в пары тайно, но знают, что их команда или менеджеры этого не одобряют.
Решение
Вы должны гордиться тем, что хотите стать парным программистом, не скрывайте своего желания помочь своей команде, практикуя парное программирование. Если вы видите, что какой-то менеджер или кто-то продолжает вносить ваши предложения, расскажите им о преимуществах спаривания. Или, еще лучше, расскажите им о недостатках отказа от спаривания.
Перестаньте притворяться, что вам это нравится
Некоторым это просто не нравится. Но почему? Просто потому, что они этого не делают. Что бы вы ни делали, вы их не убедите. Если у вас есть несколько таких людей в команде или среди менеджеров, будет действительно очень сложно заставить команду заниматься парным программированием.
Решение
Решение фактически начинается в процессе набора. Вы должны честно спросить кандидатов, будет ли им комфортно заниматься парным программированием на ежедневной основе. Если ответ отрицательный, не нанимайте их. Парное программирование - это техника, но это также и навык, и поэтому важно делать это постоянно. Простое спаривание один раз в синюю луну на самом деле не приносит многого. Команды, которые извлекают максимум пользы из парного программирования, однажды приняли его как политику и практикуют ее ежедневно.
Jira не поддерживает парное программирование
Что касается поддержки усилий команды по парному программированию, среда, а также инструменты, которые мы используем, должны быть совместимы с парным программированием. Один из примеров, иллюстрирующий этот антипаттерн, - это когда в JIRA паре не разрешено назначать тикету более одного человека одновременно.
Это довольно неприятно, потому что начинает порождать подсознательное ощущение непрозрачности в команде. Право собственности не разделяется, и также похоже, что один из участников ничего не делает, поскольку ничего не «назначено».
Agile учит нас, что мы все должны разделять собственность и ответственность.
Решение
Вам нужно попросить ваших экспертов JIRA или администраторов включить функцию, которая позволяет назначать более одного человека одному и тому же билету. Если они скажут вам, что приведенный выше бизнес не является гибким с макетом JIRA, тогда вы должны сказать им, что все должны знать, что эта команда хочет заниматься парным программированием и что доска JIRA должна это отражать.
Повторный просмотр и ветвление
Одно из преимуществ парного программирования состоит в том, что большая часть процесса непрерывной интеграции уже встроена. Если вы создаете пару, вы уже постоянно выполняете проверку. Так что вы можете пропустить классический этап проверки кода. Это может показаться радикальным, но риск пропустить просмотр при сопряжении довольно низок. Когда люди просматривают код, им нужно поставить себя на ваше место, проверить ветку, прочитать тикет и переключить контекст, чтобы выполнить проверку. Но на самом деле большинство обзоров не так исчерпывающи, потому что есть много причин, таких как срочность или сложность переключения контекста.
Итак, вы идете, парное программирование может проверять ваш код на ходу, и это ускорит процесс. Кроме того, поскольку вам не нужен рецензент кода, если вы чувствуете себя достаточно смелым, вы можете просто попрактиковаться в разработке на основе магистрали. Поскольку на самом деле нет смысла создавать ветвь, если пара выполняет постоянный обзор, поскольку функция, которую она кодирует.
Решение
Обсудите с командой, почему вы просматриваете код перед его объединением, если вы уже занимаетесь парным программированием. Также спросите у команды, нужны ли еще ветки.
Отказ от использования Pairing-Stairs
Чтобы гарантировать, что знания распределяются между членами команды, важно составить хорошую последовательность пар. Хорошая ротация пар должна позволять нам обмениваться парами без нарушения или потери контекста. Часто используемый подход называется парной лестницей.
Парные лестницы - это просто диаграмма, которую команды часто используют во время инструктажа, чтобы отслеживать, кто с кем уже связался. Диаграмма помогает команде визуализировать, кто уже подключился, чтобы можно было поменять местами. Члены команды будут просто рисовать линию каждый раз, когда завершают сеанс спаривания с коллегой. На изображении мы можем видеть, что Питер и Марк создали пару дважды, а Алиса и Сьюзен - только один раз. Эта доска проинформирует их и предоставит им возможность согласовывать свои сеансы спаривания и управлять ими.
Решение
Объединение лестниц - обычная практика, позволяющая визуализировать, кто с кем сочетался, и избегать повторений. Но обратите внимание, что хотя парные лестницы позволяют вам визуализировать, они на самом деле не показывают визуально, кто является чемпионом в истории, и не обеспечивают строгого порядка.
Нет чемпионов
Когда происходит обмен парой, но задача не завершена, если оба участника покидают задачу и просто передают ее другой паре, это может вызвать путаницу и потерю времени. Важно, что, когда вы объединяетесь в пары, но требуется обмен, если задача не выполнена, один из участников должен остаться и стать чемпионом истории.
Решение
Не передавайте незавершенную задачу полностью при объединении в пары. Вместо этого один из членов пары должен остаться и «отстоять» историю. Остающийся участник должен быть тем, кто присоединился к задаче последним.
Непонимание чередования времени и ротации признаков
Парные лестницы говорят нам, как менять пары, но не говорят нам, когда менять.
Есть два основных стиля пар. менять:
- По времени: по прошествии определенного количества согласованного времени все пары меняются местами (после парной лестницы)
- На основе характеристик: выполнение задачи одной парой вызывает обмен парой, даже если другая команда еще не выполнила эту задачу.
Оба стиля интересны, похожи и полезны.
Подход, основанный на времени, научит пару работать в срок. Поскольку мы знаем, сколько времени осталось, мы должны иметь возможность планировать соответственно, зная, что один из членов команды покинет пару.
Подход, основанный на характеристиках, позволяет по крайней мере одной из пар иметь возможность полностью выполнить задачу / функцию. Но также может застать врасплох другую пару. Так что это хорошее упражнение для пары, которая всегда будет готова ожидать неожиданного (события обмена).
Решение
Если ваша команда уже занимается парным программированием, но не применяет на практике какую-либо конкретную ротацию пар, рассмотрите возможность реализации либо замены на основе времени, либо на основе функций. Поиграйте с разными временами и размерами функций и посмотрите, что вам больше нравится. Скорее всего, большинство начинающих команд парного программирования будут использовать обмен на основе функций, а время между завершением и заменой будет использоваться для небольшого резерва. Это нормально, но попробуйте повысить устойчивость своей команды, реализовав одну из двух стратегий обмена.
Это всего лишь эксперимент
Очень распространенный антипаттерн во многих командах, которые совершенно не знакомы с парным программированием, - это рассматривать его как эксперимент с ограниченными границами. Например, они говорят, что теперь только половина команды будет играть в пары, а другая половина - нет. В такой ситуации все преимущества парного программирования не будут раскрыты. Вся команда должна применять его на практике в течение разумного периода времени, чтобы увидеть преимущества. Выполнение парного программирования в течение дня или спринта вряд ли сильно изменит вашу команду, но постоянное выполнение этого в течение нескольких месяцев с учетом передовых практик и антипаттернов определенно может иметь более положительный эффект в вашей команде. команда.
Решение
Если вы собираетесь заниматься парным программированием, убедитесь, что вся команда привержена этому, и вы согласились делать это хотя бы в течение приличного количества времени (например, 3 - 6 месяцев). Таким образом, вы наверняка начнете извлекать из него максимальную пользу, и преимущества станут заметны.
Отсутствие связи с другими командами
Часто команды, даже если они хорошо построены, могут по-прежнему жить изолированно внутри организации. Иногда рекомендуется приглашать участников из других команд в пары. Это хороший способ наладить связи с другими командами, а также улучшить понимание других систем вокруг нас.
Решение
Если несколько команд уже выработали некоторую степень ловкости и дисциплины при объединении в пары, рассмотрите возможность обмена парами между командами, используя лестницу для объединения, но включите две команды на лестницу для объединения в пары. В идеальном мире, если бы это нужно было делать часто, обе команды были бы полностью способны работать друг с другом. При правильном использовании он может создавать кросс-функциональные команды. Это может быть чрезвычайно полезно для организации, если несколько команд дойдут до этого момента благодаря объединению в пары.
Нет хорошего программного обеспечения для удаленного сопряжения
Даже если группа распределена удаленно, сопряжение все еще возможно, но требуется хорошее программное обеспечение. Сопряжение без демонстрации экрана практически невозможно. Перед началом сопряжения убедитесь, что вы открыли общий доступ к экрану. Также некоторые редакторы позволяют совместное редактирование файлов исходного кода в реальном времени. Если у вас есть такое программное обеспечение, не бойтесь его использовать.
Решение
Используйте все имеющиеся в вашем распоряжении инструменты, чтобы включить удаленное сопряжение. Не полагайтесь только на голос, убедитесь, что вы можете видеть экран собеседника.
Более важная задача
Это классический антипаттерн, который иногда встречается в командах, где определенные люди (часто менеджеры) не могут понять концепцию разработки на основе вытягивания. Они чувствуют, что им нужно всегда назначать кого-то для какой-то истории, вместо того, чтобы позволять команде управлять собой. В подобных ситуациях, если кто-то пытается создать пару, часто пара распадается только потому, что один из участников боится не выполнить «более важную задачу», поставленную до крайнего срока.
Это действительно странно и к тому же иррационально, когда в команде или даже целой компании общее отношение является чистым индивидуализмом. В таких местах производительность команды вторична, важна производительность отдельного человека. Иногда их не волнует, не ухожен ли билет или как будут проходить испытания. Просто мышление бросать вещи через стену.
Это не помогает при объединении в пары, очень редко можно увидеть людей, потому что они чувствуют, что менеджеры сочтут их недельными или «не старшими». Когда мы находимся в такой иррациональной среде, у нас практически нет выбора.
Решение
В очень иррациональной и индивидуалистической среде, где четко видно, что менеджеры просто преследуют свои индивидуальные цели и не обращают внимания на все, что вызывает даже небольшие сбои, попытка объединиться в пару - очень непростая задача. надуманная цель, которая, вероятно, может вызвать у вас проблемы с каким-то менеджером, который, вероятно, даже не понимает, что такое Agile.
Лучшее, что можно сделать, если вы все еще хотите работать в этом месте, - это попытаться найти союзников, а не только в своей команде, попробуйте изучить компанию и поговорить с другими менеджерами и посмотреть, каковы их взгляды сначала на Agile, а затем на Pairing. Если вы найдете кого-то, кто дает вам немного надежды, найдите способ присоединиться к его команде, и, как мы надеемся, у вас будет больше возможностей влиять на парное программирование, а также на Agile.
