Что такое Scrum и на чем он строится

Методология Agile сейчас на рынке доминирует – каскадную модель разработки сейчас где-то и осталась, ее используют либо в легаси-проектах, либо в очень специфичных кейсах. На ценностях Agile было построено несколько моделей, но самую большую популярность получила методика Scrum – именно ее в 90% случаев вам нужно знать (хотя бы поверхностно), если вы собираетесь устраиваться разработчиком, тестировщиком или вообще любым другим айтишником. Ниже – вкратце о методологиях гибкой разработки и подробно о Scrum: Scrum team, спринты, бэклог, сторипоинты и как методологию Scrum встраивают в проекты.

Scrum – что это и зачем оно нужно

Бизнес во многом пришел к методологии Скрам из-за множества недостатков первой устоявшейся методологии разработки – Waterfall. «Водопад» сформировался стихийно, во многом – благодаря естественной логике: придумываем проект -> пишем код -> тестируем -> выкатываем пользователям. На заре рынка IT денег было много, а конкуренции – мало, поэтому такой подход особых проблем не доставлял: даже если проект разрабатывался 2-3 года и по итогу оказывался никому не нужен, у компании обычно была еще пара проектов, которые приносили большие деньги – no big deal, похоронили неудачный проект и двинулись дальше.

Нетрудно догадаться, что когда конкуренция стала серьезнее, компании перестали иметь возможность несколько лет выкидывать деньги на ветер в случае неудачного запуска проекта – это могло закончиться (и часто заканчивалось) банкротством. Нужен был другой выход, и им стала гибкая методология, одним из первых подходов стал extreme programming. Суть его крайне проста: в кратчайшие сроки разрабатываем minimum viable product (MVP) и смотрим, дадут ли нам дальнейшее финансирование. Дали – отлично, не дали – выбрасываем идею и ищем новую.

Такой подход оказался очень успешным, потому что на разработку MVP обычно уходила пара месяцев, и постепенно на гибкую разработку стали переходить все подряд – сначала маленькие компании, а затем и крупные. Но extreme programming – довольно хаотичная вещь, потому что ничего, кроме идеи разработки MVP в кратчайшие сроки, в нем нет; на практике получалось, что каждая отдельная команда сама придумывала, как внедрять гибкую разработку, и далеко не всегда это было эффективно. В качестве дальнейшего развития идеи появились принципы Agile: методология, которая включает в себя 4 идеи и 12 принципов. Перечисление всех выходит за рамки этого материала, но основная идея: проект нужно разбивать на этапы, наращивая функциональность на каждом из них (фичи наращиваются на MVP); бизнес должен быть готов к изменениям; люди важнее процессов; работающий продукт важнее документации.

Agile всем понравился, но сам по себе он был слишком расплывчатым, чтобы внедрять его в бизнес, поэтому появились более специфичные методологии гибкого подхода к разработке, два самых популярных на текущий момент – это Kanban и Scrum. Kanban – это довольно свободный agile-подход, суть которого сводится к «мы разобьем проект на атомарные задачи и засунем в общий бэклог, каждый желающий может взять себе любую задачу». Kanban крайне хорош для небольших проектов и маленьких команд, но его сложно встроить в большой бизнес, потому что чем больше проект и чем больше участников – тем больше хаоса на Kanban-доске. Для средних и крупных проектов обычно используется фреймворк Scrum – методология, основанная на достижении поставленных задач в отведенный промежуток времени. Детальные правила прописаны в Scrum Guide, если вкратце по процессу разработки:

1. Основной артефакт Scrum – это спринт: отрезок времени в 2-4 недели, в рамках которого команда работает над поставленными задачами.
2. Задачи для спринта берутся из общего бэклога (списка задач) проекта – формируется бэклог спринта.
3. Задачи подбираются таким образом, чтобы уложиться в спринт – для этого используется покер планирования – вся команда назначает задаче оценочное время работы (в идеале этим должен заведовать scrum master, по факту этим нередко занимается ПМ).
4. Когда планирование спринта закончено – все идут заниматься задачами, которые им выдали.
5. В конце спринта команда смотрит, что получилось и что не получилось сделать, а также разбирается, почему – этот анализ ляжет в основу следующего спринта.

Основное преимущество Scrum: каждый из участников команды знает, что и в какие сроки он должен сделать. Кроме того, бизнесу существенно проще планировать сроки: сложность задач оценивают исполнители, а не заказчики, что дает более реалистичные оценки. Вести отчетность тоже проще – достаточно суммировать результаты спринта и передавать их выше руководству. Все эти преимущества существуют не только на бумаге: после того, как бизнес распробовал новый подход и посмотрел на числа прибылей, которые этот подход генерирует, внедрение Scrum началось повсеместно. И «хороший Scrum» от «плохого Scrum» отличить было довольно просто: в то время как плохой Скрам бездумно копировал практики, вроде спринтов и daily scrum meetings, хорошие менеджеры в первую очередь брали от термина Scrum фреймворк, и только потом уже применяли конкретные методы Scrum.

Scrum как фреймворк

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

• Преданность. Каждый из членов команды должен вкладываться ради всей команды.
• Смелость. Члены команды не пасуют перед сложными задачами.
• Сфокусированность. Все концентрируются как на отдельных задачах спринта, так и на целях команды.
• Открытость. Каждый член команды может сказать другому участнику команды то, что он думает (в рамках работы).
• Уважение. Все всех уважают.

Принципы Scrum:

• Прозрачность. Каждый член команды знает, над чем работают другие участники команды. Если внутри команды возникают конфликты – они выносятся в общее поле, а не скрываются.
• Инспекция. Работа команды регулярно инспектируется самой командой, это достигается за счет дейли митингов и спринт ревью митингов (последние проводятся после спринта).
• Адаптация. Команда регулярно проверяет эффективность своей работы и выбрасывает те практики/инструменты, которые не приносят пользы.

На ценностях и принципах строится жизненный цикл Скрам – набор вполне конкретных действий, которые нужно совершать в рамках методологии:

1. Создаем бэклог продукта. Бэклог – отправная точка любого проекта, работающего по Scrum.
2. Планируем спринт. Из общего бэклога задачи переносятся в спринт – первая часть планирования спринта посвящена выбору задач для конкретно этого спринта, вторая половина посвящена составлению плана реализации выбранных задач.
3. Работаем. Команда исполняет задачи, которые были выбраны для данного спринта. Каждый день проводится daily meeting, на котором команда синхронизируется.
4. Подводим итоги. В конце спринта команда смотрит, что получилось и что не получилось сделать, если что-то не получилось – выясняют, почему и как это исправить.
5. Планируем следующий спринт. Повторяем шаги 2-4.

Как Scrum работает в реальной жизни

Команда Scrum

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

• Product Owner. Человек, который планирует спринты, управляет бэклогом и налаживает связь между командой и заказчиками. Лицо с наибольшими полномочиями и наибольшей ответственностью. Product Owner отвечает за единое видение цели команды и ведет ее к этой самой цели.
• Scrum-мастер. Человек, который следит за тем, чтобы ценности Scrum соблюдались и приносили максимальную эффективность. Основная задача – повышать продуктивность команды (всей, а не отдельных участников). Зачастую скрам-мастера в команде либо вообще нет, либо его роль выполняет PO.
• Разработчики. Те, кто разрабатывает продукт. Сюда входят не только кодеры – это могут быть девопсы, дизайнеры, маркетологи и вообще любые исполнители.

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

«Спринт» как единица времени

В Scrum эффективность работы команды меряется спринтами – сколько успели сделать, насколько хорошо сделали, что можно улучшить в работе. Спринт длится от 2 до 4 недель – PO выбирает длительность следующего спринта (обычно выбирают фиксированную длину, но менять ее никто не запрещает). Артефакты, которые связаны со спринтом:

• Планирование спринта. Планирование начинается с обсуждения задач, которые можно перенести из бэклога продукта в бэклог спринта. В теории это должна решать вся команда, на практике это обычно согласовывается между PO и заказчиком. После того, как выбраны приоритетные задачи – команда обсуждает, сколько времени понадобится на их исполнение. Если что-то по оценкам не помещается в текущий спринт – эту задачу перемещают обратно в общий бэклог. Когда бэклог спринта сформирован – его одобряют, и с этого момента бэклог спринта не должен меняться ни при каких обстоятельствах (кроме самых экстренных).
• Дэйли митинг. Ежедневный созвон, на котором команда синхронизируется: каждый вкратце рассказывает, что он собирается делать. Дейли обычно длится не больше 15 минут.
• Обзор спринта. Завершающее спринт мероприятие – команда получает фидбэк от заказчика на тему того, насколько последнему понравились результаты спринта. Проблемы и общий статус обсуждаются на других мероприятиях.
• Ретроспектива спринта. А вот здесь уже команда, включая владельца продукта, обсуждает, как прошел этот спринт. В идеале нужно вывести набор корректировок, которые можно будет использовать в следующем спринте.
• Груминг бэклога. Наконец, когда все уже обсуждено, владелец продукта проводит груминг бэклога – смотрит, как за этот спринт изменились приоритеты, и упорядочивает бэклог в соответствии с этими изменениями.

Управление задачами

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

• Бэклог продукта. Все фичи, которые в теории могут быть реализованы. Сюда, по большому счету, попадают все возможные изменения. Задачи можно добавлять, менять и удалять – никаких правил о том, что задача обязательно должна быть реализована, нет.
• Бэклог спринта. Те задачи, которые будут реализованы в текущем спринте. После того, как бэклог спринта сформирован, добавлять/изменять/удалять задачи в нем нельзя.
• Инкремент. Набор задач из бэклога продукта. Их завершение указывает на то, что у бизнеса появилось что-то новое. Задачи инкремента можно выполнять на протяжении нескольких спринтов.
• DoD (Definition of Done). Набор критериев, выполнение которых указывает о том, что произошел инкремент (то есть команда выполнила какую-то существенную задачу).
• Пользовательские истории. Конкретная функциональность, которую нужно добавить в проект. Называются так потому, что часто имеют формат: «Я, как пользователь, хочу сделать вот это вот и получить такой вот результат».
• Цель спринта. Краткое описание бизнес-цели текущего спринта.
• Диаграмма сгорания задач. Диаграмма, на которой показано, с какой скоростью выполняются задачи в рамках спринта – позволяет оценить, насколько эффективно команда работает.
• Стори-поинты. Предполагаемое количество времени на решение конкретной задачи.

Как внедрить Scrum

Итак, все, что мы перечисляли выше – это теория: структура команды, организация работы, артефакты по категориям и так далее. Теперь посмотрим, как внедрять Скрам на практике. Автор метода предоставил 11 шагов для имплементации Scrum в бизнес (не обязательно в IT, к слову):

1. Выбрать владельца продукта. Скрам начинается с PO – именно он будет коммуницировать с заказчиками и вести команду к светлому будущему. PO должен наблюдать за работой команды, ориентироваться в текущей ситуации, принимать решения и брать на себя ответственность за действия команды. Желательно брать на позицию PO человека, который хотя бы работал по Scrum, а еще лучше – был владельцем продукта раньше.
2. Собрать команду. Команда должна быть автономной (самодостаточной) и многофункциональной, чем меньше людей в команде – тем лучше. Естественно, команда должна быть четко замотивированной на результат.
3. Выбрать скрам-мастера. Этот человек будет фасилитировать работу – то есть следить за коммуникацией внутри команды и упрощать ее, а также следить за соблюдением ценностей Scrum.
4. Создать бэклог продукта. В бэклог нужно поместить все бизнес-идеи, разбитые на задачи – в этом хорошо помогают user story. Может существовать только один бэклог продукта. Задачи внутри бэклога должны быть отсортированы по приоритетности.
5. Оценить бэклог. Когда набор идей сформирован – его нужно показать команде, чтобы та согласованно решила, сколько времени уйдет на ту или иную идею. Если в процессе оказалось, что команда не может прийти к общему решению по какой-либо задаче – нужно уточнить эту задачу.
6. Спланировать спринт. Нужно собраться всей командой и выбрать длительность спринта, после чего – собрать бэклог спринта (если задачи в бэклоге продукта отсортированы по приоритетности – можно просто взять самые верхние). Затем обсуждается реалистичность выполнения задач в установленный срок, если команда пришла к общему мнению – планирование закончено. Результатом спринта должен стать конкретный функционал, полезный бизнесу (или хотя бы существенная часть функционала). Когда спринт спланирован – добавлять новые задачи нельзя.
7. Завести скрам-доску. На доске будут расположены все задачи спринта, у каждой будет статус – «сделать», «в процессе», «сделано». Скрам-доска позволяет делать процессы прозрачными – вся команда будет знать, как проходит спринт.
8. Контролировать работу на ежедневной основе. Для этого есть дейли-митинги. Ежедневно команда встречается с скрам-мастером и отвечает на вопросы: 1) что было сделано вчера? 2) что будет сделано сегодня? 3) какие проблемы блокируют работу?
9. Закончить спринт и провести обзор. Когда время вышло, команда показывает заказчикам, что было сделано за спринт.
10. Провести ретроспективное собрание. Идет после обзора, здесь команда уже обсуждает спринт между собой – насколько все хорошо прошло, какие проблемы возникали, как их можно избежать в дальнейшем.
11. Начать следующий спринт. Повторить шаги 5-10.

Плюсы, минусы, альтернативы Scrum

Плюсы Скрам:

• Команда работает небольшими спринтами, между которыми выискиваются проблемы в продуктивности – это позволяет команде быстро и учиться, и адаптироваться к переменам в желаниях бизнеса.
• В рамках спринта набор задач не меняется – каждый участник команды делает конкретные дела и не думает о том, что завтра все может поменяться.
• Большие задачи разбиваются на мелкие, что и психологически разгружает команду, и помогает лучше понять, как реализовать сложные user story.
• Каждый участник команды знает, где находится его зона ответственности, поскольку задачи распределяются еще на стадии планирования спринта.
• Команда ежедневно чего-то добивается, что увеличивает мотивацию каждого отдельного участника команды.

Минусы Скрам:

• Очень сложно встроить методологию в большую команду – нужно дробить ее на более мелкие, что не всегда возможно (дополнительно появляются проблемы с координацией).
• Скрам не работает, если в команде царит атмосфера токсичности и недоверия.
• При долгой работе по Скрам команда выгорает, потому что методология предполагает максимальную самоотдачу.
• Команде нужно регулярно общаться с заказчиком – не все это любят.

Если минусы Scrum для вас перевешивают плюсы – можно попробовать одну из многих альтернатив. Самые распространенные:

• Lean. Подход похож на Скрам, только вместо спринтов здесь – потоки операций (workflow). Lean лучше подходит для больших команд, потому что нет проблем с параллельной работой над несколькими важными задачами.
• Kanban. Крайне нестрогий подход – в его основе лежат задачи, которые проходят через этапы готовности (тоже workflow), а сроки и возможные изменения значения не имеют. Kanban больше всего любят за то, что в нем нет ничего лишнего: вы просто трэкаете прогресс задач, никакой дополнительной обвязки не нужно.
• Waterfall. Пусть многими эта модель и считается устаревшей, но она все еще применима, хотя и несет в себе больше рисков, чем Agile. При работе по этой модели вы переходите на следующий этап только после того, как был завершен предыдущий. Сами этапы: инициация, планирование, разработка, реализация + тестирование, мониторинг, завершение.

Коротко о главном

• Scrum – это методология + фреймворк для эффективной работы команды.
• Скрам – это один из видов Agile-методологии.
• В основе Скрам лежат бэклог продукта, команда и спринты.
• Встроить Скрам в работу – относительно легкая задача, Scrum Guide предлагает 11 шагов для того, чтобы это сделать: от выбора владельца продукта до повторения спринтов.
• Скрам подходит не всем – иногда он может быть избыточным (слишком маленькая команда) или неудобным (слишком большая команда). В этом случае можно присмотреться к альтернативам, типа Kanban или Lean.