Недавно мне понравилось работать с некоторыми из моих коллег из Сан-Франциско на месте. Во время этого визита мы хотели найти время, чтобы сделать что-то немного другое. Итак, мы посвятили два дня экспериментам с Mob Programming на какой-то исследовательской работе. За эти два дня мы узнали много нового о групповом программировании, а также о работе, которую изучали. Хотя мы не все ушли с одними и теми же выводами, мы все согласились, что групповое программирование — это метод, который нам интересно попробовать еще.

Изучение проблемы

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

Нам нужно было изучить относительную сложность фильтров, которые мы предоставляем в нашем решении для генерального планирования. В частности, нам нужно было изучить три разных подхода к тому, как мы можем захотеть внести изменения в эти фильтры. В настоящее время эти фильтры основаны на инфраструктуре Backbone Javascript, но все новые разработки ориентированы на React. Итак, мы хотели изучить три подхода: (1) насколько сложно было бы внести функциональные изменения в один из существующих фильтров, (2) насколько сложно было бы повторно реализовать фильтры с помощью React и (3) насколько сложно было бы повторно реализовать фильтры с помощью более новая парадигма пользовательского интерфейса, которая опиралась как на React, так и на лайтбокс. В обоих последних случаях у нас также был второстепенный интерес, чтобы понять, насколько сложным может быть обеспечение беспрепятственной работы фильтров на основе React вместе с фильтрами на основе Backbone.

Ключевые правила

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

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

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

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

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

Наш график

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

Получение некоторой практики

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

Мы решили провести проверку кода открытого запроса на включение, который был у нашей команды. В процессе проверки кода мы использовали таймер, который менял машинистку каждые восемь минут. Этого времени оказалось слишком мало для ротации, что привело к тому, что мы перешли на 15 минут на человека и придерживались его до конца нашего времени программирования мобов. Мы также обнаружили, что использование нами Zoom и Apple Airplay приводит к неприемлемой задержке как для нашего удаленного участника, так и даже для членов нашей команды, находящихся в одном месте. Это привело нас к тому, что мы переключились на использование Tuple для нашего удаленного участника, что имело свои сложности, и подключили нашу рабочую станцию ​​напрямую к телевизору в конференц-зале.

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

Что мы узнали

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

О программировании мобов

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

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

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

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

О нас

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

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

О нашей работе

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

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

Куда мы идем отсюда

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

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

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

Первоначально опубликовано на https://james.thomps.onl 19 сентября 2019 г.