Scrum

Scrum
Официальный сайт	scrum.org
Медиафайлы на Викискладе

Разработка программного обеспечения
Процесс разработки ПО
Ключевые процессы
Анализ Проектирование Программирование Конструирование Тестирование Отладка Развёртывание Сопровождение Документирование
Парадигмы и модели
Agile Cleanroom Итеративная Спиральная Каскадная V-Model Dual Vee Model
Методологии
ASD DevOps DAD DSDM FDD Канбан Lean SD LeSS MDD MSF PSP OpenUP RAD RUP SAFe SCRUM TSP UP XP
Инструменты
Компилятор Отладчик Профилирование GUI-конструктор ИСР Автоматизация сборки Автоматизация релиза Инструменты тестирования

Scrum (/skrʌm/^[1]; англ. scrum «схватка») — легкий фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем^[2].

Scrum может использоваться не только в сфере разработки ПО, но и в других производственных отраслях^[3].

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

Следует различать Scrum^[4] и Agile^[5].

История

Термин «scrum» пришёл из регби, где он означает схватку. Здесь запечатлена схватка в регбийном матче клубов «Ньюпорт» и «Лондон Уэлш» 1904 года

Первоисточниками принципов фреймворка Scrum послужили: производственная система компании Toyota и цикл OODA (OODA loop, или петля OODA, или петля Бойда) концепции применения боевой авиации, включающий в себя четыре составляющих: observe («наблюдать»), orient («ориентироваться»), decide («решать»), act («действовать»)^[6].

Джефф Сазерленд

Сам подход впервые описали Хиротака Такэути^[англ.] и Икудзиро Нонака^[англ.] в статье The New Product Development Game (Harvard Business Review, январь-февраль 1986). Они отметили, что проекты, над которыми работают небольшие команды из специалистов различного профиля, систематически производят лучшие результаты, и объяснили это как «подход регби».

В 1991 году ДеГрейс и Шталь в книге «Нечестивые проблемы, праведные решения»^[7] называли подобный подход словом «scrum» (буквальный перевод — «толкотня», в регбийной терминологии — схватка), спортивный термин, приведённый в статье Такэути и Нонакой. Кен Швабер в начале 1990-х использовал подход, который привёл Scrum в его компанию. Впервые фреймворк Scrum был представлен на общее обозрение задокументированным, чётко сформированным и описанным совместно Кеном Швабером и Джефом Сазерлендом^[6] на конференции OOPSLA’95^[8] в Остине. К. Швабер и Д. Сазерленд на протяжении следующих лет работали вместе, чтобы обработать и описать весь свой опыт и лучшие практические образцы для индустрии в одно целое, в тот фреймворк, что известен сегодня как Scrum.

Кен Швабер

Швабер объединил усилия с Майком Бидлом^[англ.] в 2001 году, чтобы детально описать метод в книге «Agile Software Development with Scrum»^[9].

В 2002 году Швабер вместе с другими основал организацию Scrum Alliance^[10] и создал серию сертифицированных аккредитаций Scrum. Швабер покинул Scrum Alliance в конце 2009 года и основал Scrum.org Архивная копия от 10 декабря 2019 на Wayback Machine, который курирует параллельную серию аккредитаций Professional Scrum^[11].

С 2009 года публичный документ под названием The Scrum Guide^[12] официально определяет Scrum. Он был пересмотрен более 5 раз. В 2018 году Швабер и сообщество Scrum.org вместе с лидерами сообщества Kanban опубликовали Руководство по Kanban для групп Scrum^[13].

Определения

Процессы методологии Scrum

Scrum

Scrum (англ. «схватка» — термин из регби, обозначает стартовое состояние команд перед вбросом мяча) — минимально необходимый набор мероприятий, артефактов, ролей, на которых строится процесс Scrum-разработки, позволяющий за фиксированные небольшие промежутки времени, называемые спринтами (sprints), предоставлять конечному пользователю работающий продукт с новыми бизнес-возможностями (инкремент), для которых определён наибольший приоритет. Фреймворк базируется на идеях, озвученных в статье Таекучи и Нонака «The New New Product development Game^[англ.]», а также на командной работе, по аналогии с тем, как в регби команда действует сообща, ради достижения общей цели. Возможности к реализации в очередном спринте определяются командой в начале спринта на совещании по планированию спринта Sprint Planning Meeting. Для оценки предстоящего объёма работ в спринте могут использоваться относительные оценки (story points, T-sizing) и практика покера планирования (Planning Poker), что, несмотря на популярность, не является обязательным атрибутом Scrum и не описано в Руководстве по Scrum.

В конце спринта Scrum-команда встречается на обзорном совещании результатов спринта (Sprint Review — старое название Demonstration) с заказчиком, и представляет ему инкремент бизнес-продукта (версия продукта с законченным набором функциональности, который уже можно отдавать заказчику и пользователю для использования), который она успела сделать за спринт. Цель Sprint Review — получение обратной связи от заказчика, чтобы понять, на чём нужно делать акцент в дальнейшем, и какой должен быть следующий инкремент бизнес-продукта.

Строго фиксированная небольшая длительность спринта (от 1 до 4 недель) снижает риски, и даёт возможность быстро получить обратную связь от заказчика, чтобы скорректировать видение продукта.

Спринт

Спринт^[14] — промежуток времени, достаточный для выполнения запланированной совокупности операций Scrum, целью которой является создание инкремента бизнес-продукта. Жёстко фиксирован по времени. Длительность одного спринта от 1 до 4 недель. Чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении, но много времени тратится на митинги планирования спринта, ретроспективы. С другой стороны, при более длительных спринтах команда (Scrum Team) уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, кросс-функциональности команд и требований, часто методом проб и ошибок. Для оценки объёма работ в спринте можно использовать предварительную оценку, измеряемую в баллах истории. Предварительная оценка длины спринта фиксируется в бэклоге проекта (product backlog; см. далее).

Артефакты Scrum

Диаграмма сгорания задач (Burndown chart)

Основная статья: Диаграмма сгорания задач

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

Диаграмма, демонстрирующая количество сделанной и оставшейся работы относительно времени на разработку проекта называется диаграммой сгорания (Burndown chart).

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

Диаграмма сгорания работ для спринта — показывает сколько задач сделано и сколько ещё остаётся сделать в текущем спринте.

Журнал пожеланий проекта (Project backlog)

Журнал пожеланий проекта (бэклог проекта) содержит перечень требований к функциональности, упорядоченный по степени важности, и, соответственно, порядку реализации. Элементы этого журнала называются пользовательскими историями (user story) или элементами бэклога (backlog items). Бэклог проекта открыт для редактирования для всех участников процесса Scrum. Ответственный за ведение бэклога проекта — владелец продукта Scrum.

Журнал пожеланий спринта (Sprint backlog)

Журнал пожеланий спринта (бэклог спринта) — содержит функциональность, выбранную владельцем продукта из бэклога проекта. Все функции разбиты по задачам, каждая из которых оценивается командой Scrum. На Sprint Planning Meeting методом покера планирования команда оценивает объём работы, который нужно выполнить для завершения спринта^[15].

Scrum-доска

Скрам-доска

Scrum-доска — это инструмент открытой демонстрации состояния текущей работы Scrum-команды. Scrum-доска состоит из трёх колонок: «сделать» (to-do), «в процессе» (in progress), «сделано» (done).

На Scrum-доске размещается весь объём Sprint Backlog, который команда выбрала на Sprint Planning для реализации в текущем спринте. Обычно карточки бизнес-задач располагаются на доске сверху вниз в порядке убывания приоритета (сверху — самые важные, снизу — наименее важные). Хорошей практикой является декомпозиция бизнес-задач на конкретные работы (технические, организационные и другие), которые необходимо выполнить команде, для реализации бизнес-задачи.

Бизнес-задачи и карточки конкретных работ передвигаются по доске из колонки в колонку в соответствии с тем, как команда берёт их на исполнение (In Progress) и завершает (Done). Для обеспечения видимости прогресса работы команды «убывание работы» по дням отображается на Burndown Chart’е.

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

Так же часто используются электронные доски, с реализованными в них похожими механизмами. Например, Atlassian Jira, Trello или kaiten^[16].

Цель спринта (Sprint Goal)

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

Инкремент продукта

Инкремент продукта представляет собой готовую к использованию часть продукта, которая должна быть реализована к завершению спринта. Команда на Sprint Review (Demonstration) демонстрирует инкремент продукта скрам-мастеру, владельцу продукта, заказчикам и другим заинтересованным лицам^[4] для получения обратной связи от них и принятия решения по дальнейшему направлению развития продукта^[17].

История пользователя (User Story)

Истории пользователя

Требуемую бизнес-функциональность, которую добавляют в бэклог проекта, часто называют пользовательской историей. Зачастую история имеет следующую структуру: «Будучи пользователем <тип пользователя> я хочу сделать <действие>, чтобы получить <результат>». Такая структура удобна тем, что понятна как разработчикам, так и заказчикам.

Оценка трудоёмкости выполнения пользовательской истории (задачи спринта)

В книге^[6] Сазерленд описал следующий использованный им и подтверждённый опытом эффективный способ проведения оценки трудоёмкости выполнения задач спринта в некоторых единицах трудоёмкости — человеко-часах и тому подобных.

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

Колода карт Planning Poker

Каждый разработчик должен дать свою независимую от других оценку трудоёмкости задачи, при этом должны использоваться числа из ряда Фибоначчи (1, 2, 3, 5, 8, 13, 20, 40, 100). Вместо чисел 21, 34, 55 используются числа 20, 40, 100. Оценки могут записываться на листках бумаги, либо для этого могут использоваться специальные карточки (см. покер планирования) и должны открываться одновременно. Такая организация проведения оценки позволяет избежать эффекта привязки.

Если все выбранные разработчиками значения попадают в интервал не более чем из трёх последовательных чисел Фибоначчи, то в качестве конечной оценки задачи группой используется усреднённая оценка всех разработчиков группы. Если выбранные оценки выходят за пределы такого интервала, то разработчики с наибольшим и наименьшим значением должны объяснить основания своего выбора, после чего раунды оценки повторяются до тех пор, пока множество оценок не уложится в интервал из трёх последовательных чисел Фибоначчи. Как показывает практика, в случае, если для формирования конечной оценки трудоёмкости задачи применяется вариант с усреднением оценок лежащих в интервале большем, чем три последовательных числа Фибоначчи, то результат оказывается значительно менее точным.

Хотя изначально задачи, и, соответственно, истории и проект в целом, оцениваются в какой-то определённой единице трудоёмкости, эти оценки в дальнейшем используются как относительные величины трудоёмкости в качестве очков (баллов) для определения скорости (производительности) работы Scrum-команды (Velocity).

Очевидно, что изложенную выше методику оценки трудоёмкости отдельных задач и проекта в целом можно использовать не только в Scrum, но также и в других методах реализации проекта.

Критерий готовности (Definition of Done, DoD)

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

Скорость команды Scrum (Velocity)

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

Роли в процессе Scrum

По методике Scrum в производственном процессе можно определить роли, разбитые на две группы: «свиней» и «кур». С 2011 метафоры «свиней» и «кур» отсутствуют в руководстве Scrum, так как никаких специальных ритуалов для кур не предусмотрено^[18]. Руководство по Scrum полностью относится к свиньям. Эти термины были заимствованы из анекдота:^[6]

Свинья идёт по дороге. Курица смотрит на неё и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Курица думает и говорит: «Почему бы не назвать „Яичница с беконом“?». «Так не пойдёт, — отвечает свинья, — ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечена только частично».

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

Основные роли (Core roles) во фреймворке Scrum («Свиньи»)

«Свиньи» полностью включены в проект и в процесс Scrum. Scrum-мастер (Scrum Master) — проводит совещания (Scrum meetings), следит за соблюдением всех принципов Scrum, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учёт, хранение и выдачу Scrum-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения процесса Scrum. Таким образом скрам-мастер Scrum есть сервант-лидер^[англ.] команды.

Главным инструментом Scrum-мастера является чемодан фасилитатора, куда входят коробочки для карточек, карточки квадратные и круглые, клейкие карты, булавки, маркеры, канцелярский нож, клейкая лента, карты для Planning Poker, магниты, ножницы, точки для голосования.

Владелец Scrum продукта (Scrum Product Owner) — представляет интересы конечных пользователей и других заинтересованных в продукте сторон.

Команда разработчиков (Scrum Development Team) — кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды составляет от 5 до 9 человек. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто, кроме команды разработчиков, скрам-мастера и владельца продукта не может вмешиваться в процесс разработки на протяжении спринта. Кросс-функциональность команды позволяет максимально эффективно планировать затраты на реализацию бизнес-требований и в сжатые сроки поставлять реально работающие бизнес-приложения в полном соответствии с изменяющимися требованиями заказчика.

Scrum-команда (Scrum Team) — это, собственно, собирательный образ команды, состоящей из команды разработчиков, скрам-мастера и владельца продукта. Команда полностью самодостаточна и не зависит от внешних специалистов или заказчиков.

Дополнительные роли (Ancillary roles) во фреймворке Scrum («Куры»)

• Пользователи (Users)
• Стейкхолдеры (Stakeholders) — лица, которые инициируют проект (бизнес-заказчики) и для кого проект Scrum будет приносить выгоду. Они вовлечены в схватку только во время обзорного совещания по спринту (Sprint Review).

Пользовательские истории

Основная статья: Пользовательские истории

Обязательные поля

• ID — уникальный идентификатор, порядковый номер, применяемый для идентификации историй в случае их переименования.
• Название (Name) — краткое описание истории. Оно должно быть однозначным, чтобы и разработчики, и скрам-мастер, и владелец продукта могли понять, о чём идёт речь и отличить одну User Story от другой.
• Важность (Importance) — степень важности данной истории, по мнению владельца продукта, полученная в результате переговоров с заказчиком. Обычно представляет собой целое число, иногда для этой цели используются числа Фибоначчи. Чем больше значение, тем выше приоритет.

• Бизнес-процесс (Business process) — краткое описание бизнес-процесса.
• Начальная оценка (initial estimate) — оценка объёма работ, сделанная до начала спринта, необходимого для реализации истории. Измеряется в story point’ах. Приблизительно соответствует числу «идеальных человеко-часов».
• Как продемонстрировать (how to demo) — краткое описание способа демонстрации завершённой задачи заказчику, скрам-мастеру и владельцу продукта в конце спринта. Данное поле может содержать собой название (идентификатор) или код автоматизированного теста для приёмо-сдаточного испытания.
• Критерии приёмки (acceptance criteria) — значимые детали реализации истории, уточняющие требования владельца продукта, собранные всеми участниками Scrum-команды при планировании спринта^[19] .

Дополнительные поля

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

• Категория (track). Например, «панель управления» или «оптимизация». При помощи этого поля владелец продукта может легко выбрать все пункты категории «оптимизация» и установить им низкий приоритет.
• Компоненты (components) — указывает, какие компоненты (например, база данных, сервер, клиент) будут затронуты при реализации пользовательской истории.
• Инициатор запроса (requestor). Владелец продукта может захотеть хранить информацию о всех заказчиках, заинтересованных в данной бизнес-задаче. Это нужно для того, чтобы держать их в курсе дела о ходе выполнения работ в ходе спринта.
• ID в системе учёта дефектов (bug tracking ID) — если при разработке используется отдельная Система отслеживания ошибок, в этом случае в описании истории полезно хранить ссылки на все баги, которые к ней относятся.

Основные совещания Scrum

Следующие совещания используются в Scrum, чтобы достичь регулярности, контроля разработки и при этом минимизировать количество встреч, которые не предопределены в Scrum^[20].

Совещание планирования спринта (Sprint Planning Meeting)

Проводится в начале каждого спринта.

Весь объём работ, который должен быть выполнен за время спринта планируется на этом совещании. План должен быть результатом работы всех членов Scrum Team.

Продолжительность совещания определяется продолжительностью спринта, опытом команды и другими факторами, но не должна превышать 8 часов. За выполнением этих временных рамок следит ScrumMaster.

Sprint Planning Meeting отвечает на такие вопросы:

• Какая цель этого спринта, или что можно сделать за этот спринт?
• Как именно будет достигнута цель спринта, чтобы получить инкремент продукта?

Первый вопрос решают совместно. Product Owner обсуждает цели, которые должны быть выполнены за спринт, учитывая бэклог продукта, предыдущий инкремент продукта и т. д., добавляет новые User Story в бэклог и убирает выполненные. Команда разработчиков пытается спрогнозировать функциональность, которую смогут разработать за время спринта. Также, все члены Scrum Team должны совместно осознать и оценить всю работу грядущего спринта.

Чтобы правильно составить план спринта необходимо учитывать следующее:

• Бэклог проекта;
• Предыдущий инкремент проекта;
• Прогнозируемый потенциал команды разработчиков во время спринта;
• Прошлые результаты работы команды разработчиков.

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

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

С учётом мнения команды разработчиков, владелец продукта (Product Owner) может уточнить выбранные задачи-цели из бэклога или сформировать компромиссное с ними решение. Если разработчики решат, что работы слишком много или мало, то они с владельцем продукта могут пересмотреть выбранные задачи-цели. Также, команда разработчиков, может пригласить других специалистов для предоставления технических или предметных рекомендаций.

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

Ежедневное Scrum-совещание (Daily Scrum)

Митинг Daily Scrum

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

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

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

• Daily Scrum должен длиться не более 15 минут;

• Daily Scrum проводится каждый рабочий день, пропуск Daily Scrum недопустим;

• Примеры вопросов, которые могут рассматриваться на Daily Scrum:

• • Что я сделал вчера, что помогло команде разработчиков достичь цели спринта?

• • Что я сделаю сегодня, чтобы помочь команде разработчиков достичь цели спринта?

• • Я вижу какие-либо препятствия, мешающие мне или команде разработчиков достичь цели спринта?

Команда разработчиков или члены команды часто встречаются сразу после Daily Scrum для более подробных обсуждений или для адаптации или перепланировки остальной части работы.

Scrum Master гарантирует проведение таких встреч, но отвечает за проведение Daily Scrum команда разработчиков. Также Scrum Master обучает команду разработчиков удерживать проведение Daily Scrum в 15 минутных рамках и должен следить, чтобы встреча не была нарушена.

Цель таких встреч — улучшение коммуникаций в команде, сокращение количества дополнительных встреч, выявление будущих рисков и трудностей, способствование быстрому принятию решений.

Это основное средство проверки работы команды разработчиков.

Обзор итогов спринта (Sprint review)

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

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

Обзор итогов спринта включает в себе следующие элементы:

Демонстрация инкремента продукта заказчику

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

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

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

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

Цель ретроспективного совещания — выработка предложений по совершенствованию процесса (процедур, приёмов, операций) реализации проекта. В ходе ретроспективного анализа прошедшего спринта формируется план улучшений процесса реализации проекта для следующего спринта. Совещание проводится после обзора итогов спринта до планирования следующего спринта и должно занимать не больше 3 часов. Контролирует ход совещания Scrum Master.

Основными целями совещания являются:

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

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

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

Отмена спринта

Спринт может быть отменён, если цель спринта потеряла актуальность. Только Product Owner имеет право отменить спринт^[21].

Дополнительные совещания Scrum

Эти совещания могут не входить в общий рабочий процесс Scrum, но определённо имеют место быть в некоторых ситуациях. Они применяются когда разработчиков больше 7-11 человек, то есть больше рекомендуемого размера Scrum-команды.

Scrum of Scrums

Scrum of Scrum of Scrums

Если коллектив больше 11 человек, то команда больше рекомендуемого Scrum размера. Для расширения Scrum предложена методика Scrum of Scrums^[22].

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

Команды проводят Daily Scrum.

После ежедневного совещания Scrum проводится митинг Scrum of Scrums (SoS^[23]). Это значит следующее. От каждой команды выбирается по представителю. Представители разбиваются по 5-9 человек. Каждой группе назначается главный скрам-мастер (Chief Scrum Master^[24]) и главный владелец продукта (Chief Scrum Product Owner^[25]) из числа скрам-мастеров и владельцев продукта, участвующих в проекте. Команда представителей из разных Scrum Team называется Scrum of Scrums Team^[26]. В таком составе проводят 15-минутный стоячий митинг Scrum of Scrums (SoS) или Meta Scrum или Scaled Daily Scrum(SDS)^[27].

Кен Швабер рекомендует проводить Scrum of Scrums каждый день^[28].

Однако некоторые команды Scrum of Scrums проводят не каждый день, а 2-3 раза в неделю^[28]. Это нарушает базовые принципы Scrum и является классическим примером ScrumBut^[29][30]. Это не позволяет в полной мере использовать все преимущества Scrum^[31].

Scrum of Scrums позволяет нескольким Scrum-командам обсуждать работу, фокусируясь на общих областях и взаимной интеграции. Главный скрам-мастер (Chief Scrum Master) задаёт всем членам Scrum of Scrum-команды четыре вопроса^[28], три первых вопроса повторяют вопросы Daily Scrum:

• Что каждая команда сделала с момента предыдущего совещания Scrum of Scrums для достижения цели спринта?
• Что каждая команда сделает к следующему ежедневному совещанию Scrum of Scrums для достижения цели спринта?
• Есть ли проблемы, мешающие команде достичь цели спринта?
• Нужно ли другой команде сделать что-то из задач вашей команды для того чтобы помочь ей достичь цели спринта?

По методике Scrum of Scrums можно и дальше увеличивать число разработчиков. Если Scrum of Scrums не охватывает весь коллектив, может быть проведён митинг Scrum of Scrum of Scrums (Scrum-3, SoSoS)^[32], Scrum of Scrum of Scrum of Scrums (Scrum-4, SoSoSoS^[33])^[34], и так далее^[35]. Последний MetaScrum называется Executive Meta Scrum(EMS)^[36] или Executive Action Team(EAT)^[37]. Такой подход позволяет всего за час организовать работу 4096 человек^[34].

Порядок проведения Scrum of Scrums такой же как у Daily Scrum^[26]:

• в одно и то же время, в одном и том же месте,
• все могут наблюдать, но только «свиньи» говорят,
• в митинге участвуют Chief Scrum Master, Chief Scrum Product Owner и Scrum of Scrums Team,
• длится ровно 15 минут,
• все участники Scrum of Scrums стоят (митинг в формате Daily Standup).

Упорядочение беклога продукта (Product Backlog Refinement)

Беклог упорядочивается для того, чтобы команда разработки и владелец продукта могли^[38]:

• Добавить, убрать, объединить или разбить элементы беклога продукта (PBI), декомпозировать элементы беклога на элементы-задачи уровня программирования.
• Уточнить или дать новые оценки трудоёмкости задач и др.
• Изменить порядок следования элементов беклога продукта.
• Обсудить и прояснить бизнес-требования.

Другие методики масштабирования Scrum (Scaling Scrum)

Методика Nexus

Кроме классической методики Scrum of Scrums (SoS) применяют методики LeSS^{[39][40][41][42]} (от 2 до 8 команд), Nexus^[43], RAGE^[44], DAD^[45], APM^[46][47], SAFe^[48]. Для очень больших проектов вместо LeSS применяют LeSS Huge^[40](8+ команд). Только методики SoS^[49] и Nexus^[50] созданы Сазерлендом и Швабером^[40] и преподаются на сертификационных курсах CSM и PSM.

Обучение и сертификация специалистов по Scrum

В Scrum важнейшую роль играют квалифицированные Scrum Master, Scrum Product Owner и Scrum Team. Основатели Scrum и сертифицированные тренеры (CST®) проводят обучающие курсы с последующей сертификацией специалистов по Scrum. Обязательную основу для всех составляют навыки скрам-мастера. Далее идёт специализация на Scrum Master, Scrum Product Owner и Scrum Developer (член Scrum Team). Успешно сдавшим экзамен выдаются сертификаты: Certified ScrumMaster (CSM®), Certified Scrum Product Owner (CSPO®), Certified Scrum Developer (CSD®), Professional Scrum Master (PSM™), Professional Scrum Product Owner (PSPO™), Professional Scrum Developer (PSD™). Желающие дальше совершенствовать знания и навыки Scrum могут после базовых курсов CSM, CSPO от Scrum ALLIANCE и сдачи экзамена по ним, имеющие опыт работы в своей Scrum-роли не менее 1 года, пройти курсы Advanced Certified Scrum Master (A-CSM), Advanced Certified Scrum Product Owner, Advanced Certified Scrum Developer^[51]. Для разработчиков предусмотрен отдельный набор курсов, связанных с TDD, DevOps и пр^[52]. Прошедшие курсы CSM, CSPO, CSD, A-CSM, A-CSPO, A-CSD и сдавшие экзамены по ним, имеющие опыт работы в соответствующей Scrum-роли не менее 3 лет допускаются к курсам CSP®-SM, CSP®-PO, CSP-D®^[53]. В рамках сертификации scrum.org курсы тоже имеют несколько ступеней: PSM-I, PSM-II, PSM-III, PSPO-I, PSPO-II, PSPO-III^[54].

Возможно дальнейшее обучение с выдачей сертификата тренера по Scrum— Certified Scrum Trainer (CST®) или Professional Scrum Trainer (PST™).

К сертификации на CST допускаются лица, имеющие сертификат CSP-SM или CSP-PO или CSP-D и не менее 5 лет работы в соответствующей Scrum-роли^[55].

В рамках сертификации PST выделяются тренеры скрам-мастеров (PSSMT), владельцев продукта (PSPOT) и команды разработчиков (PSDT)^{[56][57] [58]}. Для допуска к курсам тренеров — train-the-trainer (TTT) и сертификации требуются:

• на PSSMT — сертификат PSM III;
• на PSPOT — сертификаты PSM I и PSPO I;
• на PSDT — сертификаты PSM I и PSD I.

Сертификат по Scrum действует два года. В течение этих двух лет для продления сертификата на следующие два года надо набрать определённое число Scrum Education Units (SEU®)^[59]. Scrum Education Units даются за прохождение курсов по Scrum, участие в Global Scrum Gathering℠^[60] и Regional Scrum Gathering℠^[61], преподавание Scrum и другие действия, направленные на повышение вашей Scrum-квалификации^[59]. Такая система показывает, что ваши знания по Scrum актуальны и вы всегда готовы их применить и передать другим. Это значительно повышает ценность Scrum-сертификата. Scrum Education Units начисляются следующим образом: 1 час обучения Scrum (участие в гатхеринге, преподавание, участие в вебинаре и т. д.) равен 1 SEU®. Для обновления сертификата требуется:

• CSM®, CSPO®, CSD® — 20 SEU®;
• A-CSM®, A-CSPO®, A-CSD® — 30 SEU®;
• CSP®-SM, CSP®-PO, CSP-D®, CAL II- 40 SEU®.

При наличии нескольких сертификатов число необходимых для обновления SEU® вычисляется с помощью специального калькулятора:^[62].

Не совсем Scrum

ScrumBut

ScrumBut— это использование лишь части принципов Scrum, сохраняя убеждённость в работе по Scrum^[29][30]. Это не только не позволяет в полной мере использовать все преимущества Scrum^[29], но и ухудшает производительность по сравнению с полным отсутствием ограничений фреймворке.

Исследования показали, что ScrumBut снижает ежегодную прибыль с 400 % до 0-35 %^[31]. При этом за 100 % принята производительность работы по «водопаду», а за 400 % — по Scrum. Большое исследование причин и последствий ScrumBut проведено в работе «ScrumBut in Professional Software Development»^[63].

Классические примеры ScrumBut^[29]:

• Проведение Daily Scrum или Scrum of Scrums не каждый день;
• Отсутствие ретроспектив;
• Спринты длиннее 4 недель;
• Отсутствие Definition Of Done.

Большое число примеров ScrumBut приведено на сайте альянса Scrum — Scrum ALLIANCE®^[64].

ScrumAnd

Кроме ScrumBut рассматривают ScrumAnd^[65]. Считается, что ScrumAnd использует Scrum и другие лучшие практики. Однако отличить ScrumBut от ScrumAnd бывает непросто^[66]. Например задают вопрос: у нас спринт 6 месяцев, это ScrumBut или ScrumAnd? Авторы^[66] однозначно относят это к ScrumBut и приводят методику различения ScrumBut и ScrumAnd. Следует помнить, что методика Scrum - самодостаточная, а как ScrumBut, так и ScrumAnd приводят к снижению эффективности процесса разработки бизнес-приложений^[66].

Scrum и DevOps

Связь SCRUM с DevOps появилась в 2008 году на конференции Agile Conference^[67]. Тогда Патрик Дюбуа и Эндрю Клэй Шейфер попытались наладить контакт с бизнесом в рамках выступления по теме «Agile-инфраструктура». Позже Патрик придумал термин DevOps. Изучим связь Scrum и DevOps более подробно. При разработке бизнес-приложений важно быстро доставлять отлаженные обновления бизнес-приложений до бизнеса. DevOps это система передачи, непрерывной транспортировки и развертывания продукта в операционную среду (т.е. для реального использования). Эта система предполагает взаимодействие между подразделениями разработки бизнес-приложений, к примеру – программного кода и обеспечения (development) и системой его эксплуатации (operation). Второй ключевой функцией системы DevOps является максимальная автоматизация процессов и процедур развертывания бизнес-приложения в среде эксплуатации. Программисты бизнес-приложений получают в два раза больше программистов других приложений и часто противопоставляют Scrum и DevOps, как будто они исключают друг друга^[68]. DevOps преподносят как нечто более продвинутое, чем SCRUM. DevOps не мешает SCRUM, они независимы. За написание кода ответственна Scrum-команда, за доставку продукта - DevOps-инженер. Таким образом, использование SCRUM и DevOps дает бизнесу возможность заниматься более важными задачами — он видит на продуктиве или на демо-стендах все, что было сделано ^[69]. Частые релизы позволяют делать релизы и быстро проверять свои гипотезы. Если у бизнеса меняются приоритеты, производственная команда может очень быстро изменить направление движения и при этом понести адекватные накладные расходы.

Примечания

1. «scrum» перевод английский-русский  (неопр.). Lingvo.abbyyonline.com. Дата обращения: 4 мая 2016.
2. Швабер Кен, Сазерленд Джефф. Руководство по Scrum  (рус.) (ноябрь 2020). Дата обращения: 15 марта 2021. Архивировано 14 января 2021 года.
3. Архивированная копия  (неопр.). Дата обращения: 19 октября 2018. Архивировано 20 октября 2018 года.
4. 5 ключевых инструментов метода SCRUM  (неопр.) (27 апреля 2017). Дата обращения: 21 октября 2018. Архивировано 2 октября 2019 года.
5. Agile - гибкий подход к управлению проектами  (неопр.) (4 ноября 2016). Дата обращения: 21 октября 2018. Архивировано 3 октября 2019 года.
6. Джефф Сазерленд. SCRUM. Революционный метод управления проектами = SCRUM. The art of doing twice the work in half the time. — Манн, Иванов и Фербер, 2016. — 288 с. — ISBN 978-5-00057-722-6.
7. Leslie Hulet Stahl: Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms Yourdon Press Computing Series, 1990 (первое издание), ISBN 0-13-590126-X
8. OOPSLA 2006  (неопр.). Дата обращения: 26 января 2010. Архивировано 25 июня 2010 года.
9. Schwaber, Ken^[англ.]; Beedle, Mike. Agile software development with Scrum (неопр.). — Prentice Hall, 2002. — ISBN 0-13-067634-9.
10. Maximini, Dominik. The Scrum Culture: Introducing Agile Methods in Organizations. Management for Professionals // Cham: Springer. — January 8, 2015. Retrieved August 25, 2016.. — С. 26. — ISSN 9783319118277.
11. Partogi, Joshua. Certified Scrum Master vs Professional Scrum Master // Lean Agile Institute. — July 7, 2013. Retrieved May 10, 2017.
12. Ken Schwaber; Jeff Sutherland. The Scrum Guide. — Scrum.org, Retrieved October 27, 2017..
13. Scrum.org Introduces Scrum with Kanban Course, Enabling Greater Transparency Among Development Teams  (неопр.) (2 марта 2018). Дата обращения: 22 мая 2019. Архивировано 18 ноября 2018 года.
14. Спринт — рывок; бросок; бег на короткую дистанцию.
15. Ken Schwaber. Agile Project Management with Scrum. — Microsoft Press, 2004. — 163 с. — ISBN 073561993X.
16. Визуальное управление проектами и командами @ Kaiten  (неопр.). Дата обращения: 15 марта 2021. Архивировано 22 января 2021 года.
17. Что такое Скрам — Аджайл для новичков  (неопр.). Дата обращения: 20 октября 2018. Архивировано 21 октября 2018 года.
18. Chickens and Pigs  (неопр.). Дата обращения: 23 июля 2019. Архивировано 23 января 2017 года.
19. Критерии приёмки для требований в Agile  (неопр.). Devprom ALM. Дата обращения: 3 апреля 2016. Архивировано 1 апреля 2016 года.
20. Scrum Guide | Scrum Guides  (неопр.). scrumguides.org. Дата обращения: 3 июня 2020. Архивировано 16 июня 2020 года.
21. Архивированная копия  (неопр.). Дата обращения: 15 марта 2021. Архивировано 14 января 2021 года.
22. (PDF) Scrum of Scrums Solution for Large Size Teams Using Scrum Methodology  (неопр.). Дата обращения: 21 октября 2018. Архивировано 21 октября 2018 года.
23. Scrum of Scrums (SoS) Definition | Innolution  (неопр.). Дата обращения: 21 октября 2018. Архивировано 21 октября 2018 года.
24. Role of a Chief Scrum Master | SCRUMstudy Blog  (неопр.). Дата обращения: 21 октября 2018. Архивировано 25 октября 2018 года.
25. Endava  (неопр.). Дата обращения: 21 октября 2018. Архивировано 21 октября 2018 года.
26. The Scrum of Scrums meeting — Manifesto  (неопр.). Дата обращения: 21 октября 2018. Архивировано 21 октября 2018 года.
27. Jeff Sutherland launches the Scrum@Scale Guide | Henny Portman’s Blog  (неопр.). Дата обращения: 21 октября 2018. Архивировано 21 октября 2018 года.
28. Scrum Alliance Member-Submitted Informational Articles  (неопр.). Дата обращения: 21 октября 2018. Архивировано из оригинала 21 октября 2018 года.
29. What is ScrumBut? | Scrum.org  (неопр.). Дата обращения: 21 октября 2018. Архивировано 21 октября 2018 года.
30. ITKaiZenClub «Scrum, but..» или типичные проблемы при внедрении Scrum, 8 февраля | DOU
31. (PDF) Scrum+:: Is it «ScrumBut» or «ScrumAnd»  (неопр.). Дата обращения: 21 октября 2018. Архивировано 21 октября 2018 года.
32. The Scrum Team and Scrum of Scrums  (неопр.). Дата обращения: 21 октября 2018. Архивировано 21 октября 2018 года.
33. Agile Organization with Scrum@Scale, Vimar Spa a real example
34. Agile In Military Hardware. How the SAAB Gripen became the world’s most cost effective military aircraft Архивная копия от 20 октября 2018 на Wayback Machine / Sutherland and Joe Justice, 2017 (англ.)
35. Scaling Agile Series Part 2: A look at Two of Four Popular Agile Scaling Frameworks: SoS and LeSS — Gorilla Logic  (неопр.). Дата обращения: 21 октября 2018. Архивировано 21 октября 2018 года.
36. The Executive MetaScrum | AgileGenesis  (неопр.). Дата обращения: 15 марта 2021. Архивировано 18 апреля 2021 года.
37. Executive Action Team — Scrum Inc  (неопр.). Дата обращения: 15 марта 2021. Архивировано 28 февраля 2021 года.
38. " Ищем гребешок для причёсывания Беклога Блог о проактивном бизнесе  (неопр.). Дата обращения: 8 декабря 2018. Архивировано из оригинала 27 декабря 2018 года.
39. Large-Scale Scrum (LeSS) — Алексей Кривицкий — Agile-коуч и Scrum-тренер  (неопр.). Дата обращения: 2 ноября 2018. Архивировано 4 ноября 2018 года.
40. Как масштабировать Agile? | Открытые системы. СУБД | Издательство «Открытые системы»  (неопр.). Дата обращения: 2 ноября 2018. Архивировано 4 ноября 2018 года.
41. Знакомство с LeSS — Large Scale Scrum (LeSS)  (неопр.). Дата обращения: 4 ноября 2018. Архивировано 5 ноября 2018 года.
42. LeSS — Scrum на больших масштабах — Блог ScrumTrek  (неопр.). Дата обращения: 4 ноября 2018. Архивировано 5 ноября 2018 года.
43. The Nexus Guide | Scrum.org  (неопр.). Дата обращения: 4 ноября 2018. Архивировано 5 ноября 2018 года.
44. RAGE | Scaled Agile Transformations | Process | cPrime  (неопр.). Дата обращения: 4 ноября 2018. Архивировано 4 ноября 2018 года.
45. Архивированная копия  (неопр.). Дата обращения: 4 ноября 2018. Архивировано из оригинала 5 ноября 2018 года.
46. Agile project management — the what and the why | APM  (неопр.). Дата обращения: 4 ноября 2018. Архивировано 5 ноября 2018 года.
47. Agile project management with Scrum  (неопр.). Дата обращения: 4 ноября 2018. Архивировано 5 ноября 2018 года.
48. Архивированная копия  (неопр.). Дата обращения: 4 ноября 2018. Архивировано из оригинала 5 ноября 2018 года.
49. Scrum of Scrums | Scrum.org  (неопр.). Дата обращения: 2 ноября 2018. Архивировано 4 ноября 2018 года.
50. The Nexus Guide | Scrum.org  (неопр.). Дата обращения: 2 ноября 2018. Архивировано 5 ноября 2018 года.
51. Advanced Certified ScrumMaster (A-CSM℠) Certification  (неопр.). Дата обращения: 15 марта 2021. Архивировано 17 марта 2021 года.
52. Course Search — Scrum Alliance
53. Certified Scrum Professional ScrumMaster® (CSP-SM) Certification Course  (неопр.). Дата обращения: 15 марта 2021. Архивировано 17 марта 2021 года.
54. Scrum Master Certification From the Home of Scrum  (неопр.). Дата обращения: 15 марта 2021. Архивировано 3 марта 2021 года.
55. Certified Scrum Trainer (CST) Certification Application Process  (неопр.). Дата обращения: 19 октября 2018. Архивировано 20 октября 2018 года.
56. PSD Trainer Selection Process and Application | Scrum.org  (неопр.). Дата обращения: 19 октября 2018. Архивировано 20 октября 2018 года.
57. PSPO Trainer Selection Process and Application | Scrum.org  (неопр.). Дата обращения: 19 октября 2018. Архивировано 20 октября 2018 года.
58. PSM Trainer Selection Process and Application | Scrum.org  (неопр.). Дата обращения: 19 октября 2018. Архивировано 20 октября 2018 года.
59. Scrum Education Units® (SEU®) Credits for Training  (неопр.). Дата обращения: 15 марта 2021. Архивировано 20 апреля 2021 года.
60. Global Scrum Gathering Event Information & Sponsorship  (неопр.). Дата обращения: 15 марта 2021. Архивировано 4 марта 2021 года.
61. Scrum Alliance Regional Scrum Gatherings  (неопр.). Дата обращения: 15 марта 2021. Архивировано 28 января 2021 года.
62. Agile and Scrum Training & Certification | Scrum Alliance  (неопр.). Дата обращения: 15 марта 2021. Архивировано 21 апреля 2021 года.
63. Архивированная копия  (неопр.). Дата обращения: 21 октября 2018. Архивировано 21 октября 2018 года.
64. Scrum Alliance Member-Submitted Informational Articles  (неопр.). Дата обращения: 21 октября 2018. Архивировано из оригинала 21 октября 2018 года.
65. The «ScrumAnd» Stance (requires thought and discipline) | Scrum.org  (неопр.). Дата обращения: 15 марта 2021. Архивировано 14 апреля 2021 года.
66. (PDF) Scrum+:: Is it “ScrumBut” or “ScrumAnd”  (неопр.). Дата обращения: 21 октября 2018. Архивировано 21 октября 2018 года.
67. Как взаимосвязаны agile и DevOps? | Atlassian
68. История Agile, DevOps, CI/CD. Как менялся процесс разработки
69. 40 релизов в неделю: зачем и как переходить на режим непрерывной поставки — статья в блоге ScrumTrek

Ссылки

• The Official Scrum Rulebook Архивная копия от 9 сентября 2012 на Wayback Machine
• Обзор методологии Scrum Архивная копия от 14 марта 2016 на Wayback Machine

Литература

• Хенрик Книберг. Scrum и XP: заметки с передовой = Scrum and XP from the trenches. — C4Media, 2007. — С. 140. — ISBN 978-1-4303-2264-1.
• Майк Кон. Scrum: гибкая разработка ПО = Succeeding with Agile: Software Development Using Scrum. — М.: «Вильямс», 2011. — С. 576. — ISBN 978-5-8459-1731-7.
• Джефф Сазерленд. SCRUM. Революционный метод управления проектами = SCRUM. The art of doing twice the work in half the time. — Манн, Иванов и Фербер, 2016. — 288 с. — ISBN 978-5-00057-722-6.
• Кеннет Рубин. Основы Scrum: Практическое руководство по гибкой разработке ПО = Essential Scrum: A Practical Guide to the Most Popular Agile Process. — М.: «Вильямс», 20161. — С. 544. — ISBN 978-5-8459-2052-2.