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

Авторы руководства — Кен Швабер и Джефф Сазерленд, которые также являются создателями Scrum.

Назначение руководства по Скраму

Скрам – это фреймворк¹, предназначенный для разработки, поставки и поддержки сложных продуктов. Это Руководство содержит описание Скрама, оно рассказывает о ролях, событиях, артефактах² и правилах фреймворка. Создателями Скрама являются Кен Швабер и Джефф Сазерленд, которым также принадлежит авторство этого Руководства.

¹ Фреймворк — это набор базовых элементов и правил, своего рода каркас, на котором строится процесс разработки (здесь и далее — прим. переводчиков)
² Подробнее об артефактах будет рассказано в разделе «Артефакты скрама»

Определение Скрама

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

Скрам является:

компактным,
простым для понимания,
трудным для совершенного овладения.

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

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

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

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

Применения Скрама

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

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

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

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

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

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

Теория Скрама

Скрам основан на теории эмпирического управления (эмпиризме). Согласно этой теории, источником знаний является опыт, а источником решений – реальные данные.

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

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

Прозрачность

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

Например:

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

⁶ Подробнее о Критериях Готовности будет рассказано в пункте «Критерии готовности»

Инспекция

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

⁷ Подробнее о Цели Спринта будет рассказано в пункте «Цели спринта»

Адаптация

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

Скрам предполагает четыре формальных события для инспекции и адаптации:

Планирование Спринта;
Ежедневный скрам
Обзор спринта
Ретроспектива спринта

Эти события детально рассмотрены в разделе «События Скрама».

Ценности Скрама

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

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

Скрам-команда

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

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

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

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

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

Владелец Продукта – единственный человек, который отвечает за управление Бэклогом Продукта⁸. Управление Бэклогом Продукта включает в себя:

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

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

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

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

⁸ Подробнее о Бэклоге Продукта будет рассказано в пункте «Бэклог Продукта»

Команда разработки

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

Команды Разработки обладают рядом характеристик.

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

Размер команды разработки

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

При подсчете численности Команды Разработки, Владелец Продукта и Скрам-мастер не учитываются, если они сами не выполняют работу из Бэклога Спринта.

Скрам-мастер

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

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

⁹ Кен Бланшар в своей книге “Лидерство к вершинам успеха” ввел термин “лидер-слуга”. Имеется ввиду, что Скрам-мастер не привилегированный носитель власти, как это происходит в случае с классическим менеджментом, а лидер, который вовлекает участников Скрам-команды в процесс работы, не имея формальной власти.

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

Скрам-мастер оказывает Владельцу Продукта следующие услуги:

обеспечивает условия, при которых Скрам-команда как можно лучше понимает цели, объём работ и предметную область;
помогает найти наиболее эффективные техники для управления Бэклогом Продукта;
объясняет Скрам-команде необходимость кратких и понятных Элементов Бэклога Продукта;
объясняет особенности планирования продукта в эмпирической среде;
помогает Владельцу Продукта упорядочить Бэклог Продукта, чтобы получить максимальную ценность продукта;
способствует лучшему пониманию гибкости и её применения;
фасилитирует¹⁰ события Скрама при необходимости.

¹⁰ Фасилитация – это организация процесса групповой работы, направленная на облегчение достижения целей, поставленных группой.

Услуги Скрам-мастера для Команды

Скрам-мастер предоставляет услуги Команде Разработки:

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

¹¹ Коучинг – Международная федерация коучинга (ICF) определяет коучинг как партнерство, стимулирующее работу мысли и креативность клиента, в котором он с помощью коуча максимально раскрывает свой личный и профессиональный потенциал.

Услуги Скрам-мастера для Организации

Скрам-мастер оказывает услуги Организации:

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

События скрама

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

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

Спринт

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

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

Спринт состоит из Планирования Спринта, Ежедневного Скрама, разработки, Обзора Спринта и Ретроспективы Спринта.

Во время Спринта:

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

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

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

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

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

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

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

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

Планирование спринта

Задачи, над которыми будет трудиться Команда Разработки во время Спринта, определяются на Планировании Спринта. План создается совместными усилиями всей Скрам-Команды.

Планирование Спринта ограничено по времени. Для Спринта длительностью один месяц Планирование не должно занимать более 8 часов. Если Спринт короче, то и Планирование проводится быстрее.

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

По результатам Планирования Спринта Скрам-команда решает:

каким будет Инкремент в конце Спринта;
как организовать работу, чтобы получить готовый Инкремент Продукта.

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

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

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

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

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

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

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

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

Команда Разработки самоорганизуется как во время Спринта, так и во время его Планирования при работе над Бэклогом Спринта.

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

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

Цель спринта

Цель Спринта – это установленный для Спринта ориентир, который достигается через выполнение части Бэклога Продукта. Цель Спринта формируется во время его Планирования и объясняет Команде Разработки, для чего создается Инкремент.

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

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

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

Ежедневный скрам

Ежедневный Скрам – это встреча Команды Разработки¹², которая проводится каждый день во время Спринта. Встреча не должна занимать более 15 минут, за которые Команда разработки планирует свою работу на ближайшие 24 часа. Команда оптимизирует взаимодействие между её членами и повышает свою производительность, анализируя сделанное за последние сутки и прогнозируя оставшуюся на этот Спринт работу. Для упрощения Ежедневный Скрам проводится каждый день в одно и то же время.

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

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

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

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

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

Ежедневный Скрам — это внутренняя встреча Команды Разработки. Если на ней присутствует кто-то ещё, Скрам-мастер следит, чтобы они не мешали встрече.

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

¹² Только члены Команды Разработки принимают активное участие в Ежедневном Скраме. Остальные участники Скрам Команды могут присутствовать, однако их участие не обязательно.

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

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

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

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

Ключевые элементы Обзора Спринта:

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

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

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

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

Ретроспектива Спринта проводится после Обзора Спринта и перед Планированием следующего Спринта. Максимальная продолжительность Ретроспективы – 3 часа для Спринта длительностью один месяц. Для более коротких Спринтов, как правило, отводится меньше времени.

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

Цели проведения Ретроспективы Спринта:

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

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

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

Артефакты скрама

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

Бэклог продукта

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

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

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

Каждый элемент Бэклога Продукта должен содержать описание, номер позиции в Бэклоге, оценку объёма работы и ценность. Элементы Бэклога Продукта часто содержат описания тестов, которые позволят убедиться в завершённости Элемента, когда он будет «Готов».

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

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

Уточнение Бэклога Продукта (PBR¹³) – это деятельность, направленная на уточнение, оценку и упорядочивание элементов в Бэклоге Продукта. Речь идет о непрерывном процессе, в рамках которого Владелец Продукта и Команда Разработки обсуждают детали Элементов Бэклога Продукта, тем самым проверяя и пересматривая эти элементы.

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

Элементы вверху списка обычно лучше детализированы, чем элементы внизу. Чем детальнее и яснее описание Элементов Бэклога Продукта, тем точнее может быть их оценка. В свою очередь, чем ниже находятся элементы в Бэклоге Продукта, тем меньше они детализированы. Элементы Бэклога Продукта, которыми будет заниматься Команда Разработки в будущем Спринте, прорабатываются так, чтобы их можно было реализовать за время одного Спринта. Эти элементы считаются “Готовыми”, чтобы быть взятыми в Спринт на Планировании. Такой уровень прозрачности Элементов Бэклога Продукта достигается благодаря процессу Уточнения Бэклога Продукта.

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

¹³ PBR (Product Backlog Refinement) — активность, направленная на совместную проработку Бэклога Продукта.

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

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

Для прогнозирования прогресса могут быть использованы различные практики, например, диаграммы сгорания работ (burn-down), burn-up диаграммы или кумулятивные диаграммы потока. Эти техники полезны, однако они не могут заменить важность эмпиризма. В сложных средах неизвестно, что произойдёт; принятие решений, ориентированных на перспективу, может базироваться только на том, что уже произошло.

Бэклог спринта

Бэклог Спринта — это набор Элементов Бэклога, взятых в Спринт, плюс план по достижению Цели Спринта и поставке Инкремента Продукта.

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

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

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

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

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

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

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

Инкремент

Инкремент — это сумма завершенных во время Спринта Элементов Бэклога Продукта и всех инкрементов предыдущих Спринтов.

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

Прозрачность артефактов

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

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

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

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

Критерии готовности

Когда Элемент Бэклога Продукта или Инкремент описывается как «Готовый», каждый в команде должен понимать, что именно означает «Готовый». Хотя понимание, при каких условиях работа является выполненной, может значительно отличаться от команды к команде, оно должно быть едино для всех участников одной Скрам-команды. Это необходимо для обеспечения прозрачности.

Решение о готовности Инкремента продукта принимается исходя из Критериев Готовности, принятых Скрам-командой. Эти же критерии помогают Команде Разработки во время Планирования Спринта определить, сколько Элементов Бэклога Продукта ей стоит взять в работу.

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

Если в компании принят единый стандарт Критериев Готовности, все Скрам-команды должны ему следовать. В противном случае Команда Разработки должна самостоятельно определить Критерии Готовности, подходящие её продукту. Если над выпуском одной системы или продукта работает несколько Скрам Команд, то их Команды Разработки должны совместно выработать Критерии Готовности.

Каждый Инкремент прибавляется ко всем предыдущим Инкрементам и тщательно тестируется, чтобы убедиться, что все Инкременты работают вместе.

По мере того как Скрам-команда будет становиться более зрелой, Критерии Готовности, скорее всего, будут становиться строже, обеспечивая более высокое качество разрабатываемого продукта. Применение новых критериев может привести к тому, что в уже принятых «Готовых» Инкрементах обнаружится работа, которую необходимо будет выполнить.

Любая система или продукт должны иметь Критерии Готовности, это обязательный стандарт для любой выполняемой работы в рамках этой системы или продукта.

Заключение

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

Благодарности

Личности

Среди тысяч людей, способствовавших развитию Скрама, следует выделить тех, кто внес наиболее весомый вклад на заре его становления: Джефф Сазерленд (Jeff Sutherland) работал с Джеффом МакКенной (Jeff McKenna) и Джоном Скамниоталесом (John Scumniotales); Кен Швабер (Ken Schwaber), работал вместе с Майком Смитом (Mike Smith) и Крисом Мартином (Chris Martin), вместе они работали над созданием Скрама.

В следующие годы многие другие люди внесли свой вклад в развитие Скрама. Без их содействия Скрам вряд ли бы обладал современной степенью проработанности.

История

Кен Швабер и Джефф Сазерленд работали над Скрамом вплоть до 1995 года, когда они выступили с докладом на конференции OOPSLA (Object-Oriented Programming Systems, Languages and Applications). В этом докладе были отражены знания, полученные ими за прошедшие годы, и было впервые дано формальное определение Скрама.

Историю развития Скрама можно прочитать и в других материалах. Здесь же отметим лишь те организации, которые первыми опробовали его и внесли в фреймворк изменения: Individual, Inc., Fidelity Investments и IDX (сегодня — GE Medical).

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

Команда переводчиков

Руководство переведено на русский язык командой переводчиков в составе:

Анна Буракова, Скрам-мастер, аналитик;
Иван Бударин, Владелец Продукта, PSM1, PSPO1;
Михаил Вязанкин, Владелец Продукта, Скрам-мастер, CSM, Agile Coach;
Роман Дорошенко, Владелец Продукта, Скрам-мастер;
Михаил Карасёв, Скрам-мастер;
Марк Качанов, Professional Scrum Trainer (PST), PSM3, PSM2, PSM1;
Сергей Кононенко, Скрам-мастер, PSM1, LCP;
Сергей Лобин, Скрам-мастер, PSM1, SPS;
Люба Мамаева, редактор;
Андрей Павленко, Скрам-консультант, эксперт по трансформации бизнес-процессов;
Илья Павличенко, Скрам-мастер, Professional Scrum Trainer (PST);
Ксения Пантелеева, лингвист-переводчик;
Сергей Пономарев, Скрам-мастер, PSM1, PSPO1, LCP;
Андрей Толмачёв, Скрам-мастер, PSM3, PSM2, PSM1, Agile Coach;
Александр Селяев, Скрам-мастер, PSM1, PSPO1;
Руслан Юсупов, Скрам-мастер, Agile Coach;
Алексей Ян, Скрам-мастер.

Изменения между редакциями Руководства по Скраму 2016 и 2017 годов

1. Добавлен раздел «Применения Скрама».

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

2. Изменен текст в разделе «Скрам-мастер» для более точного описания этой роли. Новая версия:

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

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

3. К разделу «Услуги Скрам-мастера для Владельца Продукта» добавлен текст:

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

4. Обновлен первый параграф раздела «Ежедневный Скрам», теперь он звучит так:

Ежедневный Скрам — это встреча Команды Разработки, которая проводится каждый день во время Спринта. Встреча не должна занимать более 15 минут, за которые Команда разработки планирует свою работу на ближайшие 24 часа. Команда оптимизирует взаимодействие между участниками и повышает свою производительность, анализируя сделанное за последние сутки и прогнозируя оставшуюся на этот Спринт работу. Для упрощения Ежедневный Скрам проводится каждый день в одно и то же время.

5. Чтобы обеспечить ясность целей Ежедневного Скрама, в раздел «Ежедневный Скрам» внесены следующие изменения:

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

6. Уточнения, касающиеся ограничений по времени.

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

7. В раздел «Бэклог Спринта» добавлен текст:

Для обеспечения непрерывного совершенствования Бэклог Спринта содержит по крайней мере одно приоритетное улучшение, выбранное во время предыдущей Ретроспективы Спринта.

8. В раздел «Инкремент» добавлено уточнение:

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

Блог про Скрам

Tехника «5 почему» или как разобраться в любой проблеме?

Пять почему — техника, используемая для изучения причинно-следственных связей, лежащих в основе той или иной проблемы. Идея исследования причинно-следственных связей была выдвинута ещё Сократом. Но сам метод, получивший название «5 почему», был разработан основателем Toyota Сакити Тоёдой (Sakichi Toyoda). Первоначально техника предназначалась для решения производственных задач компании. Задавая вопрос «Почему?» пять раз, вы определяете характер проблемы, решение…

Эффективность неэффективности — Дорофеев Максим

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

Ценообразование в ИТ-разработке: Fixed Price или T&M?

Ценовые модели работы с ИТ-аутсорсерами: T&M, Fixed Price. Когда речь касается разработки и поддержки информационных систем, многие компании предпочитают сотрудничать с внешними партнерами. Это позволяет сэкономить на содержании собственного штата ИT-специалистов, упрощает контроль затрат, обеспечивает их предсказуемость, дает возможность высвободить ресурсы для главных направлений бизнеса, привнести в него новые идеи и технологии. Fixed Price это…

Сторипоинты и идеальные дни — в чем разница при оценке задач в разработке?

В разработке часто встречается путаница при выборе подхода оценки задач — выбирать сторипоинты или идеальные дни? Вводные Надо сказать что эта тема действительно сложная и спорная. Идея оценивать сторипоинты или баллы кажется интересной. Но чтобы она работала нужно чтобы все понимали что это и чтобы в команде сложилась соответствующая культура. Это очень редко бывает. Потому…

Чек-листы в Agile-разработке: DoD, DoR, CoS (AC) & ToDo

В руководстве про Скрам-разработку и просто в статьях о Agile практиках разработки часто встречаются методы чек листов типа DoD, DoR, CoS и ToDo. Давайте разберемся что это такое и как ими пользоваться. DoD – Definition of Done По каким критериям мы можем сказать что задача выполнена (Done)? Критерий готовности инкремента продукта. Также можно сказать что это…

Барабан-буфер-канат (ББК) — из методов ТОС

Барабан-буфер-канат (ББК) (drum-buffer-rope (DBR)) – метод TOC для планирования и управления производством при наличии внутреннего ресурса-ограничения. О применении в ИТ-разработке. Видео по Канбан, Agile & ББК от Максима Дорофеева Веселое, интересное и полезное видео от Максима Дорофеева. Некоторые из цитат выписаны ниже… Четыре основные концепции управления от Ильяху Голдратта Улучшение потока первично, первичная задача руководства, убирать…

Переделанный Волк с Уоллстрит под работу Скрам команды

Шаблон сценария (user story) — популярный подход к описанию задач в SCRUM/Agile

Одна из ключевых проблем в разработке продуктов — взаимопониманием стейкхолдеров и команды, а также всех участников внутри команды. Один из классных подходов с решением проблемы — формат user story. В книге «красный скрам», этот термин переводится как «сценарий». Где каждая задача это сценарий, который может биться на более мелкие сценарии или подзадачи. Сценарии (пользовательские истории,…

Планирование спринтов в разработке с использованием принципа «Полной банки»

Часто встречается проблема понимания как планировать спринты? Или квартальные планы (например OKR). Кто-то думает что надо забивать весь ресурс команды разработки. Но так ли это? Метод Полной банки в планировании спринтов SCRUM Есть такая крутая философская притча про Полную банку. Притча отлично отражает как строятся дела и как лучше планировать спринты в разработке: Цели это…

Something went wrong. Please refresh the page and/or try again.

Руководство по Scrum-разработке

Назначение руководства по Скраму

Определение Скрама

Применения Скрама

Теория Скрама

Ценности Скрама