SCRUM

Материал из Википедии — свободной энциклопедии
(перенаправлено с «Scrum»)
Перейти к навигации Перейти к поиску
Разработка программного обеспечения
Ключевые процессы
Парадигмы и модели
Методологии
Инструменты

SCRUM (/skrʌm/[1]; англ. scrum «схватка») — метод управления проектами.

Следует различать SCRUM[2] и Agile[3].

SCRUM используется как в сфере разработки ПО, так и в других производственных бизнес-отраслях[4].

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

История[править | править код]

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

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

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

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

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

Определения[править | править код]

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

SCRUM[править | править код]

SCRUM (SCRibing Unified Methodology[13] или SCRapbooking Unified Methodology[14] или Sprint Continuous Rugby Unified Methodology[15]) — набор принципов, ценностей, политик, ритуалов, артефактов, основанных на скрайбинге[16] и скрапбукинге[17], на которых строится процесс SCRUM-разработки, позволяющий в жестко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающий продукт с новыми бизнес-возможностями, для которых определен наибольший приоритет. Методология основана на лего-фасилитации[18][19], тактиках и стратегиях из регби и бега на короткие дистанции (спринта), с помощью артефактов и ритуалов скрайбинга и скрапбукинга. Возможности к реализации в очередном спринте определяются в начале спринта на совещании Sprint Planning Meeting планирования методом Planning Poker и не могут изменяться на всем его протяжении. При этом строго фиксированная небольшая длительность спринта придает процессу разработки предсказуемость и гибкость.

Спринт[править | править код]

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

Артефакты SCRUM[править | править код]

Диаграмма сгорания задач (Burndown chart)[править | править код]

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

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

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

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

Журнал пожеланий проекта (Project backlog)[править | править код]

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

Журнал пожеланий спринта (Sprint backlog)[править | править код]

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

Канбан-доска[править | править код]

Канбан-доска должна состоять как минимум из трех колонок: «сделать» (англ. to-do), «в процессе» (in progress), «сделано»(done). При разработке ПО SCRUM канбан-доска обычно включает следующие колонки в соответствии со статусом задач: обсуждается (backlog), согласовано (ready), кодируется (coding), тестируется (testing), подтверждается (approval) и сделано (done). На доску в соответствующий столбец прикрепляются канбан-карточки[22]. Вместо специальных канбан-карточек, которые обычно обозначают потребность или пропускную способность, вместе с доской используются магниты, пластиковые фишки, цветные шайбы или стикеры для представления рабочих элементов и процессов. Каждый из этих объектов представляет собой этап производственного процесса и движется по доске, по мере прогресса. Такое движение соответствует движению SCRUM-процесса производства по Burndown Chart сверху вниз. Часто используется электронная Канбан-доска[23].

Требования к канбан-доске и канбан-карточкам[24]:

  • стирание надписей происходит легко даже спустя несколько недель
  • карточка легко магнитится к любым металлическим доскам и поверхностям
  • края карточки не расходятся при многократном снятии с доски
  • Для надписей используется маркер на водной основе

Цель спринта (Sprint Goal)[править | править код]

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

Инкремент продукта[править | править код]

Инкремент Продукта — это готовый продукт в конце спринта. Показывают заинтересованным на демонстрации[2], чтобы собрать отзывы и решить, что делать с продуктом дальше[25].

История пользователя (User Story)[править | править код]

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

Остановка спринта (Abnormal Termination)[править | править код]

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

Очки за пользовательскую историю (Story Points)[править | править код]

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

  • ряд Фибоначчи (1,2,3,5,8,13,21,34,55);
  • линейную шкалу (1,2,3,4 … n);
  • степень двойки (1,2,4,8 … 2n);
  • размеры одежды (XS, S, M, L, XL).

Задачи истории спринта (Sprint Story Tasks)[править | править код]

Добавляются к историям спринта. Выполнение каждой задачи оценивается в часах. Каждая задача не должна превышать 12 часов (зачастую команда настаивает, чтобы максимальная продолжительность задачи равнялась одному рабочему дню).

Критерий готовности (Definition of Done, DoD)[править | править код]

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

Скорость команды SCRUM (Velocity)[править | править код]

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

Роли в процессе SCRUM[править | править код]

По методике Scrum в производственном процессе были определенные роли, разбитые на две группы «свиней» и «кур», с 2011 метафоры «свиней» и «кур» отсутствуют в Scrum, см. Chickens and Pigs >.. Эти названия были использованы из-за шутки[источник не указан 570 дней]

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

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

Основные роли (Core roles) в методологии SCRUM(«Свиньи»)[править | править код]

«Свиньи» полностью включены в проект и в процесс SCRUM.

Менеджер-мастер SCRUM (SCRUM Manager) — проводит совещания (Scrum meetings) следит за соблюдением всех принципов SCRUM, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения процесса SCRUM. Таким образом менеджер-мастер SCRUM есть сервант-лидер (Servant Leader) команды.

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

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

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

Команда SCRUM (SCRUM Team) – это, собственно, собирательный образ команды, состоящей из Development Team, SCRUM Master и Product Owner. Команда полностью самодостаточна и не зависит от внешних специалистов или заказчиков.

Дополнительные роли (Ancillary roles) в методологии SCRUM(«Куры»)[править | править код]

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

Пользовательские истории[править | править код]

Обязательные поля[править | править код]

  • ID — уникальный идентификатор, порядковый номер, применяемый для идентификации историй в случае их переименования.
  • Название (Name) — краткое описание истории. Оно должно быть однозначным, чтобы и разработчики, менеджер-мастер и владелец продукта могли понять, о чем идет речь и отличить одну User Story от другой.
  • Важность (Importance) — степень важности данной истории, по мнению владельца продукта. Обычно представляет собой иррациональное число, иногда для этой цели используются числа Фибоначчи. Чем больше значение, тем выше приоритет.
  • Предварительная оценка (initial estimate) — начальная оценка объема работ, необходимого для реализации истории по сравнению с другими историями. Измеряется в story point’ах. Приблизительно соответствует числу «идеальных человеко-часов».
  • Как продемонстрировать (how to demo) — краткое пояснение того, как завершенная задача будет продемонстрирована в конце спринта. Данное поле может представлять собой код автоматизированного теста для приемо-сдаточного испытания.
  • Критерии приемки (acceptance criteria) — значимые детали реализации истории, уточняющие требования владельца продукта, собранные всеми участниками SCRUM-команды при планировании спринта.[26]

Дополнительные поля[править | править код]

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

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

Основные совещания SCRUM[править | править код]

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

Планирование спринта (Sprint Planning)[править | править код]

Происходит в начале новой итерации спринта.

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

Sprint planning не должен превышать 8 часов в зависимости от продолжительности спринта, опыта команды и т.п. За выполнением этих временных рамок следит SCRUM master.

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

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

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

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

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

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

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

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

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

Ежедневное SCRUM-совещание (Daily SCRUM)[править | править код]

Daily SCRUM - это митинг, что длится максимум 15 минут, предназначен для команды разработчиков, при этом не исключает присутствие владельца продукта и SCRUM мастера. Эта встреча проводится каждый день спринта в одном и том же месте и в одно и то же время. При этом команда разработчиков планирует работу на следующий рабочий день. Это оптимизирует командную совместную работу и продуктивность благодаря проверке работы, что была сделана с момента предыдущего Daily SCRUM и прогнозированию предстоящей работы.

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

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

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

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

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

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

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

Обзор итогов спринта (Sprint review)[править | править код]

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

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

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

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

Ретроспективное совещание (Sprint Retrospective)[править | править код]

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

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

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

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

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

Дополнительные совещания SCRUM[править | править код]

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

SCRUM of SCRUMs[править | править код]

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

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

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

После ежедневного совещания SCRUM проводится митинг SCRUM of SCRUMs (SoS[29]). Это значит следующее. От каждой команды выбирается по представителю. Представители разбиваются по 5-9 человек. Каждой группе назначается главный менеджер-мастер (Chief SCRUM Master[30]) и главный владелец продукта (Chief SCRUM Product Owner[31]) из числа менеджер-мастеров и владельцев продукта, участвующих в проекте. Команда представителей из разных SCRUM Team называется SCRUM of SCRUMs Team[32]. В таком составе проводят 15-минутный стоячий митинг SCRUM of SCRUMs (SoS) или Meta SCRUM или Scaled Daily SCRUM(SDS)[33].

Кен Швабер рекомендует проводить SCRUM of SCRUMs каждый день[34].

Однако некоторые команды SCRUM of SCRUMs проводят не каждый день, а 2—3 раза в неделю[34]. Это нарушает базовые принципы SCRUM и является классическим примером SCRUMbut[35][36]. Это не позволяет в полной мере использовать все преимущества SCRUM[37].

SCRUM of SCRUMs позволяет нескольким SCRUM Teams обсуждать работу, фокусируясь на общих областях и взаимной интеграции. Главный менеджер-мастер задает всем членам SCRUM of SCRUMs-команды четыре вопроса[34], три первых вопроса повторяют вопросы Daily SCRUM:

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

Если SCRUM of SCRUMs не охватывает весь коллектив, может быть проведен митинг SCRUM of SCRUM of SCRUMs (SCRUM-3, SoSoS)[38], SCRUM of SCRUM of SCRUM of SCRUMs (SCRUM-4, SoSoSoS[39])[40], и так далее[41]. Последний MetaSCRUM называется Executive Meta SCRUM(EMS) или Executive Action Team(EAT). Такой подход позволяет всего за час организовать работу 4096 человек[40].

Порядок проведения SCRUM of SCRUMs такой же как у Daily SCRUM[32] -

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

Груминг беклога (Grooming)[править | править код]

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

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

Масштабирование SCRUM (Scaling SCRUM)[править | править код]

Кроме классической методики SCRUM of SCRUMs (SoS) применяют методики LeSS[43][44][45][46] (от 2 до 8 команд), Nexus[47], RAGERAGE | Scaled Agile Transformations | Process | cPrime</ref>, DAD[48], APM[49][50], SAFe[51]. Для очень больших проектов вместо LeSS применяют LeSS Huge[44](8+ команд). Только методики SoS[52] и Nexus[53] созданы Сазерлендом и Швабером[44] и преподаются на сертификационных курсах CSM и PSM.

Обучение и сертификация специалистов по SCRUM[править | править код]

В SCRUM важнейшую роль играют квалифицированные SCRUM Master, SCRUM Product Owner и SCRUM Team. Основатели SCRUM и сертифицированные тренеры (CST) проводят обучающие курсы с последующей сертификацией специалистов по SCRUM. Обязательную основу для всех составляют навыки менеджер-мастера. Далее идет специализация на SCRUM Master, SCRUM Product Owner и SCRUM Developer (член SCRUM Team). Успешно сдавшим экзамен выдаются сертификаты: Certified SCRUM Master (CSM), Certified SCRUM Product Owner (CSPO), Certified SCRUM Developer (CSD), Professional SCRUM Master (PSM), Professional SCRUM Product Owner (PSPO), Professional SCRUM Developer (PSD).

Возможно дальнейшее обучение с выдачей сертификата тренера по SCRUM — Certified SCRUM Trainer (CST) или Professional SCRUM Trainer (PST). К сертификации на CST допускаются лица, имеющие сертификат CSM или CSPO[54].

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

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

Не совсем SCRUM[править | править код]

SCRUMbut[править | править код]

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

SCRUMbut — это использование лишь части принципов SCRUM, сохраняя убежденность в работе по SCRUM[35][36]. Это не только не позволяет в полной мере использовать все преимущества SCRUM[35], но и ухудшает производительность по сравнению с полным отсутствием методологии.

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

Классические примеры SCRUMbut[35]:

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

Большое число примеров SCRUMbut приведено на сайте Джеффа Сазерленда — SCRUM ALLIANCE[59].

Примечания[править | править код]

  1. «scrum» перевод английский-русский. Lingvo.abbyyonline.com. Дата обращения 4 мая 2016.
  2. 1 2 5 ключевых инструментов метода SCRUM (27 апреля 2017). Дата обращения 21 октября 2018.
  3. Agile - гибкий подход к управлению проектами (4 ноября 2016). Дата обращения 21 октября 2018.
  4. https://www.scrumalliance.org/ScrumRedesignDEVSite/media/ScrumAllianceMedia/Global%20Scrum%20Gatherings/2017%20San%20Diego/Presentations/JusticeJoe_Agile_In_Military_Hardware_SGSD.pdf
  5. 5 ключевых инструментов метода SCRUM
  6. Leslie Hulet Stahl: Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms Yourdon Press Computing Series, 1990 (первое издание), ISBN 0-13-590126-X
  7. OOPSLA 2006
  8. Schwaber, Ken (англ.); Beedle, Mike. Agile software development with Scrum (неопр.). — Prentice Hall, 2002. — ISBN 0-13-067634-9.
  9. 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.
  10. Partogi, Joshua. Certified Scrum Master vs Professional Scrum Master // Lean Agile Institute. — July 7, 2013. Retrieved May 10, 2017.
  11. Ken Schwaber; Jeff Sutherland. The Scrum Guide. — Scrum.org, Retrieved October 27, 2017..
  12. Scrum.org Introduces Scrum with Kanban Course, Enabling Greater Transparency Among Development Teams (Retrieved March 2, 2018).
  13. https://www.scribing.it
  14. https://www.scrapbooking.com
  15. Методология SCRUM. Управление проектами SCRUM
  16. Zillion — Презентации — Скрайбинг как способ визуального мышления
  17. Скрапбукинг: с чего начать создание открыток и альбомов
  18. http://lego-sp.ru
  19. Что такое Lego Serious Play? Блог о проактивном бизнесе (недоступная ссылка). Дата обращения 22 октября 2018. Архивировано 22 октября 2018 года.
  20. Спринт — рывок; бросок; бег на короткую дистанцию.
  21. Ken Schwaber. Agile Project Management with Scrum. — Microsoft Press, 2004. — 163 с. — ISBN 073561993X.
  22. Материалы для фасилитации | Москва | FTools
  23. Онлайн-доска Kanban для бизнеса | Программное обеспечение визуального управления проектами | Kanban Tool
  24. Verhov Whiteboards — Маркерные карточки для досок Agile: Scrum, Kanban 4x7
  25. Что такое Скрам — Аджайл для новичков
  26. Критерии приемки для требований в Agile. Devprom ALM. Дата обращения 3 апреля 2016.
  27. Scrum Guide | Scrum Guides. scrumguides.org. Дата обращения 3 июня 2020.
  28. (PDF) Scrum of Scrums Solution for Large Size Teams Using Scrum Methodology
  29. Scrum of Scrums (SoS) Definition | Innolution
  30. Role of a Chief Scrum Master | SCRUMstudy Blog
  31. Endava
  32. 1 2 The Scrum of Scrums meeting — Manifesto
  33. Jeff Sutherland launches the Scrum@Scale Guide | Henny Portman’s Blog
  34. 1 2 3 Scrum Alliance Member-Submitted Informational Articles (недоступная ссылка). Дата обращения 21 октября 2018. Архивировано 21 октября 2018 года.
  35. 1 2 3 4 What is ScrumBut? | Scrum.org
  36. 1 2 ITKaiZenClub «Scrum, but..» или типичные проблемы при внедрении Scrum, 8 февраля | DOU
  37. 1 2 (PDF) Scrum+:: Is it «ScrumBut» or «ScrumAnd»
  38. The Scrum Team and Scrum of Scrums
  39. https://webcache.googleusercontent.com/search?q=cache:xATQq4wnz4wJ:https://www.slideshare.net/xdatap1/agile-organization-with-scrumscale-vimar-spa-a-real-example+&cd=7&hl=ru&ct=clnk&gl=ru&client=opera
  40. 1 2 Agile In Military Hardware. How the SAAB Gripen became the world’s most cost effective military aircraft / Sutherland and Joe Justice, 2017 (англ.)
  41. Scaling Agile Series Part 2: A look at Two of Four Popular Agile Scaling Frameworks: SoS and LeSS — Gorilla Logic
  42. " Ищем гребешок для причесывания Беклога Блог о проактивном бизнесе (недоступная ссылка). Дата обращения 8 декабря 2018. Архивировано 27 декабря 2018 года.
  43. Large-Scale Scrum (LeSS) — Алексей Кривицкий — Agile-коуч и Scrum-тренер
  44. 1 2 3 Как масштабировать Agile? | Открытые системы. СУБД | Издательство «Открытые системы»
  45. Знакомство с LeSS — Large Scale Scrum (LeSS)
  46. LeSS — Scrum на больших масштабах — Блог ScrumTrek
  47. The Nexus Guide | Scrum.org
  48. http://www.disciplinedagiledelivery.com/introduction-to-dad/
  49. Agile project management — the what and the why | APM
  50. Agile project management with Scrum
  51. Архивированная копия (недоступная ссылка). Дата обращения 4 ноября 2018. Архивировано 5 ноября 2018 года.
  52. Scrum of Scrums | Scrum.org
  53. The Nexus Guide | Scrum.org
  54. Certified Scrum Trainer (CST) Certification Application Process
  55. PSD Trainer Selection Process and Application | Scrum.org
  56. PSPO Trainer Selection Process and Application | Scrum.org
  57. PSM Trainer Selection Process and Application | Scrum.org
  58. https://projekter.aau.dk/projekter/files/239952102/Thesis___Final_2016_08_22.pdf
  59. Scrum Alliance Member-Submitted Informational Articles (недоступная ссылка). Дата обращения 21 октября 2018. Архивировано 21 октября 2018 года.

См. также[править | править код]

Ссылки[править | править код]

Литература[править | править код]

  • Хенрик Книберг. 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. — М.: «Вильямс», 2016. — С. 544. — ISBN 978-5-8459-2052-2.