Для начала вспомним Scrum

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

Вот как выглядит работа по скраму:

— Процесс создания продукта декомпозируется на спринты. Каждый спринт занимает неделю (реже — две недели или дольше).

— Команда складывает все задачи по проекту в список — бэклог. По сути, бэклог — это техническое задание, разделённое на задачи.

— В начале каждого спринта команда проводит встречу и разбирает задачи из бэклога.

— А ещё команда каждый день собирается на стендап. Во время стендапа каждый участник отвечает на два вопроса: что он делал вчера и что будет делать сегодня. Иногда возникает третий вопрос: что ему мешает это делать.

— Все задачи отражаются на доске — канбане. Их наносят на доску в виде карточек и двигают: например, из колонки «Надо сделать» в колонку «В работе», после — «В тест» и «В продакшен».

Когда вы будете проходить мимо офисных зданий, например мимо офисов Яндекса, присмотритесь к окнам: часто команды превращают их в канбан, нанося группы разноцветных стикеров. Можно с уверенностью сказать, что за этими окнами работают по скраму.

Зачем нужен скрам

Новые методики часто внедряют не потому, что они хороши сами по себе: просто старые принципы работы оказываются неэффективными.

Вот с какими проявлениями «классического» подхода пытаются бороться с помощью скрама:

— Команда делает продукт так, чтобы он получился «достаточно хорошим». А что это значит и когда будет готово — никто не знает: ни заказчик решения, ни руководитель, ни разработчики.

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

— Часто разработчики простаивают, потому что не могут начать. Просто их работу блокирует кто-то в команде. И все разводят руками: «Ну а как быть? Нам что, сделать за Женю его работу?»

— Один из членов команды заявляет: «Так, я займусь системой аналитики». И занимается, например, месяц. А после оказывается, что код написан криво, не все метрики учитываются и аналитику не получается встроить в решение.

Скрам помогает избежать этого:

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

— Каждый вслух рассказывает о своих задачах. Отсидеться за спинами коллег больше не получится.

— Блокировки и пересечения в проекте видны каждый день на стендапе. Можно быстро перераспределить ресурсы.

— В разработке нет огромных задач — «слонов», есть только небольшие, умещаемые в спринт. Цена ошибки снижается.

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

Зачем нужен скрам-мастер

Скрам-мастер помогает перейти на новый процесс. Фактически это что-то вроде ментора по скраму для всей команды целиком. Вот чем он занимается:

1. Объясняет команде правила скрама.

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

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

4. Проводит ретроспективы, или просто ретро, — встречи, на которых члены команды откровенно делятся впечатлениями о том, как им работается вместе, что получилось, а что нет.

5. Участвует в регулярных встречах с заказчиком — деливеринге. Помогает обосновать решения, собирает замечания.

6. Снижает напряжение в команде. Например, помогает разработчикам, которые недолюбливают друг друга, эффективнее работать вместе.

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

Важный принцип работы скрам-мастера — ненасилие. Мастера нельзя навязать команде. Руководитель не может прийти и сказать: «Вот ваш скрам-мастер, делайте как он скажет». Это будет страшным сном для всех. Мастер должен доказать свою полезность, получить у команды кредит доверия и тратить его осмотрительно.

Бывает, что команда заявляет: «Мы не будем работать по скраму — и точка». В таком случае хороший скрам-мастер спокойно и без обид покинет проект. Он понимает, что ломать неэффективные процессы любой ценой нельзя, будет только хуже.

Можно ли обойтись без скрам-мастера

Многие попадают в так называемую ловушку скрама. В таких командах роль мастера берёт на себя продакт-менеджер, который использует фреймворк так, как понимает его сам. Например, внедряет только спринты и бэклог, но заменяет очные стендапы мини-отчётиками в чате. Такой подход называется «скрам-бат» (scrum, but).

В «чистом» скраме так делать не советуют:

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

— Продакт-менеджер работает на стороне команды, а не заказчика. Это позволяет ему продавливать решения с точки зрения разработки, принижая бизнес-требования. А «чистый» скрам-мастер одной ногой находится в команде, а другой — рядом с заказчиком, балансируя требования и процессы.

Поэтому считается, что отдельная роль скрам-мастера эффективнее.

Скрам-мастер — это работа

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

Но нельзя просто назвать себя мастером и бежать в банк за платиновой кредитной карточкой. Сперва нужно учиться, получать опыт работы, сертифицироваться — например в «Эджайл-академии».

А начать знакомство с этим фреймворком стоит с бесплатного гайда от создателей. Среди доступных языков есть и русский.