Pull to refresh

Как мы моббинг пробовали

Reading time 8 min
Views 4.8K
Схема смены ролей

Если в поисковике попытаться найти моббинг или Mobbing, то значительная часть результатов будет про «психологическое насилие над людьми». Потому лучше сразу искать «mob programming». В топ-10 результатов Яндекса на данный момент (27.02.2019) есть лишь одна статья на русском языке (и та — перевод), но много статей на английском. Если посмотреть их бегло, то большинство из них — теория, а не разбор какого-либо практического кейса. Все говорят, что он поможет команде стать эффективнее, локально распространить экспертизу по проекту, и развить в людях soft skills. Я и сам опробовал моббинг на практике во время одного из скрам-тренингов, и был, честно говоря, в восторге! Посоветовавшись с командой, мы решили провести свою тестовую сессию моббинга.

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

Что же такое моббинг


Основатель моббинга как стиля работы Woody Zuill характеризует его следующим образом:
замечательные люди, работающие вместе над одной задачей в один момент времени в одном месте за одним компьютером.
То есть Моббинг — стиль работы, когда команда постоянно работает вместе и вместе «набрасывается» на любые задачи. При этом задача проходит все необходимые этапы своего жизненного цикла, и каждый участник команды работает над ней одновременно со всеми. Таким образом достигается погружение и понимание задачи всей командой.

В моббинге выделено несколько ролей:

  • Драйвер: сидит на общем рабочем месте, делает строго то, что говорит ему навигатор.
  • Навигатор: даёт инструкции драйверу. Если он не знает, что делать, то советуется с мобом (остальной командой), транслирует драйверу необходимые действия.
  • Моб: участвует в разработке, подсказывает навигатору, что должен сделать драйвер.
  • PO (владелец продукта): точно знает, что должно получиться. Задаёт нужное направление движению команды. Может быть драйвером и навигатором.
  • Фасилитатор: следит за соблюдением правил, объявляет смены, паркует идеи. Желательно, чтобы был один человек на этой роли.

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

Смена — промежуток времени между сменой ролей драйвера и навигатора. Смена длится, как правило, 15-20 минут. Более короткие смены способствуют более высокой скорости движения и большей вовлечённости команды.

Правила игры


Во время смены драйвер сидит за общим компьютером и делает строго то, что говорит ему навигатор. Команда наблюдает и при необходимости обсуждает, что необходимо сделать. Навигатор структурирует данное обсуждение и транслирует драйверу, что конкретно ему сейчас надо сделать. Драйвер слушает только указания навигатора и может задавать ему вопросы. Навигатор может транслировать вопрос команде. Фасилитатор «паркует» идеи, которые были озвучены, но не использованы по тем или иным причинам.

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

Схема работы в моббинге

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

Негатив


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

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

Сложностей добавляло то, что у нас два разработчика работают удалённо. В первую очередь, это добавляло времени на такую операцию, как «переключение прав на курсор»: чтобы удалёнщик мог показать что-нибудь на экране, но при этом не перехватывать управление мышью. Для этого надо было развернуть окно управления конференцией, включить нужному человеку право управления курсором, и свернуть окно. Происходит не так долго, но очень сильно отвлекает, выбивает из задачи (в которую только-только начал погружаться), и вообще мешает. В результате после каждой смены новому навигатору надо было спросить у предыдущего, что тот хотел сейчас сделать, обоим надо было это вспомнить, «синхронизироваться», и только тогда двигаться дальше.

Ещё одна сложность из-за «удалённости» некоторых сотрудников — это их соседи. В какой-то момент у удалённого навигатора сосед решил просверлить дыры во всём доме, так что мы слышали полный спектр сопутствующих звуков с усилением. Это, как вы понимаете, нам нисколько не помогало.

Так как мы были весьма ограничены по времени (один час на сессию моббинга), то и смены у нас были очень короткие — по 5 минут (чтобы каждый участник успел побывать в той или иной роли хотя бы один раз). Это также сильно, на мой взгляд, отразилось на прогрессе. Как сказал ранее, все участники сессии погружались в задачу лишь под конец смены (1-2 минуты до конца), и после этого небольшого промежутка времени все отвлекались на переключение. Понятное дело, что таким образом многого не сделаешь.

Ещё команде хотелось бы больше времени, чтобы подумать «молча» и обсудить идеи, но частые смены провоцировали пытаться больше исследовать руками, нежели предположить в теории.

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

Был отмечен тот фактор, что вся команда видит решение задачи с определённой точки зрения, в том числе тестировщик. Мы предположили, что в будущем (когда дошли бы до соответствующего этапа) это могло негативно сказаться на объективности тестирования, потому что мы все будем знать «как оно работает», и подсознательно пытались бы избежать узких мест. К сожалению, это лишь предположение.

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

Камнем преткновения оказались настройки в среде разработки: каждому из разработчиков удобны свои определённые параметры. В данном же случае среда разработки были одна, и её настройки нравились, конечно же, не всем.

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

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

Позитив


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

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

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

Результаты


Обсудив полученные друг от друга отзывы о проведённой сессии, мы пришли к определённым выводам.

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

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

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

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

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

Конечное же, смены нужны длиннее. Хотя бы 15-20 минут, вместо наших 5-ти. И надо что-то делать с правилом, что драйвер – это только руки навигатора, без своей головы.

Итак, мы попробовали моббинг на практике в условиях работы своей команды. Какие-то правила нам мешали, что-то мы поняли неправильно, где-то допускали ошибки. Тем не менее мы почувствовали на себе, что это такое, можно ли и нужно ли нам работать в таком стиле. По результатам данного эксперимента мы в полной мере не получили тех ценностей, которые выделили для себя как наиболее важные. Стоит учитывать, что мы пробовали моббинг лишь один час со слишком короткими сменами, потому эти результаты могут быть не самыми достоверными. При работе по моббингу «full-time» какие-то проблемы не возникнут, а некоторые будут преодолены после «адаптации» к процессу. Вероятно, мы просто не успели получить необходимые нам ценности за столь короткое время. Чтобы узнать это наверняка, стоит попробовать моббинг в других ситуациях, но это будет уже совсем другая история.

P.S.
Можно почитать и посмотреть следующие материалы по теме:
GOTO 2017 — Mob Programming: A Whole Team Approach — Woody Zuill
Woody Zuill — A day of Mob Programming
Блог Agilix Consulting: Как убить очереди и ускорить команду при помощи моббинга
Tags:
Hubs:
+4
Comments 7
Comments Comments 7

Articles