Разработка через сворминг
Статью перевел Роман Усов, Scrum Master, DatsTeam (Telegram: @romanusov)
Мне нравятся простые подходы. Под подходом я имею в виду механизм, процесс или структуру, которую можно использовать для оформления мыслей и идей или для выполнения какой-то работы.
У меня получилось найти простой подход, чтобы встроить сворминг в разработку. Сворминг — это групповой стиль работы, при котором команда решает, что нужно сделать, а затем разбивается на группы по два и более человек и работает в режиме, схожем с парным или моб-программированием, до завершения выбранной единицы работы. После этого группа распадается, и команда перегруппируется для выполнения следующей задачи.
У этого стиля работы точно такие же преимущества как у моб-программирования — у сформировавшейся группы есть все необходимые знания и навыки, чтобы выполнить работу качественно и быстро.
Кто-то возразит, что посадить целую команду одновременно заниматься одной задачей неэффективно. Некоторые команды очень большие, поэтому в таком режиме только некоторые участники будут активно работать, а остальные просто наблюдать и ждать.
Сворминг решает эту проблему через гибкость и динамичность. Участники команды организуются в группы под конкретную задачу. Состав группы может динамично меняться по мере того, как меняются потребности в определенных знаниях и скиллах в процессе выполнения работы. Возможно, вам нужен UX-дизайнер на час в одной команде и на час в другой. Такие специалисты могут перемещаться между группами, подключаясь тогда, когда группа в них нуждается.
Динамичная природа сворминга может создавать ощущение хаоса. Стороннему наблюдателю сложно понять, что вообще происходит. Участнику, который покидает одну группу, может быть сложно быстро понять, куда двигаться и что делать дальше. Также может быть непонятно, к кому обращаться, если нужно скоординировать усилия.
Поэтому нам и нужен какой-то простой метод (подход), чтобы опрозрачить процесс работы, движение участников команды и задач.
Это можно сделать очень просто с помощью доски и стикеров — физической или в Mural или Miro.
Аватары участников
Для начала создадим аватары участников. У нас была большая команда разработчиков, и мы создали карточки для каждого.
Команды в сворминге могут быть достаточно большими без потери эффективности. Абсолютно не невозможно иметь в команде 20 и более участников. Я применял такой подход в командах до 40 человек. При таком количестве разработчиков парное программирование работает без проблем, а вот для моб-программирования лучше подходят группы не больше 10-12 человек, чтобы поддерживать фокус и вовлеченность.
Работая с онлайн-доской, участники могут быстро создать свои аватары, придать им какой-то уникальный вид и легко перемещать их по доске. В примере все аватары выглядят одинаково, но в жизни разработчики часто используют разные цвета, шрифты, картинки и т.д. Это стоит только поощрять.
Колонки для работы
Теперь нам нужно определиться с лимитами на работу в процессе (WIP limits). Сколько задач мы хотим выполнять параллельно? Сколько нам нужно людей, чтобы прояснить/реализовать/протестировать/поставить новую фичу? Какое оптимальное число участников в группе, работающей с конкретной задачей?
Мы сначала решили установить лимит в 3 параллельные задачи, потом временно увеличили его до 5 и, наконец, остановились на 4. Мы экспериментально выяснили, что для нашей команды лимит в 4 одновременно выполняемых задачи оптимален, чтобы понимать, что происходит, и поддерживать вовлеченность всех участников. Таким образом, на доске у нас появилось четыре колонки по количеству параллельных задач и сворминг-групп (“свормов”), которые с ними работают.
Чтобы метод заработал, нужно добавить еще несколько деталей. Во-первых, команде нужно принять решение, что она забирает в работу. Это может быть элемент из бэклога или задачи, образовавшиеся в результате декомпозиции. Так можно поступить, но еще лучше оттолкнуться от нескольких вопросов:
- Что у нас уже в работе и требует завершения, чтобы двигаться дальше?
- Что у нас уже работает в каком-то виде, но еще не Done?
- Что из наиболее критичного наше приложение еще не умеет делать?
- Какая наша следующая цель?
Легко представить ужас традиционных менеджеров от такого подхода к работе — без роадмапов и таймлайнов, без детального планирования и без тотального контроля. Но ключевая фишка в том, что этот подход позволяет двигаться с максимальной скоростью и получать быструю обратную связь прямо в процессе работы.
Неважно, откуда мы вытягиваем задачи, из шляпы фокусника или бэклога. Важно, чтобы мы четко обозначили тему, над которой будем работать. Это наша точка фокуса. Дальше мы размещаем ее на доске и просим разработчиков “переместиться” в колонку темы, если они хотят присоединиться к группе, которая будет с этой темой работать.
Возможно, нам будет достаточно иметь всего два элемента в параллельной работе, чтобы вовлечь всю команду в процесс разработки. Может быть, нам потребуются четыре группы. Команда сама подберет наилучшую конфигурацию под конкретную работу.
Группы будут адаптироваться в процессе работы на лету, например, если окажется, что какая-то задача сложнее, чем ожидалось, и нужно больше людей, больше интеллектуальной силы, чтобы найти решение, или, наоборот, группа разрослась и стало трудно поддерживать фокус и вовлеченность.
Формирование свормов по темам и задачам
Итак, у нас достаточно работы на всех, и теперь мы можем разбиться на группы и приступить к работе.
Участники команды обычно держат доску перед глазами на протяжении всего дня, чтобы понимать, что происходит, кто и над чем работает и где найти нужного человека, если возник вопрос или нужна помощь. Вся разработка ведется в режиме моб-программирования.
Незапланированная работа
Если случается что-то непредвиденное, требующее немедленного внимание, часть участников покидает свои группы, чтобы заняться срочной задачей. Основные же свормы продолжают работу, пока один-два человека решают неожиданно возникшую проблему.
Сворм практически никогда не оставляет работу незавершенной. Мне иногда приходилось настаивать на том, чтобы участники разошлись, наконец, по домам в конце рабочего дня. Динамичная работа в группах и быстрый прогресс в связке с перерывами после каждого часа работы — это то, что позволяет участникам поддерживать высокий уровень энергии, фокус и вовлеченность на протяжении дня.
Вот так выглядит доска при работе в сворминге. Это очень простая техника, которая поддерживает (возможно, радикально) высокую динамику работы и быстрый прогресс, позволяет получить быстрый результат и такую же быструю обратную связь о нем.
Вопросы и ответы
Поддерживают ли участники команды доску для сворминга в актуальном состоянии?
Да, вполне. Я не замечал, чтобы доска теряла актуальность больше чем на несколько минут.
Мониторят ли разработчики доску, чтобы увидеть, что какая-то тема закрыта и появилась новая тема?
Да.
Бывает ли так, что участники покидают группу, чтобы поработать над темой, которая им кажется более интересной?
Да, обычно для самостоятельной работы. Это происходит через простое информирование других ребят в сворме. Чаще всего, разработчики все-таки предпочитают оставаться в сворме, чтобы довести текущую тему до конца и увидеть результат.
Общаются ли участники одной группы с участниками другой группы по мере необходимости?
Да.
Нужно ли, чтобы все участники сворма имели одинаково высокий уровень экспертизы и навыков? Становятся ли все участники взаимозаменяемыми “универсальными солдатами”?
Нет. Обычно у нас в свормах были фронтенд-разработчики, бэкенд-разработчики, аналитики, тестировщики и доменные эксперты. Люди с разными талантами, знаниями и навыками могут контрибьютить как эксперты в те моменты, когда это необходимо.
А что насчет узких специалистов?
Узкие специалисты перемещаются по группам по мере необходимости. Команды находят их на доске, присоединяются к той группе, где такие специалисты сейчас находятся, и просят помочь или проконсультировать. Удобно выделить этих ребят специальным цветом или любым другим способом на доске, чтобы их можно было легко найти.
Что происходит, когда задача Done?
Некоторые разработчики присоединяются к другой группе, которая работает над другой темой. Некоторые формируют новый сворм и стартуют новую задачу. Кто-то может кого-то подменить в другой группе, давая возможность коллеге подключиться к какой-то другой теме.
Как команда поддерживает фокус на больших целях?
Вся текущая работа прозрачна на доске. За этим легко следить.
У нас для всех инициатив есть базовое описание, куда можно легко заглянуть, чтобы понять цель, проблему, которую хотим решить и т.д.
Мы также проводим демо и чекпоинты со стейкхолдерами, которые частенько изумляются, насколько быстро мы можем учесть их обратную связь и показать уточненный результат.
Любой участник команды или коуч может всех пригласить собраться, чтобы синхронизироваться, где мы сейчас находимся, над чем работаем, что нужно сделать, чтобы достичь нашей цели на день.
Что происходит, когда кто-то вынужден отключиться (отключили свет, пропал интернет и т.д.)?
При сворминге это не проблема. Мы просто двигаем аватар участника за пределы доски и продолжаем работу.
Этот подход реально работает?
Да.
Вы пробовали этот подход при работе с реальными разработчиками, создающими реальный продукт?
Да, несколько раз с разными командами.
Разве не утомительно работать в таком режиме, постоянно переключаясь с задачи на задачу и держа в фокусе большую цель, чтобы правильно выбрать следующую тему для работы?
Это правда. Именно поэтому у нас десятиминутный перерыв в конце каждого часа. Мы также настаиваем на том, что никто не работает после окончания рабочего дня.
Это все, конечно, прекрасно, если у вас команда звезд. Работает ли такой сворминг с реальными, средними по уровню разработчиками?
В этом и фишка этого подхода. Все от самых опытных до новичков работают вместе в свормах и контрибьютят в результат.
Что если моя компания не разрешит мне такой подход?
Значит, придется подбирать что-то еще.
Что если какие-то разработчики не хотят работать в группе или в паре?
Окей, им можно выделить отдельную колонку, чтобы работа, которую они выполняют была прозрачна для все команды. Либо их можно вообще не отображать на сворминговой доске, тогда они просто работают индивидуально. Но у таких ребят обязательно должен быть доступ к доске, чтобы они могли при необходимости найти других участников.
Сложно ли начать работать в таком режиме?
Наоборот, очень просто. Можно стартовать завтра же, просто используя эту статью в качестве гайда, при условии что ребята в команде будут готовы попробовать этот подход в качестве эксперимента.
Published by
