У Kаждого Cвой SCRUM

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

TLTR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

---
Возник вопрос? Мне всегда можно написать в Twitter: avkorablev