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

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

Забудь всё, что ты читал в официальных руководствах. Scrum — это не методология, не фреймворк и даже не набор практик.

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

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

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

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

• Владелец участка решает, каким должен быть дом (Product Owner / Владелец продукта)
• Опытный строитель помогает организовать процесс и устраняет препятствия (Scrum Master / Скрам-мастер)
• Бригада строителей решает, как именно строить и сколько работы они могут выполнить (Development Team / Команда разработки)

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

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

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

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

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

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

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

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

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

Daily Standup (Ежедневный стендап)

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

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

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

Sprint Planning (Планирование спринта)

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

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

Sprint Review (Обзор спринта)

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

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

Sprint Retrospective (Ретроспектива спринта)

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

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

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

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

Product Owner

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

Scrum Master в реальности

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

Команда разработки в реальности

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

Daily Standup (Ежедневный стендап)

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

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

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

Sprint Planning (Планирование спринта)

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

Sprint Review (Обзор спринта)

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

Sprint Retrospective (Ретроспектива)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всё!