Scrum (; — «схватка») — гибкая методология совместной командной работы, широко используемая в разработке программного обеспечения и других отраслях для адаптивного решения комплексных проблем.
Кроме управления проектами по разработке ПО, Scrum может также использоваться в работе команд поддержки программного обеспечения, как подход к управлению разработкой и сопровождения программ.
Следует различать Scrum и Agile.
История
Первоисточниками принципов фреймворка Scrum послужили: производственная система компании Toyota и цикл OODA (OODA loop, или петля OODA, или петля Бойда) концепции применения боевой авиации, включающий в себя четыре составляющих: observe («наблюдать»), orient («ориентироваться»), decide («решать»), act («действовать»).
Сам подход впервые описали и в статье The New Product Development Game (Harvard Business Review, январь-февраль 1986). Они отметили, что проекты, над которыми работают небольшие команды из специалистов различного профиля, систематически производят лучшие результаты, и объяснили это как «подход регби».
В 1991 году ДеГрейс и Шталь в книге «Нечестивые проблемы, праведные решения»Leslie Hulet Stahl. Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms. — Yourdon Press Computing Series, 1990. — ISBN 0-13-590126-X. называли подобный подход словом «scrum» (буквальный перевод — «толкотня», в регбийной терминологии — схватка), спортивный термин, приведённый в статье Такэути и Нонакой. Кен Швабер в начале 1990-х использовал подход, который привёл Scrum в его компанию. Впервые фреймворк Scrum был представлен на общее обозрение задокументированным, чётко сформированным и описанным совместно Кеном Швабером и Джефом Сазерлендом на конференции OOPSLA’95 в Остине. К. Швабер и Д. Сазерленд на протяжении следующих лет работали вместе, чтобы обработать и описать весь свой опыт и лучшие практические образцы для индустрии в одно целое, в тот фреймворк, что известен сегодня как Scrum.
Швабер объединил усилия с в 2001 году, чтобы детально описать метод в книге «Agile Software Development with Scrum».
В 2002 году Швабер вместе с другими основал организацию Scrum Alliance и создал серию сертифицированных аккредитаций Scrum. Швабер покинул Scrum Alliance в конце 2009 года и основал scrum.org, который курирует параллельную серию аккредитаций Professional Scrum.
С 2009 года публичный документ под названием The Scrum Guide официально определяет Scrum. Он был пересмотрен более 5 раз. В 2018 году Швабер и сообщество Scrum.org вместе с лидерами сообщества Kanban опубликовали Руководство по Kanban для групп Scrum.
Определения
Scrum Scrum ( — термин из регби, стартовое состояние команд перед вбросом мяча) — минимально необходимый набор мероприятий, артефактов, ролей, на которых строится процесс Scrum-разработки, позволяющий за фиксированные небольшие промежутки времени, называемые спринтами (), предоставлять конечному пользователю работающий продукт с новыми бизнес-возможностями (инкремент), для которых определён наибольший приоритет. Фреймворк базируется на идеях, озвученных в статье Таекучи и Нонака «», а также на командной работе, по аналогии с тем, как в регби команда действует сообща, ради достижения общей цели. Возможности к реализации в очередном спринте определяются командой в начале спринта на совещании по планированию спринта . Для оценки предстоящего объёма работ в спринте могут использоваться относительные оценки (story points, T-sizing) и практика покера планирования (Planning Poker), что, несмотря на популярность, не является обязательным атрибутом Scrum и не описано в Руководстве по Scrum.
В конце спринта Scrum-команда встречается на обзорном совещании результатов спринта (Sprint Review — старое название Demonstration) с заказчиком, и представляет ему инкремент бизнес-продукта (версия продукта с законченным набором функциональности, который уже можно отдавать заказчику и пользователю для использования), который она успела сделать за спринт. Цель Sprint Review — получение обратной связи от заказчика, чтобы понять, на чём нужно делать акцент в дальнейшем, и какой должен быть следующий инкремент бизнес-продукта.
Строго фиксированная небольшая длительность спринта (от 1 до 4 недель) снижает риски, и даёт возможность быстро получить обратную связь от заказчика, чтобы скорректировать видение продукта.
Спринт Спринт — промежуток времени, достаточный для выполнения запланированной совокупности операций Scrum, целью которой является создание инкремента бизнес-продукта. Жёстко фиксирован по времени. Длительность одного спринта от 1 до 4 недель. Чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении, но много времени тратится на митинги планирования спринта, ретроспективы. С другой стороны, при более длительных спринтах команда (Scrum Team) уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, кросс-функциональности команд и требований, часто методом проб и ошибок. Для оценки объёма работ в спринте можно использовать предварительную оценку, измеряемую в баллах истории. Предварительная оценка длины спринта фиксируется в бэклоге проекта ().
Артефакты Scrum
Диаграмма сгорания задач (Burndown chart)
Диаграмма, демонстрирующая количество сделанной и оставшейся работы относительно времени на разработку проекта называется диаграммой сгорания (Burndown chart).
Данные диаграммы необходимо ежедневно обновлять, чтобы в реальном времени показывать подвижки и издержки в работе над спринтом и проектом, доступные для всех членов Scrum-команды: скрам-мастера и владельца продукта.
Диаграмма сгорания работ для спринта — показывает сколько задач сделано и сколько ещё остаётся сделать в текущем спринте.
Журнал пожеланий проекта (Project backlog) Журнал пожеланий проекта (бэклог проекта) содержит перечень требований к функциональности, упорядоченный по степени важности, и, соответственно, порядку реализации. Элементы этого журнала называются пользовательскими историями (user story) или элементами бэклога (backlog items). Бэклог проекта открыт для редактирования для всех участников процесса Scrum. Ответственный за ведение бэклога проекта — владелец продукта Scrum.
Журнал пожеланий спринта (Sprint backlog) Журнал пожеланий спринта (бэклог спринта) — содержит функциональность, выбранную владельцем продукта из бэклога проекта. Все функции разбиты по задачам, каждая из которых оценивается командой Scrum. На Sprint Planning Meeting методом покера планирования команда оценивает объём работы, который нужно выполнить для завершения спринта.
Scrum-доска
Scrum-доска — это инструмент открытой демонстрации состояния текущей работы Scrum-команды. Scrum-доска состоит из трёх колонок: «сделать» (), «в процессе» (), «сделано» ().
На Scrum-доске размещается весь объём Sprint Backlog, который команда выбрала на Sprint Planning для реализации в текущем спринте. Обычно карточки бизнес-задач располагаются на доске сверху вниз в порядке убывания приоритета (сверху — самые важные, снизу — наименее важные). Хорошей практикой является декомпозиция бизнес-задач на конкретные работы (технические, организационные и другие), которые необходимо выполнить команде, для реализации бизнес-задачи.
Бизнес-задачи и карточки конкретных работ передвигаются по доске из колонки в колонку в соответствии с тем, как команда берёт их на исполнение (In Progress) и завершает (Done). Для обеспечения видимости прогресса работы команды «убывание работы» по дням отображается на Burndown Chart’е.
Чаще всего, в начале работы команды используют доски с нарисованными на листах флипчартами, при этом названия работ выписываются на клейких стикерах, и приклеиваются на доску. По мере выполнения работ по результатам совещаний, команда физически перемещает стикеры из колонки в колонку.
Так же часто используются электронные доски, с реализованными в них похожими механизмами. Например, Atlassian Jira, Trello или kaiten.
Цель спринта (Sprint Goal) Представляет собой краткое описание бизнес-цели спринта. Как артефакт, цель спринта помогает команде принимать обоснованные бизнес-решения. Этот артефакт необходим команде проекта для самостоятельного принятия решения при обнаружении альтернативных путей решения бизнес-задачи.
Инкремент продукта Инкремент продукта представляет собой готовую к использованию часть продукта, которая должна быть реализована к завершению спринта. Команда на Sprint Review (Demonstration) демонстрирует инкремент продукта скрам-мастеру, владельцу продукта, заказчикам и другим заинтересованным лицам для получения обратной связи от них и принятия решения по дальнейшему направлению развития продукта.
История пользователя (User Story)
Требуемую бизнес-функциональность, которую добавляют в бэклог проекта, часто называют пользовательской историей. Зачастую история имеет следующую структуру: «Будучи пользователем <тип пользователя> я хочу сделать <действие>, чтобы получить <результат>». Такая структура удобна тем, что понятна как разработчикам, так и заказчикам.
Оценка трудоёмкости выполнения пользовательской истории (задачи спринта) В книге Сазерленд описал следующий использованный им и подтверждённый опытом эффективный способ проведения оценки трудоёмкости выполнения задач спринта в некоторых единицах трудоёмкости — человеко-часах и тому подобных.
Оценка задач выполняется разработчиками проекта вместе со скрам-мастером и владельцем продукта. Правильным методом оценки задач является покер планирования. Показано, что такая оценка трудоёмкости значительно точнее оценок проводимых другими лицами.
Каждый разработчик должен дать свою независимую от других оценку трудоёмкости задачи, при этом должны использоваться числа из ряда Фибоначчи (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