Комментарии
Официальный перевод от студии Сибирикс — всё, что вы хотели знать о скраме, но ленились изучить самостоятельно
Руководство по скраму
Официальный перевод от студии Сибирикс — всё, что вы хотели знать о скраме, но ленились изучить самостоятельно
Листая наш сайт и блог, вы наверняка натыкались на понятие «скрам». Возможно, даже гуглили, чтобы досконально понять, что это такое. И даже находили сайт с гайдом и его русскую версию 2016 года, вот только бросали на полпути: текст большущий, язык формальный — вникать сложно. Хорошие новости: мы взяли и адаптировали скрамгайд в читаемый формат, снабдив перевод, доступный на русском, дополнениями за 2017 год. Советуем выкроить часок на вдумчивое чтение. Энджой!
Что это
Скрам — фреймворк для разработки, передачи и поддержки сложных продуктов. Он приобрел широкое применение в начале 90-х годов на примере разработки сложных продуктов. Его идейными вдохновителями и создателями стали Кен Швабер и Джеф Сазерленд. Они же являются авторами этого гайда.

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

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

Структура Скрама состоит из команд и связанных с ними ролей, событий, артефактов и правил. Компоненты структуры служат своей цели и имеют значение для успеха и использования скрама. Для них существуют скрам-правила, управляющие их отношениями и взаимодействием.
Использование
(раздел добавлен в 2017 году)

Первоначально Скрам был разработан для управления и разработки продуктов. Начиная с 1990-х годов он широко используется во всем мире для:

  1. Исследования и определения жизнеспособных рынков, технологий и возможностей продукта;

  2. Разработки продуктов и усовершенствований;

  3. Выпуска продуктов и улучшений — по нескольку раз в день;

  4. Разработки и поддержки облачных сред (онлайн, безопасных, по требованию) для использования продукта;

  5. Устойчивости и обновления продуктов.

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

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

Скрам особенно эффективен при итеративном и инкрементальном переносе знаний.

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

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

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

Эмпирическое управление держится на «трех китах»: прозрачности, инспекции и адаптации:

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

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

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

События скрама для инспекции и адаптации:

  • планирование спринта (этапа),

  • ежедневный скрам (стендап),

  • обзор спринта,

  • ретроспектива спринта.
Ценности Скрама
Скрам-команда разделяет и воплощает в жизнь Ценности Скрама:

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

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

Скрам-команда состоит из:

  • Владельца Продукта,
  • Команды Разработки
  • Скрам-мастера.

Скрам-команды — самоорганизующиеся и кроссфункциональные единицы. Они самостоятельно решают, как выполнять свою работу — без внешних указаний. А их компетенций достаточно для выполнения полного объёма работ (всего комплекса работ в сочетании с оптимальным способом их исполнения для реализации бизнес-ценности).

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

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

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

Владелец Продукта — единственный, кто может управлять Бэклогом Продукта (упорядоченным списком всех прогнозируемых задач, хотелок и работ):

  • ясно и понятно описывать элементы Бэклога;
  • упорядочивать элементы — это помогает достичь миссий и целей наиболее эффективно;
  • оптимизировать ценности команды разработки;
  • сделать Бэклог доступным, прозрачным и ясным для всех участников процесса;
  • сделать доступным, прозрачным и ясным объём работ для Скрам-команды;
  • объяснить команде разработки элементы Бэклога Продукта.
Владелец Продукта может делать это сам или делегировать эту работу кому-то из Команды Разработки, но от ответственности за Бэклог ему избавиться не удастся. Владельцем Продукта может быть только один человек, хотя пожелания заинтересованных лиц и групп в Бэклоге отражать ему не запрещается. И да, если нужно поменять приоритеты элементов в Бэклоге — это тоже к нему.

Бэклог с его содержанием и приоритетами элементов отражает решения Владельца Продукта, и все члены организации должны уважать их — иначе эффективной работы не получится. Команда Разработки следует его указаниям и ничьим другим.
Команда Разработки
Те, кто непосредственно создаёт продукт, — профессионалы, готовые показать потенциально готовую к выпуску версию продукта в конце каждого этапа (спринта — временного отрезка не более 1 месяца).

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

Характеристики команд разработки:

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

Кроссфункциональность
Наличие в рамках команды всех необходимых навыков для работы над продуктом. Разработчик — единственная роль в команде, невзирая на тип выполняемых задач. Других ролей Скрам не признает, без всяких исключений.

Отсутствие подкоманд
И неважно, какие области работы: тестирование, дизайн или какой-нибудь бизнес-анализ.

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

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

Скрам-мастер несет ответственность за:

  • должное функционирование скрам-процесса,
  • его понимание всеми членами команды,
  • соблюдение ими теории, правил и практик фреймворка.
Для команды Скрам-мастер — лидер и служитель скрам-процессов и её интересов. Он настраивает наиболее полезные взаимодействия и оптимизирует наименее эффективные процессы.
В Руководстве 2017 года формулировку для скрам-мастера поменяли — для большей ясности его роли
Скрам-мастер отвечает за продвижение и поддержку скрама, помогая членам скрам-команды понять его теорию, практику, правила и ценности.

Скрам-мастер — слуга-лидер Скрам-команды. Он помогает тем, кто не входит в скрам-команду, понять, какое из их взаимодействий со Скрам-командой полезно, а какое нет. Скрам-мастер помогает каждому изменить эти взаимодействия, чтобы максимизировать ценность, созданную командой.
Частый вопрос: является ли менеджер скрам-мастером? В общем случае — нет, не является. В идеале скрам-мастер — это член команды. Однако, на момент формирования команды, когда люди друг к другу не притерлись и никто из разработчиков не умеет работать по scrum, часто роль скрам-мастера достаётся менеджеру. Это не очень хорошо и способствует развитию шизофрении (нужно совмещать в себе несколько плохо совместимых ролей), но тем не менее, в реальности встречается. Правильно в такой ситуации как можно быстрее обучить кого-то из команды следить с процессами по scrum и делегировать ему эту роль и ответственность.

Владимир
Руководитель студии

Услуги Скрам-мастера для Владельца Продукта:

  • помогает найти наиболее эффективные техники для управления Бэклогом,
  • объясняет, как сделать элементы Бэклога краткими и понятными,
  • объясняет, как планировать продукт на основе опыта и восприятия внешней среды,
  • помогает упорядочить бэклог для максимальной ценности продукта,
  • объясняет основы гибкой разработки и их применение,
  • организовывает групповую работу над скрам-событиями при необходимости,
  • обучает и тренирует владельца продукта, команду разработки и организацию,
  • удостоверяется в том, что всем в Скрам-команде понятны цели, область действия и область продукта (пункт добавлен в 2017).


Услуги Скрам-мастера для Команды:
  • обучает самоорганизации и кроссфункциональности,
  • помогает в создании продуктов высокой ценности,
  • устраняет препятствия и внешние отвлекающие факторы, мешающие прогрессу работы,
  • организовывает групповую работу над скрам-событиями при необходимости,
  • обучает в случае неправильного или частичного внедрения Скрама.


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

События специально разработаны для максимальной прозрачности и возможности инспектировать. Отсутствует любое из Событий — снижается прозрачность и теряются возможности для инспекции и адаптации.
Спринт

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

Активности:

  • Планирование Спринта,
  • Ежедневный Скрам,
  • Разработка Продукта,
  • Обзор Спринта,
  • Ретроспективы Спринта.
Изменения допустимы на всех этапах, но цель Спринта неприкосновенна, а качество не должно страдать от изменений. Объём работ также можно регулировать и пересматривать по мере приобретения новых знаний, но только совместно — Владельцем Продукта и Командой Разработки.

Цель Спринта — достигнуть цели (масло масляное, но да), поэтому каждый спринт состоит из:
  • цели,
  • концепции реализации,
  • адаптивного плана по её достижению,
  • работы по её достижению,
  • конечного продукта.

Максимальная продолжительность Спринта — один календарный месяц, поскольку планирование на больший срок повышает риски изменения целей и возникновения сложностей. За счёт такой продолжительности можно ограничить стоимость рисков разработки одним месяцем работы.

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


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

Досрочно Спринт может отменить только Владелец Продукта, но повлиять на это решение могут и Команда Разработки, и Скрам-мастер, и другие заинтересованные лица (скажем, маркетолог заказчика, только вышедший из декрета). Причиной отмены может быть неактуальность цели Спринта: это может произойти в случае смены направления работы компании, изменений рыночных условий или технологии. Грубо говоря, Спринт можно отменить, если он потерял смысл на фоне сложившихся обстоятельств.

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

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

В рамках этого события команда обсуждает объём работ и совместно создает план действий. Планирование Спринта ограничено по времени — максимум 8 часов (при стандартной длительность спринта). Более короткие Спринты предполагают меньше времени на планирование.

По результатам этапа можно понять:

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

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


Тема первая: что будет сделано?

Владелец Продукта выносит на обсуждение два аспекта:
  • бизнес-задачи, которые должны быть достигнуты в спринте;
  • элементы бэклога продукта, необходимые для выполнения Цели спринта.

Команда Разработки на этом этапе прогнозирует объём функциональности для разработки в течение Спринта и формирует единое понимание работы в Спринте на основании:

  • Бэклога продукта,
  • последней версии продукта,
  • прогнозируемой доступности команды в будущем Спринте,
  • статистики прошлой производительности команды.

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

После прогноза Команды Разработки, Скрам-команда формирует Цель Спринта — она служит ориентиром при реализации элементов из Бэклога и даёт понимание Команде Разработки, зачем создаётся продукт.


Тема вторая: как будет выполнена работа?

На этом этапе Команда Разработки решает, как реализовать функциональность готовой версии продукта. Выбранные элементы из Бэклога Продукта и план их реализации формируют Бэклог Спринта.

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

Часто к концу этапа планирования Команда Разработки тщательно детализирует работу, выполняемую в первые дни Спринта: для этого её объём делится на задачи длиною не более 1 дня.

На всех этапах Спринта важна самоорганизация работы команды, чтобы своевременно завершить работу из Бэклога текущего Спринта. Для этого Владелец Продукта может пойти на компромиссы. Например, если объём работ слишком велик, он может разрешить Команде Разработки скорректировать количество и состав выбранных элементов Бэклога Продукта. Весомые отличия запланированных и фактических работ также могут стать поводом для изменений объёма Бэклога Спринта.

Этап планирования завершается, если Команда Разработки может объяснить Владельцу Продукта и Скрам-мастеру, как будет достигнута Цель Спринта и какими способами.


Цель Спринта

Цель Спринта — установленный ориентир, который считается достигнутым, если выполнена нужная часть Бэклога Продукта. Она формулируется во время планирования и объясняет Команде Разработки, для чего создается продукт или его версия. Также Цель связывает элементы Бэклога.
Ежедневный Скрам (стендап)
Ежедневный Скрам — мероприятие не более 15 минут для создания и синхронизации плана работ на ближайшие 24 часа. Начинается с обзора проделанных вчера работ — это помогает прогнозировать объём задач на текущий период. Ежедневный скрам следует проводить в одно и то же время, в одном и том же месте.
В 2017 году абзац обновлён:
Ежедневный Скрам — это 15-минутное мероприятие для команды разработчиков, которое проводится в каждый день Спринта для планирования работы команды разработчиков в течение следующих 24 часов. Оно оптимизирует коллективное сотрудничество и производительность, проверяя выполненную работу с момента последнего Ежедневного Скрама и прогнозируя предстоящую работу по Спринту. Ежедневный Скрам проводится каждый день в одно и то же время, чтобы уменьшить путаницу.

Во время скрам-стендапа каждый участник команды отвечает на вопросы:

  • что я сделал вчера, чтобы помочь команде разработки достичь цели спринта?
  • что я собираюсь сделать сегодня для этого?
  • какие препятствия замедляют достижение цели спринта для меня и для команды разработки?
В 2017 году абзац обновлён:

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

Примеры вопросов, которые можно использовать:

  • что я сделал вчера, что помогло команде разработки достичь Цели Спринта?
  • что я буду делать сегодня, чтобы помочь команде разработки достичь Цели Спринта?
  • я вижу какие-либо препятствия, которые мешают мне или команде разработки выполнить Цель Спринта?
Ежедневный Скрам показывает прогресс выполняемой работы и движения к цели спринта, увеличивая вероятность её достижения.

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

Обязанность Скрам-мастера здесь — убедиться, что Команда Разработки провела Ежедневный Скрам-стендап, хотя ответственность за это несет только сама команда. Главная задача Скрам-мастера — обучить Команду Разработки проводить Ежедневный Скрам за 15 минут или быстрее, и чтобы при этом активными были только члены Команды Разработки. (В руководстве 2017 года здесь и далее более ясно описаны сроки всех мероприятий: применяется фраза «самое большее», чтобы снять любые вопросы о том, что временные рамки означают максимальную длину, но могут быть короче).

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

Обзор Спринта — неформальная встреча, где демонстрируется версия продукта, собирается обратная связь и развивается командное взаимодействие. Стандартное время такой встречи для Спринтов длиною в месяц — 4 часа. Короче Спринт — меньше времени на Обзор.
В Сибирикс при Обзоре Спринта мы укладываемся максимум в два часа, чаще — справляемся за час

Скрам-мастер заботится о понимании цели обзорной встречи и обучает команду укладываться в отведённое время.

Что входит в обзор:

  • Участники встречи: Скрам-команда и приглашенные Владельцем Продукта заинтересованные лица.

  • Владелец Продукта объясняет, что готово и что нет.

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

  • Команда Разработки демонстрирует готовую работу и отвечает на вопросы.

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

  • Все присутствующие обсуждают дальнейшие планы — за счёт обзора появляются ценные данные для следующего Спринта.

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

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


Результат Обзора Спринта — пересмотренный Бэклог Продукта с элементами, которые могут войти в следующий Спринт и которые можно добавить для использования новых бизнес-возможностей.
Ретроспектива Спринта
Ретроспектива Спринта — возможность Скрам-команды исследовать себя и создать план улучшений для следующего Спринта. Проводится после Обзора текущего Спринта и перед планированием нового. Максимальная продолжительность Ретроспективы для стандартного Спринта — 3 часа.
В Сибирикс ретроспектива обычно укладывается в 1 час (в случае, если это не менеджерская ретроспектива)

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

Цели:

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


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

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

Ответственный за Бэклог (его содержание, доступность и упорядочивание элементов) — Владелец Продукта.

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

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

Каждый элемент Бэклога должен содержать описание, номер позиции, оценку объема работы и ценность.

Один продукт — один Бэклог, даже если над созданием версии трудится несколько скрам-команд.


Уточнение Бэклога

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

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

Требования к элементам: в начале списка они должны быть более детализированными и понятными по сравнению с расположенными ниже — подробно описанные элементы проще оценивать.

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


Отслеживание прогресса на пути к цели

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

Для прогнозирования скорости движения к цели можно использовать разные практики — например, burn-up и burn-down диаграммы работ или кумулятивные диаграммы. Эти техники полезны, но не могут заменить важность эмпиризма, поскольку неизвестно, что произойдёт, и для принятия решений можно полагаться лишь на то, что уже случилось.
Бэклог Спринта
Бэклог Спринта — это набор элементов из Бэклога Продукта для исполнения в текущем спринте. Он включает в себя план разработки версии продукта и план достижения Цели Спринта.
В Руководстве 2017 года добавлено: чтобы обеспечить постоянное совершенствование, Бэклог Спринта включает по крайней мере одну задачу из Ретроспективы предыдущего Спринта.
Бэклог Спринта — прогноз Команды Разработки относительно функциональности, следующей версии продукта и весь объём необходимой работы для соответствия Критериям готовности. Это более детальный план, чем Бэклог Продукта, и его прогресс определяется в рамках Ежедневного Скрама (стендапа).

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

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


Отслеживание прогресса спринта

Объем работ в Бэклоге Спринта можно подсчитать в любой момент — отслеживание оставшегося объёма задач помогает Команде Разработки правильно оценить вероятность достижения цели и управлять процессом работ.
Инкремент
Инкремент, или текущая версия продукта, — сумма всех элементов Бэклога Продукта, завершенных во время Спринта, и всех инкрементов из предыдущих Спринтов.
В Руководстве 2017 года добавлено: чтобы обеспечить постоянное совершенствование, Бэклог Спринта включает по крайней мере одну задачу из Ретроспективы предыдущего Спринта.
Попытались сделать яснее, но от этого стало ещё менее понятно. А речь (если мы говорим о разработке ПО) о том, что Инкремент — это, грубо говоря, прирост новых функций и возможностей в нашем программном продукте, относительно предыдущей версии.

Владимир
Руководитель студии
К концу Спринта Инкремент должен быть готов, а значит, должен соответствовать Критериям Готовности Скрам-команды и готовности к использованию — вне зависимости от решения Владельца Продукта выпускать его или повременить.
Прозрачность Артефактов
Скрам опирается на прозрачность.

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

Для этой цели Скрам-мастер исследует Артефакты, находит повторяющиеся шаблоны, определяет разницу между ожидаемым и полученным результатом. Также помогает анализ ранее озвученной информации от вовлеченных в процесс сторон.
Критерии Готовности
Различные Скрам-команды могут отличаться определением состояния готовности, но участники каждой команды должны понимать общее значение выполненной работы. Понимание значения работы способствует прозрачности и помогает принимать готовую работу над версией продукта. Оно же помогает Команде Разработки понять, какие элементы из Бэклога Продукта стоит взять в Спринт.

Все Скрам-команды в организации должны следовать единым Критериям Готовности, описанным во внутренних соглашениях, стандартах или рекомендациях. Если их нет, Команда Разработки определяет собственные критерии, которые могут дополняться и ужесточаться для лучшего результата по мере развития самого продукта и команды. Особенно важно иметь общие понятия о готовности продукта, когда над его выпуском трудится несколько Скрам-команд.
Финальная нота
Скрам бесплатен и распространяется свободно, в том числе через этот гайд. Роли, события, артефакты и правила Скрама неизменны. Можно реализовывать его частично, но это уже нельзя будет назвать Скрамом как таковым. Он существует только во всей полноте и функционирует как контейнер для других методов, методологий и практик.