Методология разработки Scrum: что это и зачем нужно?

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

Содержание:
1. Что такое Scrum?
2. История появления Scrum
3. Зачем нужен Scrum, чем отличается от других методологий?
4. Основы работы по Scrum
5. Стандартный состав Scrum-команды
6. Разработчики
7. Scrum-мастер
8. Владелец продукта
9. В чем отличия и сходства у Agile и Scrum?
10. Какие компании применяют Scrum?
11. Преимущества и недостатки Scrum
12. Почему Scrum не для всех?
13. Примерный срок для перехода на Scrum
14. Альтернативы
Заключение

1. Что такое Scrum?

Scrum (в переводе с английского — «схватка») — это спортивный термин, взятый из регби. Изначально он обозначал состояние команд в начале состязания, перед вбросом мяча.

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

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

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

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

Длительность одного спринта составляет 1–4 недели. При этом сокращение времени спринта ускоряет разработку и делает ее более гибкой, ведь релизы выходят чаще. Также это позволяет оперативнее реагировать на обратную связь от заказчика/клиента. При этом увеличение сроков позволяет снизить накладные расходы на уйму совещаний, коррекций и так далее. Команда подбирает длительность спринта в зависимости от типа продукта.

2. История появления Scrum

Методология Scrum появилась сравнительно недавно — в 2009 году ее официально определили в документе. Однако основа для нее возникла намного раньше.

В качестве первоисточников Scrum указывают производственные системы компании Toyota. Также часть была взяла из концепции применения боевой авиации под названием цикл OODA (она же петля OODA или петля Бойда). Название расшифровывается как observe («наблюдать»), orient («ориентироваться»), decide («решать»), act («действовать»).

Если говорить упрощенно, то речь идет о взаимодействии небольших команд для достижения результата. В военном деле это разведка, ориентировка на местности, принятие решений и удар по врагу. То же применяется в разработке и поддержке ПО.

Что касается документального определения, то впервые подход еще без устоявшегося названия был описан в статье Икудзиро Нонаки и Хиротаки Такэути под названием The New Product Development Game в 1986 году. Там проводился анализ, почему небольшие команды, состоящие из разных специалистов, выдают более качественные результаты, чем большие команды, строго «заточенные» на определенную задачу.

Впервые слово Scrum появилось в 1991 году в книге «Нечестивые проблемы, праведные решения» авторов ДеГрейса и Шталя, после чего этот термин начали использовать в бизнесе. Отметим, что буквально он переводится как «толкотня», а перевод «схватка» — это спортивная версия диалекта.

В 2001 Кен Швабер совместно с Майком Бидлом описали метод в книге Agile Software Development with Scrum. И там этот термин уже применялся официально (что видно из названия книги). С этой книги Scrum начал набирать свою популярность в IT.

Годом позже силами Швабера сотоварищи был организован Альянс Scrum. Там создали серию сертифицированных аккредитаций Scrum. После этого Швабер ушел из альянса и основал Scrum.org. На этом ресурсе идет работа над параллельной серией аккредитаций Professional Scrum.

Наконец, в том же 2009 году Кен Швабер и Джеф Сазерленд сформулировали и задокументировали этот подход, что означало его официальное внедрение в качестве методологии разработки.

3. Зачем нужен Scrum, чем отличается от других методологий?

Главной задачей Scrum является быстрое создание продукта и вывод его на рынок. Причем речь идет о разработке решений, которых ранее не существовало. Суть в том, что при наличии идеи сложно заранее сказать, как пойдет разработка, сколько потребуется времени, и что получится в итоге. Scrum же позволяет разбить процесс на четкие этапы и развеять «туман неопределенности».

Преимуществом такого подхода, помимо четкого плана, является наличие обратной связи, которая позволяет корректировать действия. Иначе говоря, есть ответ на вопрос: «То ли мы делаем, чего от нас ждут?».

До появления Scrum использовали так называемую «водопадную модель». Ее особенностью является последовательность этапов разработки. То есть пока не завершится один этап, не начинается второй.

Примерно так выглядит «водопадная модель»:

1. Сформировать первичные требования.
2. Проанализировать их.
3. Оценить первичные требования.
4. Создать на их основе техническое задание.
5. Провести разработку продукта.
6. Провести тестирование.
7. Провести приемку продукта.
8. Осуществить поставку.

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

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

Однако и этого недостаточно, поскольку зачастую обратная связь приходит только на финальном этапе. При этом, Scrum-методология позволяет получать «обратку» в конце каждого спринта, которых может быть несколько.

Отметим главные особенности Scrum, которые отличают его от других методологий:

• Наличие обратной связи.
• Малые сроки и высокая гибкость.
• Выпуск готового к использованию продукта в конце спринта (то есть нужен результат, а не простое разбиение задачи на итерации).
• Возможность минимизировать количество бюрократии и «бумажной работы».

4. Основы работы по Scrum

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

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

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

Если вкратце, схема выглядит так:

1. Создается план.
2. Запускается спринт его длительность — не более 4 недель.
3. Выполняется работа.
4. Заказчику презентуется готовое решение, по итогам принимаются коррекции или проект отдают заказчику.

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

5. Стандартный состав Scrum-команды

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

Давайте поговорим более конкретно. В число участников Scrum-команды входят обычно владелец продукта product owner — представитель заказчика или клиента, Scrum-мастер менеджер, который взаимодействует с командой разработки и сами разработчики.

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

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

При этом в случае провала ответственность тоже несет вся команда, а не отдельный руководитель или исполнитель. Здесь работает принцип «все в одной лодке».

6. Разработчики

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

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

Таким образом, особенности Scrum-команды выглядят так:

• В команду должны входить все специалисты, нужные для разработки этого продукта.
• При этом нужен именно необходимый минимум — никаких «раздутых штатов». Оптимальное количество — 9–10 человек.
• В идеальном варианте разработчики должны заниматься только этим продуктом, не отвлекаясь на что-то еще.
• Оптимальным решением является также неизменность команды.
• Разумеется, форс-мажоры случаются, но их желательно избегать.
• Нет руководителя, который распределяет задачи. Все работает на самоорганизации.
• В рамках команды поддерживается кросс-функциональность. Это позволяет обойтись без внешних экспертов, а также улучшает обмен опытом.

В целом, идея состоит в том, чтобы разработчиков ничто не отвлекало от создания продукта — ни длинные совещания, ни внешнее руководство, ни другие проекты.

7. Scrum-мастер

«Дирижер» команды, который выполняет главную задачу — создать сплоченный и сработанный коллектив для выполнения задачи и выпуска конкретного продукта.

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

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

Разумеется, в идеале Scrum-мастер должен обучить команду и отойти от этой задачи, но в реальной жизни так бывает редко. На это влияет возможное изменение позиционирования продукта, его задач и так далее. Также могут быть чисто человеческие недопонимания и «терки» в коллективе.

При этом Scrum-мастер старается на первых порах устранять внешние препятствия, которые зачастую находятся вне команды.

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

Это не заказчик, как многие могли бы подумать. Такое название проистекает из его функций — до передачи продукта им обладает владелец и никто иной.

Его можно сравнить с менеджером проекта, хотя это не совсем так. Подробнее расскажем ниже, а пока отметим, что этот человек занимается взаимодействием между заказчиками или клиентами, и командой разработки. Он отвечает за бэклог продукта (перечень задач, которые нужно выполнить, чтобы получить готовое решение), устанавливает приоритеты элементов (но не заставляет разработчиков бросить это на полпути и делать это «прямо сейчас и немедленно»).

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

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

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

9. В чем отличия и сходства у Agile и Scrum?

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

Для начала, Agile — это более общая методология, описывающая общую систему ценностей самоуправляемого подхода к разработке, набор главных принципов. Если угодно, Agile — конституция страны, а Scrum — конкретное прикладное законодательство. То есть Scrum — это практическая реализация Agile, которая реализует конкретную схему действий.

При этом цели у Agile и Scrum едины — создание новых продуктов и их передача пользователю или заказчику.

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

Набор ценностей Agile выглядит примерно так:

Таким образом, Agile декларирует принципы Scrum в разработке. Например, в рамках Agile приветствуются изменения даже на поздней стадии. Сравните это с «водопадной» или инкрементной моделями, где разработка шла строго последовательно и отклонения не допускались.

Еще один пункт — важность обмена информацией между членами команды. Благодаря малому числу участников, процесс не «провисает», а отсутствие бюрократии делает его более эффективным и быстрым.

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

10. Какие компании применяют Scrum?

Как сказано в начале статьи, Scrum используется не только для разработки программного обеспечения, а для всех подходящих задач. В Украине его используют мобильные операторы, торговые сети, фармакологические компании, производственные гиганты и так далее.

Также эту популярную методологию используют крупные IT-гиганты, вроде Google, Amazon, Zappos. А общие принципы Agile используются в Xerox, Honda, Canon и других.

В целом, многие компании — от IT-сферы до промышленных — используют либо Scrum, либо более общие принципы Agile.

11. Преимущества и недостатки Scrum

Как и любой инструмент, Scrum хорош для выполнения своих задач. Однако бывает так, что он оказывается неэффективным способом решения. В этом разделе мы поговорим о том, когда такое бывает и что с этим делать.

Итак, эффективность Scrum проявляется только при соблюдении ряда условий. Список их выглядит примерно так:

• Scrum хорошо применять в случаях, если нужно решить задачу, но решение не прослеживается сразу, его слишком сложно спрогнозировать или же заказчик допускает эксперименты и исследования для получения результата. То есть, если нужно получить некий продукт, но известно лишь, каким он должен быть — условно, крупный интернет-магазин. А моменты вроде движка сайта или платежной системы некритичны. Если же польза от результата прямо пропорциональна и зависит от четкости алгоритма, то Scrum не нужен. Хватит простого плана. И да, отсутствие бюрократии не сильно поможет в такой работе, поскольку нужно будет формировать команду, мотивировать ее и так далее.
• Scrum совершенно не подходит в случаях, если высока цена ошибки. То есть разработка отказоустойчивого железа или ПО не должна подразумевать, что его используют на самых критических важных объектах. Иначе говоря, Scrum не подходит для постройки ядерного реактора, дата-центра или самолета. Операцию на мозге тоже нельзя так провести.
• Обязательно должна быть обратная связь, а заказчик обязан вовлекаться в процесс. Иначе говоря, заказчик должен быть заинтересованным, реагировать на результат или же принимать продукт. Это подходит для программ, сайтов и так далее. Также подход оптимален при решении торговых и производственных задач, но не всех.
• При низкой квалификации команды, нехватке бюджета, ресурсов и так далее, система тоже не будет функционировать. Ведь Scrum-методология заточена на максимальную эффективность за короткое время, а не долговременную разработку.
• Ограничения по части специализации используемых методов. Это следствие пункта 1: если нет возможности экспериментировать и проверять решения, то система будет неэффективной.
• Ограничение по части общения между членами команды, бюрократизация процесса. Здесь все просто — система просто погрязнет в бумагах, согласованиях и так далее. То есть исчезнет сам смысл Scrum-методики.
• Большое число исключений — следствие пунктов 2, 4 и 6. Если цена ошибки высока, а денег нет, при этом все этапы нужно согласовывать, тогда в методологии нет смысла.

Преимущества же Scrum тоже очевидны:

1. Система позволяет решить задачу быстро и разными способами. Она позволяет экспериментировать и всячески тестировать решения, находя лучшее.
2. Самоорганизация команды позволяет исключить «бумажных» посредников и гибко реагировать на изменения.
3. Сокращается время разработки и создается готовый продукт.
   Команда мотивирована, потому никто не занимается «пассивным саботажем» — растягивая работу или замедляя процесс.

12. Почему Scrum не для всех?

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

Поэтому Scrum не подходит для государственных проектов и заказов, строительства, военных задач (кроме упомянутого в начале статьи тактического планирования и нанесения удара).

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

13. Примерный срок для перехода на Scrum

Если вам для каких-то задач необходимо перевести команду на Scrum, то на это потребуется время. Как показывает практика, нужно не менее трех месяцев «тренировок» и «обкатки». В результате можно получить этакий «спецназ» для конкретных задач, которые нужно решить быстро и эффективно.

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

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

Ну и кратко опишем типичные ошибки:

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

Проблемы есть и со стороны Scrum-мастера:

• Зачастую компании экономят и «вешают» на Scrum-мастера четыре команды или больше. В результате эффективность падает.
• Еще пример экономии: тимлиду дают полномочия Scrum-мастера, так что он одновременно распределяет задачи (что исключает самоорганизацию) и решает проблемы. Эффективность низкая.
• Scrum-мастер пытается сам решить все проблемы в команде и вне ее.

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

14. Альтернативы

В числе альтернативных фреймворков отметим такие:

Nexus

Nexus — решение для увеличения Scrum-команды. То есть, если в команде порядка 20 человек, то создается команда-посредник. Строго говоря, это просто развитие Scrum of Scrums.

Плюсы:

• Процессы ничем не отличаются от Scrum, помимо названий и масштабов.
• Все сфокусировано на интеграцию.

Минусы:

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

LeSS

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

Плюсы:

• Большое количество команд.
• Своя база знаний.
• Подходит для больших команд.

Минусы:

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

Kanban

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

Плюсы:

• Подходит для небольших распределенных команд.
• Визуализация всего на Kanban-досках.

Минусы:

• Не подходит для крупных проектов.

Заключение

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

Видео по теме: