У каждого свой Scrum. Он описан в книгах как стройный, понятный и простой процесс. Участники семинаров и тренингов утверждают, что применять его легко. Однако в реальной жизни Scrum каждого человека не похож ни на пример из книг или тренингов, ни на процессы коллег… за редкими исключениями. Почему? Не знаю. Куда интереснее выяснить, что с этим делать и нужно ли это.

TL;DR

  • Scrum эффективен, когда желания бизнеса и разработки совпадают и они готовы играть по этим правилам.
  • Scrum определяет чёткие зоны ответственности и правила для скрам‑команды. Если попытаться изменить их, это может привести к проблемам.
  • Если вы устанавливаете сроки для разработчиков, определяете исполнителей задач и не ведёте бэклог, то у вас нет Scrum, даже при наличии спринтов и ежедневных митингов.
  • В вашей команде есть скрам‑мастер, даже если он не выделен формально. Один из членов команды выполняет эту функцию. Это занимает у него время и, возможно, вызывает лишний стресс.
  • Наём скрам‑мастера показывает разработке, что компания готова играть по правилам и ожидает долгосрочного применения Scrum.
  • При работе с большой командой следует разделить её на несколько подгрупп и использовать LeSS или «Scrum of Scrums».

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

Скрам может быть любым?

Я бы сравнил Scrum с каркасом фахверкового дома. В Германии такие дома до сих пор популярны. В основе такого дома лежит каркас, промежутки в котором заполняются подходящим материалом — кирпичом или глиной с соломой.

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

Во время собеседования я не только проверяю знание алгоритмов. Я также беседую с кандидатом о его опыте работы. Один из ключевых вопросов — как организованы текущие процессы в его команде. Часто кандидат говорит, что у них используется скрам: есть спринты и ежедневные митинги. Хорошо, продолжаем:

  • Как составляется бэклог?
  • Кто и каким образом принимает задачи в работу?

И вот здесь начинаются интересные моменты…

Часто у команды нет бэклога или бэклог содержит нечто странное, неупорядоченное:

  • Задачи не выбираются из бэклога.
  • Важная задача прячется где‑то внизу списка.
  • Проработка задач оставляет желать лучшего. «Сделать хорошо» — это максимально подробное описание задач в «бэклоге».
  • Не разработка определяет, как должны быть выполнены задачи. Они попадают в руки разработчиков уже «готовыми» (см. предыдущий пункт).

Чем грозит отсутствие порядка в бэклоге?

Бардак в бэклоге приводит к следующим проблемам:

  • формальные спринты;
  • выбор задач по привлекательности, а не по важности для бизнеса;
  • длительное планирование с распределением ответственности.

Формальный спринт — это когда следующее планирование запланировано через две недели, без каких‑либо конкретных действий. Команда не знает, что является самым важным для бизнеса на этот период. Сложно понять, куда приложить усилия в первую очередь.

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

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

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

Вы сталкивались с ситуацией, когда встречу для приёмки (а не для получения обратной связи, как это часто бывает) определённой фичи, которая всё ещё находится в активной разработке, назначают на определённую дату без ведома разработчиков?

Обратная связь с пользователями важна

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

Предположим следующую ситуацию: у нас есть заказчики с позицией «сделайте, мы посмотрим». Есть пользователи, заинтересованные в результате, но не являющиеся заказчиками, поэтому их мнение не учитывается. И есть команда разработчиков, которая работает над фичей Y в течение X спринтов. Заказчик говорит «похоже». Пользователи говорят «этим невозможно пользоваться».

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

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

Чем быстрее создаётся что‑то рабочее, тем лучше. Чем быстрее получается обратная связь, тем лучше. Необязательно привязываться к демо. Можно ускорять релиз‑циклы. Хорошо организованный процесс сбора метрик может заменить классические демо с приглашением пользователей.

Можно и комбинировать подходы. И лучше это делать. В сложных продуктах ведь есть всё — от тестовых запусков до A/B‑тестирования на реальных пользователях.

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

Каждый пишет свой сервис? У вас не Scrum

Мне несколько раз встречались случаи, когда кто‑то из членов команды владел собственным участком кода, своим сервисом, в который никто больше не мог вносить изменения. Это не сочетается со скрамом. Получается своего рода матрёшка: команда в команде и бэклог внутри бэклога :) Возникает путаница.

Нужен ли вообще Scrum?

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

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

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

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

Коммуникация важна

Как правило, разработчики, несмотря на свою репутацию замкнутых людей, охотно взаимодействуют со стейкхолдерами различных функций. Разработчикам необходима открытая и прямая коммуникация. Схема «скажи своему менеджеру, он передаст менеджеру смежной команды, тот передаст своему менеджеру, а уже тот — нужному человеку» не работает. Работает схема «напиши Васе, он знает всё».

Такая коммуникация во многом определяется желанием бизнеса. Так же, как и отношение команды разработки к скраму зависит от бизнеса. Хотя команда может инициировать скрам, если бизнесу это не нужно, скрам не будет работать.

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

Заключение

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

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

Scrum предоставляет большую свободу разработчикам. Чёткое фокусирование на самом важном позволяет с полным основанием отклонять запросы тех, кто пытается внести менее важные для проекта задачи в текущий период — например, на время спринта. Это даёт возможность успеть сделать хоть что‑то значимое: закончить пусть небольшую фичу или выпустить хотя бы минимальное улучшение.