Блог Scrum.ru

Моб-программирование: как кратно ускорить команду

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

В 2014 году Вуди Зил представил общественности моб-программирование — более экстремальную версию практики парного программирования (которую изначально изобрёл Кент Бек). Это когда в работе участвует вся команда:

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

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

Команда работает по Скраму, и из Спринта в Спринт я наблюдал повторяющуюся ситуацию: в начале Спринта у команды уходило 2–3 дня на создание первоначального эскиза модели. Проблема заключалась не в том, что это долго, а в асинхронной коммуникации. Да-да, к сожалению, команда распределенная.

Я предложил сделать совместную дизайн-сессию, когда они начнут разработку новой модели. Что мы и сделали.
За 30 минут на общем звонке мы обсудили визуальный вид и набросали черновики трёх будущих моделей. Я выделю это: 30 минут вместо 2-3 дней.

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

Нужно ли всем и всегда работать так?

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

Последовательный тип зависимостей предполагает последовательность процесса без возврата на предыдущие этапы. Обычно последовательные зависимости встречаются на производстве: сначала идёт добыча, затем — обогащение, плавка и трубопрокат.

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

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

Какие проблемы вы можете встретить:

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

Преимущества:

  • Улучшение качества продукта: разнообразие мнений и навыков членов команды может привести к более качественному результату.
  • Ускорение работы: совместная работа позволяет быстрее решать задачи, так как участники могут в моменте обсуждать и принимать решения.
  • Обмен знаниями и обучение: как некий побочный эффект, люди в команде обучают друг друга, и это встроено в рабочий процесс.
  • Это весело. Правда :)

Попробуйте и поделитесь со мной, как у вас всё прошло.