Scrum за 5 минут и реальный опыт

Что такое Scrum на самом деле?

Забудь всё, что ты читал в официальных руководствах.

Scrum — это не методология, не фреймворк и даже не набор практик.

Scrum — это способ познать, что мы понятия не имеем, что делаем, но очень хотим, чтоб всё было под контролем. Шутка, но только отчасти

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

1. Вы составляете список всего, что нужно сделать (это бэклог продукта)
2. Выбираете, что будете строить в ближайшие две недели. Например, фундамент (это уже планирование спринта)
3. Строите эту часть за ограниченное время — обычно 1-4 недели (это и есть спринт)
4. Показываете результат владельцу участка (это уже ревью)
5. Обсуждаете, что пошло хорошо, а что можно улучшить (это ретроспектива)
6. Повторяете, пока дом не будет готов

У каждого есть своя роль:

• Владелец участка (Владелец продукта) решает, каким должен быть дом
• Опытный строитель (Скрам-мастер) помогает организовать процесс и решает проблемы
• Бригада строителей (Команда разработки) решает, как именно строить и сколько работы они могут выполнить за неделю (спринт)

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

Из незнакомго тебе, тут только Инкремент — это результат работы в течении недели. Именно те задачи скрама (только, не обязательно бизнес-задача должна быть закрыта в целом, на спринте может быть закрыт только какой-то её этап, изменение по нему, тоже будет результатом или Инкрементом или этапом)

Почему нужны и важны роли в Scrum

Есть три ключевые роли, и они работают вместе, как рок-группа:

Владелец продукта — это наш фронтмен группы. Он определяет, какие песни будут в альбоме (какие функции нужны в продукте) и в каком порядке их записывать. Без него группа будет играть что попало и никогда не получит музтв Гремми.

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

Команда разработки — это музыканты. Они решают, как именно исполнить песню, какие инструменты использовать и сколько времени это займет.

Когда все работают слаженно — получается хит, много денег и уважение коллег индустрии.

Когда нет — тоже музыка, но уже для Инстасамки.

Церемонии Scrum — способ сэкономить деньги

Ежедневный стендап

Что это: 15-минутная встреча каждое утро, где каждый отвечает на три вопроса:

• Что я сделал вчера?
• Что я планирую сделать сегодня?
• Какие у меня есть препятствия?

Зачем это нужно: Представь, что ты играешь в футбол с завязанными глазами. Стендап — это момент, когда ты можешь снять повязку и увидеть, где находятся твои товарищи по команде.

Планирование спринта

Что это: Встреча в начале спринта, где команда решает, какие задачи из бэклога она возьмет на ближайшие 1-4 недели.

Зачем это нужно: Это как составление списка покупок перед походом в магазин. Без него ты купишь кучу ненужного и забудешь самое важное.

Обзор спринта

Что это: Демонстрация того, что сделано за спринт, всем заинтересованным лицам.

Зачем это нужно: Это как примерка одежды. Лучше узнать, что рукава слишком короткие, когда костюм еще можно переделать, а не в день свадьбы.

Ретроспектива

Что это: Обсуждение того, что пошло хорошо, а что можно улучшить в процессе работы.

Зачем это нужно: Это как разбор полетов после футбольного матча. Без него команда будет повторять одни и те же ошибки.

Scrum работает всегда не так, как в книжках

За 15 лет в ИТ я не видел ни одной команды, которая бы использовала Scrum по книжке.

Владелец продукта

В теории: Визионер, который четко знает, чего хочет.
На практике: Человек, который транслирует противоречивые хотелки заказчика, меняя приоритеты каждые два дня или чаще.
Как вылечить: Требуй от него письменного описания задач и критериев приемки. Введи правило никаких изменений в текущем спринте (кроме критических багов).

Скрам-мастер

В теории: Коуч и фасилитатор (помогает группе работать эффективнее), защищающий команду.
На практике: Человек, который гоняется за всеми с вопросом когда будет готово? и организует бесконечные встречи.
Как вылечить: Он должен быть достаточно технически подкован, чтобы понимать реальные проблемы команды. Если он просто церемониймейстер — толку не будет, только раздражение.

Команда разработки

В теории: Самоорганизующаяся группа профессионалов.
На практике: Группа людей, которые оценивают задачи в 2 часа, а потом делают их 2 дня, потому что: «А я тут баг нашёл».
Как вылечить: Введи правило неизвестное умножаем на три. Если задача кажется простой, но команда с ней раньше не сталкивалась — умножай их оценку на 3.

Ежедневный стендап или митап

В теории: 15-минутная синхронизация команды, где каждый кратко отвечает на три вопроса.

На практике: 30-минутное совещание, где Вася подробно рассказывает о своих технических проблемах, а остальные проверяют почту.

Как вылечить: Поставь таймер на 15 минут и строго его соблюдай. Если кто-то уходит в детали, вежливо останавливай: «Давайте обсудим это после с заинтересованными лицами».

Планирование спринта

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

Обзор спринта

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

Ретроспектива

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

Уточнение бэклога

В теории: Регулярная встреча с директорами для детализации будущих задач.
На практике: Либо не проводится вообще, либо превращается в бесконечное обсуждение деталей и согласования, которые всё равно изменятся в разработке.
Как вылечить: Проводи короткие сессии (не более часа) с четким фокусом: уточнить только те задачи, которые могут попасть в следующие 1-2 спринта.

Scrum — это всегда не про процессы, а про людей

Вот что я понял после 10 лет использования Scrum в разных командах:

Методология не имеет никакого значения, если люди не хотят сотрудничать.

Самые успешные Scrum-команды, которые я видел, имели такие общие черты:

1. Психологическая безопасность — люди не боялись признаваться в факапах и просить помощи. Если сотрудник не может произнести «Я обосрался, помогите» — ничего не поможет.
2. Общая цель — все понимали, зачем они делают продукт. Буквально каждый понимал.
3. Автономия — команда сама решала, как достичь цели. Только так возможен симбиоз.

Всё остальное — вторично.

Как внедрить Scrum без страданий

Мой личный опыт: как я внедрял Scrum в компании, где никто о нем не слышал
Когда я пришел в компанию Ешь-Деревенское, там был классический хаос. Задачи прилетали в мессенджер, приоритеты менялись ежечасно, никто не знал, что делать в первую очередь.

Пошаговый план, который сработал:

Шаг 1: Создай бэклог

Я собрал все задачи в одном месте (мы использовали Trello, но подойдет даже Excel). Главное — чтобы все видели полную картину. Приоритезируй белког с директором по продукту или кто там отвечает за стратегию в компании (цифрами от одного до 10, вполне пойдет)

Шаг 2: Введи роли постепенно

Я не стал сразу назначать Скрам-мастера. Сначала я сам выполнял эту роль, показывая пример. Только когда процесс начал работать, я передал эту функцию одному из ПМ.

Шаг 3: Начни с коротких спринтов

Мы начали с недельных спринтов. Да, это мало времени, но это позволило быстрее увидеть результаты и скорректировать процесс. Команда вздохнула свободнее, бизнес увидел смысл.

Шаг 4: Упрости оценку

Вместо покера планирования, мы использовали простую систему:

• S: до 4 часов
• M: до 1 дня
• L: до 3 дней
• XL: нужно разбить на более мелкие задачи

Шаг 5: Празднуй успехи

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

Вместо заключения:

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

Кивай и продолжай делать то, что работает для твоей команды.

Всё!